Question

Est-il possible d'obtenir la répartition de l'utilisation de l'UC par base de données?

Je suis idéalement la recherche d'un Gestionnaire de Tâches de type interface pour SQL server, mais au lieu de regarder l'utilisation du PROCESSEUR de chaque PID (comme taskmgr) ou chaque SPID (comme spwho2k5), Je veux afficher la durée totale d'utilisation de l'UC de chaque base de données.Supposons qu'une seule instance de SQL.

Je me rends compte que les outils pourraient être écrites pour recueillir ces données et d'en faire rapport, mais je me demandais si il n'y a aucun outil qui me permet de voir une vue en direct de bases de données qui contribuent le plus à la sqlservr.exe La charge du PROCESSEUR.

Était-ce utile?

La solution

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.

Lorsque 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).

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

Autres conseils

SQL Server (à partir de 2000) va installer des compteurs de performances (visible à partir de l'analyseur de Performances ou de l'analyseur de performances).

L'une des catégories du compteur (à partir d'un Serveur SQL server 2005 installer est:) - SQLServer:Bases De Données

Avec un exemple pour chaque base de données.Les compteurs disponibles, mais ne fournissent pas un CPU % d'Utilisation du compteur ou quelque chose de similaire, bien qu'il existe des compteurs de taux, que vous pouvez utiliser pour obtenir une bonne estimation de la CPU.Exemple serait si vous avez 2 bases de données, et le taux mesuré est de 20 opérations/sec sur Une base de données et 80 trans/s sur la base de données B --- ensuite, vous savez que l'Un contribue à environ 20% du total de la CPU, et B à hauteur de 80%.

Il y a quelques défauts ici, comme c'est en supposant que tout le travail effectué est liée à l'UC, qui, bien sûr, avec les bases de données il n'est pas.Mais ce serait un début, je crois.

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

Je pense que la réponse à votre question est non.

Le problème est qu'une activité sur un ordinateur peut entraîner de charge sur plusieurs bases de données.Si j'ai un processus qui est de la lecture à partir d'une base de données de configuration, la connexion à un enregistrement DB, et le déplacement des transactions dans et hors de différents DBs basés sur le type, comment partitionner l'utilisation de l'UC?

Vous pouvez diviser l'utilisation de l'UC par l'opération de charge, mais c'est encore un accidenté de la métrique qui peuvent vous induire en erreur.Comment vous répartissez vous envoi des journaux de transactions à partir d'un DB à un autre, par exemple?Est la charge CPU dans la lecture ou l'écriture?

Vous êtes mieux de regarder le taux de transaction pour une machine et la charge CPU, il provoque.Vous pouvez également le profil de procédures stockées et de voir si l'un d'entre eux prennent énormément de temps;cependant, ce ne sera pas vous obtenir la réponse que vous voulez.

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é les 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;

Jetez un oeil à SQL Sentry.Il n'tous vous avez besoin et plus encore.

En ce qui concerne, Lieven

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

Prendre la norme "T-SQL" ou des "procédures Stockées" modèle, d'ajuster 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 assez 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.

veuillez vérifier cette requête:

SELECT 
    DB_NAME(st.dbid) AS DatabaseName
    ,OBJECT_SCHEMA_NAME(st.objectid,dbid) AS SchemaName
    ,cp.objtype AS ObjectType
    ,OBJECT_NAME(st.objectid,dbid) AS Objects
    ,MAX(cp.usecounts)AS Total_Execution_count
    ,SUM(qs.total_worker_time) AS Total_CPU_Time
    ,SUM(qs.total_worker_time) / (max(cp.usecounts) * 1.0) AS Avg_CPU_Time 
FROM sys.dm_exec_cached_plans cp 
INNER JOIN sys.dm_exec_query_stats qs 
    ON cp.plan_handle = qs.plan_handle
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
WHERE DB_NAME(st.dbid) IS NOT NULL
GROUP BY DB_NAME(st.dbid),OBJECT_SCHEMA_NAME(objectid,st.dbid),cp.objtype,OBJECT_NAME(objectid,st.dbid) 
ORDER BY sum(qs.total_worker_time) desc
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top