現在地

Oracle Zero Data Loss Recovery Appliance活用の可能性を探る!



川井田 明乃

オラクル事業部
システムインテグレーション担当

川井田 明乃

NTTデータ先端技術の川井田です。
はじめまして、と言いたいところですが、Oracle OpenWorld 2017レポート(前編) に引き続き、2回目の登場となります。前回はご挨拶しそびれてしまいました。

初めて Oracle Database に触ったのは 11.2.0.2 の時代ですが、当時の私はまだ Oracle Database を「SQL の結果を返すだけのもの」としか捉えておらず、インスタンスの概念を知ったときに凄まじい衝撃を受けたのを覚えています。その当時はアプリケーション開発をやりたくてやりたくてたまらなかったのですが、それ以前に基盤系の知識を身に付けることの重要性を感じ、Oracle Database の勉強を始めたところ、いまではすっかり Oracle の世界にどっぷりつかってしまいました。

ここ数年は Oracle Exadata Database Machine(以下:Exadata)をはじめとした Oracle Engineered Systems の導入や、Oracle Enterprise Manager での監視設計に多く携わっています。今回は、その中で出会った一製品の活用についてご紹介していきます。

概要

Oracle Zero Data Loss Recovery Appliance(以下:ZDLRA)という製品をご存じでしょうか。
ZDLRA は、Oracle Database のバックアップ・リカバリに特化した製品で、データロスの許容指標である RPO(Recovery Point Objective)の極小化や、バックアップ運用の効率化を目的としています。Oracle Database をある程度ご存じの方向けに端的に言うと、「ZDLRA へのリアルタイム REDO 転送でデータロスをゼロに」「全 DB のバックアップを ZDLRA に集約し、VPC 利用で DB 間のセキュリティも担保」といったところでしょうか。

製品概要については、当社の過去のインタビュー記事に詳しく掲載されています。「名前しか知らない」「そもそも ZDLRA って何?」という方は、ぜひ以下の記事をご一読ください。

本記事では ZDLRA の活用例を 2 点ほどご紹介していますので、ぜひ ZDLRA という製品への理解を深めていただき、興味を持っていただければと思います。

活用例1:DB 移行

さて、これまで Exadata の構築に関わってきた中でほぼ必ず登場したテーマの 1 つとして、DB 移行があります。過去に私が見てきたお客さまでは、Oracle Data Pump(以下:Data Pump)を採用されたケースが大多数を占めていましたが、それ以外にも、Oracle GoldenGate や Oracle Data Guard、トランスポータブル表領域やフル・トランスポータブル・エクスポート/インポート、CTAS(Create Table As Select)などなど、方式は多岐にわたります。

そんな中、今回まずは DB 移行におけるもう 1 つの選択肢として、ZDLRA を使用した移行方式をご紹介します。「どうせ難しいのだろう」と思われている方もいらっしゃるかもしれませんが、意外と簡単にできますので、ぜひご一読ください。


DB 移行には、ZDLRA に取得したバックアップを使用します。
以下では、移行前の現行環境として Oracle Database 11g Release 2(11.2.0.4)を、移行後の次期環境として Oracle Database 12c Release 2(12.2.0.1)を例に記載します。*2

まずは、現行 11g DB が ZDLRA にアクセスできるように設定を行い(1)、フルバックアップを ZDLRA 上に取得します(2)。
移行直前までは、現行 11g DB の増分バックアップを ZDLRA 上に取得し、仮想バックアップとして最新のバックアップデータを ZDLRA 上に保持しておきます(3)。
次期 12c DB から ZDLRA へのアクセスについても、事前に設定しておきます(4)。

※ 上記(1~4)は、今回の DB 移行に依存しない、ZDLRA での通常のオペレーションになります。そのため、すでに実施済みの場合には、本方式の実現のために追加で実施する必要はありません。

本番移行時には、ZDLRA 上に蓄積したバックアップを使用して、次期環境に DB を複製します(5)*3。ただし、11g から複製した DB はそのままだと 12c 環境で OPEN できないため、DB に対してアップグレードスクリプトを実行して、12c へアップグレードを行います(6)。

本移行方式で ZDLRA を利用するメリットとしては、大きく以下の 2 点があります。

