最新動向 ブログトップ

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) 

19c新機能 ~ Oracle Cloud Days [最新動向]

8/6,7に新高輪で開催されたOracle Modern Cloud Day Tokyoの1日目に参加し、19cの新機能についての話を聞いてきた。内容は概ね以下のスライド通り。3点ほど気になった点があったので以下にメモしておく。

2019/4/22 TechNight資料

1点目。プレゼンを聞いていてリアルタイム統計がデフォルト有効、かつ、無効化するにはヒント(NO_GATHER_OPTIMIZER_STATISTICS)を使うという話があった。しかし現実問題、更改案件では無効化するために全てのSQLにヒントを入れることは不可能なので、この話は受け入れがたい。性能負荷はわずかである(minやmax、num_rowsといった最小限の統計のみ取得する)といいつつも、負荷もさることながら、統計変動による実行計画変動を避けたい、というニーズは変わらず存在するからだ。

実際、以下の初期化パラメータを設定(FALSE)することで無効化できる。隠しパラメータなので、おそらく積極的に設定されないよう、あまり公にしたくないという意図が感じられた。

"_optimizer_use_stats_on_conventional_dml" ・・・リアルタイム統計を使用するか制御するパラメータ
"_optimizer_gather_stats_on_conventional_dml" ・・・ リアルタイム統計を収集するか制御するパラメータ

また、12cからのダイレクトインサート時(CreateTableAsSelectやInsertAsSelect)の統計収集機能もある。これもヒントで制御できるが以下の初期化パラメータで無効化できる(デフォルト有効化)。

"_optimizer_gather_stats_on_load"

経験上、これは取得にそれなりの負荷がかかるので、意識してインサート時に統計取得したい!、という場合の除いて無効化しておくことが良いだろう。DWHの一時表など、そもそも取得の必要がない、あるいは統計ロック等で変動を抑える対処を検討済みのシステムを更改する場合などではなおさらである。

2点目。19cの高頻度自動オプティマイザ統計収集は、15分間隔でstaleになったテーブルの統計を取得する機能であるが、これが実装されたのは興味深い。以前、同様な機能を作りこもうとしている人をOracleコミュニティで見たことがあったからだ。DWHでロードするタイミングが複雑で、適切な統計取得のウィンドウを1つに決められないケースだったと記憶している。デフォルトオフなので、あまり気にすることはないが、何かに役立つかもしれないので覚えておきたい。

3点目。上記プレゼンの中で、自動インデックスのデモがあった。単純なフルスキャンの実行計画が自動インデックスにより1秒以下にチューニングされたというもの。正直、これだけでは商用でまともに使える感触までは得られなかったが、AUTO_INDEX_MODE=report onlyでレポートだけ作成してくれる機能があるので、例えば開発環境でバッチを一通り流してどのような自動インデックスが作成されるか見るという使い方はできるかもしれない(ただ、それならSQLアドバイザとかを使えばよいだけかもしれないが)。感覚的にはインデックス作成によるチューニングは入念な試験を経て初めて商用リリースできると思っているので、15分間隔のサイクルで自動で新たなインデックスが有効化される、という世界観がどれだけ受け入れられるのか、今後の動向を注視したい。

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

Exadataと不揮発性メモリ [最新動向]

ストレージサーバにCell RAMキャッシュと呼ばれるキャッシュがある。Cell RAMキャッシュはフラッシュキャッシュの前面に位置し、フラッシュキャッシュよりレイテンシは低く、容量は小さい。そのため、cell single block physical readが上位にくるOLTPのワークロードにおいて、あたかもバッファキャッシュの追加キャッシュがストレージサーバ上にあることにより、オンライン性能向上が期待できる。ストレージサーバソフトウェア18cからの機能であり、デフォルトでは無効化されている(ramCacheModeがautoに設定されている)。

