バックアップさえしていれば本当に完璧なリカバリーができるの？──“カンニング”ではダメ！ 100点のリカバリーを実現する方法を考えよう！：データベース基盤と管理の「それって本当？」――スペシャリストが真実を暴く（3）（3/3 ページ）

なぜデータベースのバックアップを取得するのでしょうか？ もちろん、万一の障害が発生した際にバックアップを使用してリカバリーするためです。では、そのリカバリー計画は確実なものだと自信を持って言えますか？ このような質問をすると、多くの方が「正しいプロセスでバックアップを取得しているから大丈夫」と答えます。しかし、ちょっと待ってください。本当に大切なのは「バックアップを取得すること」ではありません。さて、それはどういうことでしょうか？ 詳しく解説していきます。[運用管理効率化][Oracle Database 12c]

[PR／＠IT]

「Recovery Manager（RMAN）」がブロックの中身までチェックできる理由

　確実にリカバリーできるバックアップを取得するためにはどうすればいいでしょうか。そこでオラクルが提案しているのが「Recovery Manager（RMAN）」を使ったバックアップです。RMANは、Oracle Databaseが標準で備えるバックアップ計画の管理を自動化するユーティリティーです。SQL*PlusのようにOSのプロンプトからRMANを起動してコマンドラインで実行するか、Oracle Enterprise ManagerのGUIを使用して実行できます。このRMANに備わる高速増分バックアップ機能はストレージ装置が提供するコピー機能の差分同期とほぼ同じ仕組みとなります。さらに、RMANはデータブロックの構造を理解できますので、バックアップを取得するタイミングでブロック破損の検知が可能になります。まず、RMANによる高速増分バックアップが、D2Dによるバックアップとどう違うのかを示したのが図3です。

図3　RMANによる高速増分バックアップの仕組み

　RMANの高速増分バックアップでは、更新されたブロック情報が記録されているブロック・チェンジ・トラッキングファイル（BCT File）を使用して前回のバックアップからの差分を認識し、必要最低限のデータブロックをディスクから読込むことでレベル1のバックアップセットを作成します。このバックアップの際に、データブロックの構造として正しいかをチェックしています。

　チェックによりブロックの破損が検出された場合はバックアップ処理が自動で中止されますので、ブロック破損を含んだバックアップが作成されることを防ぐだけではなく、ブロック破損を修復する作業を開始するきっかけとなります。また、更新ブロックを抽出してレベル1のバックアップセットを作成する高速増分バックアップと、レベル0バックアップに対してレベル1を適用する増分更新バックアップの2段階で行われるため、D2Dバックアップで正副ボリュームの両方が使えなくなるようなバックアップ中の障害にも対応できます。このようにして、RMANを使用することで、確実にリストア／リカバリーできるバックアップファイルを取得することができるのです。

　RMANはバックアップ処理のタイミングでブロック破損を検出するだけではなく、任意のタイミングでデータブロックの正常性をチェックするVALIDATEコマンドも提供しています。このコマンドはバックアップ元となるデータファイルに対してだけではなく、RMANで取得したバックアップに対してもチェックを行う事が可能です。このコマンドをバックアップ計画に組み込んでいくことで、リカバリーを前提にした安全なバックアップ運用が可能になるのです。

　バックアップで考えておくべきことは、バックアップを取ることではありません。バックアップは、「リカバリーできる状態を用意しておくこと」の手段にすぎません。

　日々の忙しい運用の中で、ついつい「バックアップをとればリカバリーできる」と思い込んでしまいがちですが、本来の目的を忘れず、「戻すための評価」を日頃から行っていくことが大切なのです。

今回の学び

1. バックアップは手段であり、万が一の際に「リカバリーできること」が目的である
2. ストレージのコピー機能では、「ブロック破損」も一緒にコピーされている
3. RMANはOracle Databaseを理解して正常なバックアップを取得・保持する

オラクル データベース インサイダー記事一覧