1. 仮想フルバックアップの使用による大幅なリストア時間の短縮
ZDLRA 上で自動的に作成される仮想フルバックアップをリストア(今回は複製)することで、通常のフルバックアップおよび増分バックアップを使用したリストア・リカバリに比べて、大幅に時間を短縮できます。
通常、DB をリストアする場合には、フルバックアップをリストアし、増分バックアップを順次適用してリカバリするという流れになります。しかし、ZDLRA の仮想フルバックアップの場合は、増分バックアップを適用するリカバリ時間が存在しないため、DB によっては大幅な時間短縮が期待されます。先述の記事内でも紹介されていますが、フルバックアップ +14 日分の増分バックアップを用いてリカバリした場合、フルバックアップ単体でリカバリする場合に比べて、リカバリ時間が 1.5 倍に増加したという検証結果もあります。*4
2. ブロックの自動チェックによるバックアップファイルの信頼性の向上
ZDLRA 以外の外部ストレージに RMAN バックアップを取得しておくと、仮想フルバックアップに対する定期的なブロック正常性チェックが自動的に行われます。また、バックアップ格納先として Oracle Automatic Storage Management が使用されるため、読み取り時にブロック破損が検知された場合には、自動的にミラーブロックからの修復が行われるため、バックアップの信頼性が向上します。*5

それでは、以下で DB 移行の手順をご説明していきます。

手順

1. 現行環境から ZDLRA へのアクセスを設定

以下のマニュアルの手順に従って、ZDLRA を使用するための設定を行います。

2. 現行 11g DB のフルバックアップを ZDLRA に取得

2-1. 現行 11g DB でブロック・チェンジ・トラッキングを有効化

増分バックアップの取得時間を短縮するため、ブロック・チェンジ・トラッキングが有効でない場合は有効化します。*6

[oracle@11g]$ export ORACLE_SID=<SID名>
[oracle@11g]$ sqlplus / as sysdba
SQL> alter database enable block change tracking using '<ファイル名>';

データベースが変更されました。

SQL> exit

2-2. 現行 11g DB フルバックアップの取得

カタログ DB に ZDLRA を指定して現行 11g DB に RMAN で接続し、フルバックアップを取得します。

[oracle@11g]$ export ORACLE_SID=<SID名>
[oracle@11g]$ rman target / catalog /@<SCAN名>:1521/zdlra
RMAN> run
{
 configure controlfile autobackup on;
 configure controlfile autobackup format for device type sbt_tape to 'cf_auto_%F';
 configure backup optimization on;
 allocate channel ch1 device type sbt_tape
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)'
   format '%U_%d';
 allocate channel ch2 device type sbt_tape
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)'
   format '%U_%d';
 backup incremental level 0 database filesperset 1 tag='TAG_<DB名>_LV0_D_<日付/時刻>';
 backup archivelog all filesperset 32 not backed up tag='TAG_<DB名>_LV0_D_<日付/時刻>';
 configure controlfile autobackup clear;
 configure controlfile autobackup format for device type sbt_tape clear;
 configure backup optimization clear;
}
:
RMAN構成パラメータをデフォルトの値にリセットできました

RMAN> exit

3. 現行 11g DB の増分バックアップを ZDLRA に取得

本番移行直前まで、定期的に現行 11g DB の増分バックアップを ZDLRA 上に取得します。*7

[oracle@11g]$ export ORACLE_SID=<SID名>
[oracle@11g]$ rman target / catalog /@<SCAN名>:1521/zdlra
RMAN> run
{
 configure controlfile autobackup on;
 configure controlfile autobackup format for device type sbt_tape to 'cf_auto_%F';
 configure backup optimization on;
 allocate channel ch1 device type sbt_tape
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)'
   format '%U_%d';
 allocate channel ch2 device type sbt_tape
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)'
   format '%U_%d';
backup current controlfile tag='TAG_<DB名>_LV1_C_<日付/時刻>';
 backup spfile tag='TAG_<DB名>_LV1_S_<日付>';
 backup incremental level 1 cumulative database filesperset 1 tag='TAG_<DB名>_LV1_D_<日付/時刻>';
 backup archivelog all filesperset 32 not backed up tag='TAG_<DB名>_LV1_A_<日付/時刻>';
 configure controlfile autobackup clear;
 configure controlfile autobackup format for device type sbt_tape clear;
 configure backup optimization clear;
}
:
RMAN構成パラメータをデフォルトの値にリセットできました

RMAN> exit

4. 次期環境から ZDLRA へのアクセスを設定

次期環境に対して、現行環境と同様に「1. 現行環境から ZDLRA へのアクセスを設定」の内容を実施します。

5. 次期環境上に DB を複製

5-1. ディレクトリの作成

次期 12c DB 用のディレクトリを作成します。
なお、ZDLRA に登録する DB の DB_UNIQUE_NAME は一意である必要があるため、現行 11g DB とは別の値に変更します。*8

