皆さん、こんにちは、今年ももう3月ですね。今度は花粉が飛び始めているようですので気をつけましょう。私は今のところ花粉症ではないようです（自分ではそうだと思っているだけかもしれませんが）。
今回は、前回のバッチ処理に続いてバックアップ（特にバックアップ時間短縮）について説明しようと思います。バックアップは、いざというために行う必要があることは皆さんも分かっていると思いますが、限られた運用時間の中で行うのはなかなか難しいと思います。皆さんの中でも悩まれている方も多いのではないかと思いますので、参考にして下さい。
■1. バックアップとは
まずは、バックアップについて簡単に説明しましょう。
これは、データ量が多くなってきた現在では大変な作業になりますが、行わない訳にはいかない作業です。いざデータが壊れた場合にはデータを復旧できなくなってっしまいますので、何かしらの方法で行う必要があります。
バックアップは、どのように復旧する必要があるか（復旧したいか）から検討する必要があります。まずは、復旧に掛けられる時間などから検討すると良いと思います。そうしないと使用できないバックアップになってしまいますので注意して下さい。例えば、テーブル単位に復旧したいのか、データファイル単位に復旧したいのか、データベース全体でよいのかです。基本はデータファイル単位に復旧すると思いますが、テーブル単位やパーティション単位に復旧したい場合は、表領域にテーブルを一つしか格納しないようにするなど設計段階での対処をしておく必要があります（例えば、バッチ処理などが途中でエラーが発生し完了できなかった場合は、テーブル単位にバッチ処理前に戻して再実行したいなどがあると思います）。それから、リカバリの方法（この障害のときはこのように復旧するなど）も事前にテストしておかないと、問題が発生した場合に「操作を誤ってデータを壊してしまう」、「復旧に思った以上に時間が掛ってしまう」などになってしまうので忘れずに行っておきましょう。できれば手順書などを作成しておくと良いと思います。
（1）バックアップの分類
バックアップには様々なものがありますので、ここで整理しようと思います。
バックアップを分類すると以下に示すようになります。それぞれに特長がありますので、使い分けると良いと思います。
- 論理バックアップ／物理バックアップ
- オンライン・バックアップ／オフライン・バックアップ
- 全体バックアップ／増分バックアップ
論理バックアップは、データだけ（export/importのテーブル単位など）を取得するため、ファイル構成が異なっている環境にもリストアできます（そのため、システムを別サーバー環境に移行するときなどにも使用します）。それに対して物理バックアップは、OSコマンドなどでファイル単位に取得するため、同一構成でないとリストアできないことになります。
物理バックアップには、オンライン・バックアップとオフライン・バックアップがあります（これはホット・バックアップ／コールド・バックアップとも言います）。一般的に、オンライン・バックアップは最新の状態までリカバリできますが、オフライン・バックアップはシステムを止めて取得するため取得した時点までしかリカバリできません（アーカイブログ・モードであれば最新の状態 までリカバリは可能です）。また、オンライン・バックアップには、OSコマンド（またはストレージ機能）による方法とRMAN(Recovery Manager)によるものがあります。
OSコマンドとRMANによるバックアップの違いについて
OSコマンドによるオンライン・バックアップは、データファイルをオンライン・バックアップ・モードに設定して（Being BackupからEnd backupの間）、OSコマンドで行います（このオンライン・バックアップ・モードは表領域単位とデータベース単位で指定できます）。OSコマンドがOracleのブロック・サイズを知らないため、コマンド実行中にブロックへの書込みを保護することができません。そのため、REDOログにブロック・イメージを出力して、ブロック不整合を修正できるようにしています。
それに対して Oracle データベースのツールである RMANは、Oracleのブロック・サイズを知っているので、直接書込みを保護することができます。そのため、REDOログへの無駄なブロック・イメージの出力が必要ないため、効率が良いというメリットがあります。
それから、RMANにはブロック単位にリカバリする機能もあります（ブロック・メディア・リカバリ）。これにより、ブロック破損でデータファイルをリストアする必要がありませんので、短時間で復旧することができます。このようなRMANを使用することでのメリットが多いことを知らない方も多いと思います。
そして、物理バックアップには、以下の図のように全体バックアップだけで行うか、全体バックアップと増分バックアップで行うかの方法が有ります。当然、増分バックアップの方がサイズが小さくなる（差分になる）ので短時間です。ただし、リカバリするときは、全体バックアップをリストア後に増分バックアップもリストアする必要があるため時間が掛ります。これを上手く使用して1回のバックアップ時間を短縮するのがベストだと思います。例えば、以下の図のように全体バックアップは週1回の日曜日に取得して、月曜日から土曜日はその増分バックアップを取得する。1日内の変更はアーカイブREDOログを使用して行うなどです。
（2）バックアップ対象ファイル
Oracleデータベースをバックアップするためには、以下の手順で必要なファイルをバックアップする必要があります（ここでは説明し易いようにOSコマンドでオンライン・バックアップする手順の例を使用して、どのようなファイルをバックアップする必要があるか説明します）。
-
アーカイブログ・モードで運用されているか確認します（アーカイブログ・モードでない場合はオンライン・バックアップを行うことはできませんので注意して下さい）。
SQL> archive log list ; データベース・ログ・モード アーカイブ・モード 自動アーカイブ 使用可能 ...
-
データ・ファイルをバックアップします（データベース単位に行っています）。
SQL> ALTER DATABASE Begin Backup ; OSコマンドなどでデータファイルをコピー SQL> ALTER DATABASE End Backup ;
-
アーカイブREDOログ・ファイルをバックアップします（リカバリに必要なオンラインREDOもアーカイブしています）。
SQL> ALTER SYSTEM archive log current ; アーカイブREDOログファイルをバックアップする
-
制御ファイルをバックアップします（制御ファイルがすべて壊れた場合に、CREATE CONTROLFILE文を手動で作成する必要があり大変ですので、事前にバックアップしておくことをお奨めします）。トレースファイルはDIAGNOSTIC_DEST初期化パラメータで指定したディレクトリに作成されます。
SQL> ALTER DATABASE backup controlfile to '<パス名>' ; -- バイナリファイル SQL> ALTER DATABASE backup controlfile to trace ; -- トレースファイル
-
その他に初期化パラメータ・ファイル（サーバーパラメータ・ファイル）などをバックアップします。 RMAN（Oracle9i以降）を使用して以下のように制御ファイルの自動バックアップ機能をONにすると、BACKUPコマンド発行時に制御ファイルとサーバーパラメータ・ファイルが自動的にバックアップされます（RMANの単純なバックアップは以下のコマンドだけになります）。
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON ; RMAN> BACKUP DATABASE PLUS ARCHIVELOG ;
■2. バックアップのチューニングについて
次に、バックアップのチューニング（時間短縮）について説明します。
バックアップはデータ量が多くなると時間が長くなります。そのため、できるだけ短時間で行うように、以下のような機能を上手く使用してバックアップ時間を短縮するように検討すると良いと思います。
- ディスク性能のアップ
- 並列化
- 読み取り専用表領域
- 増分バックアップ（高速増分バックアップ）
- 圧縮
それでは、それぞれについて説明していきます。
（1）ディスク性能のアップ
バックアップは、データベースが格納されているディスク装置とバックアップの格納先（テープ装置など）の性能に影響します。そのため、ディスク性能のアップによってバックアップ時間を短縮するのが最も簡単ですので、コスト的に可能であれば性能アップを行った方が良いと思います（第12回で説明したASMを使用することでも性能は向上します）。また、格納先もテープ装置より高速なディスク装置に取得することで時間が短縮されます（このためにOracle Database 10gからフラッシュ・リカバリ領域があります。Oracle Database 11g R2より高速リカバリ領域に名前が変更されました）。その後に速度が遅いテープなどに取得します。この時に、共有ディスク（SAN、NAS）を使用して別マシンでバックアップするなどすると更に効果が大きくなります。最近は、ディスク装置のコストがテープなどと大差なくなってきているため、性能が良いディスク装置を有効活用することで、バックアップ時間を短縮することができます。
高速リカバリ領域は、データファイルのコピー、アーカイブREDO、フラッシュバック・ログ（フラッシュバック・データベースに使用します）などを生成します。このフラッシュバックを上手く使用することで、バックアップを単純化することができると思います（誤った操作のため、又はバッチ処理の失敗のために、テーブル単位にリカバリするバックアップが不要になるなどです）。これにより、性能や運用に影響すると思いますので検討してみて下さい。
フラッシュバックについて
フラッシュバック機能には幾つかありますが、主に復旧のために使用するのがフラッシュバック・データベースとフラッシュバック・テーブルとフラッシュバック・ドロップになります。
バックアップからのリストアやPoint-in-Timeリカバリ（目的の時点まで復旧すること）を利用することなく、データベース全体を過去のある時点まで早急にリカバリする事ができる機能がフラッシュバック・データベースです。また、データベースレベルに加え、テーブル全体をフラッシュバックすることも可能です。これがフラッシュバック・テーブルです。同様に、ユーザーにより不用意に削除された表オブジェクト群をリカバリすることも可能になります。これがフラッシュバック・ドロップです。
つまり、ディスク装置の物理的な障害によるメディア・リカバリ以外（論理オペレーション・ミスなどの場合）は使用することができます。
ストレージ装置の高速バックアップ機能（スプリット・ミラーなどにより、ミラーリングしているデータを切り離すことでレプリカを作成する機能です。これによりバックアップを瞬時に行うことができる機能です）を使用することで、バックアップ時間を短縮します。これは多少高価になりますが、コスト的に可能であれば検討されたら良いと思います。ASMを使用時にはストレージ機能によるバックアップは、ASMのディスク・グループ単位に行う必要があります（複数のディスクの完了を待つアトミックにスプリットする機能が必要になります）ので注意して下さい。
（2）並列化
並列化は、データ量が多い場合に高速化するための一般的な手法ですので、ほとんどの場合に有効だと思います。これは、H/Wリソース（CPU、メモリ、ストレージ装置など）に余裕がある場合には、バックアップ時間を短縮することができます。RMANには並列化を行う方法として以下のものがあります。
- チャネル数による並列化
- セクション・サイズによる並列化
RMANチャネルを複数割り当ててパラレルに実行します。以下のRMANコマンドのように事前にデバイス・タイプ’disk’にチャネル数を割り当てます。これでバックアップ時に指定したチャネル数で並列に行うことができます（デフォルトのデバイス・タイプを設定しているので、バックアップ時にデバイス・タイプを指定しないと使用されます）。
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO disk ; RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 2 ;
Oracle Database 11g R1から大きなデータファイルのバックアップを取得する場合に、そのファイルを複数セクションに自動分割して行うことができます。ファイル単位ではなく、このセクション単位でバックアップを並列に行うことができます（第12回で説明したBIGFILEタイプ表領域を使用しているときにはデータファイル・サイズが大きくなってしまいますので有効だと思います）。例えば、表領域’user_ts’が20Gバイトだとすると、以下のRMANコマンドで2つのセクションに分割されて10Gバイト単位にバックアップされます。
RMAN> BACKUP SECTION SIZE 10G TABLESPACE user_ts ;
RMANを使用しない場合は、手動でデータファイルのコピーなどをパラレルに行うことで可能です。
（3）読み取り専用表領域
読取り専用表領域は、更新されることがないので一度バックアップした後はする必要がありません。そのため、変更が行われないテーブル（又はパーティション）などは読み取り専用表領域に移動することで、一度バックアップした後はバックアップをスキップすることが可能ですので、バックアップ時間を短縮することができます。変更が行われないテーブルなどが存在する場合は読み取り専用表領域を作成することを検討してみて下さい。以下のRMANコマンドを実行することでスキップされるようになります（RMANを使用しない場合は、手動でバックアップ対象から外すことで同じことは行えます）。
RMAN> BACKUP DATABASE SKIP READONLY SKIP OFFLINE ;
（4）増分バックアップ（高速増分バックアップ）
すべて（全体バックアップ）を毎日取得するのではなく、ある単位で取得する（差分だけを行う増分バックアップを行う）ことで、対象データを少なくします（例えば、曜日毎に取得するテーブルを変える。全体バックアップは週一回にするなどです）。RMANを使用した増分バックアップには、差分増分バックアップ（直近の同一レベルのバックアップに対して差分だけを取得）と累積増分バック（直近の同一レベルの差分取得はせずに、低いレベルのバックアップに対して差分を取得）があります。Oracle9iまでは、データ変更を読込みながら確認する必要があったため、すべてのデータにアクセスする必要がありましたが、Oracle Database 10gからは以下の図のようなブロック・チェンジ・トラッキング・ファイルによって更新部分のみの読込みだけで可能になり、更にバックアップ時間を短縮できるようになっています（高速増分バックアップ）。ブロック・チェンジ・トラッキングを有効にするには以下のSQL文のように行います。
SQL> ALTER DATABASE enable block change tracking using file '<パス名>' ;
それから、Oracle Database 10gからは、通常の（ブロック・チェンジ・トラッキングを使用しない）増分バックアップがEnterprise Edition以外でも使用できるようになりましたので、知っておくと便利かと思います。
Oracle Database 10gからの増分更新バックアップを上手く使用すると増分バックアップ数を減らすことができます（全体バックアップに増分バックアップをロールフォワードすることで、再度全体バックアップを取得しなくても最新の全体バックアップにすることができます）ので、リカバリ時間も短縮することができるようになります。以下のRMANコマンドを行うことで増分更新バックアップを作成できます。
RMAN> RECOVER COPY OF DATABASE WITH TAG 'incr_update' ; RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE ;
- 最初のコマンドで全体バックアップ（タグ’incr_update’に含まれているデータファイルのコピーのセット）にレベル1の増分バックアップを適用します（1回目の実行では何もないので、2回目の実行では全体バックアップがないので、それぞれ何も行われません）。
- 2番目のコマンドでタグ’incr_update’のレベル1の増分バックアップが作成されます（1回目の実行では全体バックアップが作成されます)。
（5）圧縮
バックアップのデータ・サイズを少なくできない場合は、RMANの圧縮機能を使用して書込み量を少なくすると良いと思います（圧縮は読込みサイズは変わりませんが書込みのサイズを削減できます）。
RMANの圧縮機能にはいくつかあり、どれも圧縮することで書込みサイズを削減できるため、バックアップ時間を短縮することができます。以下のRMANコマンドで指定しますが、Oracle Database 11gR2から指定方法がレベル名に変更されましたので注意して下さい（Oracle Database 11g R1はアルゴリズム名でした）。
RMAN> CONFIGURE COMPRESSION ALGORITHM '<圧縮レベル>' ;
以下の圧縮レベルによってCPUオーバーヘッドと圧縮率が異なってきます。ただし、BASIC圧縮以外はAdvanced Compressionオプションが必要ですので注意して下さい。
- BASIC圧縮（圧縮率はMEDIUMと同等だが、CPUオーバーヘッドが高い）
- HIGH圧縮（最も圧縮率が高いが、CPUオーバーヘッドも高い）
- MEDIUM圧縮（高速で、CPUオーバーヘッドと圧縮率のバランスに優れている。Oracle Database 11g R1の高速圧縮バックアップ相当）
- LOW圧縮（最も高速で、最も低いCPUオーバーヘッド）
■3. その他について
最後に、バックアップでその他に考えておかなればいけないことについて少し説明しようと思います。
（1）バックアップを取得しないとデータが無くなる（リカバリできません）
あるSQL文を行うとバックアップを取得しておかないと復旧できないことを知っておく必要があります。それは、前回も説明したダイレクト・インサートです。これはREDOログを出力しませんので、ダイレクト・インサート後にバックアップを取得していないとアーカイブREDOログを使用しても復旧することができません。性能が良いということでダイレクト・インサートを多用するような場合は注意する必要がありますので、知っておいて下さい。
（2）バックアップでは復旧できなこともある
ブロック障害などはバックアップでは復旧できない場合があります。これはチェックサム機能（db_block_checksum, db_block_checking）によって参照するときにブロックが壊れているのを知るため（知らないうちに壊れているため）、いつ壊れたか判断できないからです（つまり、いつのバックアップのデータブロックが壊れていないか判断できないからです）。どのバックアップかが判断できたとしても、物理バックアップのリカバリはデータファイル単位になりますので、1ブロックを復旧するだけでも、対象のデータファイルをリストアしてリカバリする必要がありますので、非常に時間が掛ります。このために、以下のような機能がありますので知っておくと良いかと思います。
- ASMの自動修復（Oracle Database 11g R1から）
破損ブロックを検出するとASMのミラーを使用してブロックを自動修復します（ASMでミラー化していないと機能しません）。 - Active DataGuardの自動修復機能（Oracle Database 11g R2から）
破損ブロックを検出するとスタンバイDBから自動的にブロックを転送して修復します。 - RMANのValidateコマンドによる破損チェックと手動修復（Oracle9iから）
手動で定期的にRMANのブロック破損をチェックしてブロック・メディア・リカバリにより修復します。 - 破損データの書込み防止機能（Exadata）
これは、書込み時にExadata Storage Sarverでブロック破損をチェックしてエラーにします（障害ブロックは書込まれません）。
それぞれの詳細な説明については別の機会とさせていただきますが、このようなことを知っておくと何かの際には役に立つと思いますので、参考までに載せておきました。
■4. おわりに
今回はバックアップについてRMANをメインに説明しました。すべてを詳細に説明することはできませんでしたので、また機会があれば説明しようと思います。これからも頑張りますのでよろしくお願いします。
それでは、次回まで、ごきげんよう。