ストレージサーバのRAMキャッシュがデフォルトで無効なのは、なにも新機能なので自信がない訳ではない。これを有効に使うためにはストレージサーバ側のメモリの増設が前提となる。マニュアルを見ると、AWRのBuffer Pool Advisoryから、バッファキャッシュをどの程度増やすとどの程度の物理読み込みが削減できるか確認できるが、これを見てCell側にどの程度のRAMを増設(メモリ拡張キット)するかを決定すればよいと記載されている。

RAMキャッシュの設定方法は簡単だ。cellcliからALTER CELL ramCacheMode=onして、ALTER CELL RESTART SERVICES CELLSRVによりcellsrvプロセスを再起動する。これをすべてのストレージサーバで実行すればよい。これで勝手に空きメモリをRAMキャッシュとして使うようになるそうだ。実際はバックグラウンドでRAMキャッシュは構成されるらしく、作成にはしばらく時間がかかるようだ。この様子はLIST CELL ATTRIBUTES ramCacheMaxSize,ramCacheMode, ramCacheSizeで確認できる。RAMキャッシュサイズの最大を制限することは、ALTER CELL ramCacheMaxSize=1Gのように実行できる。

昨年(2018年)秋のOOWでこの機能を紹介していたが、日本でも新機能として紹介されていた話なので特段目新しいとも思っていなかった。しかし、最近たまたま以下のブログでインテルのOptaneという不揮発性メモリがExadataで活用されようとしている話を知った。この記事は2018/10/22、ちょうどOOWの時期であったが、OOWのセミナではこのメモリの話はしていなかった記憶がある(もちろん自分の英語力にそれほど自信がある訳ではないが)。物理的には従来のDIMMスロットにそのまま刺せるので導入が容易らしい。

Exadata Persistent Memory Accelerator: Partnering with Intel on Optane DC Persistent Memory

インテルのOptaneのサイトを見ると、確かにOracleもこのメモリのベータプログラムに参加しており、ExadataのVice PresidentがExadataへの活用を紹介している。数TB程度のDBであれば、完全にインメモリで処理できるので、超低レイテンシのOLTP(証券取引やIoT)やリアルタイム分析の高速化といったユースケースを意識しているようだ。ちなみに同時期にGoogleもこのメモリを使ってクラウドサーバで7TBのサービスを提供すると発表していた。SAP HANAなどのインメモリDBへの利用も視野に入れているようだ。

Intel Optane DC Persistent Memory Hardware Beta Partners
Intel Optane DC Persistent Memory Partner: Oracle

今後の開発の方向性がどうなるかわからないが、ストレージサーバ上のDIMMスロット(の一部)がこの不揮発性メモリとなり、上記CELL RAMキャッシュにこの不揮発の領域がライトバックとしても使えるようになったら面白いかもしれない。フラッシュキャッシュよいさらに低いレイテンシ、高速に大量の処理が行えるようになるはずだ。また、これにあわせて特に分析用途ではCell側の集合計算などの機能拡充が決定的に重要になり、また処理のボトルネックはCell側のCPUになるかもしれない。

こうなってくると、もうインメモリの流れは止まらないと感じる、今日この頃である。
nice!(1)  コメント(0) 

Oracle Open World 2018で感じたこと [最新動向]

Oracleに関わるようになってから久しいが、今年初めてOracleOpenWorldに行く機会に恵まれた。Open Worldとは、毎年秋にサンフランシスコのモスコーンセンターにて開かれるOracle社の国際会議で、世界から6万人、日本からも200人以上がこのために集まる一大イベントである。今年2018年は10/22~25に開催された。
※当日のレジストレーションの様子。長蛇の列ができている。前日のレジストレーションはこんなに並ぶことはなかった。

DSC_0586 (480x640).jpg


正直、始めはわざわざサンフランシスコまで行く必要があるのか、と思っていた。ラリーエリソンの話なら、いつもまとめられた記事で読めるし、興味があればWebで動画で見られる。そもそも、それらの話(多くは製品や開発のビジョンやコンセプトなど)を聞いたところで、日々の業務に直接役立つことがあるとも思えなかった。ところが、実際に行ってみるといくつか全く新しい気づきがあったので、以下に思いつくまま特筆すべきことを記載しておく。なお、ラリーエリソンのキーノートやクラウドの話は既によい記事があちこちに出ているので、ここでの記載は控える。

