Oracle 11gR2 の使用:
特定のテーブルから、指定された保持日を過ぎたレコードを削除することで、特定のテーブルをクリーンアップするプロセスが既にあります (レコードの処理が終了したときのタイムスタンプと保持日の比較に基づきます)。現在、このプロセスが失敗した場合にチームに警告するコードを作成しています。このプロセスが失敗する可能性があることを確認できる唯一の方法は、クリーンアップしようとしている特定のテーブルで DELETE が無効になっている場合です。
アラートをテストして、プロセスを失敗させてアラートが機能し、正しく表示されることを確認したいと考えています。テーブルを一時的に排他的にロックすると、DELETE が無効になり、レコードを削除する手順が失敗しますか? それとも、DDL 操作を無効にするだけですか? これを行うより良い方法はありますか？
「失敗」とは、たとえばパフォーマンスの限界を超えることではなく、「エラーをスローする」ことを意味すると仮定すると、テーブルをロックしても目的は達成されません。SELECT FOR UPDATE1 つのセッションですべての行をロックするdeleteと、最初のセッションがロックを解除するのを待って、ジョブが永久にブロックされます。これはエラーをスローせず、ほとんどの定義でプロセスが失敗する原因にもなりません。ただし、監視に予想よりも長く実行されているジョブのアラートが含まれている場合は、うまく機能します。
監視プロセスが、プロセスが実行されてエラーが発生したかどうかのみを確認する場合、最も簡単なオプションは、削除があるときにエラーをスローするトリガーをテーブルに配置することです。子行が存在するときに親行を削除しようとすると、エラーを生成する外部キー制約を持つ子テーブルを作成することもできます。プロセスの実装方法によってdeleteは、監視しているプロセスの ORA-00060 デッドロックを生成する 2 番目のプロセスを設計することもできますが、これはおそらくトリガーや子テーブルよりも実装が困難です。