The Omedian Technical Architecture - Red Gate Software

More documents

Recommendations

Info

Page 57 of 90Chapter 7: SQL Server Performance Crib SheetBuffer Cache Hit RatioFirst off, the Buffer Cache Hit Ratio, located in the Buffer Manager, will show what percentages of pages werefound in memory, thereby avoiding a disk read. In this instance, higher is better. Under most circumstances, witha well configured machine, you should see a buffer cache hit ratio above 90% and probably average over 95%.Lower numbers indicate a lot of disk reads which will slow things down.Full Scans/SecNext, as a general measure of health, it's good to look at the Full Scans/Sec counter in Access Methods. This isbasically the number of table or index scans that the system is experiencing. A high number here shows eitherpoorly written stored procedures or bad indexing. Either way, you need to get to work identifying the source ofthe problem.Lock Requests/SecUnder Locks the Lock Requests/Sec counter can show the number of new locks and lock conversions that aretaking place on the system. This counter can be general, showing Total Locks, or it can get extremely specific,counting row ID locks (RID) in 2005 or key, file & page locks in both SQL Server 2000 & 2005. While highernumbers may be bad, depending on the circumstances, they may also be an indicator of just a lot of use on thesystem. If this number is spiking or growing over time, you will need to pursue more details to ascertain whetheror not you have a problem.Deadlock/SecAlso under Locks, you may want to put the Deadlock/Sec counter on if you're experiencing deadlocks.Deadlocks, by their very nature are indicative of performance problems that require, at the least, procedure tuningand review, and a check on the indexes of a machine. Other steps may be required.User ConnectionsNot actually an indicator, but a very useful measure in combination with all the other counters, is the UserConnections counter under General Statistics. It's not that this number will necessarily indicate a problem onyour server, but it helps in conjunction with the other counters to identify where real problems exist. Forexample, say you have a larger than normal number of locks. Check the number of user connections. If it's higherthan normal, then you're probably just experiencing a spike in usage, but if it's average or below average, then youmay have a problem and it's time for more detailed investigation.Batch Requests/SecThe last general measure is Batch Requests/Sec under SQL Statistics. This measure quite simply is the number ofrequests coming in to the server. This is a very general number and may be indicative of nothing more than highuse, but it's a good value to track over time because it can show you how your system use is scaling. It can also beused to indicate when you have peaks and valleys in the number of user requests on the system.The counters outlined above are only the beginning of the metrics you can use to get a general measure of systemperformance. Other available counters will enable you to drill down into specifics within SQL Server or theserver itself. After determining what the OS and the Server are up to, you will need to look inside at what thequeries are doing. This is where Profiler comes into play.ProfilerProfiler can run, similarly to Performance Monitor, either in a GUI mode or in an automated manner withoutputs to files or databases. Sitting and watching the GUI window is usually referred to as SQL-TV. That maybe a good way to spot-check issues on a database server, or do some ad hoc troubleshooting, but for realperformance monitoring you need to set up an automated process and capture the data for processing later.Profiler collects information on events within SQL Server. The broad categories of events are as follows:Page 57Chapter 7: SQL Server Performance Crib Sheet
Page 58 of 90Chapter 7: SQL Server Performance Crib Sheet• Cursors• Database• Errors and Warnings• Locks• Objects• Performance• Scans• Security Audit• Server• Sessions• Stored Procedures• TSQL• TransactionsKey EventsEach of these categories has a large number of events within it. Rather than detail all the various options, thefollowing is a minimum set of events for capturing basic TSQL performance.Stored Procedures – RPC:CompletedThis records the end point of a remote procedure call (RPC). These are the morecommon events you'll see when an application is running against your database.Stored Procedures – SP:CompletedThese would be calls against procedures from the system itself, meaning you'velogged into SQL Server and you're calling procedures through query analyzer, or theserver is calling itself from a SQL Agent process.TSQL – SQL Batch:CompletedThese events are registered by TSQL statements running locally against the serverwhich is not the same as a stored procedure call, for example: SELECT * FROMtablename.Data ColumnsEach of these events can then collect a large number of columns of information, each one may or may not becollected from a given event, depending on the event and column in question and each one may collect differentdata from the event, again depending on the event and column in question. These columns include but are notlimited to:TextDataApplicationNameLoginNameCPUReadsIn the events listed above this column represents the text of the stored procedurecall, including the parameters used for the individual call, or the SQL batchstatement executed.This may or may not be filled in, depending on the connections string used by thecalling application. In order to facilitate trouble shooting and performance tuning,it's worth making it a standard within your organization to require this as part of theconnection from any application.The NT domain and user name that executed the procedure or SQL batchThis is an actual measure of CPU time, expressed in milliseconds, used by the eventin question.These are the count of read operations against the logical disk made by the eventbeing captured.Page 58Chapter 7: SQL Server Performance Crib Sheet
Page 1 and 2:
The Best of Simple TalkSQL ServerCr
Page 3 and 4:
Page 2 of 90Table of ContentsTuning
Page 5 and 6:
Page 4 of 90AuthorsAuthorsAmirthali
Page 7: Page 6 of 90Chapter 1: SQL Server S
Page 10 and 11: Page 9 of 90Chapter 1: SQL Server S
Page 12 and 13: Page 11 of 90Chapter 2: SQL Server
Page 20 and 21: Page 19 of 90Chapter 3: Reporting S
Page 22 and 23: Page 21 of 90Chapter 3: Reporting S
Page 24 and 25: Page 23 of 90Chapter 4: SSIS 2008 C
Page 72 and 73: Page 71 of 90Chapter 9: Entity Fram
Page 84 and 85: Page 83 of 90Chapter 10: .NET perfo
show all

The Omedian Technical Architecture - Red Gate Software

Create successful ePaper yourself

Delete template?

Save as template?