The document discusses Microsoft's Management Data Warehouse (MDW) which allows for monitoring of SQL Server performance on the cheap. It provides built-in reports for disk usage, query statistics, and server statistics collected every 6 hours, 60 seconds, and 10 seconds respectively. The MDW uses two SQL jobs, one to collect data and store it temporarily and another to upload it. It can operate in cached or non-cached mode, with cached being heavier on performance. The presentation demonstrates the MDW and provides tips like not changing the table structure and creating smaller collector sets to stagger uploads.
4. • Troubleshooting is a pain in the neck
• Time consuming
• “After The Fact”
• Basically wait for it to happen again while you are looking.
MD What??
6. • Reactive to Proactive.
• Continuous performance monitoring.
• Easy to retrieve.
• Easy to interpret.
Management Data Warehouse
7. • Disk Usage - Collected and uploaded every 6 hours
• Query Statistics - every 60 seconds uploaded every 15 minutes
• Server Statistics - every 10 seconds uploaded every 15 minutes
Data Collection out the box
8. • Two Separate jobs
• First job collects and stores in temp location
• Second job uploads
• Scheduled independently
Cached mode
9. • One job collects and uploads
• Allows for immediate access to the collected data
• Heavy on performance – avoid if collecting from multiple instances
Non Cached mode
11. • DON’T CHANGE TABLE STRUCTURE
• DON’T TOUCH THE DATA
• DO USE THE API TO RETRIEVE THE DATA
• MAKE SURE SQL AGENT IS RUNNING
• CREATE SMALLER COLLECTOR SETS
• STAGGER UPLOAD SCHEDULES
PRO TIPS!
13. • Matt Horn (Mhorn@aphelion.bi)
• @Maxui (Twitter)
• www.intellicape.blogspot.com (B.I. User Group)
Thank you and Goodnight
Editor's Notes
Trouble shooting Performance problems are a pain.Normally its an after excersize with very little to go onBasically wait for the problem to happen again while you are lookingREACTIVE APPROACH
Used to store data from a number of SQL Servers in one central location. stored in a shareable MDWAllows for easy reporting on growth and performance trends using built in reports or roll your ownIntroduced in SQL 2008 but can be used to capture data for 2005 and up – with a bit of a hack
Actively capturing data about your SQL Server Hundreds of performance counters SQL and SSASPROACTIVEHistory – can look at what happened yesterday significantly lessens the work needed to monitor and trouble shoot SQL Server Allows for identification of obscure problems quickly and easily
Data Collection Sets collect the essential data needed to identify and troubleshoot most common SQL Server performance problemsCached VS un Cached modeDisk usage – Database and log size growth trendsQuery stats = collected every 60 seconds – uploaded every 15 minsTop CPU, Duration, Total I/O, Physical Reads or Logical writesServer Stats = Collected every 10 seconds uploaded every 15 minsCPU usage, Memory usage, Disk I/O, Network Waits
Works well when collecting from multiple instances as you can schedule the uploads to run at a time when your server is not busyhowever the drawback is that you wont be able to view the collected data immediatelyBut can force an upload
DON’T CHANGE TABLES – Doing this will cause some of the stored procs to stop workingDON’T TOUCH THE DATA – The key factor here is data integrity – if we go in and manipulate what was collected we run the risk of invalidating the entire data setDO USE THE SP’s There are a set of stored procs that allow you to view your data Use them .only collectSMALLER COLLECTOR SETS – only collect the data you will use there is more than enough in the built in reports to diagnose most problems