Найти избыточные страницы, файлы, хранимые процедуры в устаревших приложениях

Question

У меня есть несколько ужасов старых веб-приложений ASP. У кого-нибудь есть какие-либо легкие способы найти, какие скрипты, страницы и хранимые процедуры больше не нужны? (Кроме материала в "old___code", "delete_this", и т.д. ;-)

Answer 1

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

Если у вас есть объекты sp и базы данных в исходном контроле (и если вы этого не сделаете, почему бы и нет?), Возможно, вам удастся выполнить и найти, какой другой код был перенесен в производство, с которым следует дайте вам понять, что может называть это. Вы также сможете увидеть, кто его последний коснулся, и этот человек может знать, нуждается ли он в этом.

Я обычно подхожу к этому, сначала перечисляя все procs (вы можете получить это из системных таблиц), а затем отмечая те, которые, как я знаю, используются вне списка. Профилировщик может помочь вам здесь, как вы можете видеть, которые обычно вызываются. (Но не предполагайте, что, поскольку профайлер не показывал proc, что он не используется, это просто дает вам список тех, которые нужно исследовать.) Это делает те, которые нужно убрать гораздо меньший список. В зависимости от вашего соглашения об именах может быть относительно легко увидеть, какая часть кода должна их использовать. При исследовании не забывайте, что procs вызывается в других местах, кроме приложения, поэтому вам нужно будет проверять задания, пакеты DTS или SSIS, отчеты SSRS, другие приложения, триггеры и т. Д., Чтобы убедиться, что что-то не используется.

Как только вы определили список тех, которые вам не нужны, поделитесь ими с остальными сотрудниками отдела разработки и спросите, знает ли кто-нибудь, требуется ли proc. Вероятно, вы получите пару, вышедшую из списка, которая используется для чего-то специализированного. Затем, когда у вас есть список, измените имена на какое-либо соглашение, которое позволяет вам идентифицировать их как кандидата для удаления. В то же время установите дату удаления (насколько далеко эта дата зависит от того, как часто можно что-то вызывать, если она называется чем-то вроде AnnualXYZReport, а затем сделать эту дату в год). Если никто не жалуется на дату удаления, удалите proc (конечно, если он находится в исходном управлении, вы можете вернуть его обратно даже тогда).

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

Я не могу придумать какой-либо простой способ сделать это, это просто вопрос определения того, что нельзя использовать и проваливать.

Answer 2

Для SQL Server только 3 варианта, которые я могу думать:

• изменить сохраненные проки для журнала использования
• проверить, если код имеет никаких разрешений не установлен
• запустить профайлер

и конечно, удалить доступ или удалить его и посмотреть, кто звонит ...