10046 trace name context forever

前回 、Oracleの場合と同様にPostgreSQLのCOMMIT失敗時にトランザクションの結果が不定になる状況を確認しました。 今回は、PostgreSQL 10から導入された行方不明になってしまったトランザクションの結果を確認するtxid_status()について確認してみます。 前回のCOMMIT問題のまとめ txid_status()を使う流れ txid_status()でトランザクションの結果が不明になった状態を確認する大まかな流れは以下のような感じになります。 COMMIT前のトランザクションIDをtxid_current()もしくはtxid_current_if_assigned()で取得しておく COMMITの状態が不明になった場合に、1で取得したtxidを引数にしてtxid_status()でトランザクションの状態を確認する 前回 と同じ方法でCOMMITエラーを発生させてみる WALファイルへの書き込み完了前に障害が発生した場合 1) INSERTを実行(AUTOCOMMITはoffに設定) postgres=# insert into sample_table values (1); 2) txid_current()でトランザクションIDを取得 postgres=# select txid_current(); txid_current -------------- 627 (1 行) 3) backendのrecvfrom(2)をブロック(上記シーケンス図の①の部分) postgres=# select pg_backend_pid(); pg_backend_pid ---------------- 18623 (1 行) $ gdb -p 18623 ... (gdb) catch syscall recvfrom Catchpoint 1 (syscall 'recvfrom' [45]) (gdb) c Continuing. 4) COMMITを実行 postgres=# commit; 上記の状態でCOMMITが完了することはありません 5) この状...

前回 、Oracleのトランザクションガードについて見てみました。 せっかくなので、というか単純に興味があったのでPostgreSQLのCOMMITの動きやOracleと同じく障害発生のタイミングによりトランザクションが行方不明になった時の対処方法を見てみたいと思います。 PostgreSQLのCOMMITの様子 とてもざっくりですが、PostgreSQLのCOMMITの様子を見てみます。 PostgreSQL 11のcommitの動き psqlなどクライアントは"COMMIT"という文字列をsendto(2)でbackendのソケットに書き込みます クライアントからのI/Oイベントにより起床したbackendは以下の処理を行います recvfrom(2)で"COMMIT"を受け取る write(2)でWALファイルにlog bufferの内容を書き出す write(2)でWALに書き出した後backendは以下の処理を行います fdatasync(2)でファイルシステムのキャッシュにあるデータを物理デバイスと同期させる sendto(2)によりクライアントにCOMMIT完了のメッセージを送信 recvfrom(2)でメッセージを受け取ったクライアントは最終的にCOMMIT完了の処理を実施(psqlの場合はコンソールに"COMMIT"を書き出す) 余談 ちなみに、PostgreSQLにwalwriterというプロセスがいますが"COMMIT"に限定すると通常のwalwriterはその名前から想像できるようなWALファイルへの書き込みを実行しません。walwriterは5秒おき(*)にlog bufferの内容をコミットの有無に関係なくWALファイルに書き込みを実施しますがCOMMIT時の同期書き込みはbackendが実施しています。しかし、トランザクションが非同期コミットとして設定される場合(synchronous_commit=offの場合)では、backendに送られたCOMMITをトリガーにCOMMIT自体のWAL recordがwalwriterにより非同期、バッチ的にWALファイルに書き込まれます。 5秒(wal_w...

前回 、COMMITの失敗時にトランザクションの成否は未確定で、タイミングによっては成功している場合もあるし、失敗している場合もあることを検証しました。 今回は、そのような不安定なトランザクションの状態を確認する方法としてOracle 12c R1からサポートされたトランザクションガードがどのようなものが確認してみます。 前回のCOMMIT問題のまとめ トランザクションガードの前提 トランザクションガードはOracle 12c R1以降でサポートされます。また、次に示す クライアント・ドライバをサポートしています。 12c JDBCタイプ4(Thin)ドライバ 12c OCI、OCCIクライアント・ドライバ 12c Oracle Data Provider for .NET (ODP.NET)、管理対象外ドライバ 12c ODP.NET、ODAC 12c リリース4以降の管理対象ドライバ 詳細は データベース開発ガイド を確認してください。 トランザクションガードを使うための準備 今回は、JDBC(Thin)ドライバを使ってトランザクションガードの動きを確認してみますがいくつか準備を実施します。 トランザクションガードに対応するサービスの作成(変更) 以下のようなSQLでサービスを作成しますが、COMMIT_OUTCOME=TRUEおよびRETENTION_TIMEOUTを適切なサイズにしてサービスを作成(変更)する必要があります。(以下はサービスを作成しています) DECLARE PARAMETER_ARRAY DBMS_SERVICE.SVC_PARAMETER_ARRAY; BEGIN PARAMETER_ARRAY('COMMIT_OUTCOME'):='true'; PARAMETER_ARRAY('RETENTION_TIMEOUT'):=604800; DBMS_SERVICE.CREATE_SERVICE( 'TX_GUARD','TX_GUARD',PARAMETER_ARRAY); DBMS_SERVICE.START_SERVICE('...

この記事は、 JPOUG Advent Calendar 2019  の22日目の記事です。 21日目はryota_hnkさんの 11gしか知らないオッサンが19cを触る でした。そして、なんと5年ぶりにJPOUG Advent Calendarで書くのですが(そもそも、このブログで何か書くのも5年ぶり...)、最近ちょっと考えてみた誰もが知っていて日常的に使っている「COMMIT」について書いてみたいと思います。 COMMITにおけるREDOログへの同期I/Oがパフォーマンス上問題になっている際によく観測される待機イベントは皆さんがご存知の"log file sync"になるのですが、ここでは深く触れません。"log file sync"について知りたい方は、以下、かなり昔にCOMMITにまつわるLog Writerの仕組みを書いたので参考にしてもらえると良いと思います。(ブラウザで見ると文字化けする部分があるのですが、ダウンロードするときれいに見えるとフィードバックをもらっています) Dbts2013 特濃jpoug log_file_sync from Koji Shinkubo COMMITの仕組みのおさらい 今回は、普段あまり気にしない(と思われる)COMMITの「失敗」や「成功」、さらにCOMMITの結果が「不明」といった状況について考えてみたいと思います。知っている人も多いと思いますが、念の為COMMITを実行した時の動き(若干デフォルメされ複数存在するlog writer workerはlg00と記載してます)を確認しておきます。 18c(12c以降)でのコミット時のシーケンス図 sqlplusなどクライアントは"COMMIT"という文字列をwrite(2)でServer Processのソケットに書き込みます "COMMIT"を受け取ったServer Processはsemctl(2)でlog writer(lgwr)を起床させます 起床したlog writer worker(lg00)はpwrite64(2)でオンラインREDOログにlog bufferの内容およびCOMMIT自体のchange vecto...