Oracle クエリと PL/SQL プロシージャ (トリガー、制約など) の静的アナライザーを探しています。これは、DB スキームを渡し、潜在的なデッドロックを指摘するツールです。JavaのFindBugsと同じです。
そのようなツールが存在しない場合、あなたはそれを持ちたいですか?
Oracle クエリと PL/SQL プロシージャ (トリガー、制約など) の静的アナライザーを探しています。これは、DB スキームを渡し、潜在的なデッドロックを指摘するツールです。JavaのFindBugsと同じです。
そのようなツールが存在しない場合、あなたはそれを持ちたいですか?
10g 以降、データベースには静的 PL/SQL アナライザーが組み込まれています。
ALTER SESSION SET PLSQL_WARNINGS = 'ENABLE:ALL';
PLSQL_WARNINGS を Google で検索すると、役立つリファレンスがいくつか見つかります。
私はマシューに同意しますが、デッドロックを特に効果的に検出できるアナライザーを見つけることができる可能性は低いです... 変数が多すぎます。
デッドロックは、静的コードではなくトランザクションに依存します。Oracle には「BEGIN TRANSACTION」ステートメントの概念がないため、静的アナライザーはトランザクションの開始点を知る方法がありません。仮説的には、アナライザーは、開始 SQL または PL/SQL ステートメントが与えられた場合に、すべての潜在的な実行パスを追跡し、更新/削除/挿入/マージ ステートメントの対象となったテーブルをどの順序で決定できるように記述できます。次に、その 2 つ (またはそれ以上) の結果を「比較」して、テーブルが異なる順序で操作されている場所があるかどうかを判断できます (たとえば、TAB_A の次に TAB_B と TAB_B の次に TAB_A と)。それは多くの誤検知を投げかけると思います。
Oracle では、select はロックされません (SELECT...FOR UPDATE を除く)。そのため、デッドロックはデータの更新時にのみ発生し、2 つの同時トランザクションが同じ行を更新しようとしている場合にのみ発生します。
TOAD には、いくつかの静的分析 (または少なくともある種のコード品質) ツールがあります。しかし、彼らがデッドロックを見つけることができるとは思えません。
どのデータベースにもデッドロックが発生する可能性は無限にあります。したがって、どのデッドロックが統計的に毎年 1 回以上発生するかを知るために、ツールには使用統計が必要です。そのようなツールは、開発作業を正当化するには複雑すぎます。
最も一般的な方法は、データベースを Q&A または実稼働環境にインストールすることです。そして、実際に発生するデッドロックを監視します。Q&A 環境に対して自動化された単体テストを実行して、負荷をシミュレートできます。