Прерывистые тайм-ауты SQL Server и сильно различающиеся времена выполнения для хранимых процедур

Question

У меня проблема с моим SQL Server 2005, когда хранимые процессы, особенно те, которые запускают групповые вставки, иногда выполняются очень долго. Этот сохраненный процесс, назовем его DatabaseUpdate, должен занять около 2 секунд. Тем не менее, в 20-40% случаев это занимает гораздо больше времени, и очень часто оно истекает через 30 секунд.

Что такого странного в том, что у меня очень контролируемая среда. Журналы, которые я сейчас просматриваю, показывают период, в течение которого одни и те же события происходят через равные промежутки времени. Есть несколько клиентов, и все они делают запросы на основе таймеров, и все эти машины работают с приложениями атомной синхронизации часов. Так что я могу с уверенностью сказать, что одна и та же последовательность событий происходит каждые пять минут, но мой сохраненный процесс, который импортирует файл размером 100 КБ в базу данных, отличается по времени выполнения от 1,5 до 30 с.

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

10: 30 2062 мс 10:35 24250 мс 10:40 1921 мс 10:45 25703 мс 10:50 1734 мс 10:55 25406 мс 11:00 1625 мс

Есть идеи?

Answer 1

Проверьте, есть ли у вас какие-либо события роста журнала или базы данных. Если базы данных имеют неправильный размер, они будут автоматически расти. Во время события автоматического увеличения (которое может произойти во время массовой вставки) база данных будет зависать до тех пор, пока файл не будет увеличен и инициализирован 0. Эта операция длится довольно долго (десятки секунд) и увеличивается по мере роста базы данных, потому что по умолчанию авторазмер составляет процент от размера, поэтому авторазмер увеличивается.

Чтобы проверить наличие событий автоматического роста, просмотрите ERRORLOG и значение счетчика производительности SQL Server:Database/Log Growth.

Если у вас есть события роста базы данных, вы должны установить правильный размер базы данных. Правильное значение зависит от вашей фактической загрузки данных. Вам также следует включить инициализацию инициатора NTFS, см. Мгновенная инициализация - что, почему и как? . Вы не можете использовать этот параметр для файлов журнала.

Answer 2

Может ли быть [b] проблема с блокировкой? Что показывает SQL Profiler (включить ошибки и взаимоблокировки тоже)? Для каких ресурсов (висят) вставки ждут?

Answer 3

В дополнение к рекомендациям Митча я бы также предложил устранить проблему, запустив трассировку SQL, чтобы убедиться, что для каждого вызова хранимой процедуры используется один и тот же «фактический», а не «оценочный» план выполнения.

Кроме того, проверьте, что при каждом выполнении обрабатывается одинаковое или подобное количество записей / BULK INSERT, потому что, естественно, чем больше записей вставлено процедурой, тем больше времени потребуется для выполнения.

Считаете ли вы, что размер вашей базы данных может не соответствовать размеру ваших вставок? Например, нужно ли увеличивать размер файла данных вашей базы данных, чтобы он соответствовал выполнению любой другой процедуры?

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

Answer 4

Посмотрите на контрольно-пропускные пункты.

Я видел то же самое при загрузке большого количества данных.

Проблема в том, что ядро ​​базы данных записывает грязные страницы из памяти на диск.

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