まず1つ目は、OracleOpenWorldは開発者のための技術の情報共有の場であるということ。10/22~25の4日間に2500以上のテクニカルセッションが開かれるため、興味のあるテーマやスピーカーで好きなセッションを選ぶことができる。今回私はExadataや18c(RAC)のコア技術に特化してセッションを選んだが、それだけでも時間が足りないほどのセッションがあった。新機能や製品コアの内容はおおむねOracle社の開発のマネージャによるものであるが、それ以外にユーザ(IOUGのACEディレクターや企業の方)の製品・サービスの事例も豊富にあり興味深かった。例えば、私が参加したのは、クラウドへのRMANバックアップ活用のススメ(下記写真のセミナ)、DellEMCの方のshadingを検証してみた話、18cRACでundoセグメントヘッダがキャッシュフュージョンできるようになった話、ExadataのストレージサーバのメモリにDBぼバッファキャッシュが拡張できるようになった話、EnterpriseManagerでマルチテナントのプロビジョニングが簡単にできるようになった話などなど。
※セミナ終了後の様子。講演者の周りに人だかりができてQAしている様子

DSC_0005 (480x640).jpg


次に、ユーザ企業個別のニーズに応じて、CVC(Customer Visit Center)にて現地開発のキーマンと打ち合わせで情報交換ができること。最新の製品の仕様や動向、あるいはこちら側のニーズ(改善要望)を双方から出しながら議論することができるのだ。たとえばExadataのSmartScanの最新の仕様や、プロジェクトの状況において、どのようにフラッシュキャッシュを有効活用すべきか、といった議論を、開発責任者と直接できるのである。もちろん、改善要望をあげたとしてもすぐに製品へ反映される訳ではない。しかし、Oracleのような巨大な製品プロセスに関与できる(かもしれない)機会があるのは、なかなか興味深い。また、現地開発者とのリレーションが確立できれば、トラブル発生時のエスカレーションにもポジティブな影響があるかもしれないとの期待もある。

最後に、これは言うまでもないことだが、ベンダ、ユーザ企業間の交流の場であること。各種懇親会を通してベンダ、日本企業の間で情報交換ができる機会がある。今回自分はあまり有効活用できなかったが、継続的に参加していれば横のつながりを作る機会にはなるだろう。

以上、私が当初思っていたOpenWorldのイメージと異なっていた点である。

今回実際に行ってみて、何が直接得られたか、というと、1つは「人と人とのつながり」なのではないかと思う。キーノートの内容や技術的な内容の多くは日本でも得られるが、現地での開発者やユーザ同士の交流は、なかなか日本で通常の業務を行っている中では得られないものだと思う。日本のセミナでは企業間の敷居が高いが、海外に出ると比較的気軽に名刺交換できる。また、先進的な機能や事例を聞くことで、エンジニアとしての視野を広げる機会としても良いと思う。これは自社にこもって開発や維持運用をしているだけでは難しい。開発の効率化・生産性向上の新しいヒントを得るには良いだろう。また、総じて、やはり英語がある程度できないとせっかくの機会を有効に活用できない(キーノートは同時通訳がつくが、多くのテクニカルセッションは英語のみである)ことを改めて感じた。英語のモチベーション向上にも良いだろう。

現地で下記書籍をつい購入してしまった。さらっと見た感じ、浅く広く12cの機能を活用したパフォーマンスチューニングについて記載されているので、ちょっと気になったトピックについて調べるのに良さそうである。厚くて帰りのスーツケースに入れるのに苦労した割に、まだ読めていない。



Oracle Database 12c Release 2 Performance Tuning Tips & Techniques (Oracle Press)

Oracle Database 12c Release 2 Performance Tuning Tips & Techniques (Oracle Press)

  • 作者: Richard Niemiec
  • 出版社/メーカー: McGraw-Hill Education
  • 発売日: 2017/03/16
  • メディア: ペーパーバック



nice!(0)  コメント(0) 
最新動向 ブログトップ