[oracle@12c]$ mkdir -m 750 ${ORACLE_BASE}/admin/<12c DB_UNIQUE_NAME>
[oracle@12c]$ mkdir -m 750 ${ORACLE_BASE}/admin/<12c DB_UNIQUE_NAME>/adump
[oracle@12c]$ mkdir -m 750 ${ORACLE_BASE}/admin/<12c DB_UNIQUE_NAME>/dpdump
[oracle@12c]$ mkdir -m 750 ${ORACLE_BASE}/admin/<12c DB_UNIQUE_NAME>/pfile

5-2. 補助インスタンス用 PFILE の作成

補助インスタンス用の PFILE を作成します。

[oracle@12c]$ vi ${ORACLE_HOME}/dbs/init<SID名>_aux.ora
db_name='<12c DB_NAME>'
db_unique_name='<12c DB_UNIQUE_NAME>'
db_domain='<DB_DOMAIN>'

5-3. 補助インスタンスの起動

補助インスタンスを NOMOUNT 状態で起動します。

[oracle@12c]$ export ORACLE_SID=<SID名>
[oracle@12c]$ sqlplus / as sysdba
SQL> startup nomount pfile='${ORACLE_HOME}/dbs/init<SID名>_aux.ora'

ORACLEインスタンスが起動しました。

Total System Global Area 1073741824 bytes
Fixed Size                  2932632 bytes
Variable Size             377487464 bytes
Database Buffers          687865856 bytes
Redo Buffers                5455872 bytes

SQL> exit

5-4. 複製の実行

ZDLRA 上のバックアップを使用して、次期環境上に DB を複製します。*9

[oracle@12c]$ rman auxiliary / catalog /@<SCAN名>:1521/zdlra
RMAN> run {
 allocate auxiliary channel 'ch1' device type sbt_tape 
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)';
 allocate auxiliary channel 'ch2' device type sbt_tape 
   PARMS='SBT_LIBRARY=${ORACLE_HOME}/bin/orara.dll,
   SBT_PARMS=(RA_CLIENT_CONFIG_FILE=${ORACLE_HOME}/database/ra_ikou.ora)';
 set newname for block change tracking file to '<ブロック・チェンジ・トラッキングファイル格納先>';
 set until scn <任意のSCN>;
 duplicate database <11g DB_NAME> dbid <11g DBID> to <12c DB_NAME> noopen
 db_file_name_convert ('<11g DB_UNIQUE_NAME>','<12c DB_UNIQUE_NAME>')
 spfile 
   set db_unique_name='<12c DB_UNIQUE_NAME>'
   set control_files='<制御ファイル1>', '<制御ファイル2>', '<制御ファイル3>'
   set cluster_database='false'
   set audit_file_dest='${ORACLE_BASE}/admin/<12c DB_UNIQUE_NAME>/adump'
   set diagnostic_dest='${ORACLE_BASE}'
   set log_archive_dest_1='LOCATION=<アーカイブログ出力先>';
logfile
   group 1 ('<REDOロググループ1/メンバ1>', '<REDOロググループ1/メンバ2>') size <任意のサイズ>,
   group 2 ('<REDOロググループ2/メンバ1>', '<REDOロググループ2/メンバ2>') size <任意のサイズ>,
   group 3 ('<REDOロググループ3/メンバ1>', '<REDOロググループ3/メンバ2>') size <任意のサイズ>;
}
:
Duplicate Dbが完了しました(完了時間: YYYY/MM/DD HH24:MI:SS)

RMAN> exit

6. 次期環境上の DB をアップグレード

6-1. DB を UPGRADE モードで起動

次期環境に複製された DB は MOUNT モードで起動しているため、UPGRADE モードで OPEN します。

[oracle@12c]$ export ORACLE_SID=<SID名>
[oracle@12c]$ sqlplus / as sysdba
SQL> alter database open resetlogs upgrade;

データベースが変更されました。

SQL> exit

6-2. アップグレードの実行

アップグレードスクリプトを実行します。

[oracle@12c]$ ${ORACLE_HOME}/bin/dbupgrade

6-3. アップグレード後の確認

アップグレードスクリプトの実行後には、インスタンスは停止しています。
「READ WRITE」のステータスでオープンすること、バージョンが正しいことを確認します。

[oracle@12c]$ sqlplus / as sysdba
SQL> startup
:
データベースがオープンされました。

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ WRITE

SQL> select version from v$instance;

VERSION
-----------------
12.2.0.1.0

SQL> exit

活用例2:検証 DB 作成

