しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、ようやく春が来ますね～。有り難いことに、東奔西走という言葉を使いたくなる状況の”しばちょう”こと柴田長（しばた つかさ）です。
さて、不幸にも何かしらの原因によりデータベースのリストア・リカバリが必要になったが、いざ実行しようとしても設計から漏れていて手順が無いとか、バックアップを取得しているだけで一度もリカバリのテスト実行した事が無いので本当に戻せるのか不安だ。と言う話を耳にすることが残念ながら少なくありません。私のSIer時代を思い返してみても、万が一の場合にしか必要の無い備えは開発スケジュール上、後回しになる傾向があったかなとも思います。しかし、トラブルが発生する場合は、二重、三重の障害が重なる事も少なからずありますので、被害を最小限に食い止める絶対的な防護壁として確実なリストア・リカバリの実行が求められるのも事実です。
という事で今回は、RMANのVALIDATEコマンド/オプションを使用してRecovery Managerの名前の通りにリカバリを管理する方法を第21回から第24回の連載の復習も兼ねて、体験して頂きたいと思います。（この第44回の連載は、RMANコマンドのリファレンスとしてご活用頂きたいなと思いながら書きましたので、前半の演習問題はほぼ復習となります）
第21回 Recovery Managerによる差分増分バックアップ 2013.08.27公開
第22回 Recovery Managerによる高速差分増分バックアップ 2013.09.30公開
第23回 Recovery Managerにおけるバックアップ時間をResource Managerで制御 2013.10.31公開
第24回 Recovery ManagerによるData Recovery Advisorの活用 2013.11.29公開
以下の演習をOracle Database 12c Release 1のデータベースで試してみてください。
なお、Oracle Database 12c Release 1 (12.1.0.2) の単一インスタンス・データベースのインストレーション・ガイド 及び、Oracle VM VirtualBoxを用いたOracle Database 12c Release 1 環境の構築ガイドが、Oracle Technology Networkのこちらのページに公開されておりますので、参考にしてみてください。
【参考情報】
しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニング
データベースのバックアップ・リカバリは何が正解なのか
統合データベース環境の運用効率化に「マルチテナント」と「Zero Data Loss Recovery Appliance」は使えるか？
- 【今回ご紹介するネタ一覧（逆引き）】
- ✓ RMANの高速増分バックアップを取得可能な環境設定（演習2）
- ✓ RMAN関連パラメータの設定（演習3）
- ✓ RMANのREPORTコマンド（演習4,5）
- ✓ 日曜日にフルバックアップを取得するバックアップ・スクリプト例（演習6）
- ✓ 月～土曜日に高速増分バックアップ（累積）を取得するバックアップ・スクリプト例（演習8）
- ✓ レベル0イメージ・コピー・バックアップのVALIDATE（演習9）
- ✓ VALIDATEコマンドでマルチ・セクション機能を使う（演習9）
- ✓ レベル0バックアップのリストア事前評価（演習10）
- ✓ レベル1バックアップのVALIDATE（演習11）
- ✓ 増分更新バックアップの事前評価（演習12）
- ✓ アーカイブ・ログのバックアップのVALIDATE（演習13）
- ✓ リカバリの事前評価（演習14）
1. 512MBの表領域”TBS44″を作成します。その表領域上に約400MBのTRYスキーマの表”TAB44″（第一カラムが主キーでNUMBER型の列名COL1、第二カラムがCHAR(1000)型の列名COL2）を作成して下さい。
$ sqlplus / as sysdba
SQL> -- TBS44表領域と、この表領域をデフォルト表領域とするTRYユーザーの作成
create tablespace TBS44 datafile '+DATA(DATAFILE)' size 512m uniform size 4m ;
create user TRY identified by TRY default tablespace TBS44 ;
grant connect, resource, dba to TRY ;
SQL> -- TAB44表の作成とデータ・ローディング
connect TRY/TRY
create table TAB44 (COL1 number NOT NULL, COL2 char(1000)) pctfree 10 ;
insert /*+append */ into TAB44 select LEVEL, 'hoge'||to_char(LEVEL)
from DUAL connect by LEVEL <= 7 * 128 * 400 ;
commit;
create unique index IDX_TBL21_COL1 on TAB44(COL1) ;
alter table TAB44 add primary key (COL1) using index ;
SQL> -- TRYスキーマ内のセグメント・サイズを確認
set linesize 150
col SEGMENT_NAME for a24
select SEGMENT_TYPE, SEGMENT_NAME, sum(BYTES)/1024/1024
from USER_SEGMENTS
group by rollup(SEGMENT_TYPE, SEGMENT_NAME) ;
SEGMENT_TYPE SEGMENT_NAME SUM(BYTES)/1024/1024
------------------ ------------------------ --------------------
INDEX IDX_TBL21_COL1 8
INDEX 8
TABLE TAB44 404
TABLE 404
412
はい、こちらの演習問題については何も問題無いと思いますので、説明は割愛させて頂きますね。毎度のことながら原稿提出の締め切り時刻が迫ってきています（笑）
2. アーカイブ・ログ・モードと高速リカバリ領域の設定を行い、さらに高速増分バックアップ用にブロック・チェンジ・トラッキングを有効化して下さい。
$ sqlplus / as sysdba SQL> -- アーカイブ・ログ・モードの設定 shutdown immediate startup mount alter database archivelog ; SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 408 Next log sequence to archive 410 Current log sequence 410 SQL> alter database open ; SQL> -- 高速リカバリ領域の設定確認（すいません。設定は省略） show parameter DB_RECOVERY NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string +FRA db_recovery_file_dest_size big integer 8000M SQL> -- ブロック・チェンジ・トラッキングの有効化 alter database enable BLOCK CHANGE TRACKING using file '+FRA(CHANGETRACKING)' ; col FILENAME for a48 select * from V$BLOCK_CHANGE_TRACKING ; STATUS FILENAME BYTES CON_ID ---------- ------------------------------------------------ ---------- ---------- ENABLED +FRA/ORCL/CHANGETRACKING/ctf.264.907940933 11599872 0 SQL> -- オマジナイ alter system checkpoint ; alter system switch logfile ;
はい、この設定を施すだけでRMANの高速増分バックアップを取得することが可能な状態になります。こちらは「第22回 Recovery Managerによる高速差分増分バックアップ」の演習1と演習3の復習となりますので、そちらの解説を読んでみて下さいね。
本当に、万が一のリカバリを考えた場合には、必ずアーカイブ・ログ・モードで運用しておいてくださいね。一昔と言うか、二昔ぐらい前はストレージのI/O性能が十分では無くアーカイブ・ログを書き出す処理が性能へ大きな影響を与えることを嫌がり、ノーアーカイブ・ログ・モードを選択される事があったかもしれませんが、最近はこの部分がボトルネックになるケースは稀なH/Wスペックになってきていると感じていますので、是非、ノーアーカイブ・ログ・モードは卒業しましょう。
3. 次の要件を満たすように、RMANの関連パラメータを設定して下さい。
要件1) 自動的に2つのチャネル（RMANのサーバー・プロセス）が割り当てられること
要件2) 常に、レベル0バックアップが1つ保持されること
要件3) アーカイブ・ログファイルは一度バックアップされない限り削除されないこと
要件4) アーカイブ・ログファイルのバックアップは圧縮アルゴリズム”LOW”で取得されること
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"; $ rman target / RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 ; CONFIGURE RETENTION POLICY TO REDUNDANCY 1 ; CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DEVICE TYPE DISK ; CONFIGURE COMPRESSION ALGORITHM 'LOW' ;
こちらは連載の中で扱うのは初めてになりますが、分かってしまえばそれほど難しい内容では無いと思います。
CONFIGUREコマンドはRMANのバックアップ・リストア作業全般に影響する設定を作成・変更するコマンドであり、今回は4つの要件に合わせて4つの設定を施している例となりますので、要件とコマンドを見比べて頂ければ、それっぽいキーワードが含まれていますのでご理解頂けるかと思います。詳細は、Oracle Databaseバックアップおよびリカバリ・リファレンスをご参照ください。
少しだけ補足します。
RMANの用語で「チャネル」がありますが、これはRMANのサーバー・プロセスだと思って下さい。デフォルトではこのチャネルが一人だけ起動してバックアップやリストアを行いますが、その場合は一つのOSプロセスしか動けないと言う事なので一つのCPUコアが性能限界となりますし、それによりI/O性能も充分に引き出せない事を意味しています。つまり、より早くバックアップ・リカバリを行いたい場合にはチャネル数を増加すれば良いですし、逆に、業務アプリのSQL処理時間へのバックアップ処理による影響を極小化したい場合にはチャネル数は「1」のままで良いです。さらに絞りたければ、「第23回 Recovery Managerにおけるバックアップ時間をResource Managerで制御」をご参考にして頂ければと思います。
ちなみに、圧縮アルゴリズムは「BASIC」、「LOW」、「MEDIUM」、「HIGH」の4段階から選択可能です。「BASIC」以外のアルゴリズムを使用する為には、Advanced Compression Optionが必要となりますのでご注意ください。でも、私のお薦めはCPUコストが低くて圧縮率もそれなりの効果が期待できるバランス型の「LOW」だったりします。。。
4. RMANのREPORTコマンドで、データベースの全てのデータファイルと表領域名を表示して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
RMAN> REPORT SCHEMA ;
using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name ORCL
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 800 SYSTEM YES +DATA/ORCL/DATAFILE/system.261.841575323
2 400 SYSAUX NO +DATA/ORCL/DATAFILE/sysaux.262.841575331
3 512 TBS44 NO +DATA/ORCL/DATAFILE/tbs44.263.907940129
4 100 USERS NO +DATA/ORCL/DATAFILE/users.265.841575363
6 200 UNDOTBS YES +DATA/ORCL/DATAFILE/undotbs.267.896676927
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1 500 TEMP 32767 +DATA/ORCL/TEMPFILE/temp.264.841575341
ホトンド使われていないコマンドかもしれなかったので、今回は普及の為に演習問題として組み込んでみました。それほど画期的な情報を出力してくれるわけでは無いですが、同じ結果を得るSQL文を書くよりも瞬間的に実行出来ますので便利だったりします。
REPORTコマンドには、この他にも面白い情報を出力するオプションが組み込まれていますので、もう一つの例を次の演習5で試してみましょう。
5. RMANのREPORTコマンドで、バックアップが必要なファイルを表示して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
RMAN> REPORT NEED BACKUP ;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- -----------------------------------------------------
1 0 +DATA/ORCL/DATAFILE/system.261.841575323
2 0 +DATA/ORCL/DATAFILE/sysaux.262.841575331
3 0 +DATA/ORCL/DATAFILE/tbs44.263.907940129
4 0 +DATA/ORCL/DATAFILE/users.265.841575363
6 0 +DATA/ORCL/DATAFILE/undotbs.267.896676927
じゃーん、ですね。この情報は実は非常に大切なのです。なぜならば、演習3で設定したRMANのバックアップの保持ポリシーに従ってバックアップが必要なデータファイルを示してくれるからですね。つまり、このコマンドの結果が一件でも存在した場合、バックアップ保持ポリシーを満たしていない状態である為、もしもの時にリカバリできない可能性があることを意味していますから、急いでバックアップ取りましょう！！もちろん、データファイルが作成された直後であればREDOログからリカバリすることは可能なので、絶対にリカバリ出来ないとは言えない状況では無いのでご安心ください。
演習4、5以外にもREPORTコマンドには興味深い情報を出力するオプションが満載なので、是非ともOracle Databaseバックアップおよびリカバリ・リファレンスの次のリンクを参照してみて下さい。特に、表3-7なんて実に面白いですよね。表データをAPPENDヒント句付きのダイレクト・ロードをNOLOGGINGオプションで実行した場合が該当します。
• 表3-1「データベース・スキーマのレポート」
• 表3-2「n日分より多くのアーカイブ・ログがリカバリ用に必要なファイルのレポート」
• 表3-3「nより多くの増分がリカバリ中に必要なファイルのレポート」
• 表3-4「n日のリカバリ期間を満たすようにバックアップを行う必要があるファイルのレポート」
• 表3-5「n未満の冗長度のバックアップしかないファイルのレポート」
• 表3-6「不要なバックアップとコピーのレポート」
• 表3-7「リカバリ不能操作が原因でバックアップが必要となったファイルのレポート」
6. 日曜日はフルバックアップで月～土曜日は高速増分バックアップ（累積）、常に約1日前の時点までリカバリ可能な状態のレベル0イメージ・コピー・バックアップを保持するバックアップ運用を仮定し、
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN> -- 日曜日のフルバックアップ
run{
RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-23/24' ;
DELETE NOPROMPT OBSOLETE ;
BACKUP AS COPY INCREMENTAL LEVEL 0 DATABASE TAG 'INCR_UPDATE' ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}
（実行ログは長いので省略）
現実に良くあると思われる、データベースのバックアップ運用を想定してみましたので、参考にしてみて下さい。
一行目の「RECOVER COPY OF DATABASE」文は、レベル0のイメージ・コピー・バックアップに対してレベル1の差分増分バックアップを適用する増分更新の処理を行っています。このタイミングではレベル0もレベル1も存在していませんから空振りとなりますが、次の日曜日にこのバックアップ・スクリプトを実行したタイミングでは、金曜日時点のレベル0に対して土曜日のレベル1を適用する増分更新処理が実行されます。増分更新については 第21回 Recovery Managerによる差分増分バックアップで復習してみて下さい。
ちなみに、UNTIL TIME句で「SYSDATE-23/24」を指定していますが、これはこのコマンドを実行したタイミングから23時間前の時点までリカバリしろーという意味です。何故、23時間で24時間では無いのか？この謎についてはバックアップ運用のスケジュールを引いてみて頂けるとご理解頂けると思います。ヒントは「バックアップ取得時間を1時間考慮している」です。答えの解説は 【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニングのスライドP.27~28をご参照ください。
二行目の「DELETE NOPROMPT OBSOLETE」文は、バックアップの保持ポリシー及びアーカイブ・ログの削除ポリシーに従って自動的に不要なバックアップを削除する処理を実行しています。この二つのポリシーは非常に大切なので解説しておきたいところですが、まだまだ先が長いのでサボラらせて下さい。とは言え、 【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニングのスライドP.30~P.36で紹介させて頂いておりますので、そちらをご参照頂けると幸いです。すいません！
三行目の「BACKUP AS COPY」文がメインである、レベル0のイメージ・コピー・バックアップを取得するコマンドですね。このレベル0を取得する際に指定したTAG名が以降に実行する増分バックアップを取得する際の起点（SCN）を識別する情報となりますので、絶対に忘れないようにして下さい。もちろん、後からLISTコマンド等で確認することは出来ますけどね。
四行目の「BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL」文が、アーカイブ・ログを圧縮してバックアップしておく処理となります。今回の環境に関しては演習2で「Archive destination」が「USE_DB_RECOVERY_FILE_DEST」に設定されていることから、オンラインREDOログからアーカイブされたアーカイブ・ログはFRA領域に書き込まれており、圧縮したアーカイブ・ログのバックアップと同じストレージ上に配置されることとなります。なので、四行目を絶対に実行しなければならないかと問われると、そんなことはありません。しかしながら、圧縮して保持しておけると言う事で何となくストレージ容量的にお得な感じがしますし、別のストレージ筐体へアーカイブ・ログのバックアップを退避するケースも多いと思いますので、参考までに記載しています。
また、RMANのコマンドに少し詳しい方は、何故？と思うでしょう。何故、三行目のバックアップに「plus archivelog」オプションを付けなかったのか？それはアーカイブ・ログだけを明示的に圧縮したかったからですね。
7. 差分データを生成する為、TAB44表内の100MB分のブロックをUPDATE文にて更新してください。
$ sqlplus /nolog
SQL> -- UPDATE対象量の確認
connect TRY/TRY
select count(distinct(dbms_rowid.rowid_block_number(ROWID))) * 8 / 1024 as "UPDATED_MB"
from TAB44
where COL1 < 7 * 128 * 100 ;
UPDATED_MB
----------
100
SQL> -- 150MB分を更新
update TAB44 set COL2='updated' where COL1 < 7 * 128 * 100 ;
commit ;
はい、こちらは完全な復習となります。更新量を制御する便利なスキルですから、第21回 Recovery Managerによる差分増分バックアップの演習4で復習しておいてください。
と言う所で、ようやく折り返し地点です。後半頑張っていきましょう。
8. 日曜日はフルバックアップで月～土曜日は高速増分バックアップ（累積）、常に約1日前の時点までリカバリ可能な状態のLevel0イメージ・コピー・バックアップを保持するバックアップ運用を仮定し、
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN> -- 月～土曜日の高速増分バックアップ
run{
RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' UNTIL TIME 'SYSDATE-23/24' ;
DELETE NOPROMPT OBSOLETE ;
BACKUP CHECK LOGIFAL INCREMENTAL LEVEL 1 CUMULATIVE FOR RECOVER OF COPY
WITH TAG 'INCR_UPDATE' DATABASE ;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL TAG 'INCR_UPDATE' ;}
（実行ログは長いので省略）
こちらは演習6で扱ったバックアップ運用の続きをイメージしています。一行目、二行目、そして四行目は演習6と全く同じですが、三行目のコマンドだけ変えてありますのでご注意ください。こちらのコマンドが高速増分バックアップ（累積）であり、このコマンドを実行した際にTAG名「INCR_UPDATE」が付いているレベル0バックアップのCheckpoint SCN番号以降に更新が行われた差分ブロックをレベル1の差分バックアップとして取得してくれます。
また、「FOR RECOVER OF COPY」句は非常に便利なオプションです。例えば、日曜日にフルバックアップによって全データファイルに対するレベル０のイメージ・コピー・バックアップを取得していますが、火曜日に新たな表領域が作成されたことでデータファイルが追加されたとしましょう。この新規データファイルのレベル０のイメージ・コピー・バックアップは何曜日に取得されるのでしょうか？次の日曜日まで待たなければなりませんか？いいや、それは待てませんよね。でも安心して下さい。火曜日夜間に実行するこちらの高速増分バックアップ（累積）で自動的に取得されちゃいますよ。と言うのが、「FOR RECOVER OF COPY」句の効果となります。凄いでしょ？このオプションは絶対に使うべきです！！
ちょっと説明がややこしかったと思いますので、「レベル0バックアップのCheckpoint SCN番号以降」という表現部分と「FOR RECOVER OF COPY」句に関しては、これまた【Oracle DBA & Developer Day 2014】しばちょう先生による特別講義！ RMANバックアップの運用と高速化チューニングのスライドP.25~26も参考にしてみて下さい。
9. 演習6で取得したレベル0イメージ・コピー・バックアップの正常性（破損ブロックが含まれていないか）を確認して下さい。ただし、高速化の目的で各ファイルをセクション・サイズ128MBに分割して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"; $ rman target / connected to target database: ORCL (DBID=1369356044) RMAN> VALIDATE CHECK LOGICAL SECTION SIZE 128M DATAFILECOPY ALL NODUPLICATES DEVICE TYPE DISK ; Starting validate at 2016/04/01 06:33:57 using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: including datafile copy of datafile 00004 in backup set input file name=+FRA/ORCL/DATAFILE/users.286.907999891 channel ORA_DISK_2: starting validation of datafile channel ORA_DISK_2: including datafile copy of datafile 00001 in backup set input file name=+FRA/ORCL/DATAFILE/system.290.907999849 validating blocks 1 through 16384 channel ORA_DISK_1: validation complete, elapsed time: 00:00:03 List of Datafile Copies ======================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 4 OK 0 11363 12800 2241085 File Name: +FRA/ORCL/DATAFILE/users.286.907999891 Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 1280 Index 0 0 Other 0 157 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: including datafile copy of datafile 00001 in backup set input file name=+FRA/ORCL/DATAFILE/system.290.907999849 validating blocks 16385 through 32768 （以降は省略）
さあ、ようやく復習も一段落して、今回の連載で本当に体験して頂きたいVALIDATEコマンドが連続して登場してきます。
その一つ目として、取得済みのレベル0イメージ・コピー・バックアップの正常性（破損ブロックが含まれていないか）を確認する方法となります。これは定期的に実行して頂きたいコマンドです。いざバックアップからリストアする必要がある場合、リストアしようと試みたレベル0バックアップが壊れていたら最悪ですよね。もちろん、RMANはバックアップする際に各ブロック内に埋め込まれているチェックサムの値を再計算してブロック破損をチェックしてくれています。（データベースの初期化パラメータDB_BLOCK_CHECKSUM=OFF以外の場合。OFFの場合はSYSTEM表領域だけにチェックサムが埋め込まれています。）しかしながら、バックアップを書き込む際に何かしらの原因で壊れてしまう事が絶対に無いとは言い切れません。これがSystem Engineerのサガなのかもしれませんけど。と言う事で、保存されているバックアップの正常性は定期的に確認をして、万が一に備えておいて頂きたいのです。
上記の回答例の構文は少々複雑ですが、簡単に書くとしたら「VALIDATE COPY OF DATABASE ;」でも動きます。ただし、それだけでは私の連載としてはつまらないので追加で3つのオプションをご紹介しておきましょう。（盛り込み過ぎ・・・）
(1) CHECK LOGICAL : チェックサムによる破損検出だけでは無く、論理的なブロック破損のチェックを追加で行わせる
(2) SECTION SIZE 128M : マルチ・セクション機能で一つのデータファイルを128MBに区切って複数のチャネルで処理させる
(3) NODUPLICATES : 任意のデータファイルに対するDATAFILECOPY（バックアップされているイメージ・コピー・バックアップ）が複数存在する場合、それらを全てチェックする必要は無く、一番新しいDATAFILECOPYだけを対象とする
マルチ・セクション機能が上手く動いているのか否かは、上記回答例の青文字部分を確認して頂ければご理解頂けるかと思います。SYSTEM表領域のASMファイル番号290のデータファイルに対して、ORA_DISK_2というチャネル1~16384番目のブロック（128MB=(16384-1+1)*8KB/1024）をチェックし、ORA_DISK_1というチャネルがその続きである16385~32768番目のブロック（128MB=(32768-16384+1)*8KB/1024）をチェックしていることから、一つのデータファイルを二つのチャネルが分割して読み込んでいることが一目瞭然です。ビッグ・ファイル表領域のデータファイルには非常に効果が高い機能だと思います。
さて、如何でしょうか？VALIDATEコマンドは奥が深いですよね。使いこなすのは少々難しいかもしれませんが、是非、Oracle Databaseバックアップおよびリカバリ・リファレンスのVALIDATEの解説を読んで頂ければと思います。
10. レベル0バックアップがリストア可能か否かを評価して下さい。(演習9と同じ目的)
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN>
RESTORE (DATABASE FROM TAG 'INCR_UPDATE') CHECK LOGICAL VALIDATE ;
Starting restore at 2016/04/01 06:36:20
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: scanning datafile copy +FRA/ORCL/DATAFILE/system.290.907999849
channel ORA_DISK_2: scanning datafile copy +FRA/ORCL/DATAFILE/sysaux.289.907999875
channel ORA_DISK_2: scanning datafile copy +FRA/ORCL/DATAFILE/tbs44.294.907999847
channel ORA_DISK_1: scanning datafile copy +FRA/ORCL/DATAFILE/users.286.907999891
channel ORA_DISK_1: scanning datafile copy +FRA/ORCL/DATAFILE/undotbs.288.907999883
Finished restore at 2016/04/01 06:36:40
こちらはRESTOREコマンドとなりますので、えー？リストアしちゃうの？と驚く方もいるのですが、大丈夫ですよ。VALIDATEオプションが付いていますから、実際にはリストアされません。あくまでもリストアすると同じ様にレベル0イメージ・コピー・バックアップをメモリ上に読み込んでくれる機能です。と言う事なので、はい、演習9と同じチェックを行っているのです。
演習9と少し違うのは結果の出力でしょうか？演習9は丁寧にブロック破損の数や読み込んだブロック数をDATAFILECOPY単位で表示してくれるのですが、こちらは特に何も表示してくれないようです。とは言え、もしも、リストアに失敗した場合にはそれなりのメッセージが出力されることになると思います。
11. 演習8で取得した累積増分バックアップ（レベル1のバックアップ・セット）の正常性（破損ブロックが含まれていないか）を確認して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS"; $ rman target / connected to target database: ORCL (DBID=1369356044) RMAN> -- バックアップ・セットの表示 LIST BACKUP OF DATABASE BY FILE ; List of Datafile Backups ======================== File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag ---- ------- - -- - ---------- ------------------- ------- ------- ---------- --- 1 16 B 1 A 2289478 2016/04/01 06:18:31 1 1 NO INCR_UPDATE 2 17 B 1 A 2289475 2016/04/01 06:18:31 1 1 NO INCR_UPDATE 3 17 B 1 A 2289475 2016/04/01 06:18:31 1 1 NO INCR_UPDATE 4 17 B 1 A 2289475 2016/04/01 06:18:31 1 1 NO INCR_UPDATE 6 16 B 1 A 2289478 2016/04/01 06:18:31 1 1 NO INCR_UPDATE RMAN> -- バックアップ・セット16と17の評価 VALIDATE BACKUPSET 16,17 ; Starting validate at 2016/04/01 06:45:46 using channel ORA_DISK_1 using channel ORA_DISK_2 channel ORA_DISK_1: starting validation of datafile backup set channel ORA_DISK_2: starting validation of datafile backup set channel ORA_DISK_1: reading from backup piece +FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.266.908000317 channel ORA_DISK_2: reading from backup piece +FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.267.908000321 channel ORA_DISK_1: piece handle=+FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.266.908000317 tag=INCR_UPDATE channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: validation complete, elapsed time: 00:00:03 channel ORA_DISK_2: piece handle=+FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.267.908000321 tag=INCR_UPDATE channel ORA_DISK_2: restored backup piece 1 channel ORA_DISK_2: validation complete, elapsed time: 00:00:03 Finished validate at 2016/04/01 06:45:49
レベル0バックアップのVALIDATEの次は、そうですよね。レベル1バックアップも同じように正常性を確認しておくべきです。レベル1バックアップはバックアップ・セット形式となりますから、バックアップ・セットを識別する「Key」値を引数として与える必要がありますので、まずは「LIST」コマンドで各データファイルのレベル1バックアップがどのバックアップ・セットに含まれているのかを確認する必要があります。と言う例です。はい、簡単ですね。
12. 増分更新バックアップ（レベル0イメージ・コピー・バックアップにレベル1バックアップを適用）が可能か否かを評価して下さい。(演習11と同じ目的)
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN>
RECOVER COPY OF DATABASE WITH TAG 'INCR_UPDATE' CHECK LOGICAL TEST ;
Starting recover at 2016/04/01 06:41:18
using channel ORA_DISK_1
using channel ORA_DISK_2
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile copies to recover
recovering datafile copy file number=00001 name=+FRA/ORCL/DATAFILE/system.290.907999849
recovering datafile copy file number=00006 name=+FRA/ORCL/DATAFILE/undotbs.288.907999883
channel ORA_DISK_1: reading from backup piece +FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.266.908000317
channel ORA_DISK_2: starting incremental datafile backup set restore
channel ORA_DISK_2: specifying datafile copies to recover
recovering datafile copy file number=00002 name=+FRA/ORCL/DATAFILE/sysaux.289.907999875
recovering datafile copy file number=00003 name=+FRA/ORCL/DATAFILE/tbs44.294.907999847
recovering datafile copy file number=00004 name=+FRA/ORCL/DATAFILE/users.286.907999891
channel ORA_DISK_2: reading from backup piece +FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.267.908000321
channel ORA_DISK_1: piece handle=+FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.266.908000317 tag=INCR_UPDATE
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
channel ORA_DISK_2: piece handle=+FRA/ORCL/BACKUPSET/2016_04_01/nnndn1_incr_update_0.267.908000321 tag=INCR_UPDATE
channel ORA_DISK_2: restored backup piece 1
channel ORA_DISK_2: restore complete, elapsed time: 00:00:07
Finished recover at 2016/04/01 06:41:26
演習9に対する演習10があったように、演習11に対するこの演習12があります。（分かりづらいですかね。すいません）
増分更新バックアップ（レベル0イメージ・コピー・バックアップにレベル1バックアップを適用）を行うコマンドの最後に、「TEST」オプションを追加して下さい。これによって名前の通り、増分更新バックアップのテストが行えます。実際には、増分更新バックアップの処理は行われません。凄く分かり易過ぎて拍子抜けしちゃいますよね。
「CHECK LOGIFAL」オプションはお好みで付けたり外したりして下さい。「追加の論理破損チェックを行う事になる」=「CPUコストが増加する」と言う事なので、上手く調整してみて下さい。とは言え、日中の業務負荷がピークの時間帯に実行する訳ではないと思いますので、基本的には「CHECK LOGIFAL」句を付けることをお薦めします。
13. バックアップ済みのアーカイブ・ログの正常性を確認して下さい。
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN> -- アーカイブ・ログのバックアップ・セットの表示
LIST BACKUP OF ARCHIVELOG ALL ;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
15 4.55M DISK 00:00:00 2016/04/01 06:11:40
BP Key: 25 Status: AVAILABLE Compressed: YES Tag: INCR_UPDATE
Piece Name: +FRA/ORCL/BACKUPSET/2016_04_01/annnf0_incr_update_0.278.907999901
List of Archived Logs in backup set 15
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 433 2281504 2016/03/31 13:59:11 2288410 2016/04/01 06:11:39
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
20 9.64M DISK 00:00:02 2016/04/01 06:18:52
BP Key: 30 Status: AVAILABLE Compressed: YES Tag: INCR_UPDATE
Piece Name: +FRA/ORCL/BACKUPSET/2016_04_01/annnf0_incr_update_0.271.908000331
List of Archived Logs in backup set 20
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 434 2288410 2016/04/01 06:11:39 2288621 2016/04/01 06:16:11
1 435 2288621 2016/04/01 06:16:11 2288656 2016/04/01 06:16:14
1 436 2288656 2016/04/01 06:16:14 2289268 2016/04/01 06:16:36
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
21 4.45M DISK 00:00:03 2016/04/01 06:18:53
BP Key: 31 Status: AVAILABLE Compressed: YES Tag: INCR_UPDATE
Piece Name: +FRA/ORCL/BACKUPSET/2016_04_01/annnf0_incr_update_0.272.908000331
List of Archived Logs in backup set 21
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- ------------------- ---------- ---------
1 437 2289268 2016/04/01 06:16:36 2289324 2016/04/01 06:16:40
1 438 2289324 2016/04/01 06:16:40 2289349 2016/04/01 06:16:46
1 439 2289349 2016/04/01 06:16:46 2289502 2016/04/01 06:18:49
RMAN> -- アーカイブ・ログのバックアップ・セットの評価
VALIDATE BACKUPSET 15, 20, 21 ;
（実行ログは省略）
ですよね。レベル０バックアップ、レベル１バックアップと来たら、アーカイブ・ログのバックアップを評価しますよね。と言う事で、実行方法は上記の通り。VALIDATEコマンドは簡単ですが、アーカイブ・ログのバックアップが含まれるバックアップ・セットを探す為のLISTコマンドをどのように書いたら良いのかが悩み所ですね。はい、私も良く困っています。なので、今回の連載をRMANコマンドのリファレンスとしてまとめたいと考えて・・・しかし道半ばで、力尽きました。。。次、最後の演習です。
14. データファイルのリカバリが可能かを評価してみましょう。(本来はリストア処理後に実施する)
$ export NLS_DATE_FORMAT="YYYY/MM/DD HH24:MI:SS";
$ rman target /
connected to target database: ORCL (DBID=1369356044)
RMAN>
shutdown immediate
starup mount
RECOVER DATABASE CHECK LOGICAL TEST ;
Starting recover at 2016/04/01 07:09:27
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=13 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=240 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 2016/04/01 07:09:28
最後にオマケ的な演習です。本来はバックアップをリストアした後に実行するコマンドとなりますが、このようなコマンドが存在することを知っておいて頂きたいと思い演習に無理やり組み込んでみました。
実際にリカバリをするわけでは無いですが、データファイルに対してREDOログやアーカイブ・ログを適用可能か確認することができます。マニュアルには次の記載があります。「標準リカバリの手順で問題が発生した場合に役立ちます。試行リカバリを使用すると、データベースでREDOの適用後を予測し、発生する可能性のある問題を検出できます。試行リカバリでは、標準リカバリと同じ方法でREDOを適用しますが、ディスクへの変更書込みは行わず、試行リカバリの終了時に変更をロールバックします。」
リカバリ処理で何かしら上手く行かない場合に、データファイルを汚すことなく色々と試行することが出来そうな気がしますね。まだ私もこの機能の恩恵を得た経験はありませんが、もしもの時に思い出せるようにココに記載しておきたいと思います。
さて、過去最多ではないかという演習問題の量でRecovery ManagerのVALIDATEコマンド/オプションを体験頂きましたが、如何でしたでしょうか？ バックアップを取得しているだけで安心していませんか？そのバックアップで本当にリカバリ出来ますか？このような観点で考えてみた場合、Recovery ManagerはBackup Managerには留まらず、正常なバックアップを取得出来ることは当然ながら、確実にリストア・リカバリ出来るような機能でRecoveryまで司るユーティリティです。万が一の障害時に被害を最小限に食い止める絶対的な防護壁として、Recovery Managerを使いこなして確実にリストア・リカバリできるバックアップ取得と評価を運用に組み込んで頂ければと切に願います。（この辺りの主張は、今後、別の媒体やセミナー等で展開したいなと考えています）
今回は力尽きてしまい、VALIDATEコマンドを全てご紹介は出来ませんでしたが、通常のデータファイルの破損チェックも可能ですし、制御ファイルのバックアップやSPFILEをチェックすることが可能です。是非とも通勤電車の中ででも構いませんので、一度、Oracle Databaseバックアップおよびリカバリ・リファレンスのVALIDATEの説明を読んで頂ければ幸いです。
また、RMANのコマンドを使いこなすのは難しい。破損チェック等でデータベース・サーバーのH/Wリソースを消費することを避けたい。運用管理しているデータベースが沢山ある等の課題をお持ちでしたら、Zero Data Loss Recovery Applianceを一度ご検討頂くことをお薦めします。RMANを知っているDBAの方には特にRecovery Applianceの凄みをご理解頂けると私は思います。
[オラクル データベース インサイダー]
データベースのバックアップ・リカバリは何が正解なのか
統合データベース環境の運用効率化に「マルチテナント」と「Zero Data Loss Recovery Appliance」は使えるか？
今回も原稿提出締め切りに何とか間に合いました。乱文にも関わらず、最後まで体験して頂きましてありがとうございました。是非、感想や質問をお待ちしておりますね。次回以降もどうぞよろしくお願い致します。