Простой запрос на обновление занимает слишком много времени

Question

У меня есть таблица CurrentStatus в моей базе данных (база данных подписки в репликации слиянием). Столбцы: StatusID {Primary Key + Clustered Index}, StatusName, StatusDate, UserID,CreatedDate, ModifiedDate, ModifiedBy, AllowDelete,AllowUpdate

Таблица CurrentStatus в виде 26000 строк

обновления и удаления в этой таблицевнезапно занимает слишком много времени, скажем, от 1 минуты 30 секунд до даже 5 минут.

Выполнение запроса ниже занимает минуту.

update StatusMaster set StatusName='OK' where StatusID = 22

Ранее в таблице было 5 индексов (даже тогдаэтот запрос выполнялся быстро.) Теперь, когда запросы на обновление / удаление не выполняются, я удалил все индексы и сохранил только два индекса 1) Кластерный индекс по StatusID 2) Репликационный индекс по столбцу rowguid, который является уникальным некластеризованным индексом, созданнымрепликация автоматически.

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

Еще одна вещь - у меня есть сложные запросы, которые выполняются каждые 2 минуты примерно с 20 машин насервер.

Что заставляет эти запросы тратить так много времени на выполнение?

Нажмите здесь для ExecПлан действий

Answer 1

Я рекомендую обновить статистику с помощью команды UPDATE STATISTICS , например:

UPDATE STATISTICS StatusMaster 

Answer 2

После большого количества вставок, удалений, обновлений и т. Д. Ваша таблица может стать фрагментированной и ваши индексы могут быть не оптимизированы. Я бы посоветовал вам переиндексировать и обновить статистику.

Когда вы делаете резервную копию и восстанавливаете ее, я полагаю, что вы выполняете то же самое, что и повторное индексирование, и обновление статистики.

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

Answer 3

В прошлый раз, когда некоторые простые запросы занимали ненормальное количество времени [в нашей маленькой компании], это было вызвано повреждением массива RAID в [к счастью, не производственном] SQL-сервере.