Question
A customer is experiencing poor performance within Console and\or ServicePortal and their SQL Server database is a possible culprit.
Answer
Using SQL Server Performance Tools: SQL Server Profiler and Database Engine Tuning Advisor.
Background:
When dealing with performance issues it is essential to define exactly what is underperforming, and specifically when. Also, it may help to understand what the customer's idea of underperforming actually is - 2 seconds to display a reference list from a dropdown is perfectly acceptable, for example.
When it has been established that performance could be improved in a certain area, a series of test steps must be created in order establish timings for each stage so that improvements can be measured.
Indexing a database can significantly improve performance, however it should be used with caution - it makes the database larger, and can affect data writing because when you enter data it has to update the indexes as well.
To create new indexes:
Load up SQL Profiler, create a new trace and select the 'Tuning' template.
Start the trace and perform the steps you previously decided on (e.g logging and assigning an incident within Console - or whatever area of the system is perceived as being slow), timing each stage. When you have finished the predefined steps stop the trace.
Save the trace as a trc file and open the Database Tuning Advisor.
Under Workload, highlight File and browse to your trace file then select the database you want to use for the workload analysis - this is just where the tuning advisor does its work, it's best to stick with the same database throughout.
Tick the database you want to tune then click Start Analysis.
When the advisor returns its results, click Action>Save Recommendations as Script (assuming it has returned anything, if it hasn't the performance issue isn't likely to do with the database itself).
This script can be run on a copy of the customer's database and will create the necessary indexes.
From there, run through the steps you decided on and take new timings and compare them to the original ones. If there is any significant improvement it is probably worth getting the customer to run the script on site. If not it's best NOT to create indexes for the sake of it because of the aforementioned impact to writing data.
Notes:
The script may need to be edited. At the top of the script will be:
USE either needs to be corrected to show the customer's database name as they have it on site, or the whole "Use, Go" statement can be deleted, and the customer just needs to make sure they are running the script on the correct database.
Environment
SQL Server 2005