The Day After Tomorrow; why you need to baseline - PASS SQL Rally Nordic - 2013

540 views

Published on

Presentation by Richard Douglas - @SQLRich - on baselining a SQL Server environment from the PASS SQL Rally conference held in Stockholm 2013.

Abstract:
Ensuring peak SQL Server performance isn’t always easy and requires a lot of work on the part of the DBA. To maintain the best-possible performance, you need to make sure you’re monitoring the right things. But how do you know if the figures you’re seeing are good or bad? Baseline comparisons can help, and in this educational session, SQL Server expert Richard Douglas will show you how to get the most from them. Richard will explain what a baseline is, why and when you need to take one, and how you can create one. You’ll also learn about a number of native Windows and SQL Server tools that will allow you to do just that.

Read more: Presentations - 2013 | Richard Douglas - SQL Server Professional http://sql.richarddouglas.co.uk/presentations/presentations-2013#ixzz2kcBNBxMK

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

  • Be the first to like this

No Downloads
Views
Total views
540
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Day After Tomorrow; why you need to baseline - PASS SQL Rally Nordic - 2013

  1. 1. “The Day After Tomorrow”; why you need to baseline Richard Douglas Dell Software
  2. 2. Who’s this guy? • • • • • • • Richard Douglas Editor in Chief – ToadWorld.com MCITPro Maidenhead PASS Chapter Leader Blog: http://SQL.RichardDouglas.co.uk Twitter: @SQLRich Email: Richard.Douglas@Software.dell.com
  3. 3. Agenda • • • • • • What is a “baseline”? What is “benchmarking”? Where do I start? What should I capture? What should I capture it with? Summary
  4. 4. What is a “baseline”? • Typical state • Average over a time period • Multiple baselines Why baseline? • Line in the sand • Usage patterns A measurement or calculation used as a basis for comparison.
  5. 5. What is “benchmarking”? A level by which something can be measured or judged Allows you to make informed decisions
  6. 6. Performance tuning lifecycle
  7. 7. Obligatory analogy
  8. 8. When should I capture it? It depends • Consider different baselines for different business periods – Maintenance windows – Month/Quarter/Year end – Seasonal peaks • After Windows and SQL Server patches • After failovers / DR scenarios • After any new project deployment
  9. 9. What should I capture? System Configuration Windows OS Counters SQL Server Counters Wait statistics
  10. 10. What should I capture? System configuration • • • • • Infrastructure diagrams. Windows and SQL Server version information. Driver information. IO Subsystem information. System catalogue information: – Sys.configurations – Sys.databases – Sys.master_files
  11. 11. What should I capture? Operating System / SQL Server Counters - Memory • • • • • • Memory: Available Mbytes Paging File: %Usage 0 SQL Server Memory Manager: Target Server Memory(KB) SQL Server Memory Manager: Total Server Memory(KB) SQL Server Memory Manager: Memory Grants Pending SQL Server Buffer Manager: Buffer cache hit ratio 300 SQL Server Buffer Manager: Page Life Expectancy • SQL Server Buffer Manager: Extension Page Unreferenced Time PLE * 16 or 32 • SQL Server Buffer Manager: Database Pages • SQL Server Buffer Manager: Procedure Cache Pages
  12. 12. Virtualisation Considerations - VMWare • Memory Limit (MB) • Memory Reservation (MB) • Memory Ballooned (MB) • Memory Swapped (MB) Read more about VMWare memory settings here: http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt. pdf
  13. 13. What should I capture? Operating System / SQL Server Counters - CPU • Processor: % Processor Time LT 80% • Process: % Processor Time (SQLServr) LT 80% LT 12 good ideally LT 4 LT 3000 good ideally LT 1500 • System: Processor Queue Length • System: Context Switches/Sec • SQL Server SQL Statistics: SQL Compilations/Sec • SQL Server SQL Statistics: SQL ReCompilations/Sec
  14. 14. What should I capture? Operating System / SQL Server Counters - IO • Physical Disk: Current Disk Queue Length ? • Physical Disk: Avg. Disk Sec/Read LT 20ms • Physical Disk: Avg. Disk Sec/Write LT 10ms • Physical Disk: Avg. Bytes/Read • Physical Disk: Avg. Bytes/Write
  15. 15. SAN Considerations • Virtualised storage – How is it connected? – How many spindles? – How many other servers share this? • Dynamic storage – Your data may move!!!!! • What’s a good way to test for consistency? – Baseline your maintenance window(s)
  16. 16. What should I capture? SQL Server Counters • SQL Server Access Method: Forwarded Records/Sec • SQL Server Access Method: Page Splits/Sec • SQL Server General Statistics: User Connections • SQL Server SQL Statistics: Batch Requests/Sec • SQL Server Buffer Manager: Page Reads/Sec • SQL Server Buffer Manager: Page Writes/Sec Ideally 0 It depends* Beware pooling LT 90 LT 90 ** *Page splits include “regular” new page allocations ** Cross reference this with Checkpoint and Lazy Writer counters
  17. 17. What should I capture? • Query information – Understand the server workload – Consider exporting plans from the cache. • Job information – Are my jobs taking longer? • Wait statistics – What is SQL Server waiting on?
  18. 18. What free tools can I capture it with? • Performance Monitor (OS + SQL Server Counters) • Your favourite T-SQL editor - SSMS or Toad for SQL Server freeware (Dynamic Management Objects) • Profiler / Extended events (Query information)
  19. 19. How do I analyse? • Import data into Microsoft Excel – http://www.toadworld.com/platforms/sqlserver/w/wiki/10421.performance-monitor.aspx – http://bit.ly/YXOfZD - Brent Ozar at SQLBits
  20. 20. Demo
  21. 21. Mature Information Management Processes Level 1 Reactive Level 0 Chaotic         Ad hoc Undocumented Unpredictable Multiple help desks Minimal IT operations User call notification     Level 3 Service Level 2 Proactive   Fight fires  Inventory  Desktop sw distribution  Initiate  problem mgt process Alert and event mgt Monitor component availability  Analyze trends Set thresholds Predict problems Monitor end-user response time Automate Mature problem, configura tion, change, asse t and performance mgt processes       IT as strategic business partner IT and business metric linkage IT/business collaboration improves business process Real-time infrastructure Business planning  IT as a service provider  Define services, classes, p ricing Understand costs  Guarantee SLAs Monitor and report  service availability Manage IT as a Business Capacity mgt Service and Account Management Service Delivery Process Engineering Operational Process Engineering Tool Leverage Level 4 Value
  22. 22. “The Day After Tomorrow”; why you need to baseline Summary • What a “baseline” is. • What “benchmarking” means. • How to plan your baseline. • How to choose your measures. • Native tools.
  23. 23. THANK YOU! • For attending this session and PASS SQLRally Nordic 2013, Stockholm Richard Douglas @SQLRich http://SQL.RichardDouglas.co.uk Richard.Douglas@Software.Dell.com

×