データベース
 Computer >> コンピューター >  >> プログラミング >> データベース

Oracle RMANの増分マージバックアップで実現する超高速データベースリカバリ

ダウンタイムの最小化とデータベース可用性の向上は、あらゆる企業が目指す重要な課題です。データベース管理者(DBA)は、データファイルやデータベース全体が破損した場合に備え、より迅速なリカバリソリューションを常に模索しています。Oracle® Recovery Manager(RMAN)には、バージョン10g以降、「増分マージバックアップ(Incremental Merge Backups:IMB)」と呼ばれる機能が搭載されており、特に超大規模データベース(VLDB)において、リカバリ時間の大幅な短縮を実現する強力なソリューションとなります。

はじめに

IMB機能は、適切なオプションを設定すれば、データベースのリカバリ時間を劇的に短縮できます。あまり広く知られていない機能ではありますが、VLDBにとって理想的なバックアップ手法です。まずデータファイルのイメージコピーを作成し、その後、バックアップ操作のたびに増分バックアップを適用してイメージコピーをロールフォワードしていきます。

本記事では、IMBを使用する際の考慮事項を紹介し、処理の流れを示すサンプルコードと、いくつかの具体的なリカバリシナリオをご紹介します。

考慮事項

イメージコピーバックアップ戦略を採用する前に、以下の点に留意してください。

  • データベースでブロック変更トラッキング(BCT)を有効にしておく必要があります。
  • データベースのデータファイルが実際に使用している容量と同等のディスク領域を、イメージコピーの保存用として確保する必要があります。
  • ポイントインタイムリカバリ(PITR)を行うには、最低1回のフルバックアップが必要であり、リカバリ完了までのアーカイブログも保持しておく必要があります。
  • イメージコピーは、I/O特性の観点で同じ種類のストレージに配置してください。データベースコピーへの切り替え時にパフォーマンスが低下しないようにするためです。

次の図は、増分更新バックアップの仕組みを示しています。

Oracle RMANの増分マージバックアップで実現する超高速データベースリカバリ

サンプルコード

以下のコードを実行すると、毎日イメージコピーを作成し、増分的に更新できます。

run
{
   allocate channel c1 device type disk format '/home/oracle/backup/%U';
   recover copy of database with tag 'IMG_COPY';
   backup incremental level 1 for recover of copy with tag 'IMG_COPY' database;
   release channel c1;
}

初回実行時は、recover copy of databaseコマンドは何もしません。backup incrementalコマンドは、このタグでの最初のバックアップとなるため、IMG_COPYタグ付きの新しい増分level 0バックアップを作成します。

2回目の実行時は、recover copy of databaseコマンドは、INC 1バックアップが見つかるまで何もしません。backup incrementalコマンドがINC 1バックアップを作成します。

3回目以降の実行時は、recoverコマンドが、利用可能な最新のINC 1バックアップを既存のイメージコピーに適用します。そしてbackupコマンドが次のINC 1バックアップを作成します。

リカバリシナリオ

以下のユースケースでは、増分マージバックアップがさまざまなリカバリ状況でどのように役立つかを説明します。

ケース1:データファイルの破損・削除・上書き

まず、次のコードのようにテスト用のテーブルを作成し、前述のスクリプトを使ってイメージコピーを取得します。

SQL> create table ImgCpyTab tablespace tbs2 as select * from dba_objects;
Table created.

FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————

/home/oracle/Sw/oradata/test/tbs02.dbf 5	TBS2

SQL> select count(1) from ImgCpyTab;
COUNT(1)
———-
72476

このシナリオをテストするために、物理データファイルを意図的に移動してみます。すると、次のコードのようにselectコマンドが想定どおりのエラーを返します。

mv /home/oracle/Sw/oradata/test/tbs02.dbf /home/oracle/Sw/oradata/test/tbs02.dbf_BKP

select count(1) from scott.IMGCPYTAB
*
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: '/home/oracle/Sw/oradata/test/tbs02.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

この場合、物理ファイルをリストアする必要はありません。代わりにバックアップへ切り替えてリカバリを実行します。この方法は非常に高速で、データファイルやデータベースがテラバイト級のサイズであっても同様です。

次のコードで、データファイルをオフラインモードにします。

SQL> alter database datafile 5 offline;
Database altered.

続いて、データファイルをコピーに切り替え、リカバリを実行します。

[oracle@localhost backup]$ rman target /
Recovery Manager: Release 11.2.0.2.0 – Production on Thu Jun 5 18:17:15 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: TEST (DBID=2122535405)

RMAN> switch datafile 5 to copy;
using target database control file instead of recovery catalog
datafile 5 switched to datafile copy "/home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1"

RMAN> recover datafile 5;
Starting recover at 05-JUN-14
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=149 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 05-JUN-14

RMAN> sql 'alter database datafile 5 online';
sql statement: alter database datafile 5 online

RMAN> exit

次のコードのとおり、データファイルが復旧し、テーブルにもアクセスできるようになりました。

FILE_NAME FILE_ID TABLESPACE_NAME
————————- ——————— ———————————————

TBS2 /home/oracle/backup/data_D-TEST_I-2122535405_TS-TBS2_FNO-5_6ppa3ev1 AVAILABLE

SQL> select count(1) from scott.IMGCPYTAB;

COUNT(1)
———-
72476

注:file_name列を確認すると、データベースがイメージコピーファイルを使用していることがわかります。

ケース2:データベース全体の破損またはディスク障害

データベース全体が破損した場合やディスク障害が発生した場合は、以下の手順でデータベースをコピーに切り替えるだけで対応できます。

  1. データベースをシャットダウンします。
  2. 制御ファイルが失われている場合は、リストアします。
  3. イメージコピーをカタログに登録します。
  4. データベースをコピーに切り替えます。
  5. アーカイブログが利用可能な時点までリカバリし、データベースをオープンします。

まとめ

本記事では、RMANのイメージコピーバックアップおよびリカバリ機能の使い方について解説しました。さらに、物理的な破損が発生した場合におけるデータファイルやデータベースの実装・リカバリのユースケースも紹介しました。増分マージバックアップ機能を活用すれば、データベースのバックアップ運用が簡素化され、迅速かつ柔軟なデータリカバリが実現できます。

コメントやご質問がある場合は、フィードバックタブをご利用ください。

  1. Verticaデータベースのバックアップと復元方法を徹底解説

    データ破損や誤操作による削除が発生した場合に備え、確実にデータを復旧できるようにするには、データベースのバックアップを日常的なメンテナンス作業として組み込むことが重要です。本記事では、Vertica®データベースのバックアップとリストア(復元)について詳しく解説します。 はじめに Verticaは、大量のデータを扱うために設計されたカラム型ストレージプラットフォームを採用する分析データベース管理システムです。従来はリソースを大量に消費していたシナリオにおいても、高速なクエリパフォーマンスを実現します。 Verticaには、次のようなメリットがあります。 従来のリレーショナルデータベース管理シ

  2. 増分バックアップを使用してフィジカル・スタンバイ・データベースをリカバリーする方法

    スタンバイ・データベースとは、本番データベースの一貫性のあるコピーのことです。本番環境で災害やデータ損失、データ破損が発生した際の保護手段として重要な役割を果たします。 はじめに プライマリ・サイトとスタンバイ・サイトの間にラグ(遅延)が発生する主な理由としては、以下が挙げられます。 プライマリ・データベースとスタンバイ・データベース間のネットワーク帯域幅の問題 スタンバイ・データベースが利用できない状態 プライマリ・データベース上のアーカイブREDOデータの誤削除 プライマリ・サイトからアーカイブログをコピーして適用することで両環境を同期させることも可能ですが、この方法は非常に時間がかか