This will leave the trace returning all the statements that are executed against the SQL Server instance see Figure 10.13.. When you run the SQL Profiler Trace by clicking the Run button
Trang 1You can turn off the events in the Security Audit and Sessions sections
by unchecking their respective check boxes You can also uncheck the
SQL:BatchStarting event because it only shows when commands are started not when they are completed You will also want to check the box in the TextData column for the RPC:Completed event This will leave the trace returning all the statements that are executed against the SQL Server instance (see Figure 10.13)
Figure 10.12 Default SQL Profiler Event Selection
Trang 2When you run the SQL Profiler Trace by clicking the Run button, every
statement being executed against the database instance is returned to the SQL
Profiler application If you are monitoring a high load database server, this will
quickly become more data than you can sift through You can reduce the amount
of data by clicking the Column Filters button This allows you to return only
certain rows back to the client
By setting the trace to be filtered against the Duration column, you will see all
statements executed against the database that take over 2.5 seconds (2500 milliseconds)
to complete (see Figure 10.14) If this trace returns too much data, you can stop it,
change the filter to a higher number, and then run it again
Figure 10.13 SQL Profiler Event Selection
Trang 3Next, begin performance tuning the queries by looking at your indexes and execution plans As you can see in Figure 10.15, it becomes easy to identify which queries are long running and need to be tuned
Figure 10.15 SQL Server Profiler Showing Long Running Queries
Figure 10.14 SQL Profiler Trace Set to
Return Queries That Run for Longer Than 2.5 Seconds
Trang 4Performance Monitor
The Performance Monitor includes hundreds of performance counters related
directly to the performance of the SQL Server instance Like the SQL Server
Profiler, you have to know which counters to look at depending on the data you
wish to see
If you want to look at memory issues, some counters to monitor are found
under the SQLServer:Buffer Manager group The buffer cache hit ratio and page
life expectancy tells you how long the data is staying in the buffer cache and what
the odds are that SQL Server will be able to find the data in memory The higher
the buffer cache hit ratio and page life expectancy, the better the chances that SQL
Server will be able to find what it is looking for in RAM and will not need to read
data from the disk The less SQL Server needs to go to the disk, the better it will
perform Because the page life expediency data is in seconds, you may need to
divide the value by 60 (for minutes) or 3600 (for hours)
TEsT Day Tip
When using SQL Server Profiler, remember that times filters are done in
milliseconds, not seconds, for greater control.
Exam Warning
SQL Server 2008 has many new performance monitor objects While
not all of them are covered here specifically, you should familiarize
yourself with them.
For disk issues, you can look at the physical disk counters Some counters that
give you the best insight are the following:
current disks queue
■
■
avg disk sec / read
■
■
avg disk sec / write
■
■
disk read / sec
■
■
disk write / sec
■
■
Trang 5The current disks queue counter records the number of operations currently queued and waiting for disks to become available The avg disk sec / read and / write
tell you how long it’s taking disks to respond to each operation This number is critical to the health of your SQL Server Any number over 01 seconds per operation
is going to show as higher than normal CPU load and waits within the SQL Server The read and write operations-per-second numbers tell you how much load is being placed on the disks by SQL Server and other operations If the operations-per-second number is low and the seconds-per-operation number is high, you may have a disk performance issue that needs to be addressed
If you think that another application on the server is causing high disk IO, you can use performance monitoring to look that data as well Under the Process group, you’ll find several counters including the IO Data Operations / sec counter You can then select the application you think is causing the problem, as well as the SQL Server process, to see which is taking the IO You can also add in all your applications
to see which ones are taking the IO load
TEsT Day Tip
There are many performance monitor counters with similar names Pay
careful attention when the exam refers to the avg disk sec / read and disk reads / sec counters, for example, since these two counters have very
different meanings.
noTE
Performance monitoring data can be scheduled and saved into a
text file or database.
When you are monitoring backup jobs, throughput to your backup devices is very important However, monitoring the number of IOs per second doesn’t give you a true idea of how fast your backup is taking In addition, you also need to subtract the IO of anything else writing to the disk Because of this, Microsoft has included the SQL Server:Backup Device counter, which has the Device Throughput Bytes / sec Doing some math will give you the throughput in kilobytes or mega-bytes per second