I don't think you can find this by an easy way but it is possible anyway to get through this. Profiler offers many event class types that can be used in analyzing the performance of a query. Start a new Profiler session and check following events:
Performance: Performance statistics
Stored Procedures: RPC:Completed
TSQL: SQL:BatchCompleted
TSQL: SQL: BatchStarting
Check to Show all columns and select each one of the columns under Performance: Performance statistics event only. The rest of events can be left with default setting.
Next, Select Column Filters and filter by DatabaseName and/or LoginName/ApplicationName/HostName etc.., if you know them. The purpose is to limit the number of rows dispalyed in Profiler and concentrate only on your needs.
Next, press Run and let it run for a while (2-3 min as long as you need).
Analyse the results dispalyed looking primarily at: Performance statistics event.
If Performance Statistics will occur often it means that the plan of a query was cached for the first time, compiled, re-compiled or evicted from PlanCache. From my knowledge if a query does not have its query plan in Plan Cache - you will see 2 rows of PerformanceStatistics event and followed by SQL:BatchStarting, then SQL:BatchCompleted. It means that the Query Plan was first compiled, cached and then the query started and completed.
Look at following columns under Performance Statistics event:
SPID - ID of the session on which the event occurred. You can use it to identify the
row on SQL:BatchCompleted event which will display the SQL Query text and other
usefull information (Read/Writes, StartTime/EndTime)
Duration - Total time, in microseconds, spent during compilation.
EventSubClass - 0 = New batch SQL text that is not currently present in the cache.
1 = Queries within a stored procedure have been compiled.
2 = Queries within an ad hoc SQL statement have been compiled.
3 = A cached query has been destroyed and the historical performance
data associated with the plan is about to be destroyed.
4 = A cached stored procedure has been removed from the cache and the
historical performance data associated with it is about to be
destroyed.
5 = A cached trigger has been removed from the cache and the historical
performance data associated with it is about to be destroyed.
Considering the EventSubClass number you can find out what happened with the Query Plan and take specific measures. Additionally you can add other columns to Stored Procedures and TSQL Event Classes if you are interseted in HostName, WindowsUser or other info from Profiler trace.
Also the trace can be stored in a SQL table making the analyse more easy and much more customizable. Here is a link describing more the Performance Statistics Event Class.
CHeck to see if you are having the backups stored on the same physical location as your data and log files. If you are trying to write all activity to one disk, that is going to be a likely bottleneck.
Also, if you are using a 3rd party tool (such as Litespeed) for backup compression, there is a chance you are consuming more CPU than you expected, and that could also result in less than optimal performance.
HTH
Best Answer
SQL Compilations/sec is a good metric, but only when coupled with Batch Requests/sec. By itself, compilations per sec doesn't really tell you much.
You are seeing 170. If batch req per sec is only 200 (a little exaggerated for effect) then yes, you need to get down to the bottom of the cause (most likely an overuse of ad hoc querying and single-use plans). But if your batch req per sec is measuring about 5000 then 170 compilations per sec is not bad at all. It's a general rule of thumb that Compilations/sec should be at 10% or less than total Batch Requests/sec.
If you really want to drill down into what's being cached, run the following query that utilizes the appropriate DMVs:
To get all single-use plans (a count):
To get a ratio of how many single-use count plans you have compared to all cached plans:
As for durations captured through a SQL Server Trace, it is not available for the Recompile events. It isn't so significant to see the duration or pain that plan compilation is causing, as there's not much you can do for a case-by-case situation. The solution is to attempt to limit compilations and recompilations through plan re-use (parameterized queries, stored procedures, etc.).