Очистка Базы данных MSSQL - Как Вы находите неиспользуемые объекты (Таблицы, Представления, Procs, Функции)
Tcl {фигурные скобки} похожи на 'одинарные кавычки' оболочки - расширение переменных внутри не выполняется.
Вы должны использовать различные цитаты:
set value "PublicKey"
set cmd "cat .pass | cut -d'&' -f1 | openssl base64 -d | openssl enc -d -rc2 -k $value"
set output [ exec sh -c $cmd ]
puts $output
2 ответа
Это ТАК вопрос, Определяя Неиспользуемые объекты В Microsoft SQL Server 2005, могло бы быть релевантно.
Ответ будет зависеть немного от того, как база данных была соединена, но мой подход к подобной проблеме был 3-кратным:
Фигура, какие объекты не имеют никаких внутренних зависимостей. Можно работать это из запросов против sysdepends, таких как:
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), поскольку Вы только захотите изолировать таблицы, функции, сохранил procs и представления. Также проигнорируйте любые процедуры стартовый "SP _", если люди не создавали процедуры с теми названиями Вашего приложения!
Многие возвращенные процедуры могут быть точками входа Вашего приложения. То есть процедуры, которые называют от Вашего прикладного уровня или от некоторого другого удаленного вызова и не имеют никаких объектов, которые зависят от них в базе данных.
Принятие процесса не будет слишком агрессивно (это создаст некоторую дополнительную загрузку, хотя не слишком много) можно теперь включить некоторое профилирование SP:Starting, SQL:BatchStarting и / или события SP:StmtStarting. Выполните это столько, сколько Вы считаете целесообразным, идеально входя в sql таблицу для легких перекрестных ссылок. Необходимо смочь устранить многие процедуры, которые называют непосредственно из приложения.
Перекрестными ссылками текстовые данные из этого журнала и Вашего зависимого списка объектов Вы, надо надеяться, изолируете большинство неиспользованных процедур.
Наконец, можно хотеть взять список кандидатов, следующий из этого процесса и grep база исходного кода против них. Это - громоздкая задача и просто потому что Вы находите, что ссылки в Вашем коде не означают необходимость в них! Может просто случиться так, что код не был удален, хотя это теперь логически недоступно.
Это далеко от идеального процесса. Относительно чистая альтернатива должна настроить намного более подробный (и поэтому агрессивный) представляющий на сервере для контроля всего действия. Это может включать каждый SQL-оператор, названный в течение времени, журнал активен. Можно затем работать назад через зависимые таблицы или даже зависимости перекрестной базы данных от этих текстовых данных. Я нашел надежность детали журнала (слишком много строк, в секунду пытаясь быть проанализированным) и чистый quanitity данных, трудных иметь дело с. Если Ваше приложение, менее вероятно, пострадает от этого затем, это может быть хороший подход.
Протест:
Поскольку, насколько я знаю, нет идеального ответа на это особенно опасаться удалять таблицы. Процедуры, функции и представления легко заменяются, если что-то идет не так, как надо (хотя удостоверяются, что у Вас есть они в управлении исходным кодом прежде, чем записать их, конечно!). Если Вы действительно нервничаете, почему бы не переименовать таблицу и создать представление со старым названием, Вы затем вывели легкое.