Sunday, January 22, 2006

SQL Performance reports from profiler traces

Over the December and January period I have been working with some developers to get their database performance improved. Not that there has been a problem with performance, rather we have been looking proactively at the slower stored procedures and reviewing the SQL and the logic behind each to see if we can improve.

This has lead to the need for the ability to compare the performance of stored procedures over periods. After finally fixing the buggy SQL code which returns the stored procedure name or DML that was run, I reworked some older code to return a comparison of some performance metrics over two periods.
This code uses two inline views which then join on the stored procedure name or DML SQL to compare number of calls, total duration and the main one, duration per call. This enables us to produce a report which can quickly identify code which is running significantly slower.

Unfortunately I am not going to publish that code just yet. I want to rework into a stored procedure which can be added to an expanding library of jobs and stored procedures to performance tune SQLserver.
The plan is to have a complete solution to provide the tools to automate performance metric collection and reporting using tools provided by SQLserver. I am hoping that people will be able to download a zip file which provides an easy install.
Tuning based on the reports is always going to be harder, but capturing the information is the first step.

After some other workload is over (doing an database migration), I will have time to recode into stored procedure and also install and play with SQLserver 2005.
Given the new performance tables, and my existing library of Oracle scripts I should be in a position to remap those Oracle scripts to use the new SQLserver 2005 tables where possible.

Have Fun

No comments: