バックアップ&リカバリの目的 (1/2):EnterpriseZine(エンタープライズジン)
Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

バックアップ&リカバリの目的

2017/06/23 06:00

 データベース管理者の皆さんにとって、日々の運用に関わる負担を軽減することは大きな関心事です。バックアップの負荷を減らす工夫はたくさん試されているでしょう。しかしそのために、肝心の「リストア・リカバリ」を考慮しない運用になりがちです。バックアップを取得する目的は、万が一の場合にリストア・リカバリを実施し「停止している業務を復旧すること」「大切なデータを消失しないこと」です。つまり、バックアップは常にリストア・リカバリできるように取得されていることが大切です。この連載ではOracle Databaseのバックアップとリカバリに焦点をあて解説していきます。第1回目のテーマはバックアップ・リカバリの目的です。

「バックアップを使って確実にリカバリできる」と自信を持って言えますか?

 自信を持って「リカバリできる」と言い切れる人は少ないのではないかと思います。ある外部機関の調査(図1)では84%のデータベース管理者が過去1年以内にリストア・リカバリに失敗した経験があると回答をしています。失敗理由として上位に来るのが、「オペレーションミス」「バックアップの破損・不足」です。オペレーションミスについては、一刻も早い業務再開が求められる緊迫した場面で絶対になくすというのは難しいかもしれません。一方で、バックアップの破損や不足というのは事前に気付くことができます。

出典:UNISPHERE RESEARCH “Oracle Database and Data Protection Survey” http://www.dbta.com/DBTA-Downloads/ResearchReports/Oracle-Database-and-Data-Protection-Survey-Results-4331.aspx

 Oracle Databaseのバックアップ・リカバリ用ユーティリティであるRecovery Manager(以降RMAN)は、バックアップの破損や不足を事前に検知するための機能が用意されています。以降ではその点について話をしたいと思います。

ファイルの不足を検知する - CROSSCHECKコマンド

 いざリカバリをしようとしたけど利用できるバックアップがない—。

 意外かもしれませんが、残念なことに良くあるシチュエーションです。もともとアーカイブREDOログのバックアップを取っていなかったケース、NAS上に配置していたはずのバックアップファイルが意図せずに削除・移動されているケースなど理由は様々です。

 この対策として、バックアップのスクリプトを正しく書く、あるいは適切なアクセス権を与えることを考えることももちろん大事ですが、「利用できるバックアップが存在する」ことを確認できる仕組みを持っておくことが重要です。

 RMAN には CROSSCHECK というコマンドが用意されており、「リカバリカタログ」に格納されているバックアップの管理情報(いつ、どこにバックアップを取り、どういう状態か)と、バックアップファイルの実体との間に乖離がないかをOracle Database インスタンスがチェックする仕組みがあります。

 例えば図2のようにバックアップがRMANで取得されている場合に、そのバックアップファイルの実体が意図せず移動・削除されてしまったとします。もし、このCROSSCHECKコマンドを定期的に実行していれば、図3のように管理情報と実体との間に乖離があることを検知(’EXPIRED’が検出されました)することができます。

<図2>
RMAN> LIST BACKUP

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
37      Incr 0  379.17M    DISK        00:00:12     2017/05/24 15:03:38
        BPキー: 37   ステータス: AVAILABLE  圧縮: NO  タグ: TEST
        ピース名: /fast_recovery_area/orcl/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp

  バックアップ・セット37のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間             Name
  ---- -- ---- ---------- ------------------- ----
  1    0  Incr 3715141    2017/05/24 15:03:26 /oradata/orcl/system01.dbf
  2    0  Incr 3715141    2017/05/24 15:03:26 /oradata/orcl/sysaux01.dbf
  3    0  Incr 3715141    2017/05/24 15:03:26 /oradata/orcl/undotbs01.dbf
  4    0  Incr 3715141    2017/05/24 15:03:26 /oradata/orcl/users01.dbf
  5    0  Incr 3715141    2017/05/24 15:03:26 /oradata/orcl/test01.dbf
<図3>
RMAN> crosscheck backup;

リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=5 デバイス・タイプ=DISK
バックアップ・ピースがクロスチェックされました: 'EXPIRED'が検出されました
バックアップ・ピース・ハンドル=/fast_recovery_area/orcl/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp レコードID=37 スタンプ=944838206

<以降省略>

RMAN> list backup;
BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ -------------------
37      Incr 0  379.17M    DISK        00:00:12     2017/05/24 15:03:38
        BPキー: 37   ステータス: EXPIRED  圧縮: NO  タグ: TEST
        ピース名: /fast_recovery_area/ORA11203S/backupset/2017_05_24/o1_mf_nnnd0_TEST_dlb8kg8q_.bkp
<図4>
RMAN> backup incremental level 1 database;

backupが開始されました(開始時間: 17-05-24)
チャネルORA_DISK_1の使用
データファイル1の親バックアップまたはコピーが見つかりません
データファイル2の親バックアップまたはコピーが見つかりません
データファイル3の親バックアップまたはコピーが見つかりません
データファイル4の親バックアップまたはコピーが見つかりません
データファイル6の親バックアップまたはコピーが見つかりません
チャネルORA_DISK_1: 増分レベル0のデータファイル・バックアップ・セットを開始しています

 検知さえ出来れば、管理者は必要なバックアップが存在しないものとして以降の運用を行うことができますし、RMANはバックアップが存在しないものとして以降の動作を行いますので、仮に削除されてしまったバックアップを親(レベル0バックアップ)とするような増分バックアップ(レベル1バックアップ)の取得を実行したとしても、バックアップの実体が存在しないことをRMANはすでに知っていますので、レベル0のバックアップから取得しなおしてくれます(図4)。

※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 佐々木亨(ササキトオル)

    日本オラクル株式会社  日本オラクル入社から一貫してOracle Databaseの持つ高可用性分野のスペシャリストとして活動。Mission Critical Certified CenterやOracle GRID Centerといったパートナー企業との共同検証の経験を通じて今の土台を築き、現...

バックナンバー

連載:目指せ黒帯!Oracle Database バックアップ&リカバリ道場
All contents copyright © 2007-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5