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

У меня есть таблица 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) Clustered Index on StatusID 2) Индекс репликации в столбце rowguid, который является уникальным некластеризованным индексом, созданным репликацией автоматически.

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

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

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

Click here for Execution plan

источник

2012-01-30 Thakur

Репликация работает, когда вы делали эти тесты? Если БД является подписчиком, вы фактически не должны удалять \ обновлять свои данные, если вы? – Diego

Пожалуйста, не отправляйте сообщения во ВСЕХ CAPS. Это грубо, и кажется, что вы «кричите». –

@Diego да репликация работает + ее репликация слиянием, поэтому обновление вставки может работать на любом из подписчиков и издателей – Thakur

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

UPDATE STATISTICS StatusMaster

источник

2012-01-30 13:37:21 RedFilter

его помогло сократить время выполнения, но все еще занимает 20 нечетных секунд. – Thakur

иногда занимает 1 секунду, а иногда и более 15 секунд, потребление памяти на сервере составляет 2,5 ГБ из 4 ГБ, а загрузка процессора составляет 45%. – Thakur

Возможно, что столбец 'StatusID' имеет низкую мощность, так что он выполняет сканирование таблицы. Что скажет ваш план выполнения? – RedFilter

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

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

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

источник

2012-01-30 13:44:09

. Я перестроил индексы и обновил статистику, но все же столкнулся с проблемой – Thakur

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

источник

2012-01-30 15:01:19 Arvo

, как я могу узнать, поврежден ли мой массив RAID? – Thakur

Запросите человека, который управляет этим компьютером, на котором расположен SQL-сервер. Вам нужно проверить журналы событий Windows и, если они есть, журналы состояния RAID-контроллера. Я не говорю, что это ваш случай - у меня нет опыта в репликации и я не могу сказать, какое влияние это может вызвать; Я просто намекнул, что иногда странные задержки вызваны аппаратными проблемами. – Arvo

Поскольку эта таблица находится в репликации, и я получаю ошибку на 4-5 серверах, я не думаю, что это будет проблема RAID – Thakur

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

ответ

Смежные вопросы