Дано: есть проект, который на боевом сервере живет несколько лет и постоянно дорабатывается и перерабатывается разными людьми по живому, часто в режиме "дедлайн был вчера". Там есть база, субд mssql 2008. За время существования проекта в базе скопилось множество всяческих хранимок, функций и временных таблиц, значительная часть из которых определенно не используется и никогда не будет: может больше не нужны, может в процессе разработки создали временную и забыли удалить. И когда я смотрю на все эти авгиевы конюшни у меня чешутся руки вычерпать оттуда ведерко-другое. Однако сразу же встает проблема: как не выплеснуть с водой младенца, то есть не выпилить случайно что-нибудь лишнее. Вопрос: есть ли какие-нибудь способы с помощью механизмов встроенных в субд выяснить, что такая-то хранимая процедура или функция точно вызывалась за последнее время? Были ли обращения к этой таблице? Может быть, какой-нибудь анализ кешей или что-нибудь в этом роде? Как бы Вы решали аналогичную проблему? Сразу говорю - вопрос скорее теоретический, поэтому замечательный практический совет "Работает - не трожь" мне не нужен, я итак скорее всего ему последую. Пока мне в голову приходит: 1). Определить подозрительные процедуры, встроить в них логирование и посмотреть есть ли что-нибудь в логах через некоторое время. Однако я подозреваю что какой-нибудь встроенный механизм логирования есть итак. 2). Распарсить серверные исходники на предмет обращения к базе и посмотреть что они цепляют. Но во-первых, серверные исходники - еще большее болото. Во-вторых, придется потом парсить результаты первого шага, потому что не все же цепляется напрямую из кода, некоторое только базой.
Ответ
Для начала рекомендую взглянуть сюда: sys.dm_db_index_usage_stats - тут использование всех индексов с момента последнего перезапуска SQL Server'а. Поскольку любая таблица - это тоже индекс, с типом HEAP или с типом CLUSTERED, вы сможете получить таблицы, к которым ни разу не обращались с перезапуска сервера. Естественно, это не поможет от выпиливания "очень важной и нужной" таблицы, к которой обращаются раз в год, но без нее никак. Так что лучше, конечно, всех кандидатов на удаление для начала поискать в коде серверной части. По хранимым процедурам статистики нет, но можно выгрузить код хранимых процедур, триггеров и функций, и опять же простым поиском поискать таблицы - кандидаты на удаление. Если хранимая процедура обращается к таблице, которая ни разу не запрашивалась - есть подозрение, что хранимая процедура тоже не используется. Такой поиск еще поможет обнаружить ситуации, когда таблица редко, но используется именно из хранимой процедуры, например, для сбора информации о сбоях.
Комментариев нет:
Отправить комментарий