Pick Upテクノロジー

技術検証が明らかにした、バックアップ/リカバリの進化――SSDとFlashback Databaseの活用法を探ってみた

新日鉄ソリューションズとEMCジャパン、そして日本オラクルの3社は先ごろ、データ保護手段の1つとしてOracle Database 10gから搭載されている「Flashback Database」機能について協同で検証作業を行い、その結果をホワイトペーパーとして公開した。今回は、この検証作業に携わった新日鉄ソリューション ズと日本オラクルの担当者に、検証内容やFlashback Database機能の効果、SSDと併用した場合のメリットなどについて話を聞いた（編集部）。
 
■物理バックアップを補完するFlashback Database
 
　ハードウェア障害や作業中のトラブル、あるいはセキュリティ上のリスクなどへの備えとして、データベースに蓄積したデータのバッ クアップは不可欠である。そのため、Oracle Databaseにはさまざまなバックアップ機構が用意されているが、その1つとしてぜひ活用してほしいのがOracle Database 10gから提供されているFlashback Database機能だ。
 
　Flashback Databaseは過去の指定された時点にデータベース全体の状態を戻すという機能であり、物理バックアップとリカバリを補完できるほか、ストレージのスナップショット機能の代替手段としても利用できる。
 
　Flashback Database機能を使うと、OracleクライアントによるINSERTやDELETE、UPDATE、あるいはTRUNCATEなどのデータ更新処 理が発生した際、自動的に更新前のブロック・イメージが高速リカバリ領域である「Fast Recovery Area」にFlashback Logとして記録される。バックアップを取得するためにデータベースを停止したり、オンライン・バックアップ・モードに変更したりする必要はない。
 
　また、高速にリカバリできることもFlashback Database機能の大きな魅力だ。同様の機能として「Point-in-Timeリカバリ（不完全リカバリ、DBPITR）」があるが、これを使う場 合はバックアップしたすべてのデータ・ファイルをリストアし、さらにアーカイブREDOログ・ファイル、REDOログ・ファイルを使ってロール・フォワー ドしなければならない。一方、Flashback Databaseではリストア作業は不要であり、過去の時点に高速にデータベース全体を戻すことが可能だ。ただし、データ・ファイルが消失または破損して いる場合などFlashback Databaseで戻せないケースもあるので、あくまでもDBPITRを補完する役割であることに注意したい。
 
　なお、Flashback Database機能には2つの使い方がある。1つは任意の時点に戻せる「Flashback Logging」を利用する方法、もう1つは必要なFlashback Logが保持されていることが保証される「保証付きリストア・ポイント（GRP：Guarantee Restore Point）」を作成する方法だ。これにより、OLTPなど常時更新されるケースではFlashback Loggingを、バッチ処理など必要なリストア・ポイントが特定できるケースではGRPをといった具合に使い分けることが可能となっている。
 
■Flashback Database機能利用時の性能を検証

瀧本秀典氏"
新日鉄ソリューションズ ITインフラソリューション事業本部 ITエンジニアリング事業部 ITアーキテクティンググループ シニア・マネジャーの瀧本秀典氏
　今回は、このFlashback Database機能について、新日鉄ソリューションズとEMCジャパン、日本オラクルの3社が共同で検証作業を行ったわけだが、その目的について、新日 鉄ソリューションズの瀧本秀典氏（ITインフラソリューション事業本部 ITエンジニアリング事業部 ITアーキテクティンググループ シニア・マネジャー）は次のように説明する。
 
　「バックアップとリカバリを検討する際、人為的なミスなどによって格納しているデータに不整合が生じる論理障害については、アプ リケーション側で対応するケースが一般的。ただ、この課題に対し、システムの基盤部分を担当する我々のチームでも何かアプローチできないかと考えていた。 そこで注目したのがFlashback Database機能だ。ただし、この機能を使うとパフォーマンスが低下するのではないかと懸念するユーザーが少なくない。そこで、実際にOracle GRID Centerで検証を行い、性能面への影響などを調査することにした」
 
　Flashback Database機能を使うメリットとして瀧本氏が挙げるのが、バッチ作業における処理時間の短縮だ。バッチ処理を行う際、途中で障害が発生した場合に備 えて、事前にデータベースの内容をエクスポートしておくことは珍しくない。問題が発生した際には、エクスポートした内容をインポートすることでデータベー スを元に戻すわけだ。ただし、データ量が増大するとエクスポートに多くの時間が取られ、バッチ・ウィンドウを圧迫してしまうという問題があった。
 
　「だが、トラブルが発生した際にFlashback Databaseを使って元に戻すことができれば、エクスポートの時間が不要となり、バッチ・ウィンドウの改善につながる。さらに、この機能は簡単に扱え るので、運用負荷の低減というメリットもある。そうすると、残る問題はFlashback Databaseを有効にした場合のパフォーマンス低下だけとなる。今回の検証のポイントは、この問題を回避できるのかどうかを明らかにすることだった」 （瀧本氏）
 
■SSDとの組み合わせによりバッチ処理を高速化

宮本佐和氏"
新日鉄ソリューションズ ITインフラソリューション事業本部 ITエンジニアリング事業部 エンジニアリング第一部の宮本佐和氏
　この検証において、実際の作業を担当した新日鉄ソリューションズの宮本佐和氏（ITインフラソリューション事業本部 ITエンジニアリング事業部 エンジニアリング第一部）は、検証結果について次のように説明する。
 
