web-dev-qa-db-ja.com

カスケード削除についてのOracleの説明が間違っている

Oracle11での削除は非常に遅いです。テーブルは外部キーによってリンクされており、すべての外部キー制約には削除カスケードが設定されています。

このDELETE FROM TOP_LEVEL_TABLE WHERE SOMETHING = 'whatever'のようなステートメントで説明ボタンを押すと、他に30個のテーブルが含まれている場合でも、TOP_LEVEL_TABLEの関与のみが表示されます。

より現実的な結果を得るにはどうすればよいですか？

oracleperformanceoracle-11g-r2deleteexplain
3
Franz Kafka

これは不可能だと思います。

私が間違っていなければ、オプティマイザーは、ステートメントが他のテーブルにも「触れる」ことさえ知りません（または少なくとも知りようとはしません）。

明示的に文書化されていませんが、次の マニュアルからの引用 SQLステートメントで「参照されている」テーブルについてのみ説明しています（強調は私のものです）。

行ソースツリーは、実行プランの中核です。次の情報が表示されます。
-テーブルの順序 ステートメントによって参照されます
-ステートメントに記載されている各テーブルのアクセス方法
 .。

重要な部分は、「ステートメントによって参照されるテーブル」だと思います。 「依存」テーブルについては言及されていません。

編集：
その情報を抽出する必要がある場合は、おそらくセッションをトレースしてTKPROF出力を確認する必要があります。

5
a_horse_with_no_name

実行プランに含まれるテーブル全体を表示することはできません。 （カスケード外部キー制約による）ロックされたオブジェクトが考慮事項である場合は、次のクエリが役立ちます。

  1. スキーマでクエリを実行します。

  2. SYSTEMスキーマで次のクエリを同時に実行し、それを更新して、どの依存テーブルが関与してロックされているかを確認します（場合によっては、tkprofをチェックするよりも簡単です）。

    SELECT l.OS_USER_NAME,
        sys_context('userenv','ip_address') IP ,
        NVL(l.Oracle_username, '(Oracle)')  Oracle_USER_NAME,
        obj.OBJECT_TYPE,
        OBJECT_NAME,
        Decode(l.locked_mode,
              0, 'None',
              1, 'Null (NULL)',
              2, 'Row-S (SS)',
              3, 'Row-X (SX)',
              4, 'Share (S)',
              5, 'S/Row-X (SSX)',
              6, 'Exclusive (X)',
              l.locked_mode) locked_mode    ,
        v.SID  "SESSION_ID(SID)" ,
        v.SERIAL# ,
        v.INST_ID ,
        'ALTER SYSTEM KILL SESSION '''||v.SID ||','||v.SERIAL# ||',@'||  v.INST_ID||''' IMMEDIATE; '  KILL_COMMAND
from v$locked_object l   ,   
    dba_objects obj , 
    gv$session v
where obj.OBJECT_ID=l.OBJECT_ID
and v.SID  = l.SESSION_ID
and obj.OBJECT_NAME not like '%DR$%';
1
Amirhossein Farmad