SQL Server: сохранение результатов из sys.dm_db_index_usage_stats. Продолжение
Другой вариант — сначала назначить контекст базы данных lifeboat с помощью синтаксиса USE , но я всегда предпочитал полностью определенные имена, поскольку, как и всем администраторам, мне пару раз приходилось направлять запросы к базе данных с неправильной областью. По мере подготовки сценария мы продолжаем применять SELECT * к sys.dm_db_indexjusage_stats. При этом, вероятно, возвращаются необязательные столбцы. Прежде чем удалить их, я приведу полный список столбцов для этого динамического административного представления:
• database_id;
• objectid;
• index_id;
• user_seeks;
• user_scans;
• userlookups;
• user_updates;
• last_user_seek;
• last_user_scan;
• lastuserlookup;
• last_user_update;
• system_seeks;
• system_scans;
• systemlookups;
• systemupdates;
• last_system_seek;
• last_system_scan;
• last_system_lookup;
• last_system_update.
• objectid;
• index_id;
• user_seeks;
• user_scans;
• userlookups;
• user_updates;
• last_user_seek;
• last_user_scan;
• lastuserlookup;
• last_user_update;
• system_seeks;
• system_scans;
• systemlookups;
• systemupdates;
• last_system_seek;
• last_system_scan;
• last_system_lookup;
• last_system_update.
После начального анализа меня интересовали только столбцы, относящиеся к last_user|system_ action, при наблюдении за малоиспользуемыми индексами. Поэтому теперь мы исключим эти столбцы и вернемся к ним в следующей статье. Аналогично, меня не волнует, как SQL Server обращается к этим индексам, поэтому я исключил все столбцы, основанные на действиях системы (systemseeks, system_scans и т. д.). Теперь, когда для идентификации используются удобные имена, можно исключить и столбцы database_id и object id.
Столбец index_id полезен для идентификации типа индекса (0 = куча | 1 = кластеризованный | > 1 = некластеризованный).
Необходимо рассмотреть как отдельные типы операций чтения, так и сумму этих операций чтения в сравнении с операциями записи, чтобы обеспечить базовые метрики чтения и записи. Наш запрос раскрывает полезные сравнительные сведения о чтении и записи, на которые направлено большинство решений, полученных на основе этого динамического административного представления (вновь используем lifeboat для замены шаблонного параметра ) (см. код ниже). Результат представлен на скриншоте выше. На данном этапе мы выяснили, как направить запрос к этому динамическому административному представлению, ограничить диапазон результатов и осмысленно идентифицировать результаты. Еще две настройки для базового запроса, и мы сможем приступить к начальному анализу результатов.
SELECT DB_NAME(ixUS.database_id) AS database__name
, SO.name AS object__name
, SI.name AS index__name
, ixUS.index_id
, ixUS.user_seeks
, ixUS.user_scans
, ixUS.user_lookups
, (ixUS.user_seeks + ixUS.user_scans + ixUS.user_lookups) AS total_reads
, ixUS.user_updates AS total_writes
FROM sys.dm_db_index_usage_stats AS ixUS
INNER JOIN lifeboat.sys.objects AS SO
ON SO.object_id = ixUS.object_id
INNER JOIN lifeboat.sys.indexes AS SI
ON SI.object_id = ixUS.object_id
AND SI.index_id = ixUS.index_id
WHERE ixUS.database_id = DB_ID('<db_name,,>')
ORDER BY OBJECT_NAME(ixUS.object_id), ixUS.index_id;Проверка операций чтения