MS SQL Server тормозит со временем?

Мы нашли это. Оказалось, что на самом деле проблема с одним из пулов приложений возникла на веб-сервере. Он застрял, выполняя один и тот же набор запросов снова и снова (что случилось с временными таблицами). Это будет просто зацикливаться и в конечном итоге заставит SQL-сервер грустить. Как только этот пул ошибочных машин / приложений был найден и «отложен», все было решено.

Вы должны спросить себя, что происходит при перезапуске службы SQL? Многое, но на ум приходят два важных момента:

1) память SQL освобождена.

это возможно (не уверен, насколько вероятно), что если параметр MaxMemory установлен слишком высоко, служба SQL будет использовать всю доступную память, и Windows начнет перекачивать важные данные в файл подкачки. Убедитесь, что для MaxMemory установлено разумное значение, оставляя достаточно дополнительной памяти для всего остального, что необходимо для работы в этом блоке (это выделенный сервер SQL? Или это также сервер приложений?)

2) TempDB перестраивается из размеров по умолчанию.

Проверьте размер файла tempdb по умолчанию, особенно размер по умолчанию и интервал роста файла журнала TempDB. Если задан слишком низкий интервал роста, то в журнале может возникнуть невероятная внутренняя фрагментация, которая может значительно замедлить нормальное использование. Видеть эти два отличные статьи в блоге Кимберли Трипп.

Вы часто используете временные таблицы или курсоры? Убедитесь, что курсоры закрываются и освобождаются правильно. Также следите за связанными серверами - мы должны использовать драйвер с ошибками для старого связанного сервера Informix, и это периодически означает, что мы должны перезагружать сервер.

Если это выглядит странно, ищите странное.

Если настройка параметров сервера sql не помогает, попробуйте диспетчер задач Windows: перейдите на вкладку процессы, затем параметры> столбцы> добавить время процессора, дескрипторы, чтение, запись, другие параметры и параметры памяти.

Вернитесь к списку процессов. Для каждого столбца отсортируйте по убыванию и просмотрите 5 первых процессов. Что-нибудь необычное? например У утечки памяти в процессе будет странное количество дескрипторов. У нас есть несколько * ki-принтеров, которые добавляют дескриптор к процессу DCSLoader каждые 2 секунды. Через несколько недель машина перечисляет много свободной памяти и ЦП, но процесс со 100 000 дескрипторов почти не перемещает указатель мыши.

Также проверьте свой список запланированных задач. Скажите вашему AV не сканировать файлы .mdf.

Дэйв,

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

Если ваша "модель восстановления" резервной копии ПОЛНАЯ, то делает ли резервное копирование БД, а затем резервное копирование журналов транзакций вообще что-нибудь? В системе, в которой не хватает места на диске, подобные вещи могут объяснить проблему.

Похоже, у меня конфигурация очень похожа на вашу (16 ГБ, обновлено до 32 ГБ и MD1000 с терабайтом дисков, двухъядерный процессор xeon).

Единственное, что помогало мне диагностировать подобные странные проблемы в прошлом, - это beta_lockinfo пользователя Erland Sommarskog. Запустите его, когда время идет медленно, и сравните.

Также у меня было безумное количество проблем с SQL 2005 до SP2, но SP3 действительно стабилен.

Надеюсь, это даст больше полезной информации:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Убедитесь, что db подходит для:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Следите за пространством журнала с помощью:

DBCC SQLPERF(LOGSPACE)

Если вы видите, что расширение продолжается, это определенно замедлит работу. Если вы запустите это, вы увидите, что ваше пространство журнала все ближе и ближе к 100%, затем журнал будет расширяться, а процент уменьшится, поскольку в нем есть место. Надеюсь, вы никогда не увидите, как он расширяется, пока не сработает ваша резервная копия и не очистит журнал.

В основном идиотская конфигурация. Бывает.

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

• Во-вторых, не увеличивайте базу данных автоматически и особенно не уменьшайте ее автоматически. В зависимости от загрузки автоматическое увеличение / автоматическое сжатие в основном самоубийственные настройки.

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