SQL Server: как определить подходящее время для обновления статистики таблиц / индексов - PullRequest
Новая
       32

SQL Server: как определить подходящее время для обновления статистики таблиц / индексов

0 голосов
/ 09 октября 2018

Могу ли я спросить, есть ли способ узнать подходящее время для обновления статистики таблиц / индексов?

В последнее время производительность ухудшается с одной из основных таблиц витрины данных в нашем BI-DWH, SQL Server 2012Все индексы обрабатываются каждые выходные для реорганизации / перестройки в соответствии с их процентом фрагментации, и теперь они меньше 5% как avg_fragmentation_in_percent.

Таким образом, мы обнаруживаем, что это вызвано устаревшей статистикой таблицы / индекса или фрагментацией таблицы или около того..

Как правило, мы включили автоматические статистические данные, и статистика таблиц / индексов была обновлена ​​в июле 2018 г.ежедневное увеличение примерно на 0,5 млн. записей.

Вот статистика PK и фактическое количество записей в этой таблице. 

-- statistics

dbcc show_statistics("DM1","PK_DM1")

Name    Updated Rows        Rows            Sampled     Steps   Density     AveragekeylengthString      Index   Filter Expression   Unfiltered Rows
------------------------------------------------------------------------------------------------------------------------------------------------------
PK_DM1  07 6 2018  2:54PM   661696443       1137887     101         0                       28          NO          NULL                661696443

-- actual row count

select count(*) row_cnt from DM1;

row_cnt
-------------
706723646

-- Current Index Fragmmentations

SELECT a.index_id, name, avg_fragmentation_in_percent  
FROM sys.dm_db_index_physical_stats (DB_ID(N'DM1'), 
      OBJECT_ID(N'dbo.DM1'), NULL, NULL, NULL) AS a  
    JOIN sys.indexes AS b 
      ON a.object_id = b.object_id AND a.index_id = b.index_id;   
GO  

index_id    name    avg_fragmentation_in_percent
--------------------------------------------------
1        PK_DM1             1.32592173128252
7        IDX_DM1_01         1.06209021193359
9        IDX_DM1_02         0.450888386865285
10       IDX_DM1_03         4.78448190118396

Таким образом, разница между статистикой составляет менее 10%, но более 45 миллионовколичество строк и фактическое количество записей.Мне интересно, может ли стоить обновить статистику таблицы / индекса вручную в этом случае.

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

Спасибо.

- Результат

Благодаря совету @scsimon я подробно проверил всю статистику индекса, и в главном индексе отсутствовал RANGE_HI_KEY - этот индекс основан надата регистрации и не было диапазона после июля 2018 года последняя обновленная статистика.(Заявление было сделано пользователем, когда он искал записи за сентябрь 2018 года)

Поэтому я решил обновить статистику таблиц / индексов и подтвердил, что этот же запрос был улучшен с 1 часа 45 минут до 3,5 минут.

Дилпи оценил все советы на мой вопрос.

С наилучшими пожеланиями.

1 Ответ

0 голосов
/ 09 октября 2018

Ну, у вас есть автоматическое обновление статистики, так что это хорошо.Кроме того, каждый раз, когда индекс перестраивается, статистика пересчитывается.SQL Server 2008R2 и более поздние версии, вплоть до 2016 года, ведут себя так же, как и TF 2371, что означает, что для большой таблицы требуется меньше строк, которые необходимо изменить для автоматического вычисления. Подробнее об этом читайте здесь.

Также вы показываете статистику для одного индекса, а не для всей таблицы.Этот индекс может быть отфильтрован.И помните, что Общее количество строк, выбранных для статистических вычислений.Если Rows Sampled Подробнее об этом можно прочитать здесь

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

  • Конфликт / нераспределение памяти
  • Узкое место в процессоре
  • Параллелизм (возможно, MAXDOP установлен в 0)
  • Медленные диски
  • Недостаточно памяти, что приводит к физическим чтениям
  • План выполнения больше не является оптимальным, и, возможно, вам нужно перекомпилировать этот запрос
  • и т. Д.,и т. д. и т. д. ... именно здесь будет отображаться план выполнения и статистика ожидания
...