SQL Server 2000: поиск в базе данных - PullRequest
0 голосов
/ 13 октября 2009

Некоторые записи в моей таблице обновляются со значением xyz в определенном столбце. Как из сотен хранимых процедур, функций, триггеров определить, какой код выполняет это действие. Есть ли способ поиска по базе данных, как через каждый сценарий кода?

Пожалуйста, помогите.

Ответы [ 3 ]

3 голосов
/ 13 октября 2009

Один из подходов - проверить системные комментарии

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

  e.g.  select text from syscomments

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

Попробуйте это

Select text from syscomments
where CharIndex('x', text) > 0 
and CharIndex('y', text) > 0 
and CharIndex('z', text) > 0

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

0 голосов
/ 16 ноября 2009

Вы можете использовать sql-profiler для отслеживания обновления данной таблицы / столбца.

0 голосов
/ 13 октября 2009

Это будет почти невозможно сделать в SQL Server 2000, потому что обновление вполне может происходить из переменной, имеющей это значение, или соединения с другой таблицей, которая имеет это значение и не жестко запрограммирована в хранимом процессе, триггер и т. д. Обновление также может происходить из пакета DTS, задания, фрагмента динамического кода, запускаемого приложением, или даже из анализатора запросов, поэтому сам код может нигде не записываться в базе данных.

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

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

Вот подсказка о том, как вы можете получить некоторую информацию, которую вы хотите для конечного кода триггера, который вы пишете:

create table #temp (eventtype nvarchar (1000), parameters int, eventinfo nvarchar   (4000), myspid int)

declare @myspid int
select @myspid =@@spid

insert #temp (eventtype,parameters, eventinfo)
exec ('dbcc inputbuffer (@@spid)')

update #temp set myspid = @ myspid

выберите имя хоста, имя_программы, eventinfo от #temp t присоединиться к sysprocesses s на t.myspid = s.spid ГДЕ spid = @ myspid

...