How To Write A SQL Server Performance Review

2,978 views
2,776 views

Published on

Learn how to write a report that managers and developers will love. Use Perfmon and Profiler to document your application's bottlenecks, and turn those into a reader-friendly report.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,978
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
132
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

How To Write A SQL Server Performance Review

  1. 1. How to Write a SQL Server Performance Review Brent Ozar, SQL Server Expert for Quest Software http://flickr.com/photos/sean002/2510541359/ Photo Licensed with Creative Commons Copyright © 2007 Quest Software
  2. 2. What The Heck Do I Know? • SQL Server Expert for Quest Software • Former SQL DBA, SAN admin, VMware admin • Recovering ASP coder • Specializes in performance tuning • Came up through management, not IT
  3. 3. Today’s Agenda • The Deliverable • Gathering The Data • Finding the Problems • Mitigating the Problems • Writing the Report • Resources and Q&A
  4. 4. The Deliverable: A Report
  5. 5. Key Parts of Our Review • Capture objective, definitive and credible metrics • Analyze problems causing bad metrics • List of ways we could mitigate each problem
  6. 6. Definitive Metrics • Start with Perfmon: www.BrentOzar.com/perfmon • Gather for longest time possible • Check results daily to refine metrics
  7. 7. Tracing the Problems • Focus the trace on the problem statistics (CPU, reads, writes) • Filter duration > 2000ms at first • Refine duration filter down over time • Put results in a different SQL Server – Very fast server, faster than what you’re tracing – Write into a simple mode database, no backups
  8. 8. Querying the Trace Table
  9. 9. ORDER BY Duration DESC
  10. 10. Casting and Grouping
  11. 11. Correlate the Metrics & Queries • Demonstrate good investigation skills • Show a cause and effect relationship • Fields to mentally “join” on: – Date/Time ranges – CPU – Reads/Writes – Duration
  12. 12. DO NOT FIX ANYTHING YET! • No matter how easy it looks • No matter whose fault it is • You have to show fruits from your labor • We want clear before & after snapshots • Worst thing we can tell our bosses: “It’s OK now. I didn’t change much.”
  13. 13. Mitigations For Each Problem Photo From:http://flickr.com/photos/sneakums/1345233680/
  14. 14. A Problem Has Many Mitigations • EVERY problem has multiple choices: – Money – Time – Manpower • Go out of your way to identify all of them
  15. 15. Explain Mitigations That Suck • Shows you know about the option • May come in handy for another problem • Explain why it doesn’t work in this case • Displays wise decision-making • The PM may know something you don’t
  16. 16. Be Willing To Implement Them Photo From: http://flickr.com/photos/ninjapoodles/1130650313/
  17. 17. Sample Problem • Metric: – Very high disk queue lengths on data file drive • Trace tells us: – Report queries doing table scans without indexes – Many scheduled reports run simultaneously
  18. 18. Ways We Can Mitigate It • Add indexes • Run reports serially, not all at once • Add hard drives to the data file array • Add memory to cache scanned tables
  19. 19. Percent vs Order of Magnitude • Incremental (Percentage): – Any improvement from 1% to 100%. • Order of Magnitude: – Any improvement over 100% faster. • How to explain it in your doc: – This mitigation should give an incremental (percentage) improvement. – This mitigation should give an order of magnitude improvement.
  20. 20. How To Explain It To Readers In this performance review, I classify mitigations as giving us a Percentage Improvement (meaning 1- 100% faster) or an Order of Magnitude Improvement (meaning over 100% faster). In addition, because we’re talking about making multiple improvements simultaneously across different parts of the app and server, it’s hard to give exact numbers when one improvement might impact another area. A new index or server configuration change might improve performance for more than just one query or process.
  21. 21. This Is How DBAs Write:
  22. 22. Use A Different Way of Writing • Be friendly and upbeat – ideas at: http://delicious.com/brento/powerpoint • Document like a consultant • Write like you’re an outsider looking in • Create clear, concise steps that managers can assign to people
  23. 23. Don’t Point Fingers
  24. 24. Goal: Progress, Not Debating
  25. 25. Moving Your Career Forward
  26. 26. Your Target Reader… • Reads Fortune, not SQL Magazine • Doesn’t understand indexes or locks • Wants answers, not questions • Only reads the section headers
  27. 27. The Executive Summary
  28. 28. (Bunch of stuff here clipped out)
  29. 29. Wrapping It Up • Gather data with Profiler &Perfmon • Analyze the queries like it’s BI • Make a list of mitigation options • Write an upbeat, positive report • Aim for forwards, not replies • Save your reports for raise time!
  30. 30. My Resources, Your Questions • My blog about SQL and performance: www.BrentOzar.com www.BrentOzar.com/perfreport • My bookmarks: Delicious.com/brento • SQL Server community w/expert Q&A: SQLServerPedia.com • Performance tools for a second opinion: www.Quest.com

×