SQLServerCentral / Article Discussions / Article Discussions by Author / Discuss content posted by Brad M. McGehee / SQLServerCentral Best Practices Clinic: Part 1 / Latest Posts

RE: SQLServerCentral Best Practices Clinic: Part 1

Peter Trast — Wed, 11 May 2011 07:57:59 GMT

I noticed when I first opened the tool that the INS1 page splits ratio to batch requests was running close to 20%, pushing the limits for my preferences, although it dropped back to about 10% after I started going back to check on it.I normally have several more memory counters, too. I am guessing that you don't look at Page Lookups/sec because you have close to zero adhoc access to the data and are not worried about poorly performing queries?Pages Reads/sec and writes/sec not being used because you know that your indexing is already as good as it can be? (or plenty of memory?)It's a nice tool, though.

RE: SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Thu, 24 Mar 2011 14:21:41 GMT

[quote][b]Steven O (3/9/2011)[/b][hr]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?[/quote]The server has Dual Quad Core Xeon L5520 (2.66GHz) CPUs, for a total of eight cores.MDFs and LDFs are on separate RAID 10 arrays. Tempdb is also on its own array. The arrays are part of a SAN where we have 20 dedicated disks.Later in the series, I will go review the rest of the settings you asked about.

RE: SQLServerCentral Best Practices Clinic: Part 1

newsqldba — Thu, 24 Mar 2011 14:18:17 GMT

Can you tell us more about the hardware configuration?

RE: SQLServerCentral Best Practices Clinic: Part 1

tgarland — Wed, 09 Mar 2011 13:08:18 GMT

I also noticed that there are a lot of unlimited max file size settings for the databases. I personally prefer to set those limits to something reasonable and monitor the filegrowth and adjust them accordingly.

RE: SQLServerCentral Best Practices Clinic: Part 1

tgarland — Wed, 09 Mar 2011 12:59:18 GMT

One of the other things I noticed was that the collations are different for some of the databases. SQLServerCentral, as well as others, use Latin1_General_CI_AS as where some of the others use SQL_Latin1_General_CI_AS like CommunityServer and SQLServerCentralForums.

RE: SQLServerCentral Best Practices Clinic: Part 1

Steve Jones - SSC Editor — Wed, 09 Mar 2011 12:50:43 GMT

We see two quad core processors in the VM. (8 virtual CPUs)

RE: SQLServerCentral Best Practices Clinic: Part 1

Steven O — Wed, 09 Mar 2011 12:39:10 GMT

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?

RE: SQLServerCentral Best Practices Clinic: Part 1

ALZDBA — Wed, 09 Mar 2011 12:08:19 GMT

since for now we are at instance level, I would expect exposure of [b]sys.configurations[/b] 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 locations2) to see how best practices match setup and impact after modifications3) nice product promotion.For RedGate probably the other way around ;-)

RE: SQLServerCentral Best Practices Clinic: Part 1

UMG Developer — Wed, 09 Mar 2011 11:13:02 GMT

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 CHECKSUMapps_prettifier DB: Compatibility level: 80 (Is that needed?), change page_verify to CHECKSUMsqlMonitor22 DB: autogrowth: 1GB, log size: 46GB? (Almost 8x the size of the data file?)

RE: SQLServerCentral Best Practices Clinic: Part 1

Grant Fritchey — Wed, 09 Mar 2011 10:55:36 GMT

RE: SQLServerCentral Best Practices Clinic: Part 1

Steve Jones - SSC Editor — Tue, 08 Mar 2011 08:46:31 GMT

[quote][b]tgarland (3/7/2011)[/b][hr]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.[/quote]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.

RE: SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Tue, 08 Mar 2011 07:51:04 GMT

[quote][b]tgarland (3/7/2011)[/b][hr]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.[/quote]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.

RE: SQLServerCentral Best Practices Clinic: Part 1

tgarland — Mon, 07 Mar 2011 19:08:19 GMT

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.

RE: SQLServerCentral Best Practices Clinic: Part 1

GlennBerry — Mon, 07 Mar 2011 10:59:51 GMT

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.

RE: SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Mon, 07 Mar 2011 09:58:32 GMT

[quote][b]GlennBerry (3/7/2011)[/b][hr]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?[/quote]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.

RE: SQLServerCentral Best Practices Clinic: Part 1

GlennBerry — Mon, 07 Mar 2011 09:43:47 GMT

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?

RE: SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Mon, 07 Mar 2011 09:34:50 GMT

[quote][b]Chris Golla (3/7/2011)[/b][hr]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.[/quote]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.

RE: SQLServerCentral Best Practices Clinic: Part 1

Chris Golla — Mon, 07 Mar 2011 09:07:45 GMT

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.

RE: SQLServerCentral Best Practices Clinic: Part 1

Steve Jones - SSC Editor — Mon, 07 Mar 2011 08:58:17 GMT

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.

RE: SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Mon, 07 Mar 2011 08:55:53 GMT

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.

SQLServerCentral Best Practices Clinic: Part 1

bradmcgehee@hotmail.com — Mon, 07 Mar 2011 00:00:17 GMT

Comments posted to this topic are about the item [B]SQLServerCentral Best Practices Clinic: Part 1[/B]