March 7, 2011 at 12:00 am
Comments posted to this topic are about the item SQLServerCentral Best Practices Clinic: Part 1
Brad M. McGehee
DBA
March 7, 2011 at 8:55 am
Please add your feedback below about the SSC server configuration. SQL Monitor on the two clustered nodes has been upgraded to Version 2.2, the latest release of SQL Monitor.
Brad M. McGehee
DBA
March 7, 2011 at 8:58 am
One quick note: we use Standard Edition.
I was hoping to use Resource Governor to tune the newsletter load and limit the impact of that process on our servers, but it's not available in Standard or Workgroup editions.
March 7, 2011 at 9:07 am
several of your databases are set to auto grow the data file in increments of 1mb. I wouldn't use that setting for any database, i prefer to use percentages, usually 10%. It really doesn't make sense though for the SQLServerCentral database, due to its larger size.
March 7, 2011 at 9:34 am
Chris Golla (3/7/2011)
several of your databases are set to auto grow the data file in increments of 1mb. I wouldn't use that setting for any database, i prefer to use percentages, usually 10%. It really doesn't make sense though for the SQLServerCentral database, due to its larger size.
I agree that the default value of 1MB autogrowth is a poor choice, but I prefer to use a larger fixed amount rather than a percentage, as percentages don't always act as you expect. For example, if I set a percentage of 10%, 10% of 1GB is a lot different of 10% of 1TB. Thus, I prefer to pick a fixed amount that makes sense for the existing size of the database. Ideally though, I prefer to proactively manage the size my MDFs and LDFs so that autogrowth doesn't have to kick in at all. I prefer to use autogrowth only to cover unexpected growth spurts I had not planned on.
Brad M. McGehee
DBA
March 7, 2011 at 9:43 am
The main interesting thing I saw is that you are on Build 2714, which is fairly old (SP1 CU2). I would want to get SP2 CU2, Build 4272 installed. If you could run my full set of diagnostic queries, I would know a lot more...
Do you have "Optimize for ad-hoc workloads" enabled for the instance?
March 7, 2011 at 9:58 am
GlennBerry (3/7/2011)
The main interesting thing I saw is that you are on Build 2714, which is fairly old (SP1 CU2). I would want to get SP2 CU2, Build 4272 installed. If you could run my full set of diagnostic queries, I would know a lot more...Do you have "Optimize for ad-hoc workloads" enabled for the instance?
In this installement, we are only focusing on the properties revealed by SQL Monitor. I think running your diagnostic queries would work great for another part of this article series. I'll get back with you when we are ready to do this.
Brad M. McGehee
DBA
March 7, 2011 at 10:59 am
It seems like you are getting regular CPU spikes to 100% every night at about midnight. Is that when your full backups occur? Are you using 3rd party backup compression that has an adjustable compression ratio?
It seems like your page splits are a little high at the instance level.
March 7, 2011 at 7:08 pm
Besides the obvious filegrowth setting issues mentioned previously, one thing I found was there was not much use of filegroups. One of the things I like to do is have all of my nonclustered indexes on a separate filegroup that is located on a different I/O path.
March 8, 2011 at 7:51 am
tgarland (3/7/2011)
Besides the obvious filegrowth setting issues mentioned previously, one thing I found was there was not much use of filegroups. One of the things I like to do is have all of my nonclustered indexes on a separate filegroup that is located on a different I/O path.
Good point. This option wasn't chosen for two reasons. First, the servers are hosted, and our I/O options weren't wide. Second, the activity on the server is not really that great, relatively speaking, necessitating the need for such tweaking. Of course, there are other performance issues, but separating the nonclustered indexes wouldn't have helped much to alleviate them. We will talk about what is causing the performance problems in a later article.
Brad M. McGehee
DBA
March 8, 2011 at 8:46 am
tgarland (3/7/2011)
Besides the obvious filegrowth setting issues mentioned previously, one thing I found was there was not much use of filegroups. One of the things I like to do is have all of my nonclustered indexes on a separate filegroup that is located on a different I/O path.
To follow on from Brad, we also have cost constraints, as do many other companies. Getting additional drive paths in this hosted environment was outside our budget. We could potentially argue for it, but as Brad mentioned, not sure there is a need for this.
However planning for the future makes some sense. Perhaps Brad, Grant, and I will consider this as a way to plan for future growth and pre-separate things so that a quick alter would allow us to take advantage of a new array.
March 9, 2011 at 10:55 am
tgarland (3/7/2011)
Besides the obvious filegrowth setting issues mentioned previously, one thing I found was there was not much use of filegroups. One of the things I like to do is have all of my nonclustered indexes on a separate filegroup that is located on a different I/O path.
That is a good suggestion. I know we're not talking about performance bottlenecks at this point, but keep an eye out for any indications of I/O loading since something like this could help.
Did you see any issues with any of the other properties?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 9, 2011 at 11:13 am
I quickly reviewed a bunch of stuff and have some notes, though I won't go into detail as I have limited time:
Review both instances for updating to the most current SQL Server SP, and possibly CU.
Instance 1:
A lot of growth rates are 10% or 1MB (Review and set for each DB/file)
SQLServerCentral_Data file is limited to 10,000.0 MB and it is over 50% of that size, is that limit what you want?
tempDB: Has testing indicated that you actually need 8 data files?
ips_notifications_log size: 0.0MB?
Instance 2:
tempDB: Has testing indicated that you actually need 8 data files?
Simple-Talk DB: Compatibility level: 80 (Is that needed?)
Simple-Talk_Log Size: 12,908.0 (4x the size of the data file?)
apps_excuse DB: Compatibility level: 80 (Is that needed?), change page_verify to CHECKSUM
apps_prettifier DB: Compatibility level: 80 (Is that needed?), change page_verify to CHECKSUM
sqlMonitor22 DB: autogrowth: 1GB, log size: 46GB? (Almost 8x the size of the data file?)
March 9, 2011 at 12:08 pm
since for now we are at instance level, I would expect exposure of sys.configurations but I seem not to be able to find it using the product.
Interesting project tough:
1) to be able so see how things are at other locations
2) to see how best practices match setup and impact after modifications
3) nice product promotion.
For RedGate probably the other way around 😉
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
March 9, 2011 at 12:39 pm
I noticed the same things that others have mentioned: file growths and sizes, tempdb, filegroups...
I have always been advised to use a set size, rather than percentage, for file growth. I have participated in a Microsoft SQL Server RAP, and they advised us to do things in increments of 1024MB.
So I set all all my file growths and sizes in multiples of 1024M.
I realize you wanted us to focus on settings we can see from the monitoring tool, but I am curious about instant file initialization, ad-hoc optimization, asynchronous update stats, etc.
Is there a way to customize what the tool shows you?
Regarding TempDB and the number of files, I was not able to find how many cores are on the servers.
What about separating TempDB MDF and LDF?
Also regarding separate filegroups for non-clustered indexes. In addition to the possible IO related benefits, I find that there are several administrative benefits, as well. For example, you then have more flexibility in where you locate your files, you can take filegroup backups, you can do filegroup dbcc checkdb commands, etc.
The forums database seems to be using full text filegroups. What about locating them on a separate file system from the regular data files?
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply