サービスレベルに応じてデータベースの可用性を確保する「Oracle Maximum Availability Architecture」とは何か？：データベースクラウドに求められる3つの要件（1）（4/4 ページ）

[PR／＠IT]

PR

データベースをリアルタイムに同期するテクノロジー

　「データベースそのものを分散配置したい」「本番環境とは異なる場所にスタンバイ環境を構築したい」といったニーズのために用意されているのがOracle Data Guardだ。これはデータベースを複製するためのテクノロジーであり、「データの誤差が発生しない」「高速なデータ同期が可能である」「トランザクションの順次性が保証される」といった特徴を備える。

　Oracle Data Guardで注目いただきたいのは、データそのものを転送して同期するのではなく、REDOログのみを送信するという点だ。プライマリ側からREDOログを受け取ると、スタンバイ側ではそれを使ってトランザクションを再現し、データを同期する。REDOログだけを転送するため、広帯域のネットワークを使わなくても高速にデータ同期が行える。

　データ破損がスタンバイデータベースに伝搬しないことも、REDOログを転送する方式ならではのメリットである。データそのものを転送する同期の場合、ブロック破損によってデータが壊れた際、その内容がそのままスタンバイ側にも反映されてしまうという問題が生じる。しかし、REDOログを使ってプライマリデータベース環境のトランザクションを再現するOracle Data Guardであれば、プライマリ側のデータ破損がスタンバイ側に影響することはないのだ。

　Oracle Data Guardに、より高度な機能を付加した「Oracle Active Data Guard」では、スタンバイデータベースを読み取り専用モードでオープンし、SELECT文を実行することができる。さらには、「Automatic Block Media Recovery」と呼ばれる機能が備わっている点にも注目だ。これはブロック障害を検知すると、同期している別のデータベースから正常なデータを取得し、自動的にリカバリするというものだ。クライアント側には正常なエラーが返されるため、データ障害の影響を受けずに処理を継続することが可能である。

ローリングアップデートで計画停止の時間を短縮

　Oracle Data Guardによるデータベース同期では、同期が完了したタイミングでコミットを返す方式と、コミットを転送したタイミングでコミットする非同期のいずれかを選択できる。確実にデータを保証したい場合には同期を、パフォーマンスが優先される場合には非同期を選べばよいだろう。

　計画停止時間の短縮にも、Oracle Data Guardが有効だ。例えば、パッチの適用やアップグレードを行う際には、まずスタンバイ側で作業を行い、それが完了したらクライアントの接続先データベースをプライマリからスタンバイに変更する。その後、プライマリ側で作業を行うことにより、データベースを長時間止めることなくパッチ適用やアップデートを実施できる。プライマリとスタンバイを切り替える際には、同期と非同期のいずれでもデータ損失が発生しないスイッチオーバーを使うことで、データベースを安全に切り替えられる。

　なお、Oracle Database 12cでは、新たに「Far Sync」と呼ばれる機能が追加された。遅延が大きい遠隔地間のデータベース同期では、どうしてもコミットに時間がかかってしまう。この問題を解決する機能がFar Syncであり、同期する2つのデータベースの間に中間サーバを置き、送信したREDOログがそのサーバに保存されたタイミングでコミットする。中間サーバにREDOログを残すことでデータの更新内容などが損失するリスクを抑えつつ、中間サーバから遠隔地のデータベースへのREDOログ送信を非同期にすることで、コミットにかかる時間の短縮を図るわけだ。

任意の時点のデータベースを復元するテクノロジー

　Oracle MAAの構成要素の中で、もう1つ、ぜひご活用いただきたいテクノロジーが「Flashback Technology」である。これはデータベースに対して行った操作を復元したり、無効化したりすることのできる仕組みであり、特に任意の時点のデータベースを復元できる「Flashback Database」の有用性は高い。例えば、「人的ミスでデータを削除してしまった」、あるいは「更新ミスが発生した」といった場合にも、素早くリカバリすることができるのだ。

　このテクノロジーの鍵を握るのが、「Flashback Log」と呼ばれる独自のロギング機構である。データ更新時、自動的に更新前のブロックイメージをリカバリ領域にFlashback Logとして保存する。Flashback Databaseでは、これを利用してデータベースを以前の状態に高速に戻せるようにしているのだ。

　一般に、操作ミスなどからの復旧方法としては、バックアップデータからのリカバリが使われる。この方法では、データ量に比例して復旧に要する時間が長くなり、業務などにも大きな影響が及んでしまう。これに対して、Flashback Databaseならば過去の任意の時点に瞬時に戻せるため、業務への影響を最小限に抑えられるというメリットがある。

カットオーバー直前のトラブルをOracle MAAで回避

　これらのテクノロジーで構成されるOracle MAAを活用することで、実際にトラブルの影響を最小限に抑えたケースは少なくない。

　例えば、ある企業では、システムのカットオーバー直前のタイミングで、旧データベースから新データベースへのデータ移行中に作業ミスからデータを破壊してしまった。既にコミットされているためロールバックも不可能なうえ、本番稼働前だったためにバックアップ運用も始まっていなかった。データベース作成直後のバックアップは取っていたが、そこから復旧していたのではカットオーバーに間に合わない。そこで使われたのがFlashback Technologyである。

　このシステムのデータベース環境はOracle ExadataとOracle RAC、Oracle ASMによって構成されており、さらにOracle Data GuardでDR（Disaster Recovery）サイトのデータベースと同期していた。そして幸いにも、DRサイト側のデータベースでFlashback Logを取得していた。Flashback Log取得のオーバーヘッドを避けるために、プライマリではなくスタンバイデータベースでFlashback Logを記録し、トラブルに備えていたのだ。

　担当者らは、まずFlashback Databaseを使ってスタンバイデータベース側をトラブル発生前の状態に戻し、その内容をプライマリに反映することで事なきを得た。この事例は、Oracle MAAを使うことでデータベースのトラブルを迅速に解決した典型的なケースといえるだろう。

　Oracle MAAには、今回紹介したOracle RACやOracle ASM、Oracle Data Guardなどの他にも、データベースシステムの可用性を高めるためのさまざまなテクノロジーが用意されている。その全てを使う必要はなく、求められるサービスレベルに応じて、必要なテクノロジーを読者のデータベース環境にも組み入れていただきたい。なかでも、Oracle ASMは導入のハードルが低い一方で大きなメリットが得られるため、積極的に利用することをお勧めする。

　以上、今回はOracle Database 12cによるプライベートクラウド環境の可用性を高めるためのテクノロジーとしてOracle MAAを紹介した。次回は、データベースシステムの運用管理において厄介な課題であるバックアップを効率化する手法を紹介する。