2

バックエンドが本番環境で使用するのに十分な品質であるかどうかを確認できるように、オラクルのストーム バックエンドで単体テストを実行する任務を負っています。私が直面している問題の 1 つは、シリアル化可能モードで接続すると、ORA-08177 (このトランザクションのアクセスをシリアル化できません) が発生することです。コミット読み取りモードを使用すると、問題はなくなります。

この質問記事を読んだところ、これは基本的に同時実行の問題であることがわかりました。

データベースに接続しているスレッドが 1 つしかなく、世界中でこのデータベースに接続している人がいないと仮定すると、このエラーが発生する可能性はありますか? もしそうなら、誰かがこのエラーを生成するクエリの例を教えてくれませんか?

それとも、これはカーソルまたは接続がどこかで閉じられていないことを示している可能性がありますか? または、トランザクションがコミットまたはロールバックされていませんか?

4

2 に答える 2

1

「トリガーが関係していますが、更新や挿入ではなく、DDLステートメントでエラーが発生します。」

DDLステートメントは独自のコミットを処理する必要があります。基本的に、それらはコミットを実行し、次にメタデータを変更し（これには、多数の基になるオブジェクトが含まれる可能性があります）、次に再度コミットします（DDLが成功した場合、失敗した場合は変更をロールバックする必要があります）。

したがって、DDLを実行している場合は、コミットし、トランザクションを読み取りコミットに変更し、DDLを実行してから、トランザクションをシリアライズ可能に戻すのが安全です。完全なテストケース（または少なくともあなたが話している種類のDDL）を与えることができれば、それは役立つかもしれません。たとえば、マテリアライズド・ビューの作成またはCREATE TABLE AS SELECTは、DDL（固有のコミットを含む）とDMLのように、「奇数」になる場合があります。

于 2009-06-19T00:22:50.320 に答える
1

セッションが 1 つだけの場合、このエラーは発生しません。ただし、次のスクリプトは、最初のセッションとは無関係に行を更新するセカンダリ セッションを生成し、ORA-8177 をトリガーできるようにします。これがあなたの望むものかどうかわかりません。

検討：

SQL> alter session set isolation_level=serializable;

Session altered
SQL> create table test (a number);

Table created
SQL> insert into test values (1);

1 row inserted
SQL> commit;

Commit complete
SQL> declare
  2     pragma autonomous_transaction;
  3  begin
  4     update test set a = 2;
  5     commit;
  6  end;
  7  /

PL/SQL procedure successfully completed
SQL> update test set a = 3;

update test set a = 3

ORA-08177: can't serialize access for this transaction
于 2009-06-16T15:08:55.737 に答える