Надежна ли информация в sys.dm_db_index_usage_stats?

Я архивирую данные из старой системы, у которой нет документации. Повезло мне ...

Я хотел бы узнать, когда таблицы создавались, когда к ним обращались и т. Д. Могу ли я верить, что этот запрос даст мне правильный ответ или есть какие-то параметры, которые мне сначала нужно проверить? SQL Server 2008 R2:

 SELECT t.Name AS Tabelname, p.rows AS NoOfRows, MAX(us.last_user_lookup) AS LastUsed, t.create_date AS CreatedDate
FROM sys.tables t
INNER JOIN      
    sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN 
    sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
LEFT JOIN --A lot of the tables did not have any records in this table
    sys.dm_db_index_usage_stats as us ON t.OBJECT_ID = us.OBJECT_ID
GROUP BY t.Name, p.rows, create_date
ORDER BY MAX(us.last_user_lookup) DESC

Нет.

Представление sys.dm_db_index_usage_statотражает в лучшем случае только данные с момента последнего запуска базы данных (последний запуск экземпляра или последний раз, когда БД была подключена к сети). Кроме того, записи могут очиститься под давлением памяти. Это даст точные положительные результаты (если таблица имеет ненулевую статистику, то она используется)), но может дать ложные отрицательные значения (0 использование в статистике может не отражать фактическое использование). Также есть много систем, которые используют определенные таблицы только один раз в неделю, один раз в месяц или даже один раз в год.

Вот еще одна причина, почему вы не можете слепо полагаться на DMV sys.dm_index_usage_stats. sys.dm_db_index_usage_stats не обновляется после использования индекса только для статистики, связанной с индексированными столбцами. Павел показал это в своей ссылке.

Что sys.dm_index_usage_stats DMV не говорит вам

Вы также хотели бы читать

Эта статья об индексе использования статистики DMV

Кроме того, IMO, я не думаю, что при использовании DMV существует ИДЕАЛЬНЫЙ способ узнать, когда таблица использовалась в последний раз. Я считаю, что использование трассировки профилировщика или расширенной трассировки событий было бы более лучшим вариантом. Хотя профилировщик может вызвать нагрузку, трассировка на стороне сервера - хороший вариант.