SQL Server: изменчивая статистика использования
Содержание:
1.Индексирующие объекты динамического управления (Вы читаете данный раздел);
2. Сохранение результатов из sys.dm_db_index_usage_stats;
3. Добавления статистики чтения-записи и соответствующая сортировка.
Sys.dm_db_index_physical_stats — лишь один из семи (на сегодня) объектов динамического управления:
• dm db index_operational_stats;
• dm db index_physical_stats;
• dm_db_index_usage_stats;
• dm_db_missing_index_columns;
• dm_db_missing_index_details;
• dmdbmissingindexgroupstats;
• dm db missing index_groups. Существуют дополнительные «индексирующие» объекты DMO, но они связаны с полнотекстовым индексированием и выполняющейся в памяти OLTP (Hekaton) и выходят далеко за рамки данной статьи. В дальнейшем мы рассмотрим каждый из этих объектов — последние четыре, ориентированные на отсутствующие метаданные индекса, будут представлены вместе, так как по отдельности они бесполезны.
Динамическое административное представление с подходящим названием dm_db_index_usage_ stats предоставляет информацию об использовании каждого индекса базы данных на экземпляре SQL. Как большинство объектов DMO, информация не сохраняется после перезапуска службы, поэтому к ее использованию следует относиться внимательно. Я всегда старался представить количество времени, прошедшее после удаления метаданных, с помощью одной из программных конструкций:
2. Использование session_id в Iogin_ time:
Любой вариант должен дать один и тот же результат (в минутах), и поскольку речь идет о принятии производственных решений по индексации на основе этого временного интервала, а ваши результаты измеряются в минутах, то, возможно, будет полезно пересмотреть требования ко времени непрерывной работы серверов.

Кроме того, необходимо понимать деловую среду и правила, которым должны соответствовать базы данных. Некоторые индексы можно использовать только для периодических операций (ежемесячных, ежеквартальных, сезонных или ежегодных). Большой ошибкой может быть решение об удалении индекса, который не использовался в последние четыре месяца, если впоследствии выяснится, что он применяется один раз в год при расчете налогов. Впрочем, это решение может оказаться и верным. В зависимости от размеров индекса, с учетом как числа строк, так и соотношения активности при чтении и записи, может быть полезно удалить индекс, когда он не используется, и восстановить его перед периодическим применением.
1.
2. Сохранение результатов из sys.dm_db_index_usage_stats;
3. Добавления статистики чтения-записи и соответствующая сортировка.
Индексирующие объекты динамического управления
Sys.dm_db_index_physical_stats — лишь один из семи (на сегодня) объектов динамического управления:
• dm db index_operational_stats;
• dm db index_physical_stats;
• dm_db_index_usage_stats;
• dm_db_missing_index_columns;
• dm_db_missing_index_details;
• dmdbmissingindexgroupstats;
• dm db missing index_groups. Существуют дополнительные «индексирующие» объекты DMO, но они связаны с полнотекстовым индексированием и выполняющейся в памяти OLTP (Hekaton) и выходят далеко за рамки данной статьи. В дальнейшем мы рассмотрим каждый из этих объектов — последние четыре, ориентированные на отсутствующие метаданные индекса, будут представлены вместе, так как по отдельности они бесполезны.
Изменчивая природа результатов, получаемых из dm_db_index_usage_stats
Динамическое административное представление с подходящим названием dm_db_index_usage_ stats предоставляет информацию об использовании каждого индекса базы данных на экземпляре SQL. Как большинство объектов DMO, информация не сохраняется после перезапуска службы, поэтому к ее использованию следует относиться внимательно. Я всегда старался представить количество времени, прошедшее после удаления метаданных, с помощью одной из программных конструкций:
SELECT create_date
, DATEDIFF(dd, create_date, GETDATE()) AS days_metadata
FROM sys.databases
WHERE name = 'tempdb';2. Использование session_id в Iogin_ time:
SELECT login_time
, DATEDIFF(dd, login_time, GETDATE()) AS days_metadata
FROM sys.sysprocesses
WHERE spid = 1;Любой вариант должен дать один и тот же результат (в минутах), и поскольку речь идет о принятии производственных решений по индексации на основе этого временного интервала, а ваши результаты измеряются в минутах, то, возможно, будет полезно пересмотреть требования ко времени непрерывной работы серверов.

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