インメモリと聞いて一番気になること
セミナーや勉強会などで、「Oracle Database In-Memoryはメモリ上にデータがあるのだから、サーバがダウンしたら復旧が大変ではないか？」というご質問をいただくことがあります。仕組みを考えればこうした懸念は当然です。サーバがダウンすればもちろんRAMの中身は消えますし、インスタンスがダウンすればデータベースから見たキャッシュは空になってしまいます。データの整合性はどうなるのか、インメモリの状態に復旧するまでどの程度かかるのかといった情報は、採用を検討する上で必ず抑えておかなければいけません。
まず、データの整合性についてですが、Oracle Database In-Memoryでは更新処理にこれまでどおりデータベース・バッファ・キャッシュを使用しています。もしサーバがダウンしたとしてもクラッシュリカバリによってデータの整合性が維持されるため、Oracle Database In-Memoryならではの懸念事項というのはありません。それよりも問題なのは、クラッシュリカバリが終わってもディスクからメモリ上にデータを配置（ポピュレーション）し直さなければ、インメモリの状態には戻らないということです。
これまでの検証でご紹介したように、ポピュレーションは行フォーマットから列フォーマットへの変換と圧縮を行うため、それなりに時間のかかる作業です。ポピュレーションの途中でもクエリを発行できますが、部分的にインメモリになった状態では本来期待する性能を発揮することができません。
これはOracle Database In-Memoryに限った話ではなく、インメモリ技術全般に当てはまります。メモリにデータを配置する以上、常に「消える」というリスクと戦わなければいけません。特にクリティカルなシステムの場合は、ダウンタイムを短く抑えるための可用性構成を組めるかどうかが、採用可否を大きく左右します。
Oracle Database In-Memory + RAC
Oracle Databaseの代表的な可用性構成と言えば、Real Application Clusters(RAC)です。RACは全てのサーバ(ノード)で読み取りと書き込みが可能なアクティブ-アクティブ型のクラスタ構成なので、もし1台のノードがダウンしても生き残ったノードに接続すれば処理を継続できます。
Oracle Database In-MemoryはRAC上でも動作しますので、可用性を確保したい場合はRACの構成を選択するのが最も良い方法です。ただし、話はそれほど単純ではなく、各ノードのメモリ上でどのようにデータを保持するか、3つのパターンから選択する必要があります。それが以下の図です。
「NO DUPLICATE」は、各ノード上のインメモリ・カラムストアにデータを分散します。データの複製を保持しないため、より多くのデータをメモリ上に配置できますが、例えば図のノード1がダウンしてしまうと、P1のデータにはインメモリでのアクセスができなくなってしまいます。
「DUPLICATE」と「ALL DUPLICATE」は、異なるノード上に複製を保持します。「NO DUPLICATE」と比べて使えるメモリ量は減ってしまいますが、いずれか一つのノードがダウンしたとしても別のノードに複製が存在するため可用性に優れています。ただし、この構成がとれるのは、Oracle Exadata Database Machine（Exadata）やOracle Database Applianceなどの、Engineered Systemsのみになっています。機材の選定と可用性のレベルが密接に関わってきますので、特に「DUPLICATE」と「ALL DUPLICATE」を選択する場合は注意が必要です。
