12

膨大な数の従来のストアド プロシージャが機能していて、問題が発生しています。これらの手順をよりよく理解するのに役立つツールをお勧めしますか? プロシージャ間の依存関係および/またはプロシージャとテーブルの依存関係を特定するある種のリバース エンジニアリング。無料または商用のツールを使用できます。

ありがとう！

4

8 に答える 8

6

「依存関係トラッカー」よりも安価なソリューションは、データ ディクショナリ テーブル sys.sql_dependencies です。このテーブルから、データ ディクショナリからこのデータをクエリできます。Oracle には、DBA_DEPENDENCIES (および同等の USER_ および ALL_ ビュー) と呼ばれる同様の機能を持つデータ ディクショナリ ビューがあります。他のデータ ディクショナリ テーブル (sys.tables/DBA_TABLES) などを使用して、オブジェクトの依存関係レポートを生成できます。

特に興味がある場合は、再帰クエリ (Oracle CONNECT BY または SQL Server 共通テーブル式) を使用して、完全なオブジェクト依存関係グラフを作成できます。

sys.sql_dependencies での再帰 CTE の例を次に示します。すべての依存関係のエントリとその深さを返します。項目は、すべての依存関係に対して異なる深さで複数回発生する可能性があります。DBA_DEPENDENCIES で CONNECT BY クエリを作成するための動作中の Oracle インスタンスがないため、編集権限と時間と専門知識を持っている人なら誰でも、この回答に注釈を付けたり編集したりできます。

sys.sql_dependenciesから列参照を取得できることにも注意してくださいreferenced_minor_id。これは (たとえば)、実際に使用されているよりも多くの列を持つソースからの DB テーブルのコピーを使用して、ステージング領域から ETL sproc で実際に使用された列を特定するために使用できます。

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 インスタンスが手元にありません。

于 2008-09-18T16:07:16.870 に答える
4

Redgate には、要件を満たすと思われるSQL Dependency Trackerと呼ばれるかなり高価な製品があります。

于 2008-09-16T07:00:49.620 に答える
3

rpetrich が言及した Red Gate Dependency Tracker はまともなソリューションだと思います。うまく機能し、Red Gate には 30 日間の試用版があります (理想的には、フォレンジックを行うのに十分な長さです)。

また、システムを分離して、テーブルに対するすべての SQL アクションを表示する SQL プロファイラーを実行することも検討します。これは、多くの場合、シーケンス図を作成するための適切な出発点であり、これらのコードを文書化することを選択します。幸運を！

于 2008-09-16T07:07:51.070 に答える
1

Jacob Sebastianによるデータベースオブジェクト（MS SQL Server 2000（？）+）の依存関係チェーンを見つける方法

新しいレポートを展開したり、既存のレポートを変更したりする必要があるたびに、特定のレポートストアドプロシージャに依存するデータベースオブジェクトを知る必要があります。レポートが非常に複雑な場合があり、各ストアドプロシージャには数十の依存オブジェクトがあり、各依存オブジェクトは他の数十のオブジェクトに依存している場合があります。

彼は、特定のストアドプロシージャのすべての依存オブジェクトを再帰的に見つける方法を必要としていました。これを実現するために、CTEを使用して再帰クエリを作成しました。

于 2011-10-27T22:33:48.063 に答える
1

Redgate SQL ドキュメント。生成されたドキュメントには、相互参照された依存情報が含まれていました。たとえば、テーブルごとに、そのテーブルを参照するビュー、ストアド プロシージャ、トリガーなどを一覧表示します。

于 2008-09-17T02:47:49.593 に答える
1

ストアド プロシージャはどのデータベースにありますか? Oracle、SQL Server、その他の何か?

コメントに基づく編集: Oracle を使用している場合は、TOADをご覧ください。その中の Code Roadmap と呼ばれる機能を使用します。これにより、データベース内の PL/SQL の相互依存性をグラフィカルに表示できます。ランタイム コール スタックの依存関係を表示するコード オンリー モードで実行するか、コードによって操作されるデータベース オブジェクト (テーブル、ビュー、トリガー) も表示するコード プラス データ モードで実行できます。

(注 - 私は TOAD ユーザーであり、参照しても何のメリットもありません)

于 2008-09-17T18:46:07.870 に答える
1

これはあまり深くも完全でもありませんが、MS SQL Server または Oracle を使用している場合 (おそらく Nigel が PL-SQL サンプルで役立つ可能性があります)...Nigel は何かに取り組んでいます。これは 3 つの依存関係の深さしかありませんが、必要な深さまで変更することができます。それは最も美しいものではありません...しかし、それは機能的です...

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
于 2008-09-18T17:02:55.130 に答える
0

リバースエンジニアリングに最適なツールはAPEXによるものです。すごい。.NETアセンブリをトレースして、procが使用されている場所を通知することもできます。その種の製品の中で群を抜いて最も深い。RedGateには他にも優れたツールがありますが、この場合はありません。

于 2008-09-18T20:34:45.607 に答える