CPU использование базы данных?

Что-то вроде того. Проверьте этот запрос:

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

Это позволит вам получить запросы в кэше плана в порядке того, сколько CPU они израсходовали. Вы можете запускать это периодически, как в задании агента SQL, и вставлять результаты в таблицу, чтобы убедиться, что данные сохраняются после перезагрузки.

Когда вы прочтете результаты, вы, вероятно, поймете, почему мы не можем соотнести эти данные непосредственно с отдельной базой данных. Во-первых, один запрос может также скрыть свой истинный родитель базы данных, выполнив такие трюки:

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

Запрос будет выполнен в MSDB, но он будет опрашивать результаты из AdventureWorks. Где мы должны назначить потребление CPU?

Все становится еще хуже, когда ты ... :

• Соединение между несколькими базами данных
• Выполните транзакцию в нескольких базах данных, и усилие блокировки охватывает несколько баз данных
• Запустите SQL задание агента в MSDB, что "work" в MSDB, но создайте резервные копии отдельных баз данных

Это продолжается и продолжается. Вот почему имеет смысл настраивать производительность на уровне запросов, а не на уровне базы данных.

В SQL Server 2008R2 Корпорация Майкрософт представила функции управления производительностью и управления приложениями, которые позволят нам упаковать единую базу данных в распространяемый и развертываемый пакет DAC, а также перспективные функции, облегчающие управление производительностью отдельных баз данных и их приложений. Но он все равно не делает того, что вы ищете.

Для получения дополнительной информации о них проверьте репозиторий T-SQL на Toad World's SQL Server wiki (ранее на SQLServerPedia).

Обновлено 1/29 включать в общее число, а не только средние.

SQL сервер (начиная с 2000 года) будет устанавливать счетчики производительности (видимые с монитора производительности или Perfmon).

Одна из категорий счетчиков (от установки SQL Server 2005) - это:) - SQLServer:Databases

С одним экземпляром для каждой базы данных. Однако доступные счетчики не предоставляют счетчик использования CPU % или что-то подобное, хотя есть некоторые счетчики скорости, которые можно использовать для получения хорошей оценки CPU. Например, если у вас есть 2 базы данных, и измеряемая скорость составляет 20 транзакций/сек в базе данных A и 80 транзакций / сек в базе данных B - - - тогда вы знаете, что A вносит примерно 28 из общего числа CPU, А B вносит вклад в другие 80%.

Здесь есть некоторые недостатки, так как это предполагает, что вся выполняемая работа связана с CPU, что, конечно, с базами данных не так. Но я думаю, что это было бы только начало.

Вот запрос, который покажет фактическую базу данных, вызывающую высокую нагрузку. Он полагается на кэш запросов, который может часто сбрасываться в сценариях с низким объемом памяти (что делает запрос менее полезным).

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

Я думаю, что ответ на ваш вопрос-нет.

Проблема заключается в том, что одно действие на компьютере может вызвать нагрузку на несколько баз данных. Если у меня есть процесс, который читает из конфигурации DB, записывает в журнал DB и перемещает транзакции в различные DBs в зависимости от типа, как я разделяю использование CPU?

Вы можете разделить использование CPU на нагрузку транзакции, но это опять же грубая метрика, которая может ввести вас в заблуждение. Например, как бы вы разделили доставку журнала транзакций от одного DB до другого? Является ли CPU нагрузка в чтении или записи?

Вам лучше посмотреть на скорость транзакций для машины и нагрузку CPU, которую она вызывает. Вы также можете профилировать хранимые процедуры и посмотреть, не занимают ли они чрезмерно много времени; однако это не даст вам желаемого ответа.

Имея в виду все сказанное выше.
Начиная с SQL Server 2012 (может быть 2008 ?), есть столбец database_id в sys.dm_exec_sessions .
Это дает нам простой расчет cpu для каждой базы данных для текущих подключенных сеансов. Если сеанс отключили, то пошли его результаты.

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;

Взгляните на SQL Sentry . Он делает все, что вам нужно, и даже больше.

С уважением, Ливен

Вы смотрели на SQL profiler?

Возьмите стандартный шаблон "T-SQL" или "Stored Procedure", настройте поля для группировки по базе данных ID (я думаю, что вы должны использовать номер, вы не получаете имя базы данных, но это легко узнать, используя exec sp_databases, чтобы получить список)

Запустите это на некоторое время, и вы получите общее количество CPU / Disk IO / Wait и т. д. Это может дать вам долю CPU, используемую каждой базой данных.

Если вы одновременно отслеживаете счетчик PerfMon (регистрируете данные в базе данных SQL) и делаете то же самое для профилировщика SQL (регистрируете данные в базе данных), вы можете соотнести их вместе.

Тем не менее, это должно дать вам достаточно подсказок относительно того, какой DB стоит рассмотреть более подробно. Затем проделайте то же самое еще раз с одной базой данных ID и найдите самые дорогие SQL / хранимые процедуры.

пожалуйста, проверьте этот запрос:

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