しばちょう先生の試して納得！DBAへの道 indexページ▶▶
みなさん、こんにちは。 “しばちょう”こと柴田長（しばた つかさ）です。
非常に暑い日が続いておりますが、いかがお過ごしでしょうか？ビアガーデンやBBQ等、ビール好きには堪らない季節なのではないでしょうか？私は良く冷えたソフトな炭酸飲料 が専門なのですけどね。
さて、今回からはRecovery Manager（RMAN）をご紹介していきます。「RMANは、Oracle Databaseと統合し、バックアップおよびリカバリ・アクティビティを実行するためのOracle Databaseユーティリティ（概要マニュアルから抜粋）」です。
データベース管理者として最も恐ろしいのは”データ損失”であり、もしも貴重なデータが消えてしまった場合には、お客様のビジネス機会の損失にも繋がってしまう為、何としてでも回避しなければなりません。とは言え、データ損失を引き起こすメディア障害（データファイルを格納しているハードディスク・ドライブの故障等）やユーザー・エラー（データベース管理者や利用者の誤操作等）が何時発生するかは誰にも分かりませんので、もしもの時の為に十分な準備、さらには復旧オペレーションの習得をしておくことがDBAには求められます。
この「十分な準備」の中で絶対的なものが「バックアップ」ですが、“必要最低限の時間とH/Wリソースの消費で取得することができる”、”いざと言う時に必ず復旧することができる”ことが要求されます。ちなみに、前回、前々回で体験して頂いたFlashback Databaseでは論理障害からの復旧を高速化する非常に有効な機能ではありますが、メディア障害やデータファイルの削除からの復旧には対処することができないのです。
と言う前振りからも想像できるように、RMANを使用すれば上記2つの要求をクリアできるという事を複数回にわたりご紹介していきたいと考えています。今回は基礎編として、RMANによる差分増分バックアップを体験して頂きたいと思います。以下の演習をOracle Database 11g Release 2 Enterprise Editionのデータベースで試してみてください。
- 【今回ご紹介するネタ一覧（逆引き）】
- 増分バックアップのベースとなる Level0イメージ・コピー・バックアップの取得（演習3）
- データファイルとバックアップ ファイルのサイズ比較（演習3）
- RMANのI/O量の確認（演習 3）
- Level1の差分増分バック アップの取得（演習5）
- Level0とLevel1の増分更新バックアップ（演習6）
1. RMANで非一貫性バックアップを取得するターゲット・データベースに対し、アーカイブ・ログ・モード、および高速リカバリ領域を設定してください。
$ sqlplus /nolog
SQL> -- 設定
connect / as sysdba
select STATUS from V$INSTANCE ;
STATUS
------------
OPEN
alter database archivelog ;
alter system set DB_RECOVERY_FILE_DEST = '+FRA' ;
alter system set DB_RECOVERY_FILE_DEST_SIZE = 10g ;
SQL> -- 確認
archive log list
SQL> データベース・ログ・モード アーカイブ・モード
自動アーカイブ 有効
アーカイブ先 USE_DB_RECOVERY_FILE_DEST
最も古いオンライン・ログ順序 2
アーカイブする次のログ順序 4
現行のログ順序 4
show parameter db_recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +FRA
db_recovery_file_dest_size big integer 10G
マニュアル「バックアップおよびリカバリ・ユーザーズ・ガイド」で使用されている単語に慣れて頂く目的で、少し堅い言葉で演習問題を記述させて頂きました。
非一貫性バックアップとはデータベースがオープンされているときに作成されたバックアップです。ホット・バックアップ、オンライン・バックアップとも呼ばれるものですね。バックアップ処理の中ではデータ・ブロックのコピーを作成しますが、数多くのデータ・ブロックをコピーするとなると一瞬で完了するものではなく数十秒、数分、数時間という単位の時間を要することになるので、バックアップ中にデータ・ブロックが更新されることもあるでしょう。よって、バックアップ開始直後にコピーされたデータ・ブロックと、バックアップ終了直前にコピーされたデータ・ブロックではズレが生じる（一貫性が無い）ことになるので、それらのデータ・ブロック（正確にはデータファイル）をリストアした後に、メディア・リカバリを実行し、REDOログ内の更新情報を適用して全てのブロックを同じ地点に揃える（一貫性のある状態）にロールフォワードする必要が生じます。また、その際に必要となるREDOレコードがオンラインREDOログ・ファイル内に存在しているとも限りません。ログスイッチを繰り返して上書きされて消えてしまっているかもしれませんので、アーカイブ・モードでない限り非一貫性バックアップを作成することができないのです。
ターゲット・データベースとは、RMANがバックアップおよびリカバリ操作を実行するデータベースですね。これは特に説明は不要かと思いますが、概要マニュアルでは図を用いて紹介してあるので、そちらも必要に応じて参照してみてください。
上記の解答例は、Flashback Databaseの演習でも体験して頂いた設定ですね。今回もさりげなく、ASMディスクグループ（上記では”FRA”という名前）を高速リカバリ領域に設定しています。ASMについても近いうちにご紹介していきたいと考えています。
2. 本演習での差分増分バックアップの動作を理解し易くする為、ターゲット・データベース上に1GBの表領域”TBS21″を新たに作成し、その表領域上に512MBの表”TAB21″（第一カラムが主キーでNUMBER型の列名COL1、第二カラムがCHAR(1000)型の列名COL2）を作成して下さい。
sqlplus /nolog
SQL> -- TBS21表領域と、この表領域をデフォルト表領域とするTRYユーザーの作成
connect / as sysdba
create tablespace TBS21 datafile '+DATA(DATAFILE)' size 1g uniform size 4m ;
create user TRY identified by TRY default tablespace TBS21 ;
grant connect, resource, dba to TRY ;
SQL> -- TAB21表の作成とデータ・ローディング
connect TRY/TRY
create table TAB21 (COL1 number NOT NULL, COL2 char(1000)) pctfree 10 ;
insert /*+append */ into TAB21
select LEVEL, 'hoge'||to_char(LEVEL)
from DUAL connect by LEVEL <= 7 * 128 * 508 ;
commit;
create unique index IDX_TBL21_COL1 on TAB21(COL1) ;
alter table TAB21 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 TAB21 512
TABLE 512
520
こちらも毎回の作業となりますね。演習問題で”512MBの表”と細かくサイズを指定させて頂きましたが、この辺りをスラスラと実装できるスキルはあらゆる検証作業で重宝します。
非常に細かい話なので、ご興味があれば読んで頂きたいのですが、TAB21の表定義より1レコードが約1KB。データ・ブロックのサイズは8KBで、かつPCTFREEを10%確保したので、一つのデータ・ブロックには7レコードを格納することができる。そのブロックが128個で1MBになるので、「7 * 128 * 512」個のレコードを挿入すれば512MBになりそうです。しかし、INSERT文を高速化する為にダイレクト・ロードを行う「APPENDヒント句」を付けているので、初期エクステントである4MB（表領域作成時にUNIFORMサイズを4MBに指定している為）にはレコードは挿入されません。つまり、512 – 4 = 508MBにレコードを挿入することになりますので、「7 * 128 * 508」個のレコードを挿入すれば良いということになります。
3. RMANを使用して、増分更新バックアップのベースとなる、全てデータファイルのレベル0のイメージ・コピー・バックアップを取得してください。
$ rman target /
ターゲット・データベース: ORCL (データベースID=1287039091)に接続されました
RMAN> -- レベル0のバックアップ実行
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE ;
backupが開始されました(開始時間: 13-08-21)
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=37 デバイス・タイプ=DISK
データファイル1の親バックアップまたはコピーが見つかりません
データファイル2の親バックアップまたはコピーが見つかりません
データファイル3の親バックアップまたはコピーが見つかりません
データファイル5の親バックアップまたはコピーが見つかりません
データファイル4の親バックアップまたはコピーが見つかりません
チャネルORA_DISK_1: データファイルのコピーを開始しています
入力データファイル・ファイル番号=00001 名前=+DATA/orcl/datafile/system.258.820462945
出力ファイル名=+FRA/orcl/datafile/system.269.824073717 タグ=INCR_UPDATE レコードID=48 スタンプ
=824073733
チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:25
チャネルORA_DISK_1: データファイルのコピーを開始しています
入力データファイル・ファイル番号=00002 名前=+DATA/orcl/datafile/sysaux.259.820462945
出力ファイル名=+FRA/orcl/datafile/sysaux.279.824073741 タグ=INCR_UPDATE レコードID=49 スタンプ
=824073758
チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:25
チャネルORA_DISK_1: データファイルのコピーを開始しています
入力データファイル・ファイル番号=00003 名前=+DATA/orcl/datafile/undotbs1.267.820462947
出力ファイル名=+FRA/orcl/datafile/undotbs1.291.824073767 タグ=INCR_UPDATE レコードID=50 スタンプ
=824073783
チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:26
チャネルORA_DISK_1: データファイルのコピーを開始しています
入力データファイル・ファイル番号=00005 名前=+DATA/orcl/datafile/tbs21.257.824073659
出力ファイル名=+FRA/orcl/datafile/tbs21.282.824073793 タグ=INCR_UPDATE レコードID=51 スタンプ
=824073808
チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:25
チャネルORA_DISK_1: データファイルのコピーを開始しています
入力データファイル・ファイル番号=00004 名前=+DATA/orcl/datafile/users.264.820462947
出力ファイル名=+FRA/orcl/datafile/users.276.824073817 タグ=INCR_UPDATE レコードID=52 スタンプ
=824073819
チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:03
backupが完了しました(完了時間: 13-08-21)
Control File and SPFILE Autobackupが開始されました(開始時間: 13-08-21)
ピース・ハンドル=+FRA/orcl/autobackup/2013_08_21/s_824073820.284.824073821 コメント=NONE
Control File and SPFILE Autobackupが完了しました(完了時間: 13-08-21)
RMAN>
演習問題を実現するRMANのバックアップ・コマンドを探すのには少々苦労したかと思います。バックアップおよびリカバリ・ユーザーズ・ガイドは非常に情報量が豊富であり様々なケースに対応したコマンドが掲載されていますが、それが逆にある程度の読み込み時間が必要となってしまうのかと想像しています。
ポイントは「増分更新バックアップのベースとなる」という部分です。とは言え、マニュアルには「増分」、「差分」、「累積」、「更新」と言った日本人的には紛らわしい単語が組み合わさったバックアップ名がRMAN初心者にとっては混乱させられてしまうポイントだと思います。ちょっと整理してみますね。
まず、これらはすべて増分バックアップにカテゴライズされます。増分ということなので、ベースの全体バックアップが存在していて、そこから変更の有ったデータ・ブロックだけ（増分）をバックアップしていくことを増分バックアップと呼びます。この前者がレベル0バックアップ、後者がレベル1バックアップと呼びます。
そして、この増分バックアップの方法として、差分増分バックアップと累積増分バックアップの2種類が存在します。前述の説明の通り、レベル0はどちらの増分バックアップでも親（ベース）となるバックアップですが、レベル１の違いを理解することが各増分バックアップの違いを理解する近道です
・差分増分バックアップのレベル1バックアップとは、 レベル1またはレベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。
・累積増分バックアップのreberu1バックアップとは、 レベル0の最新の増分バックアップ以降に変更されたすべてのブロックをバックアップします。
さらに、この増分バックアップで作成したレベル0バックアップ（イメージ・コピー・バックアップ=データファイルそのままのコピー）にレベル1バックアップ（増分部分のデータ・ブロックだけの集合なので、データファイルそのままのコピーではない=バックアップ・セット形式）を適用して、レベル0バックアップを最新化していくことを増分更新バックアップと呼びます。
各単語の違いを理解するのは難しいですね。と言うことで、コマンドと合わせてもう少し理解を進めてみましょう。
「イメージ・コピー・バックアップ」を作成するのであれば、もっとシンプルな構文（BACKUP AS COPY DATABASE ;）で実現できますが、増分バックアップのベースとなるレベル0バックアップを作成する場合には、INCREMENTAL LEVEL0句を付ける必要があります。さらに、増分更新バックアップの為には、FOR RECOVER COPY OF句を付ける必要があります。
ちなみに、演習問題では「レベル0」とも宣言していますが上記の私の解答例では「INCREMENTAL LEVEL 1」としています。これは誤りでは無く、これでも正解です。このコマンドを実行したタイミングでレベル0のイメージ・コピー・バックアップが存在しない場合、自動的にレベル0のイメージ・コピー・バックアップの作成になることを覚えておいてください。データベースを運用する上でバックアップ処理は、恐らくDBAが手動で実行するのではなく、定期的に自動実行されるようにジョブに組み込むことになるでしょう。そのような場合、状況に合わせてレベル0 or レベル1のどちらのコマンドを実行させるのかという判断ロジックをDBAが実装しなければならないと考えがちですが、RMANではレベル0もレベル1も同じコマンドで実行できるので、この判断ロジックの実装が不要になるというメリットがあるのですね。
さて、バックアップの実行結果の読み方を少しだけご紹介しておきますね。次はTBS21表領域のデータファイルのコピーを実行している部分を4行だけ抜き出して、左側に行番号を私が振ったものです。
1. チャネルORA_DISK_1: データファイルのコピーを開始しています
2. 入力データファイル・ファイル番号=00005 名前=+DATA/orcl/datafile/tbs21.257.824073659
3. 出力ファイル名=+FRA/orcl/datafile/tbs21.282.824073793 タグ=INCR_UPDATE レコードID=51 スタンプ
=824073808
4. チャネルORA_DISK_1: データファイルのコピーが終了しました。経過時間: 00:00:25
1行目：データファイルのコピーを開始すると宣言している
2行目：コピー元のデータファイル名は、「+DATA/orcl/datafile/tbs21.257.824073659」である
3行目：コピー先のバックアップ・ファイル名は、「+FRA/orcl/datafile/tbs21.282.824073793」である
4行目：データファイルのコピーが25秒で完了した
この演習3だけでも非常に多くの解説となってしまい申し訳ないのですが、「データファイルとバックアップのサイズ比較」と「レベル0バックアップ取得時のI/O量を確認」する2つのSQLをご紹介しておきます。
$ sqlplus /nolog
SQL> -- レベル0バックアップとデータファイルのサイズ比較
connect / as sysdba
set linesize 150 pages 5000
col DATAFILE_NAME for a48
col BKUPFILE_NAME for a48
select A.FILE#,
A.NAME as "DATAFILE_NAME", A.BYTES/1024/1024 as "DATAFILE_SIZE(MB)",
B.NAME as "BKUPFILE_NAME", B.OUTPUT_BYTES/1024/1024 as "BKUPFILE_SIZE(MB)"
from V$DATAFILE "A", V$BACKUP_COPY_DETAILS "B"
where A.FILE# = B.FILE#
order by 1 ;
FILE# DATAFILE_NAME DATAFILE_SIZE(MB) BKUPFILE_NAME BKUPFILE_SIZE(MB)
----- ------------------------------------------- ----------------- ------------------------------------------- -----------------
1 +DATA/orcl/datafile/system.258.820462945 1024 +FRA/orcl/datafile/system.269.824073717 1024.00781
2 +DATA/orcl/datafile/sysaux.259.820462945 1024 +FRA/orcl/datafile/sysaux.279.824073741 1024.00781
3 +DATA/orcl/datafile/undotbs1.267.820462947 1024 +FRA/orcl/datafile/undotbs1.291.824073767 1024.00781
4 +DATA/orcl/datafile/users.264.820462947 23.75 +FRA/orcl/datafile/users.276.824073817 23.7578125
5 +DATA/orcl/datafile/tbs21.257.824073659 1024 +FRA/orcl/datafile/tbs21.282.824073793 1024.00781
SQL> -- レベル0バックアップ取得時のI/O量を確認
set linesize 150 pages 5000
select FILETYPE_NAME, SMALL_READ_MEGABYTES, LARGE_READ_MEGABYTES, SMALL_WRITE_MEGABYTES, LARGE_WRITE_MEGABYTES
from V$IOSTAT_FUNCTION_DETAIL
where FUNCTION_NAME = 'RMAN' ;
FILETYPE_NAME SMALL_READ_MEGABYTES LARGE_READ_MEGABYTES SMALL_WRITE_MEGABYTES LARGE_WRITE_MEGABYTES
---------------------------- -------------------- -------------------- --------------------- ---------------------
Control File 10 19 2 9
Data File 0 4120 0 0
Other 0 0 0 0
Data File Copy 0 0 0 4120
Other 0 0 0 0
Other 0 0 0 10
データファイルの名前とサイズはでV$DATAFILEビュー、バックアップのファイル名とサイズはV$BACKUP_COPY_DATAILSビューで確認することができるので、それら2つのビューをFILE#カラムでジョインすれば簡単にサイズを比較することができます。小数点の差は気になるところですが、ほぼ同じサイズになっていることからレベル0バックアップはデータファイルをそのままコピーしていると理解して頂けるかと思います
また、これはV$IOSTAT_FUNCTION_DETAILビューを確認しても同じく理解できます。RMANがレベル0の為にデータファイルを読んだ量が4120MB（FILETYPE_NAME列がData Fileの行のLARGE_READ_MEGABYTES）であり、バックアップ・ファイルを書き出した量も4120MB（FILETYPE_NAME列がData File Copyの行のLARGE_WRITE_MEGABYTES）ですよ。このビューはRMAN以外でも使用できるので是非覚えておいてくださいね。
4. TAB21表内の150MB分(TBS21表領域の約15%)のブロックをUPDATE文にて更新してください。
$ sqlplus /nolog
SQL> -- UPDATE対象量の確認
connect TRY/TRY
select count(distinct(dbms_rowid.rowid_block_number(ROWID))) * 8 / 1024 as "UPDATED_MB"
from TAB21
where COL1 < 7 * 128 * 150 ;
UPDATED_MB
----------
150
SQL> -- 150MB分を更新
update TAB21 set COL2='updated' where COL1 < 7 * 128 * 150 ;
commit ;
次の演習5において差分増分バックアップでレベル1バックアップを作成するので、TAB21表のレコードをUPDATEすることでバックアップ対象のデータ・ブロックを作ることが目的です。演習2において表を作成する際に、レコード数を指定して表のサイズを制御した考え方を用いれば、ここで何行のレコードを更新すれば150MB分のデータ・ブロックをUPDATEできるのかは難しくはないと思います。
5. RMANを使用して、全てデータファイルのレベル0の差分増分バックアップを取得して下さい。 ただし、RMANのI/O量を確認し易くする為にV$IOSTAT_FUNCTION_DETAILを初期化する目的で、データベースを再起動してからバックアップを開始してください。
$ rman target /
RMAN> -- ターゲット・データベースの再起動(あくまで検証の為。本来の運用では不要)
shutdown immediate ;
startup ;
RMAN> -- レベル1の差分増分バックアップ実行
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'incr_update'
DATABASE ;
backupが開始されました(開始時間: 13-08-21)
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=38 デバイス・タイプ=DISK
チャネルORA_DISK_1: 増分レベル1のデータファイル・バックアップ・セットを開始しています
チャネルORA_DISK_1: バックアップ・セットにデータファイルを指定しています
入力データファイル・ファイル番号=00001 名前=+DATA/orcl/datafile/system.258.820462945
入力データファイル・ファイル番号=00002 名前=+DATA/orcl/datafile/sysaux.259.820462945
入力データファイル・ファイル番号=00003 名前=+DATA/orcl/datafile/undotbs1.267.820462947
入力データファイル・ファイル番号=00005 名前=+DATA/orcl/datafile/tbs21.257.824073659
入力データファイル・ファイル番号=00004 名前=+DATA/orcl/datafile/users.264.820462947
チャネルORA_DISK_1: ピース1(13-08-21)を起動します
チャネルORA_DISK_1: ピース1(13-08-21)が完了しました
ピース・ハンドル=+FRA/orcl/backupset/2013_08_21/nnndn1_incr_update_0.288.824074119 タグ
=INCR_UPDATE コメント=NONE
チャネルORA_DISK_1: バックアップ・セットが完了しました。経過時間: 00:00:46
backupが完了しました(完了時間: 13-08-21)
Control File and SPFILE Autobackupが開始されました(開始時間: 13-08-21)
ピース・ハンドル=+FRA/orcl/autobackup/2013_08_21/s_824074164.281.824074165 コメント=NONE
Control File and SPFILE Autobackupが完了しました(完了時間: 13-08-21)
RMAN>
いよいよ今回の演習の本丸である、差分増分バックアップですね。とは言え、意外にもあっさり実行できたのではないでしょうか？演習3の解説（長過ぎてポイントしづらいですが）で、「RMANではレベル0もレベル1も同じコマンドで実行できる」と説明させて頂いた通り、上記の解答例でのレベル1バックアップの実行コマンドは、演習3でのレベル0バックアップの実行コマンドと完全に同じですよね。
ちなみに、累積増分バックアップのレベル1バックアップを取得したい場合には、「INCREMENTAL LEVEL 1」の後ろにCUMULATIVE句を付けるだけ良いです。
さて、実行結果としては出力が変化していますね。入力データファイルはきちんと5つのデータファイルが対象となっていますが、データファイル毎にバックアップ・ファイルが作成されているようには読めません。これはレベル1バックアップ=レベル0のバックアップ取得以降に変更されたデータ・ブロックだけをバックアップした増分なので、データファイルそのままのイメージ・コピー形式ではなくバックアップ・セット形式で保存されています。何となく、この2つの形式の違いについては分かってきた感じですよね。
と言う事は、このレベル1バックアップのサイズは、小さくなっていなければいけないと思いませんか？を確認してみたいと思います。
$ sqlplus /nolog
SQL> -- データファイルとレベル1のバックアップのサイズを比較
connect / as sysdba
select FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS, BLOCKS / DATAFILE_BLOCKS
from V$BACKUP_DATAFILE
where INCREMENTAL_LEVEL > 0
and BLOCKS / DATAFILE_BLOCKS > .1
ORDER BY FILE#;
FILE# INCREMENTAL_LEVEL COMPLETI BLOCKS DATAFILE_BLOCKS BLOCKS/DATAFILE_BLOCKS
---------- ----------------- -------- ---------- --------------- ----------------------
3 1 13-08-21 31295 131072 .238761902
5 1 13-08-21 19203 131072 .146507263
SQL> -- レベル1バックアップ取得時のI/O量を確認
set linesize 150 pages 5000
select FILETYPE_NAME, SMALL_READ_MEGABYTES, LARGE_READ_MEGABYTES, SMALL_WRITE_MEGABYTES, LARGE_WRITE_MEGABYTES
from V$IOSTAT_FUNCTION_DETAIL
where FUNCTION_NAME = 'RMAN' ;
FILETYPE_NAME SMALL_READ_MEGABYTES LARGE_READ_MEGABYTES SMALL_WRITE_MEGABYTES LARGE_WRITE_MEGABYTES
---------------------------- -------------------- -------------------- --------------------- ---------------------
Control File 5 19 2 9
Data File 0 4120 0 0
Other 0 0 0 0
Data File Incremental Backup 0 0 0 395
Other 0 0 0 0
Other 0 0 0 10
まず、V$BACKUP_DATAFILEビューを参照してデータファイルとレベル1バックアップのサイズを比較してみましょう。如何でしょうか？150MB分更新したTAB21表が格納されているTBS21表領域（FILE#=5）のレベル1バックアップのブロック数は「19,293 」ですが、そのレベル1バックアップを作成した際に読み込んだデータファイルのブロック数は「131,072」となっています。その比率は約14.6%となっており、演習4で更新したTBS21表領域のサイズ1GB上のTAB21表を150MB分更新した比率（約15%=150MB/1024MB）とほぼ一致するかと思います。凄いですね。本当に変更されたデータ・ブロックのみをバックアップしていると言い切れそうです。
また、RMANがこのレベル1バックアップを作成する為に読み書きしたI/O量をV$IOSTATA_FUNCTION_DETAILビューで確認する限り、データファイルの読み込みは4120MBに対し、バックアップとしての書き出し（DATA File Incremental Backupの行）は395MBとなっていますね。レベル0バックアップを作成する際は読み込み量と書き出し量は同じ4120MBでしたから、ここからもレベル1バックアップのサイズが必要最低限のサイズであることが理解できます。
それでは最後の演習6として、レベル0バックアップに、レベル1バックアップを適用する増分更新の処理を実施してみましょう。
6. レベル1のバックアップ取得時のイメージ・コピー・バックアップを作成(レベル0のイメージ・コピー・バックアップをレベル1の増分が作成された時点にロールフォワード)してください。
$ rman target /
RMAN> LIST DATAFILECOPY ALL ;
データファイル・コピーのリスト
=======================
Key File S 終了時間 Ckp SCN Ckp時間
------- ---- - -------- ---------- --------
48 1 A 13-08-21 14782610 13-08-21
名前: +FRA/orcl/datafile/system.269.824073717
タグ: INCR_UPDATE
49 2 A 13-08-21 14782626 13-08-21
名前: +FRA/orcl/datafile/sysaux.279.824073741
タグ: INCR_UPDATE
50 3 A 13-08-21 14782638 13-08-21
名前: +FRA/orcl/datafile/undotbs1.291.824073767
タグ: INCR_UPDATE
52 4 A 13-08-21 14782663 13-08-21
名前: +FRA/orcl/datafile/users.276.824073817
タグ: INCR_UPDATE
51 5 A 13-08-21 14782654 13-08-21
名前: +FRA/orcl/datafile/tbs21.282.824073793
タグ: INCR_UPDATE
RMAN> LIST BACKUP OF DATABASE ;
バックアップ・セットのリスト
===================
BS Key Type LV Size Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
67 Incr 1 395.25M DISK 00:00:40 13-08-21
BPキー: 67 ステータス: AVAILABLE 圧縮: NO タグ: INCR_UPDATE
ピース名: +FRA/orcl/backupset/2013_08_21/nnndn1_incr_update_0.288.824074119
バックアップ・セット67のデータファイルのリスト
File LV Type Ckp SCN Ckp時間 Name
---- -- ---- ---------- -------- ----
1 1 Incr 14825979 13-08-21 +DATA/orcl/datafile/system.258.820462945
2 1 Incr 14825979 13-08-21 +DATA/orcl/datafile/sysaux.259.820462945
3 1 Incr 14825979 13-08-21 +DATA/orcl/datafile/undotbs1.267.820462947
4 1 Incr 14825979 13-08-21 +DATA/orcl/datafile/users.264.820462947
5 1 Incr 14825979 13-08-21 +DATA/orcl/datafile/tbs21.257.824073659
まずは、増分更新を行う(レベル0のイメージ・コピー・バックアップをレベル1の増分が作成された時点にロールフォワード)前に、各バックアップのSCN（システム変更番号）を確認しておきましょう。簡単に行ってしまえば、SCNはデータベースでコミット処理が行われることでカウントアップしていくものなので、値が小さい方が古い、値が大きい方が新しいバックアップであることが理解できます。
ちなみに、RMANの「LIST DATAFILECOPY ALL;」コマンドでレベル0のイメージ・コピー・バックアップのSCNを確認すると、5つ全部覚えてられないのでTBS21表領域のデータファイルに限定すると「14782654 」となっていて、「LIST BACKUP OF DATABASE;」コマンドでレベル1のバックアップ・セットのSCNを確認すると「14825979」となっています。よって、これから行う増分更新処理により、レベル0のイメージ・コピー・バックアップのSCNがレベル1のバックアップ・セットのSCNに変化すれば、検証成功ということになることが予想できたかと思います。
$ rman target /
RMAN> -- 増分更新処理の実行
RECOVER COPY OF DATABASE WITH TAG 'incr_update';
recoverが開始されました(開始時間: 13-08-21)
チャネル: ORA_DISK_1が割り当てられました
チャネルORA_DISK_1: SID=37 デバイス・タイプ=DISK
チャネルORA_DISK_1: 増分データファイル・バックアップ・セットのリストアを開始しています
チャネルORA_DISK_1: リカバリするデータファイル・コピーを指定しています
リカバリしているデータファイル・コピーのファイル番号=00001 名前=+FRA/orcl/datafile/system.269.824073717
リカバリしているデータファイル・コピーのファイル番号=00002 名前=+FRA/orcl/datafile/sysaux.279.824073741
リカバリしているデータファイル・コピーのファイル番号=00003 名前
=+FRA/orcl/datafile/undotbs1.291.824073767
リカバリしているデータファイル・コピーのファイル番号=00004 名前=+FRA/orcl/datafile/users.276.824073817
リカバリしているデータファイル・コピーのファイル番号=00005 名前=+FRA/orcl/datafile/tbs21.282.824073793
チャネルORA_DISK_1: バックアップ・ピース
+FRA/orcl/backupset/2013_08_21/nnndn1_incr_update_0.288.824074119から読取り中です
チャネルORA_DISK_1: ピース・ハンドル
=+FRA/orcl/backupset/2013_08_21/nnndn1_incr_update_0.288.824074119 タグ=INCR_UPDATE
チャネルORA_DISK_1: バックアップ・ピース1がリストアされました
チャネルORA_DISK_1: リストアが完了しました。経過時間: 00:00:07
recoverが完了しました(完了時間: 13-08-21)
Control File and SPFILE Autobackupが開始されました(開始時間: 13-08-21)
ピース・ハンドル=+FRA/orcl/autobackup/2013_08_21/s_824074426.259.824074427 コメント=NONE
Control File and SPFILE Autobackupが完了しました(完了時間: 13-08-21)
RMAN>
はい、RECOVER COPY OF DATABASEコマンドを実行することで、増分更新の処理を行っています。上記の解答例での出力結果を読む限り、「リカバリするデータファイル・コピー（増分更新する先）」として、レベル0のイメージ・コピー・バックアップの5つのデータファイルが指定されていることが理解できます。また、「リストアするバックアップ・ピース（増分更新する元）」として、レベル1のバックアップ・セットが読み込まれていることも理解できます。そして、この増分更新処理は7秒で完了しています。レベル0のバックアップでは5つのデータファイルで合計104秒（演習3を参照）要していたことと比較すると、非常に効率的に処理を行っているような感覚を覚えますよね。
$ sqlplus /nolog
SQL> -- 増分更新時のI/O量を確認
connect / as sysdba
set linesize 150 pages 5000
select FILETYPE_NAME, SMALL_READ_MEGABYTES, LARGE_READ_MEGABYTES, SMALL_WRITE_MEGABYTES, LARGE_WRITE_MEGABYTES
from V$IOSTAT_FUNCTION_DETAIL
where FUNCTION_NAME = 'RMAN' ;
FILETYPE_NAME SMALL_READ_MEGABYTES LARGE_READ_MEGABYTES SMALL_WRITE_MEGABYTES LARGE_WRITE_MEGABYTES
---------------------------- -------------------- -------------------- --------------------- ---------------------
Control File 8 20 2 9
Other 0 0 0 0
Data File Backup 0 395 0 0
Data File Copy 0 0 2 393
Other 0 0 0 0
Other 0 0 0 10
V$IOSTATA_FUNCTION_DETAILビューを参照する限り、読み込みと書き出しのI/O量は395MBで同じであることが確認できます。（読み込みはData File Backup行のLARGE_READ_MEGABYTES列、書き出しはData File Copy行のSMALL_WRITE_MEGABYTES + LARGE_WRITE_MEGABYTES）さらに、この395MBと言うのは、演習5で取得したレベル1の差分増分バックアップのサイズと完全に一致します。
これらの事実より、この演習6で実行した増分更新の処理は、レベル1の差分増分バックアップを読み込んで、（レベル0のイメージ・コピー・バックアップは読み込まずに）レベル0のイメージ・コピー・バックアップへ直接書き出していることが理解できますね。
RMAN> LIST DATAFILECOPY ALL ;
データファイル・コピーのリスト
=======================
Key File S 終了時間 Ckp SCN Ckp時間
------- ---- - -------- ---------- --------
54 1 A 13-08-21 14825979 13-08-21
名前: +FRA/orcl/datafile/system.269.824073717
タグ: INCR_UPDATE
55 2 A 13-08-21 14825979 13-08-21
名前: +FRA/orcl/datafile/sysaux.279.824073741
タグ: INCR_UPDATE
56 3 A 13-08-21 14825979 13-08-21
名前: +FRA/orcl/datafile/undotbs1.291.824073767
タグ: INCR_UPDATE
53 4 A 13-08-21 14825979 13-08-21
名前: +FRA/orcl/datafile/users.276.824073817
タグ: INCR_UPDATE
57 5 A 13-08-21 14825979 13-08-21
名前: +FRA/orcl/datafile/tbs21.282.824073793
タグ: INCR_UPDATE
最後になりましたが、上記の出力結果より、増分更新の処理によって、想定通りにレベル0のイメージ・コピー・バックアップのSCNがレベル1のバックアップのSCNまでロールフォワードされていることが確認できますね。RMAN、お見事です。
さて、いかがでしたでしょうか？
少々長い解説となってしまいましたが、RMANの増分バックアップについての理解を深めて頂けたかと思います。今回は基礎編ということで、まだRMANの魅力をご紹介し切ることはできておりませんが次回以降も頑張っていきたいと思います。もっと早くRMANの魅力を知りたいという方は、本ページの先頭にある「Oracle DBA & Developer Day 2012」の私のプレゼン資料をご参照頂ければ幸いです。
ちなみに、今回の演習ではレベル1の増分バックアップは、レベル0のバックアップ以降に変更のあったデータ・ブロックだけをバックアップするという必要最低限のサイズになる部分をフォーカスさせて頂きましたが、次回はこのレベル1バックアップを作成する際に、H/Wリソースの消費量を低減し、より高速化に寄与するブロック・チェンジ・トラッキングというブロックの変更履歴を管理する機能を体験して頂く予定です。次回もよろしくお願い致します。