さて、ここまでで ZDLRA を使用した DB 移行についてご紹介しましたが、そうすると、「一度 DB を移行したらもう ZDLRA の活用用途はないのか」と考えられる方も出てくるかもしれません。
そこで、2 点目の活用例として、ZDLRA を使用した検証 DB 作成方法をご紹介します。ここでも DB 移行と同様に Data Pump を利用されている方が多いかと思いますが、ZDLRA を使用しても簡単に検証 DB を作成できますので、是非こちらの方式も検討されてみてください。


以下では、本番環境の DB から ZDLRA に取得したバックアップを使用して、複数の検証 DB を作成する例を記載しています。

本番環境の DB が ZDLRA にアクセスできるように設定を行い(1)、初回フルバックアップおよび定期的な増分バックアップを取得します(2~3)。
検証環境にも同様に ZDLRA へのアクセス設定を行っておきます(4)。

※ 上記(1~4)は、通常の ZDLRA 利用における DB バックアップのオペレーションです。すでに実施済みの場合には、本方式の実現のために追加で実施する必要はありません。

いざ検証 DB の作成時には、ZDLRA 上に取得したバックアップを使用して、DB を複製すれば OK です(5)。
アップグレードを必要としないくらいで、実施内容は DB 移行手順とほぼ変わりません。

本方式での検証 DB 作成のメリットとしては、以下が挙げられます。

1. 任意の断面を指定した検証 DB 作成が可能
事前にリアルタイム REDO 転送設定を行っておくことにより、最新のデータまで ZDLRA 上に同期されるため、本番 DB に触ることなく、任意の断面を指定して DB の複製を行うことが可能です。*10
2. 通常のバックアップの転用
バックアップ運用で ZDLRA 上に取得したバックアップを DB 複製に転用できるため、Data Pump のように検証 DB 作成のために本番 DB から都度データを抜く必要がなく、データの断面を揃えるために業務を停止する必要がありません。

以下、検証 DB の作成手順をご説明します。

手順

DB 移行手順の5-3までは、同様の手順を実施します。なお、複製元の DB に対しては、予めリアルタイム REDO トランスポートの構成 を行っておきます。
5-4 では、同じバージョン間であればアップグレードは不要なため、DUPLICATE 実行時の "NOOPEN" オプションを外すことで、複製後に DB が自動的に OPEN 状態まで遷移します。
なお、検証 DB を再作成する場合には、事前に DBCA 等で既存の検証 DB を削除してから、再度 DUPLICATE を実行するようにしてください。

おわりに

以上、ZDLRA の活用例をご紹介しましたが、これらはあくまで付加価値であり、ZDLRA の利用における最大のメリットは、DB のデータロスをゼロにするという点であることはご認識いただければと思います。
もしかしたら、「DB のバックアップ・リストアの用途しかない」と考えられて ZDLRA の導入に二の足を踏んでいる企業様もいらっしゃるかもしれませんので、こういった副次的な活用法についても知っていただいた上で、改めて ZDLRA の利用を検討していただけると幸いです。

番外編~私の散歩道~

残念ながら目的がないと外出できない私は、お散歩というものをほとんどしないのですが、ふと小さい頃によく訪れた場所を思い出しました。

東京都杉並区にある馬橋公園です。育ちは九州の田舎ですが、実は東京生まれな私は、小さい頃はよく母に連れられて、2 歳上の兄と一緒に近所のこの公園のアスレチックに遊びに来ていました。それから約 25 年が経ち、近年の安全問題を受けてか、現在はすっかり遊具が減って殺風景になってしまいました。ただ、昔はアスレチックしか目に入っていませんでしたが、敷地内に池があって鯉も泳いでいるなど、なかなか風情のある公園です。

道半ばにあるコンビニも、幼少期にオーナー夫妻や従業員の方にとても可愛がっていただき、大変思い入れのあるお店です。先日久々に訪れたところ、オーナーは入院中とのことで、残念ながらお会いできませんでした。もう結構なお年のはずなので、近いうちにまた足を運ぼうと思ったのでした。

前提条件

共通
・各手順はシングルインスタンス構成の DB を基準に記載しています。Real Application Clusters 構成の DB の場合は、設定を全ノードに対して実施するなど、適宜手順を見直して実施してください。
・DUPLICATE の要件として、複製元と複製先の環境は、同一プラットフォームであることを前提としています。具体的にはマニュアルの記載に準じます。
・各手順は ZDLRA を利用した DB 移行の流れに注目して記載しており、複製やアップグレード前後におけるチェック手順は省略しています。また、複製についても環境やバージョンによってコマンドが異なる場合がありますので、正確な手順はマニュアルを参照してください。
DB 移行
・次期 12c DB は、非 CDB を前提として記載しています。CDB として利用する場合には、別途 CDB 化の作業を実施する必要があります。
・次期環境には、予め Oracle Database 12c のソフトウェアがインストールされており、移行対象 DB と同じ DB_UNIQUE_NAME の DB は存在しないことを前提としています。
検証 DB 作成
・本番環境から検証環境に DB を複製するにあたり、両環境では PSR(Patch Set Release)から個別パッチまで同じものが適用されていることを前提としています。パッチ・レベルが違う場合の対応については、マニュアルや My Oracle Support を参照してください。

