Published on

November 25, 2011

Понимание проблем с производительностью SQL Server

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

Несколько дней назад я заметил необычные показатели в мониторе операций одного из моих базовых серверов. Среднее количество задач и использование ЦП были выше нормы, а ожидающие изменения полнотекстового поиска были необычно высокими. Кроме того, описание повторного использования журнала для одной из баз данных указывало на активную транзакцию, что было необычно для моей рабочей нагрузки OLTP.

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

Вспоминая соответствующую белую книгу на эту тему, я быстро просмотрел “Как диагностировать и исправить ошибки 17883, 17884, 17887 и 17888” Боба Дорра и Самира Тежани в Microsoft. Во время чтения я заметил, что активная транзакция для проблемной базы данных все еще присутствует. Чтобы исследовать дальше, я запустил команду DBCC OPENTRAN и обнаружил транзакцию, которая была активна несколько часов, что было очень необычно.

Затем я использовал команду DBCC INPUTBUFFER с SPID транзакции, чтобы определить хранимую процедуру, ответственную за долгую транзакцию. К сожалению, отмена задания SQL Agent, связанного с хранимой процедурой, не дала результатов. В качестве последнего способа я выполнил команду KILL для завершения SPID, что привело к откату транзакции.

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

Чтобы помочь вам отслеживать свои собственные базовые серверы, я включил ниже некоторые полезные запросы и команды:

-- Получить среднее количество задач и среднее количество запущенных задач
SELECT AVG(current_tasks_count) AS [Среднее количество задач], AVG(runnable_tasks_count) AS [Среднее количество запущенных задач]
FROM sys.dm_os_schedulers WITH (NOLOCK)
WHERE scheduler_id < 255;

-- Получить описание ожидания повторного использования журнала
SELECT [name], log_reuse_wait_desc
FROM sys.databases WITH (NOLOCK)
WHERE database_id > 4;

-- Узнать, сколько ожидающих изменений полнотекстового поиска есть в таблице
SELECT OBJECTPROPERTY(OBJECT_ID('YourTableName'), 'TableFulltextPendingChanges') AS 'Ожидающие изменения';

-- Найти самую старую открытую транзакцию
DBCC OPENTRAN;

-- Найти команду для заданного SPID
DBCC INPUTBUFFER(SPID);

-- Завершить SPID
KILL SPID;

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

Помните, что при столкновении с проблемами производительности важно сохранять спокойствие и систематически собирать информацию для диагностики и устранения проблемы. Следуя логическому подходу, вы можете эффективно решать проблемы производительности SQL Server и поддерживать бесперебойную работу вашей производственной среды.

Click to rate this post!
[Total: 0 Average: 0]

Let's work together

Send us a message or book free introductory meeting with us using button below.