　「今回は、OLTP処理とバッチ処理を想定してFlashback Database機能を有効にした場合のパフォーマンスを検証した。その結果、OLTP処理については、Flashback Loggingを有効にしても性能の低下はほとんど見られなかった。その理由として、OLTP処理ではINSERTやUPDATEが含まれているものの、 SELECTによる参照が中心であり、Flashback Logの生成量が多くはないことが考えられる」

110303-03_01.png
 
　Flashback Logとは、Flashback Databaseを有効にした状態でデータを更新した際に生成されるログデータだ。SELECTによるデータ参照では、当然ながらFlashback Logは生成されず、そのSELECTがメインであるOLTP処理の性能は低下しないというわけである。
 
　では、バッチ処理についてはどうなのか。今回の検証作業では、expdpでエクスポートした後にバッチ処理を行うケースと、 GRPでリストア・ポイントを生成した後にバッチ処理を行うケースの2つの手順で比較した。バッチ処理の内容は全件UPDATEだ。その結果について宮本 氏は、「Flashback Log生成のオーバーヘッドが顕著に現れ、Flashback Database機能を使うとバッチ処理に1.5倍以上の時間がかかった。もっとも、エクスポートの時間まで考慮すれば、ほぼ同等という結果になる」と説 明する。

110303-03_02.png
　ここで注目したいのは、バッチ処理に失敗した場合を想定したリカバリの処理時間だ。データベースに対してtruncateを実行 し、続けてimpdpでインポートを行った場合を100％だとすれば、Flashback Database機能によるリカバリは約36％の時間で完了したのである。

110303-03_03.png
柴田長氏"
日本オラクル テクノロジー製品事業統括本部 アライアンス技術本部 アライアンス技術部 シニアエンジニアの柴田長氏
　このように、バッチ処理の時間では両者の間に大きな違いがない一方で、リストアはFlashback Database機能を利用することで圧倒的に速くなる。これだけでもFlashback Database機能は十分に魅力的だが、バッチ処理の時間が伸びる点は気になるところである。この対策として、日本オラクルの柴田長氏（テクノロジー製 品事業統括本部 アライアンス技術本部 アライアンス技術部 シニアエンジニア）は、UNDO表領域を高速なSSDに配置することでオーバーヘッドを解消できると説明する。
 
　「検証を始める前は、Flashback Logの出力によるディスクI/Oの頻発が性能劣化を引き起こすと予測していた。しかし検証の結果、実際にはUNDO表領域からのデータ・ブロックの読み 込みが頻発し、それに時間がかかっていることが判明した。そこでUNDO表領域をSSD（EMC CLARiX CX4-240のEnterprise Flash Drive）上に配置したところ、同じバッチ処理を約70％も高速化できることがわかった」（柴田氏）

110303-03_04.png
　データ量の増大は、バッチ・ウィンドウの圧迫というかたちで多くの企業のシステム担当者を苦しめている。この課題に対し、 Flashback Database機能はトラブル発生時のリカバリ時間の短縮を可能にするだけでなく、SSDと組み合わせることでバッチ処理時間の短縮にもつながることが 今回の検証によって証明されたわけである。
 
　また、新日鉄ソリューションズの瀧本氏は、「運用負荷の低減」というメリットも強調する。
 
　「バッチ処理でトラブルが発生した際には、それまでにどのテーブルのデータが更新されているのかを洗い出し、truncateし てデータをインポートするという作業が必要になる。これらの処理を手作業で進めた場合、関係のないテーブルまで消してしまうといった"2次災害"が起こら ないとは限らない。そのため、手順をしっかりとチェックして進めることが肝要だが、Flashback Database機能であればコマンド1つで元に戻せる。実際の運用時において、この手順の違いによる効率の差は大きい」（瀧本氏）
 
■人為的なミスへの対策としても有効
 
　バッチ処理だけでなく、人為的なミスへの対策としてもFlashback Database機能は有効だ。例えば、業務時間内にユーザーの誤操作によってデータに不整合が発生した際、どのタイミングで誤操作したのかがわかれば、 Flashback Database機能によってその時点までデータベースの内容を元に戻せるので、迅速にトラブルに対応できる。また、Flashback Database機能を利用していたおかげで、大規模なトラブルを未然に防げたという事例もあるという。
 
　「あるユーザー企業において、間違った処理によって本番システムのデータを更新してしまうというトラブルが発生した。しかも、こ の企業ではOracle Data Guardを使ってデータベースのレプリカを待機系に作成していた。Oracle Data Guardはリアルタイムにデータベースを同期するため、当然、待機系のデータベースにも間違ったデータが流れてしまっていた。だが幸い、待機系では Flashback Database機能を有効にしていたため、元に戻すことができ、その内容を使って本番系もリカバリすることができた」（瀧本氏）
 
　今回、新日鉄ソリューションズとEMCジャパン、日本オラクルの3社協同で実施された検証作業により、Flashback Database機能の有用性が実証された。また、オーバーヘッド増大への有効な対策まで明らかになったことにより、今後ますます同機能の利用が広まるの は間違いない。なお、本検証で利用した環境や条件、結果などについては、ホワイトペーパーで詳しく解説されている。ぜひそちらもご参照いただきたい。
 
 

Oracle GRID Centerの検証資料はこちらからダウンロードできます。
「Oracle GRID Centerホームページ」
《GRID Center》シリーズをお見逃しなく！