注釈

  • *1: 2015 年 6 月時点での ZDLRA X4-2 を基にした記事となりますが、2019 年 3 月現在の ZDLRA X7-2 においても、当該記事に記載のある製品仕様における変更点は特にありません。
  • *2: 移行前後の各バージョンについては、ZDLRA および DB アップグレードの要件を満たしている必要があります。詳細はマニュアルを参照してください。
    なお、DB 複製時に 12c 新機能のオプション*3を指定するため、移行後のバージョンは 12c Release 1(12.1.0.1)以上である必要があります。
  • *3: 11g までは、異なるバージョン間での DB 複製は、DUPLICATE の一連の処理内で、DB のリカバリ後の OPEN に失敗するため、サポートされていませんでした。しかし、12c からは、DUPLICATE 実行時に自動的に DB をオープンしない NOOPEN 句を指定できるようになったため、異なるバージョン間での DUPLICATE コマンドの実行がサポートされるようになりました。
    参考:Frequently Asked Questions about Restoring Or Duplicating Between Different Versions And Platforms (ドキュメントID 369644.1)
  • *4: 参考:Zero Data Loss Recovery Appliance検証 - 永遠差分バックアップ
  • *5: 参考:Comprehensive Recovery Appliance Validation (ドキュメントID 2176338.1)
  • *6: 通常、ブロック・チェンジ・トラッキングファイルは、Level 0 フルバックアップ後の Level 1 増分バックアップに対してデフォルトでは 7 回(フルバックアップを入れて 8 回)までしか利用されないという制限がありますが、ZDLRA の場合は、都度作成される仮想フルバックアップが Level 0 として扱われるため、その制限には該当しません。
    参考:Optimice ZDLRA Backups (ドキュメントID 2352267.1)
  • *7: 以下の理由から、今回の DB 移行の例ではリアルタイム REDO 転送設定は行っていません。
    • 仮想フルバックアップは、フルバックアップと増分バックアップに対して作成される。リアルタイム REDO 転送設定によって作成されたアーカイブログに対しては、仮想フルバックアップは作成されない。
    • リアルタイム REDO 転送を行えば、定期的に増分バックアップを取得しなくても最新状態までデータが保持されるが、仮想フルバックアップによる複製時間短縮の恩恵を受けられない。
    要件に応じてリアルタイム REDO 転送設定を行うこと自体は特に問題ありませんが、上記の点には留意しておく必要があります。
  • *8: 移行後は元の 11g DB のバックアップは不要となりますが、ZDLRA 上での手動でのバックアップ削除はサポートされません。また、11g DB のバックアップが存在する状態で ZDLRA 上から 11g DB の情報を削除すると、 ZDLRA 上に当該バックアップが残存し続ける可能性があります。そのため、11g DB が保護ポリシーの定義に従って削除されるまで、ZDLRA 上に 11g DB の情報を登録しておくことが望ましいと言えます。その際、ZDLRA 上では保護対象 DB の DB_UNIQUE_NAME は一意である必要があるため、次期 12c DB の DB_UNIQUE_NAME は、現行 11g DB のものとは別名を定義する必要があります。
  • *9: 12c で「廃止」された(※「非推奨」ではない)パラメータが SPFILE に明示的に設定されていると、DUPLICATE 実行時に "ORA-32014: error processing parameter \"%s\" from the SPFILE restore image" や "LRM-00101: unknown parameter name '%.*s'" といったエラーが発生して、処理が失敗します。なお、この場合、DUPLICATE 実行時に RUN 句内で当該パラメータに対して RESET 句を指定しても、"RMAN-06581: option %s not supported" が発生して処理が失敗します。
    そのため、現行環境に次期バージョンで廃止されたパラメータが設定されている場合には、ZDLRA へのバックアップ取得前に現行 DB で SPFILE から削除しておくか、PFILE を使用した DUPLICATE を実行するなど、対処を行う必要があります。
  • *10: *7 と同様の理由から、リアルタイム REDO 転送設定を行っていても、定期的に増分バックアップを取得することを強くお勧めします。