Как узнать, какие таблицы наиболее доступны или часто используются в SQL-сервере

Question

В настоящее время я нахожусь в ситуации, когда мне нужно выяснить, какие таблицы часто используются или сколько раз в нашем приложении в течение определенного периода времени.Давайте скажем от некоторого startDate до endDate.

Подробности, которые я хотел бы получить, это tableName и сколько раз к нему обращались.Например: -

tableName    No.Of Access
Table5        100
Table2         80
...
Tablen         n

Также было бы замечательно, если бы вышеупомянутый запрос или был какой-либо другой способ проверить, какие столбцы в этих таблицах часто используются.Идея этого упражнения - правильно индексировать столбцы в большинстве используемых таблиц.Но я не уверен, что это правильный путь для оптимизации тоже.Так что, если у вас, ребята, есть более подходящие альтернативы, чтобы определить, как оптимизировать вышеперечисленное, это также было бы здорово.

Мы используем SQL Server 2005, и приложение работает на .net framework 3.5, размещенном на IIS.Если потребуется дополнительная информация, дайте мне знать.

Answer 1

Единственное, что мне известно о чем-либо подобном этому типу информации, это sys.dm_db_index_usage_stats

Редактировать: получается, что более достоверная информация может быть получена из

select * from sys.dm_db_index_operational_stats(db_id(),NULL,NULL,NULL)

Разница между тем, что оба отчета хорошо освещены в этом сообщении в блоге .

Answer 2

Я бы настроил «плохо работающую» базу данных, чтобы сначала определить проблемные запросы, а затем оптимизировать их, а не пытаться оптимизировать все сразу.

Вы можете использовать SQL Profiler для выявления плохо выполняющихся запросов. В зависимости от вашей системы отслеживайте соответствующие события RPC, пакета SQL, T-SQL или хранимых процедур, фильтруя события, которые занимают слишком много времени (я обычно начинаю с> 5 секунд) или которые выполняют слишком много операций чтения (я начинаю с 12800 чтений, около 100 МБ). Отследите их для подходящей продолжительности использования системы в «прайм-тайм», и вы получите представление о том, какие части вашей базы данных работают плохо, а какие - хорошо (то есть те, которые не отображаются в списке).

В качестве альтернативы, спросите своих пользователей (или себя), какие части системы работают плохо, и проверьте соответствующие запросы.

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