L'utilisation de l'UC par la base de données?

En quelque sorte. Cochez cette requête:

SELECT total_worker_time/execution_count AS AvgCPU  
, total_worker_time AS TotalCPU
, total_elapsed_time/execution_count AS AvgDuration  
, total_elapsed_time AS TotalDuration  
, (total_logical_reads+total_physical_reads)/execution_count AS AvgReads 
, (total_logical_reads+total_physical_reads) AS TotalReads
, execution_count   
, SUBSTRING(st.TEXT, (qs.statement_start_offset/2)+1  
, ((CASE qs.statement_end_offset  WHEN -1 THEN datalength(st.TEXT)  
ELSE qs.statement_end_offset  
END - qs.statement_start_offset)/2) + 1) AS txt  
, query_plan
FROM sys.dm_exec_query_stats AS qs  
cross apply sys.dm_exec_sql_text(qs.sql_handle) AS st  
cross apply sys.dm_exec_query_plan (qs.plan_handle) AS qp 
ORDER BY 1 DESC

Cela vous aidera à les requêtes dans le cache du plan afin de PROCESSEUR qu'ils ont utilisé. Vous pouvez exécuter cette opération régulièrement, comme dans une tâche de l'Agent SQL, et insérer les résultats dans une table assurez-vous que les données persiste au-delà de redémarrages.

Quand vous lisez les résultats, vous aurez probablement réaliser pourquoi on ne peut pas corréler les données directement à un individu de la base de données. Tout d'abord, une seule requête peut également masquer sa véritable base de données parent en faisant des trucs comme ça:

USE msdb
DECLARE @StringToExecute VARCHAR(1000)
SET @StringToExecute = 'SELECT * FROM AdventureWorks.dbo.ErrorLog'
EXEC @StringToExecute

La requête sera exécutée dans la base de données MSDB, mais il serait de résultats d'un sondage à partir de la base de données AdventureWorks. Où faut-il attribuer la consommation de CPU?

Il y a pire quand vous:

• Jointure entre plusieurs bases de données
• Exécuter une transaction dans de multiples bases de données, et l'effort de verrouillage s'étend sur plusieurs bases de données
• Exécuter des travaux de l'Agent SQL dans la base de données MSDB que le "travail" dans la base de données MSDB, mais de sauvegarder des bases de données individuelles

Il va sur et sur. C'est pourquoi il est logique d'optimisation des performances au niveau de la requête au lieu de la base de données de niveau.

Dans SQL Server 2008R2, Microsoft a introduit la gestion de la performance et de l'application de gestion des fonctionnalités qui va nous permettre de package d'une base de données unique dans une distribuable et déployable DAC pack, et ils sont prometteurs fonctionnalités pour faciliter la gestion de la performance des bases de données individuelles et de leurs applications. Il n'est toujours pas ce que vous cherchez, si.

Pour plus de personnes, découvrez la T-SQL référentiel Crapaud Monde SQL Server wiki (anciennement à SQLServerPedia).

Mis à jour sur 1/29 à inclure le total des nombres au lieu de juste moyennes.

Voici une requête qui affiche la base de données réelle, provoquant de fortes charge. Il s'appuie sur la mise en cache de requêtes qui pourraient être vidées fréquemment dans les bas-mémoire des scénarios (pour faire une requête pour le moins utile).

select dbs.name, cacheobjtype, total_cpu_time, total_execution_count from
    (select top 10
        sum(qs.total_worker_time) as total_cpu_time,  
        sum(qs.execution_count) as total_execution_count, 
        count(*) as  number_of_statements,  
        qs.plan_handle
    from  
        sys.dm_exec_query_stats qs 
    group by qs.plan_handle
    order by sum(qs.total_worker_time) desc
    ) a
inner join 
(SELECT plan_handle, pvt.dbid, cacheobjtype
FROM (
    SELECT plan_handle, epa.attribute, epa.value, cacheobjtype
    FROM sys.dm_exec_cached_plans 
        OUTER APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa
     /* WHERE cacheobjtype = 'Compiled Plan' AND objtype = 'adhoc' */) AS ecpa 
PIVOT (MAX(ecpa.value) FOR ecpa.attribute IN ("dbid", "sql_handle")) AS pvt
) b on a.plan_handle = b.plan_handle
inner join sys.databases dbs on dbid = dbs.database_id

Avec tous dit ci-dessus à l'esprit.

À partir de SQL Server 2012 (peut-être en 2008 ?) , il est la colonne database_id dans sys.dm_exec_sessions.

Il nous donne facile de calcul du processeur pour chaque base de données pour actuellement connecté sessions. Si la session a déconnecté, puis ses résultats ont disparu.

select session_id, cpu_time, program_name, login_name, database_id 
  from sys.dm_exec_sessions 
 where session_id > 50;

select sum(cpu_time)/1000 as cpu_seconds, database_id 
 from sys.dm_exec_sessions 
group by database_id
order by cpu_seconds desc;

Avez-vous regardé le générateur de profils SQL?

Prendre la norme "T-SQL" ou des "procédures Stockées" modèle, modifiez les champs de groupe par l'ID de base de données (je pense que vous avez utilisés, le nombre, vous n'obtenez pas le nom de base de données, mais il est facile à trouver en utilisant exec sp_databases pour obtenir la liste)

Exécuter ce pour un certain temps et vous aurez le CPU total compte /e /s de Disque /d'Attente etc. Cela peut vous donner le pourcentage de CPU utilisé par chaque base de données.

Si vous surveillez le compteur PerfMon en même temps (enregistrer les données sur une base de données SQL), et faire de même pour le générateur de profils SQL (journal de base de données), vous peut être en mesure de corréler les deux ensemble.

De même, il devrait vous donner suffisamment d'indices quant à ce qui DB est intéressant de regarder plus en détail. Ensuite, faire de même avec cet ID de base de données et de rechercher le plus cher SQL ou des Procédures Stockées.