September 25, 2012 at 1:47 am
Hi All,
I am having few Databases in which i have to go through each and every table and stored procs etc.
I know if i have the statistics of DB it will be easy for me to go through tables and sps based on the priority of their execution .
Things I did
1. Found the frequency of each SP (hence i know which SP is frequently executed)
2. Found the no of Tables & SPS in each Database
My Doubt is
What are the other ways to get the statistics of Database in SQL Server 2008 so that i will be having an informed data hence i can learn more
Or How one can master all Databases in SQL Server (2008)
Thanks,
Charan
September 25, 2012 at 2:11 am
The sys.dm_exec_query_stats is a central DMV to find the statistics of the current performance of cached query plans.
September 25, 2012 at 3:04 am
Familiarisation? Probably the easiest place to start is the Activity Monitor.
Watch for Recent Expensive Queries and examine them in detail as they come up. Experiment by sorting the columns - click on [Executions/mi] to see frequently-run queries. Hover on column titles to see which DMV is called to obtain the values.
Keep an eye on Waits in the Processes pane, and obtain more information if necessary from the relevant DMV.
Don't forget indexes. Glen Berry [/url]publishes a suite of diagnostic information queries on his website - they are tremendously useful for this type of investigation and include index investigation for refactoring.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
September 25, 2012 at 4:30 am
If you're parachuting into a situation where there is no monitoring in place, then, as was already mentioned, use the Dynamic Management Objects (DMO) to query the cache in order to understand the most frequently called, most expense, longest running queries.
If you're living with a database over time, then setting up monitoring, preferably using a combination of Performance Monitor and Extended Events, to capture performance metrics about the system. This will lead you to understanding of the system in general.
I would ensure that you have maintenance routines in place to take care of statistics and possibly defragment indexes. While we're on indexes, most tables in most databases absolutely should have a clustered index. Where to place it is a design issue you won't be able to address directly since you're not designing the system, but I'd be concerned about any tables missing indexes.
From there, it's a slog. There are no shortcuts. See a query running long? Get the execution plan and see if modifying the structure or the T-SQL can help improve performance.
For lots more detail, get a copy of my book.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply