バックアップの所要時間を短縮するテクニック：Oracleバックアップ／リカバリ講座（9）（2/4 ページ）

[渡辺学，株式会社アゲハ]

増分バックアップの取得例

　ここからは具体的に増分バックアップを行うコマンドについて説明します。増分バックアップを行うには、まずベースとなるバックアップ（LEVEL 0）を取得する必要があります。リスト1がその例になります。

Configure channel device type disk   format='/opt/app/oracle/oraback/full_db_%U';　　←（1） backup as backupset incremental level 0 database   plus archivelog delete all input;　　　　　　　　 ←（2）

リスト1　増分バックアップで全体バックアップを取得するコマンド例 （1）DISKチャネル共通でバックアップファイルの保存先を設定（置換変数「%U」を指定すると、RMANによってユニークな値が指定される） （2）バックアップ・セットでターゲット・データベースの全体バックアップ、およびアーカイブREDOログファイルのバックアップを取得、その後バックアップ済みのアーカイブREDOログファイルを削除

　次に差分増分バックアップ（LEVEL 1）の取得方法を見てみましょう。

configure channel device type disk   format='/opt/app/oracle/oraback/inc_db_%U'; backup as backupset incremental level 1 database   plus archivelog delete all input;

リスト2　差分バックアップを差分増分バックアップで取得するコマンド例

　リスト2の差分増分バックアップコマンドに「cumulative」句を付けると累積増分バックアップになります。

configure channel device type disk   format='/opt/app/oracle/oraback/inc_db_%U'; backup as backupset incremental level 1 cumulative database   plus archivelog delete all input;

リスト3　差分バックアップを累積増分バックアップで取得するコマンド例

　また、差分増分と累積増分バックアップは組み合わせて使用することもできます。例えば、ベースとなるバックアップ（LEVEL 0）を月に1回のみとし、週末に累積増分バックアップ（LEVEL 1 cumulative）、平日は差分増分バックアップ（LEVEL 1）というバックアップ運用も可能です。

増分バックアップの高速化

　増分バックアップの最初で説明したように、増分バックアップは更新したブロックのみを書き込むため、バックアップファイルサイズは小さくなり、保存先のDISKやTAPEへの書き込み時間が短縮されます。しかし、更新したブロックを確認するためには、バックアップ対象のデータファイルをすべて読み込む必要があります。そのため、バックアップ対象ブロックを確認するI/O負荷や、その処理時間については効果的であるといえません。

　しかし、Oracle 10gからの新機能であるブロック・チェンジ・トラッキング機能を設定することで、この部分のパフォーマンスを改善できます。この機能では、データベースに対する更新が発生したときに、変更されたブロックの情報をブロック・チェンジ・トラッキングファイルに記録しておきます。そして、増分バックアップの実行時には、そのブロック・チェンジ・トラッキングファイル内の変更されたブロック情報を参照し、変更されたブロックのみにアクセスします（図5）。そのため、増分バックアップ時の変更ブロックを確認する時間が短縮され、結果的に大幅なバックアップ時間の短縮が可能となります。

図5　ブロック・チェンジ・トラッキング機能を利用した増分バックアップ
日曜日に全体バックアップ、平日に差分増分バックアップを行う例。

　ブロック・チェンジ・トラッキング機能を設定するには、DBA権限を持つ管理者で接続し、SQL*Plusを使用してリスト4のコマンドを実行します。

SQL> alter database enable block change tracking      using file '/opt/app/oracle/oradata/v102/block.ctf';

リスト4　ブロック・チェンジ・トラッキング機能を有効にする

　それでは実際に、ブロック・チェンジ・トラッキング機能の有無により、どれだけ処理時間が短縮されるかを確認してみましょう。今回は、ベースとなる全体バックアップとして、リスト1のコマンドを実行後、テーブルを1万行（約3500ブロック）更新し、その後、リスト2の差分増分バックアップをブロック・チェンジ・トラッキング機能が有効になっている場合と、そうでない場合で処理時間を比較したものが表1になります。

	バックアップ方法	処理時間
	全体バックアップ（LEVEL 0）	3分16秒
	差分バックアップ（LEVEL 1、ブロック・チェンジ・トラッキング機能なし）	2分6秒
	差分バックアップ（LEVEL 1、ブロック・チェンジ・トラッキング機能あり）	7秒
表1　ブロック・チェンジ・トラッキング機能の有無による処理時間の違い

　表1のとおり、ブロック・チェンジ・トラッキング機能を使用することにより、処理時間が改善されたことが分かります。ただし、実際のシステムでどれぐらい改善されるかについては、事前に検証して確認を行ってください。

　また、ブロック・チェンジ・トラッキングファイルを使用するうえで、以下のような注意点があります。

• ブロック・チェンジ・トラッキングを使用することにより、わずかながらではありますが、更新処理時にデータベース全体に対するオーバーヘッドが発生します。
  
  
• ブロック・チェンジ・トラッキングファイルのために別途領域が必要です。目安としての見積もりサイズはバックアップ対象全データ・ブロックの約3万分の1程度です。
  
  
• ブロック・チェンジ・トラッキングファイルは冗長化構成が取れませんので、OSやハードウェアレベルでRAIDなどを使用した冗長化が推奨されます。
  
  
• データベース自体には影響がありませんが、ブロック・チェンジ・トラッキングファイルが壊れた状態ではデータファイルのバックアップを取得するとエラーとなります。このため、一度リスト5にあるコマンドでブロック・チェンジ・トラッキング機能を無効にしてバックアップを取得するか、再作成を行う必要があります。

SQL> alter database disable block change tracking;

リスト5　ブロック・チェンジ・トラッキング機能を無効にする