Ответ будет немного зависеть от того, как база данных была собрана, но мой подход к подобной проблеме был трехкратным:
Выясните, какие объекты не имеют внутренних зависимостей. Вы можете решить это из запросов к системным зависимостям, таким как:
select
id,
name
from
sys.sysdepends sd
inner join sys.sysobjects so
on so.id = sd.id
where
not exists (
select
1
from
sysdepends sd2
where
sd2.depid = so.id
)
Вы должны объединить это с сбором типа объекта (sysobjects.xtype), поскольку вам нужно будет только изолировать таблицы, функции, хранимые процедуры и представления. Также игнорируйте любые процедуры, начинающиеся с sp_, если только люди не создавали процедуры с этими именами для вашего приложения!
Многие из возвращенных процедур могут быть точками входа вашего приложения. То есть процедуры, которые вызываются из уровня вашего приложения или из какого-либо другого удаленного вызова и не имеют никаких объектов, которые зависят от них в базе данных.
Предполагая, что процесс не будет слишком инвазивным (он создаст дополнительную нагрузку, хотя и не слишком большую), теперь вы можете включить некоторое профилирование событий SP: Starting, SQL: BatchStarting и / или SP: StmtStarting. Запускайте это столько времени, сколько считаете нужным, в идеале входя в таблицу sql для облегчения перекрестных ссылок. Вы должны быть в состоянии устранить многие из процедур, которые вызываются непосредственно из вашего приложения.
Перекрестные ссылки на текстовые данные из этого журнала и списка зависимых объектов позволят выделить большинство неиспользуемых процедур.
Наконец, вы можете взять список кандидатов, полученный в результате этого процесса, и сопоставить с ними базу исходного кода. Это громоздкая задача, и если вы найдете ссылки в своем коде, это не значит, что они вам нужны! Может просто случиться так, что код не был удален, хотя теперь он логически недоступен.
Это далеко не идеальный процесс. Относительно чистой альтернативой является настройка гораздо более подробного (и, следовательно, инвазивного) профилирования на сервере для мониторинга всей активности. Это может включать в себя все операторы SQL, вызываемые во время активности журнала. Затем вы можете вернуться через зависимые таблицы или даже кросс-зависимости базы данных из этих текстовых данных. Я обнаружил надежность деталей журнала (слишком большое количество строк в секунду при попытке анализа) и огромное количество данных, с которыми трудно иметь дело. Если ваше приложение менее подвержено этому, то это может быть хорошим подходом.
Оговорка:
Потому что, насколько мне известно, не существует идеального ответа на этот вопрос, особенно опасаться удаления таблиц. Процедуры, функции и представления легко заменяются, если что-то идет не так (хотя, конечно, убедитесь, что они есть в контроле исходного кода, прежде чем записывать их!). Если вы действительно нервничаете, почему бы не переименовать таблицу и создать представление со старым именем, тогда у вас все получится.