With the 2014 Winter Olympics only days away, we thought it would be a good time to pass on some podium worthy SQL tips that can help professionals address the myriad challenges involved with performance optimization. Gold Medal Tip # 1: Benchmark and Analyze Your Data Establish a performance baseline – Talk to system administrators, end users, and application administrators to get a good feel for what usage patterns are (peak-period, off hours, and average use). The more predictable your load patterns, the less data you will require. Consider the capacity required to store your measurement data and extrapolate the extent to which this repository will grow overtime. If you are monitoring over an extended time period, consider aggregating historical data at intervals. For better performance, your measurement repository should not reside in the same place as the database you are monitoring. Limit the number of changes you make between each benchmark run. Test one hypothesis at a time, allowing you to rule out each improvement method. Honing in on each change provides details as to why you are seeing the change in behavior, revealing additional improvement options. Repeat the measurements (and timeline) you took for your original baseline then compare the two. Did your changes have the desired effect? Did any changes result in unexpected side effects? A baseline enables you to objectively determine whether or not you have made progress. Establishing accurate performance norms against typical conditions enable you to predict performance issues in future scenarios. For example, you perform capacity planning by extrapolating from current typical resource consumption per connected user, and predict when your systems will hit user connection bottlenecks. Have you ever spent several long days and nights fire-fighting a performance issue with your database only to find it was actually nothing to do with the database itself? Ruling out the things that are not responsible can help you troubleshoot problems more effectively. Once the usual suspects are ruled out, you can now begin to search for significant deviations from baseline, collect related indicators together, and begin to drill into the root cause. Gold Medal Tip # 2: Find the Rogue Query Once you have identified a bottleneck, you need to find the workload that is causing it. This is a lot easier to do since the introduction of Dynamic Management Objects (DMOs) in SQL Server 2005. For a CPU bottleneck, the first thing that you would want to do is get the top CPU consumers on the server. This is a very simple query on sys.dm_exec_ query_stats: The really useful part of this query is your ability to use cross apply and sys.dm_ exec_sql_text to get the SQL statement, so you can analyze it. For an I/O bottleneck, it is a similar story: Gold Medal Tip #3: Utilize SQL Server Profiler SQL Server Profiler allows you to create a trace file that captures events occurring in SQL Server – proving invaluable in providing information about your workload and poorly performing queries. View a video tutorial on SQL Server Profiler on Toad World. Note – running Profiler requires the ALTER TRACE permission. While it is true that SQL Server Profiler has been marked as deprecated in SQL Server 2012 in favor of Extended Events, it should be noted that this is just for the database engine and not for SQL Server Analysis Services. Profiler can still provide great insight into the working of applications in real time for many SQL Server environments. Here’s how to build on the process of collecting data in Performance Monitor (Perfmon) and correlate the information on resource usage with data on the events being fired inside SQL Server: 1. Open Perfmon. 2. If you do not have a Data Collector set already configured, create one now using this tip as a guide. Do not start the data collector set yet. 3. Open Profiler. 4. Create a new trace by specifying details about the instance, events, and columns you want to monitor, as well as the destination. 5. Start the trace. 6. Switch back to Perfmon to start the data collector set. 7. Leave both sessions running until the required data has been captured. 8. Stop the Profiler trace. Save the trace and then close it. 9. Switch to Perfmon and stop the data collection set. 10. Open the recently saved trace file in Profiler. 11. Click File and then Import Performance Data. 12. Navigate to the Data Collection data file and select the performance counters of interest. You will now be able to see the performance counters in conjunction with the Profiler trace file (see figure below), which will enable a much faster resolution of bottlenecks. Extra tip: The steps above use the client interface; to save resources, a server-side trace would be more efficient. Please refer to Books Online for information about how to start and stop server-side traces. SQL Server experts Patrick O’Keeffe and Richard Douglas co-authored the “ Ten Tips for Optimizing SQL Server Performance ” white paper. While there is no definitive “10 best” list for SQL Server performance tips, you can’t go wrong by starting with these suggestions, which offer DBAs and others detailed information on specific issues and ways to apply them to their environment
↧