問題タブ [read-committed]

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

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

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

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

オラクルに接続されたWebアプリに取り組んでいます。Oracleには、「アクティブ化された」列を持つテーブルがあります。この列を一度に1に設定できるのは1行だけです。これを強制するために、JavaでSERIALIZED分離レベルを使用していますが、「トランザクションをシリアル化できません」というエラーが発生し、その理由を理解できません。

READCOMMITTEDの分離レベルでうまくいくかどうか疑問に思っていました。だから私の質問はこれです：

次のSQLを含むトランザクションがある場合：

これらのトランザクションの複数が同時に実行される可能性があるとすると、複数のMODEL行でアクティブ化されたフラグを1に設定することは可能でしょうか？

どんな助けでもいただければ幸いです。

私は簡単な質問から始めます：

Wikipedia およびMsdnの Dirty Read の定義によると 、次のようになります。

T1 と T2 の 2 つの同時トランザクションがあります。

T1 が行を更新しており、T2 が T1 によって「まだコミットされていない」行を読み取っている場合、ダーティ リードが発生します。

ただし、Read Committed レベルでは、データが読み取られるとすぐに共有ロックが解放されます (トランザクションの終了時やステートメントの終了時でさえありません)。

では、Read Committed はどのようにダーティ リードを防止するのでしょうか? Bkaz 更新された行 T2 で解放された共有ロックが更新された行を読み取ることができ、t1 が操作全体をロールバックできるようになるとすぐに、t1 の手でダーティ リードが発生します。

Teradata が以下を使用していることがわかりました。

通常のデータベースで通常の read commited/dirty にどのように対応しますか? ありがとう。

『Oracle Database Concepts』という本の中で、オラクルは例を挙げて説明していますRead Committed Isolation Level。

この例では、トランザクション 1 が行 1 を更新し、トランザクション 1 がコミットされる前に、トランザクション 2 が同じ行を更新します。したがって、トランザクション 2 は、トランザクション 1 がコミットされるまで待機します。次に、トランザクション 1 がコミットされます。その後、トランザクション 2 がコミットされます。もちろん、トランザクション 2 がコミットされた後、トランザクション 1 による行 1 の更新は、トランザクション 2 によってオーバーライドされます。

この状況を と見なしlost updateます。しかし、私の見解では、トランザクション 1 がコミットされているため、「失われた更新」であってはなりません。失われた更新は、1 つのトランザクションで考慮されます。スケジュールは、読み取り操作に関係なく、シリアル化可能なスケジュールと同じです。

例はhere、またはより具体的にはhereです。

オラクルの用語集では、失われた更新は -

データの 1 つのライターが、同じデータを変更する別のライターの変更を上書きするデータ整合性の問題。

それで、あなたはこれについてどう思いますか？それは「失われた更新」ですか?もしそうなら、この種の失われた更新は、データベースの同時実行制御によって回避できますか?

コメントやヘルプをいただければ幸いです。

同じ主キーで新しい行を作成し、この行をロックする2 つのREAD COMMITTEDPostgreSQL データベース トランザクションがある場合、両方のロックを同時に正常に取得できますか?

これらの新しい行は両方とも個々のトランザクションのスコープにのみ存在するため、私の本能はイエスですが、新しい行とロックがトランザクション間で異なる方法で処理されるかどうかに興味がありました。

私には奇妙な状況があります。私は SQL Server 2005 データベースで作業しています。これを使用して DB のロックを検索しました。

終日キャプチャした後、トレースを停止して結果を確認すると、挿入をブロックするブロッキング クエリが見つかりましたが、クエリはコミットされた分離を読み取り、テーブル A を読み取り、挿入はすべての値が定義されたテーブル B に挿入しようとしました。

最初のクエリが 2 番目のクエリをブロックしている理由を知っている人はいますか?

2 つのテーブルのすべての依存関係を検索しましたが、何も見つかりませんでした。

これは、select ステートメントの分離レベルを変更することで解決できることはわかっていますが、なぜこの問題が発生するのか知りたいです。

ありがとう！

SO、私たちは画面に行くレポートを実行しようとしていますが、保存されているデータは変更されません。ただし、複雑なため、いくつかの (TEMPORARY*) テーブルを通過する必要があります。

レプリケートされたライブ テーブルからデータを取得します。

「適格な」レコードを取得する際の厄介な点

temp_PreCalc

ライブ データからデータを取り込み、次の (TEMPORARY*) テーブル出力を作成します。

効果的に次のようになります。

INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc live_Tab1 に参加 ... live_Tab2 に参加 ... live_Tab3 に参加 ...

レポートは「決定的な」回答ではありません。期待されるのは、単なる「スナップショット」レポートであり、画面に表示されるとすぐに古くなります。

順序や再現性の問題はありません。

したがって、理想的には、TRANSACTION ISOLATION LEVEL を READ COMMITTED に下げます...ただし、live_Tab1,2,3 は BIN_LOG STATEMENT タイプで複製されるため、できません...

ステートメントは素敵で迅速です-実行にほとんど時間がかからないため、リソースの負荷は以前よりも少なくなりました（選択と挿入を別々に行っていました）が、待機するSELECTのために（私が理解しているように）待機します結果を安全に複製できるように、live_Tab の反復可能/同期可能なロック用。実際、その待機のために時間がかかるようになりました。

応答時間のパフォーマンス上の利点を確認したいと思います!

ただし、データが (TEMPORARY*) テーブルに書き込まれてから破棄されます。

live_ テーブルの宛先はありません - ソースのみ...

• • これらのテーブルは、実際には TEMPORARY TABLES ではなく、動的に作成されて破棄される InnoDB テーブルです。これは、レポートの計算に自己結合と削除が必要なためです...しかし、それらは一時的なものです

私は今、答えを見つけるためにぐるぐる回っているようです。

SUPER 特権を持っていないので、この接続セッションで BIN_LOG=0 を設定することはできません (なぜこれが必要なのですか?)

そう...

すべての temp_ "Temporary" テーブルをレプリケーションから除外するスクラッチ データベースまたはテーブル ワイルドカードがある場合... (この変更がホスト センターで行われるのを待っています)

MySQL は私に許可しますか?

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

INSERT INTO temp_PostCalc (...) SELECT ... FROM temp_PreCalc JOIN live_Tab1 ON ... JOIN live_Tab2 ON ... JOIN live_Tab3 ON ... ;

それとも私はまだ私のものを手に入れますか

「ステートメントを実行できません: BINLOG_FORMAT = STATEMENT であるため、バイナリ ログに書き込むことができず、少なくとも 1 つのテーブルが行ベースのログ記録に限定されたストレージ エンジンを使用しています...」

技術的には真実ではありませんが？「INSERT」ステートメントが表示されるという理由だけでレプリケーションが開始され、実際には宛先がレプリケーションではない場合でも、レプリケーションに適格である関連するテーブルの簡単なチェックを行うと推測しているため、私はそれを期待しています。対象....

それとも嬉しい驚きでしょうか？

私は本当に不快なソリューションを使用して直面することはできません

OUTFILE を選択 LOAD DATA INFILE

実際、それを使用することさえできないと思います-どうすれば一意のファイル名を取得できますか? どうすればそれらをクリーンアップできますか? レポートはエンド ユーザーによってオンデマンドで直接実行され、サーバーへのアクセスは MySQL インターフェイスのみです。

またはPHPクライアントを介してストリーミングし、INSERTをSELECTから分離して、MySQLがどのテーブルがレプリケーションの対象であるかについて動揺しないようにします....