Oracle Open World 2019とコミットキャッシュ [最新動向]

今年もOOWへ参加することができた。3泊5日の弾丸ツアーでかなり慌ただしかったが、帰りのフライトでようやくホっと一息つけたので、振り返って感じたことをメモしておく。

IMG_0050.jpg


今年のOOWは9/16-19と昨年と比べると1か月程度早めで、このうち私が参加できたのは初日と2日目のみであった。OOWといっても、ラリーのキーノートはライブで配信されいずれ記事にもなるので、ここで改めて書くつもりはない。また、Oracle Linuxがautonomousになっても、開発用にオラクルクラウドが無償提供されるようになっても、コーポレートカラーが赤から黒になって、雰囲気が変わったことなど、私にとってはどうでも良いことである。私が今回一番印象に残ったExadataのコミットキャッシュについて記載したい。

Exadataのコミットキャッシュとは、コミット済みトランザクション情報をストレージサーバ側にキャッシュし、未コミットブロックを遅延ブロッククリーンアウトが必要かストレージサーバ上でチェックできる仕組みである。これにより、スマートスキャンが遅延ブロッククリーンアウトにより阻害される状況を防ぐことができる。

今回OOWにて、Exadataの技術責任者の方とお話しできる機会があり、以前このブログで紹介した「exadataと遅延ブロッククリーンアウトとシングルブロックリード」の事例について説明した。すると彼女は、まず、ロングトランザクションがないことを確認した上で、即座に何らかの原因でこのコミットキャッシュが効いていない可能性を指摘した。具体的なキャッシュサイズは教えてくれなかったが、サイズは有限であるはずなので、遅延ブロッククリーンアウトまでに発生したコミット回数が多いと、キャッシュがパージされる可能性は高まるだろう。さすがに開発している技術者だけあって、原因の核心に辿り着くのが早い。

実は私もExadataの遅延ブロッククリーンアウト時の挙動は気になっており、行きのフライトの中でExpert Oracle Exadata(下記参考文献[1])の該当部分(p.388-389)をコピーして(重いので)読み直していたのだが、その中でコミットキャッシュに被疑があるのではと考えていた。簡単に訳すと以下のような内容である。若干翻訳は正確でないかもしれないが、著者の意図は変えていないつもりなので、ご容赦願いたい。

---
もしロックされたトランザクションがまだコミットしていなければ、スマートスキャンはブロックI/Oモードに切り替わり、DBレイヤで通常の読み取り一貫性の処理、つまりバッファクローニング、ロールバックといったメカニズム、を通らなければならない。そして、これを避けるワークアラウンドはない。・・・

トランザクションがコミットされているのに、いくつかのブロックのいTL上のロックバイトがクリーンアウトされていない状況(通常、大量の更新後に発生し、遅延ブロッククリーンアウトと呼ばれる)では、スマートスキャンはブロックI/Oに切り替える必要はない。読み取り一貫性メカニズムを行う必要もない。なぜなら、セルは、ロックを保持しているトランザクションは本当はコミットされており、これらの行は既にロック解除されている、ということを知っているからである。たとえ、ロックバイトが(ITL上に)まだあったとしても、である。

特定のトランザクションがRDBMS上でコミットされたことを、セルはどの様に知るのだろうか。これは、最近コミットされたトランザクションの番号をキャッシュすることで実現されており、「コミットキャッシュ」と呼ばれる。ロックバイトが設定された行を多く読まなければならないとき、コミットキャッシュがなければスマートスキャンの性能は悪くなるだろう。

コミットキャッシュは恐らく単なるインメモリのハッシュ表で、トランザクションIDで構成されているだろう。そして、どのトランザクションがコミットされたか、されていないかを記録し続ける。セルスマートスキャンがロックされた行に遭遇すると、トランザクションIDをデータブロックのITLから取り出し、コミットキャッシュ上にそのトランザクション情報があるかチェックする。このチェックで「cell commit cache queries」が1増加する。

もしコミットキャッシュにそのようなトランザクションが無ければ、スマートスキャンには不運であるが、読み取り一貫性処理をしなければならないので、遅いシングルブロックリード処理に戻る。一方、キャッシュにヒットした場合は「cell blocks helped by commit cache」が1増加する。
---

上記部分は以前、「ExadataのI/O統計を整理する」をメモした際に一度読んではいたが、今改めて読むと良く理解できる。まだ勉強が足りないなと反省する次第である。

いずれにしても今回OOWを終えて思うのは、現地開発者との距離の近さが、問題解決のスピードに決定的な違いを生むという事実である。適切な問い合わせ先組織・人に、問題を明確に伝えられれば、今回の様に1時間の打ち合わせでも、適格に問題を特定できると実感した。Oracle databaseもExadataも核心はソフトウェアであり、所詮開発者がコーディングしたプログラムに過ぎない。問題が発生すれば、普段はブラックボックス前提でサポート問い合わせし、満足いかない回答にサポートを罵るような現場は少なくない。しかし、適切な開発者と直接コミュニケーションできれば世界観が変わる。もちろん、そのようなパスは一朝一夕にできる訳はなく、この様な機会を通じてお互いの信頼関係を築いていくしかないのだろうと考えるのである。

なお、その他のトピックとしてExadata関連では、今回X8M (MはMemory performanceを表すらしい) が発表されたことである。以前「Exadataと不揮発性メモリ」で、できたら面白いと記載していたが、それが現実となった形である。しかも今回IBがRocE (Ethernet上のRDMA)に切り替え、帯域が40Gb/sから100Gb/sに向上している。これについては既にGavin Parish氏の以下のBlog記事が出ており、OOWで聞いてきた内容もおおむねここに記載されているように思う。

Introducing Exadata X8M: In-Memory Performance with All the Benefits of Shared Storage for both OLTP and Analytics

また、会場で面白そうなOracleのトラシュー本(下記参考文献[2])があったので手に取ったら、著者が昨年のOOWで講演を聞かせていただいたFarooq氏だったので、思わず(重いのにもかかわらず)買ってしまった。いつ読めるかわからないが、こちらについてもまた紹介できたらと思う。

以上

◆参考文献
[1] Expert Oracle Exadata

Expert Oracle Exadata

Expert Oracle Exadata

  • 作者: Martin Bach
  • 出版社/メーカー: Apress
  • 発売日: 2015/08/13
  • メディア: ペーパーバック



[2] Oracle Database Problem Solving and Troubleshooting Handbook

Oracle Database Problem Solving and Troubleshooting Handbook

Oracle Database Problem Solving and Troubleshooting Handbook

  • 作者: Tariq Farooq
  • 出版社/メーカー: Addison-Wesley Professional
  • 発売日: 2016/04/28
  • メディア: ペーパーバック



nice!(0)  コメント(0) 

nice! 0

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

※ブログオーナーが承認したコメントのみ表示されます。