Monitoring on the cheap with Management Data Warehouse
•Download as PPTX, PDF•
0 likes•445 views
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.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Monitoring on the cheap with Management Data Warehouse
Similar to Monitoring on the cheap with Management Data Warehouse (20)
Recently uploaded
Recently uploaded (20)
Monitoring on the cheap with Management Data Warehouse
- 1. Management Data Warehouse Monitoring on the cheap
- 2. • Senior Consultant – Aphelion Software • Microsoft® Certified Technology Specialist • Co-lead JHB Business Intelligence Developer Network • Lead - IntelliCape B.I. User Group Matt Horn
- 3. Agenda MD What?? Setting it up Built in reports Extending with custom collector sets
- 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??
- 5. • Relational Database • Built in reports • Introduced in SQL Sever 2008 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
- 10. Demo!
- 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!
- 12. Be selective in what you collect
- 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