У нас проблема с огромным количеством действующих хранимых процедур. Ребята, вы порекомендуете какой-либо инструмент, который поможет лучше понять эти процедуры? Некий вид обратного проектирования, который идентифицирует межпроцедурные зависимости и / или зависимости между процедурами и таблицами. Может быть бесплатным или коммерческим инструментом.
Спасибо!

У Redgate есть довольно дорогой продукт под названием Трекер зависимостей SQL, который, кажется, удовлетворяет требованиям.
Я думаю, что Red Gate Dependency Tracker, упомянутый rpetrich - достойное решение, оно работает хорошо, и у Red Gate есть 30-дневная пробная версия (в идеале достаточно долгая, чтобы вы могли провести свою экспертизу).
Я бы также подумал об изоляции системы и запуске SQL Profiler, который покажет вам все действия SQL в таблицах. Часто это хорошая отправная точка для построения диаграммы последовательности или как вы решите документировать эти коды. Удачи!
Redgate SQL Doc. сгенерированная документация включала информацию о зависимостях с перекрестными ссылками. Например, для каждой таблицы перечислены представления, хранимые процедуры, триггеры и т. д., Которые ссылаются на эту таблицу.
В какой базе данных хранятся хранимые процедуры? Oracle, SQL Server, что-то еще?
Редактировать на основе комментария: Если вы используете Oracle, обратите внимание на ЖАБА. Я использую в нем функцию под названием Code Roadmap, которая позволяет графически отображать взаимозависимости PL / SQL в базе данных. Он может работать в режиме «Только код», показывая зависимости стека вызовов времени выполнения, или в режиме «Код плюс данные», где он также показывает объекты базы данных (таблицы, представления, триггеры), затронутые вашим кодом.
(Примечание - я пользователь TOAD и не получаю никакой пользы от ссылки на него)
Более дешевым решением, чем «трекер зависимостей», является таблица словаря данных sys.sql_dependencies, из которой эти данные могут быть запрошены из словаря данных. Oracle имеет представление словаря данных с аналогичной функциональностью, называемое DBA_DEPENDENCIES (плюс эквивалентные представления USER_ и ALL_). Используя другие таблицы словаря данных (sys.tables / DBA_TABLES) и т. д., Вы можете создавать отчеты о зависимостях объектов.
Если вам особенно интересно, вы можете использовать рекурсивный запрос (Oracle CONNECT BY или SQL Server Common Table Expressions) для построения полного графа зависимостей объектов.
Вот пример рекурсивного CTE для sys.sql_dependencies. Он вернет запись для каждой зависимости с ее глубиной. Элементы могут встречаться более одного раза, возможно, на разной глубине для каждого отношения зависимости. У меня нет рабочего экземпляра Oracle для создания запроса CONNECT BY для DBA_DEPENDENCIES, поэтому любой, у кого есть права редактирования, время и опыт, может комментировать или редактировать этот ответ.
Также обратите внимание на sys.sql_dependencies, что вы можете получить ссылки на столбцы из referenced_minor_id. Это можно использовать (например), чтобы определить, какие столбцы фактически использовались в sprocs ETL из промежуточной области с копиями таблиц БД из источника с большим количеством столбцов, чем фактически используется.
with dep_cte as (
select o2.object_id as parent_id
,o2.name as parent_name
,o1.object_id as child_id
,o1.name as child_name
,d.referenced_minor_id
,1 as hierarchy_level
from sys.sql_dependencies d
join sys.objects o1
on o1.object_id = d.referenced_major_id
join sys.objects o2
on o2.object_id = d.object_id
where d.referenced_minor_id in (0,1)
and not exists
(select 1
from sys.sql_dependencies d2
where d2.referenced_major_id = d.object_id)
union all
select o2.object_id as parent_id
,o2.name as parent_name
,o1.object_id as child_id
,o1.name as child_name
,d.referenced_minor_id
,d2.hierarchy_level + 1 as hierarchy_level
from sys.sql_dependencies d
join sys.objects o1
on o1.object_id = d.referenced_major_id
join sys.objects o2
on o2.object_id = d.object_id
join dep_cte d2
on d.object_id = d2.child_id
where d.referenced_minor_id in (0,1)
)
select *
from dep_cte
order by hierarchy_level
Теперь у меня есть возможность открыть это сообществу. Может ли кто-нибудь с удобным доступом к работающему экземпляру Oracle опубликовать здесь рекурсивный запрос CONNECT BY? Обратите внимание, что это специфично для SQL-сервера, и с тех пор владелец вопроса ясно дал понять, что он использует Oracle. У меня нет работающего экземпляра Oracle для разработки и тестирования чего-либо.
Это не очень глубоко или тщательно, но я думаю, что если вы используете MS SQL Server или Oracle (возможно, Найджел может помочь с образцом PL-SQL) ... Найджел кое-что понимает. Это касается только трех зависимостей, но может быть изменен так, как вам нужно. Не самое красивое ... но функциональное ...
select
so.name + case when so.xtype='P' then ' (Stored Proc)' when so.xtype='U' then ' (Table)' when so.xtype='V' then ' (View)' else ' (Unknown)' end as EntityName,
so2.name + case when so2.xtype='P' then ' (Stored Proc)' when so2.xtype='U' then ' (Table)' when so2.xtype='V' then ' (View)' else ' (Unknown)' end as FirstDependancy,
so3.name + case when so3.xtype='P' then ' (Stored Proc)' when so3.xtype='U' then ' (Table)' when so3.xtype='V' then ' (View)' else ' (Unknown)' end as SecondDependancy,
so4.name + case when so4.xtype='P' then ' (Stored Proc)' when so4.xtype='U' then ' (Table)' when so4.xtype='V' then ' (View)' else ' (Unknown)' end as ThirdDependancy
from
sysdepends sd
inner join sysobjects as so on sd.id=so.id
left join sysobjects as so2 on sd.depid=so2.id
left join sysdepends as sd2 on so2.id=sd2.id and so2.xtype not in ('S','PK','D')
left join sysobjects as so3 on sd2.depid=so3.id and so3.xtype not in ('S','PK','D')
left join sysdepends as sd3 on so3.id=sd3.id and so3.xtype not in ('S','PK','D')
left join sysobjects as so4 on sd3.depid=so4.id and so4.xtype not in ('S','PK','D')
where so.xtype = 'P' and left(so.name,2)<>'dt'
group by so.name, so2.name, so3.name, so4.name, so.xtype, so2.xtype, so3.xtype, so4.xtype
Единственный лучший инструмент для обратного проектирования - APEX. Это потрясающе. Он даже может отслеживать сборки .NET и сообщать вам, где используются процедуры. Это, безусловно, самый глубокий продукт в своем роде. У RedGate есть отличные другие инструменты, но не в этом случае.
Как найти цепочку зависимостей объекта базы данных (MS SQL Server 2000 (?) +) Джейкоб Себастьян
Every time he needs to deploy a new report or modify an existing report, he needs to know what are the database objects that depend on the given report stored procedure. Some times the reports are very complex and each stored procedure might have dozens of dependent objects and each dependent object may be depending on other dozens of objects.
He needed a way to recursively find all the depending objects of a given stored procedure. I wrote a recursive query using CTE to achieve this.
Не знал об этом. Но я думаю, что это не очень удобно. Я все же посмотрю.