Назад | Перейти на главную страницу

Как определить медленные запросы на сервере sql?

Я нашел длинные сложные инструкции как это при поиске ответа на этот вопрос краткие справочные ссылки, например, в эта почта.

Я ищу краткую процедуру, насколько это возможно для создания списка SQL-запросов со временем выполнения, где время выполнения> some_threshold.

Думаю, ответа здесь не было, потому что это так просто! Вот что я выяснил:

  1. открыто Профайлер SQL Server (в инструментах производительности)
  2. File -> New Trace...
  3. Подключитесь к вашей базе данных
  4. Щелкните вкладку Выбор событий.
  5. Выбирать только события, соответствующие завершению SQL-запросов:
    • RPC:Completed
    • SQL:BatchCompleted
  6. Нажмите Фильтры столбцов ...
  7. Нажмите Продолжительность в списке
  8. Развернуть Больше или равно и введите пороговое время, которое вы считаете "медленным" в миллисекундах.
  9. Нажмите хорошо
  10. Нажмите Бегать

Вы можете фильтровать по ApplicationName, NTUserNameи т. д., если у вас работает много приложений и вы хотите снизить уровень шума. Вы также можете показать только некоторые столбцы, например просто TextData и Duration.

Вот гораздо более продвинутое лечение Профилировщика.

вы можете использовать это, чтобы получить 10 самых дорогих запросов (если вы используете Sql server 2005 и выше): 

SELECT TOP 10 SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC -- logical reads
-- ORDER BY qs.total_logical_writes DESC -- logical writes
-- ORDER BY qs.total_worker_time DESC -- CPU time

Использование трассировки Profiler, особенно при импорте трассировки в базу данных, является отличной методологией.

Если вы используете SQL Server 2005 или новее, DMV (динамические управленческие представления) предлагают альтернативную методологию:

SELECT TOP 100
(total_logical_reads + total_logical_writes) / qs.execution_count AS average_IO,
(total_logical_reads + total_logical_writes) AS total_IO,
qs.execution_count AS execution_count,
SUBSTRING (qt.text,qs.statement_start_offset/2, 
     (CASE WHEN qs.statement_end_offset = -1 
        THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
      ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) AS indivudual_query,
o.name AS object_name,
DB_NAME(qt.dbid) AS database_name
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
LEFT OUTER JOIN sys.objects o ON qt.objectid = o.object_id
where qt.dbid = DB_ID()
ORDER BY average_IO DESC;

Следует помнить, что DMV очищаются при запуске SQL Server, поэтому, если ваш сервер работал в течение 12 минут, он может мало что вам сказать. Кроме того, они кумулятивны, поэтому окна обслуживания (checkDB) могут исказить данные.