Как почистить замусоренную боевую бд?

#база_данных #sql_server #рефакторинг #sql

Дано: есть проект, который на боевом сервере живет несколько лет и постоянно дорабатывается
и перерабатывается разными людьми по живому, часто в режиме "дедлайн был вчера".
Там есть база, субд mssql 2008. За время существования проекта в базе скопилось множество
всяческих хранимок, функций и временных таблиц, значительная часть из которых определенно
не используется и никогда не будет: может больше не нужны, может в процессе разработки
создали временную и забыли удалить. 
И когда я смотрю на все эти авгиевы конюшни у меня чешутся руки вычерпать оттуда
ведерко-другое. Однако сразу же встает проблема: как не выплеснуть с водой младенца,
то есть не выпилить случайно что-нибудь лишнее.

Вопрос: есть ли какие-нибудь способы с помощью механизмов встроенных в субд выяснить,
что такая-то хранимая процедура или функция точно вызывалась за последнее время? Были
ли обращения к этой таблице? Может быть, какой-нибудь анализ кешей или что-нибудь в
этом роде?
Как бы Вы решали аналогичную проблему?

Сразу говорю - вопрос скорее теоретический, поэтому замечательный практический совет
"Работает - не трожь" мне не нужен, я итак скорее всего ему последую.
Пока мне в голову приходит:
1). Определить подозрительные процедуры, встроить в них логирование и посмотреть
есть ли что-нибудь в логах через некоторое время. Однако я подозреваю что какой-нибудь
встроенный механизм логирования есть итак.
2). Распарсить серверные исходники на предмет обращения к базе и посмотреть что они
цепляют. Но во-первых, серверные исходники - еще большее болото. Во-вторых, придется
потом парсить результаты первого шага, потому что не все же цепляется напрямую из кода,
некоторое только базой.    

Ответы

Ответ 1

Для начала рекомендую взглянуть сюда: sys.dm_db_index_usage_stats - тут использование
всех индексов с момента последнего перезапуска SQL Server'а. Поскольку любая таблица
- это тоже индекс, с типом HEAP или с типом CLUSTERED, вы сможете получить таблицы,
к которым ни разу не обращались с перезапуска сервера.
Естественно, это не поможет от выпиливания "очень важной и нужной" таблицы, к которой
обращаются раз в год, но без нее никак. Так что лучше, конечно, всех кандидатов на
удаление для начала поискать в коде серверной части.
По хранимым процедурам статистики нет, но можно выгрузить код хранимых процедур,
триггеров и функций, и опять же простым поиском поискать таблицы - кандидаты на удаление.
Если хранимая процедура обращается к таблице, которая ни разу не запрашивалась - есть
подозрение, что хранимая процедура тоже не используется. Такой поиск еще поможет обнаружить
ситуации, когда таблица редко, но используется именно из хранимой процедуры, например,
для сбора информации о сбоях.


Ответ 2

Для начала запустила бы sys.dm_db_index_usage_stats 
После того, как получила неиспользуемые объекты - проверила, какие другие объекты
с ними связаны (right click по имени таблицы,  из меню выбрать View Dependecies), и
затем Profiler-ом отлавливала к ним обращения