ユーザー管理のバックアップとリカバリ：独学！ ORACLE MASTER Gold 11g講座（10）（1/2 ページ）

ORACLE MASTER資格の上級に位置付けられる「ORACLE MASTER Gold Oracle Database 11g」。本連載では、Gold試験の頻出ポイントを解説する。確認問題付き。

[武見弘之，システム・テクノロジー・アイ]

　今回は、Recovery Manager（以後、RMAN）を使わないデータファイルのバックアップを紹介します。

データファイルバックアップとバックアップモード

　RMANを使わないデータファイルのバックアップは、OSやストレージシステムのコピー機能で実行します。そして、オンラインでデータファイルのバックアップを取得するためには、表領域をバックアップモードにする必要があります。まずは、このモードの必要性について解説します。

　オンライン中ということは、DBWRによりデータファイルに書き込みが発生しています。この書き込みは、いつ発生するか分かりません。果たして、書き込み最中のファイルをバックアップ、すなわちコピーしたら、そのコピーしたファイルはどのような状態になるでしょうか？

　OracleはDBブロック単位でI/Oを発生させます。そして、どんなに小さいデータでも、書き込みには瞬間的に時間が経過します。この書き込みの間、同じ個所を読み取るファイルコピーが発生したら、バックアップされたファイルには、整合性の取れないブロックが存在することになります。

　このような状態のブロックを「分裂ブロック」と呼びます。

　RMANでのバックアップには、分裂ブロックを検出する機構があり、分裂状態が解消されるまで、読み取りを繰り返します。

　ユーザー管理バックアップの場合は、分裂ブロック状態を検出できません。そこで、この分裂ブロック状態で獲得されたバックアップからでもリカバリできる、追加のREDOを生成することで対応します。この追加REDOを生成する状態が「バックアップモード」です。加えて、データファイルのヘッダ情報がロックされます。

　コマンドと、バックアップの手順は以下のとおりです。

1．表領域、もしくはデータファイルをバックアップモードにします

ALTER TABLESPACE 表領域名 BEGIN BACKUP;

2．OSで、その表領域のデータファイルをコピーコマンドによりバックアップします

3．表領域のバックアップモードを終了します

ALTER TABLESPACE 表領域名 END BACKUP;

バックアップモードは、データベース全体を対象とすることも可能です。

ALTER TABLESPACE DATABASE { BEGIN | END } BACKUP;

　ただし、追加のREDOはオーバーヘッドとなります。可能な限りこれを削減するため、データファイル単位、もしくは表領域単位でバックアップモードを切り替えることをお勧めします。

　なお、手動でバックアップするデータファイルを特定するには、動的パフォーマンスビューを確認します。

SQL> SELECT tablespace_name , file_name FROM dba_data_files;
TABLESPACE_NAME FILE_NAME
--------------- ---------------------------------------------------
USERS           /u01/app/oracle/oradata/orcl/users01.dbf
SYSAUX          /u01/app/oracle/oradata/orcl/sysaux01.dbf
UNDOTBS1        /u01/app/oracle/oradata/orcl/undotbs01.dbf
SYSTEM          /u01/app/oracle/oradata/orcl/system01.dbf
EXAMPLE         /u01/app/oracle/oradata/orcl/example01.dbf

ユーザー管理のデータファイルリカバリ

　続いて、リカバリ方法です。ユーザー管理のリカバリでも、完全リカバリと不完全リカバリがあり、その手順の概念は、RMANによるリカバリと全く同じです。第8回で紹介したイメージを再掲します。

• 完全リカバリ

• 不完全リカバリ

　RMAN利用時と違うのは、バックアップとアーカイブログの格納先管理を私たち自身が行う必要があるため、リストア＆リカバリ作業においてファイル名の指示が必要になるということです。

　バックアップのリストアはOSコマンドを使い、ログを適用するリカバリは、以下のコマンドです。

• データファイル単位のリカバリ

RECOVER [AUTOMATIC] [FROM 'ディレクトリ名'] DATABASE;

• 表領域単位のリカバリ

RECOVER [AUTOMATIC] [FROM 'ディレクトリ名'] TABLESPACE 表領域名;

• データファイル単位のリカバリ

RECOVER [AUTOMATIC] [FROM 'ディレクトリ名'] DATAFILE { ファイル番号 | 'ファイルパス'};

　AUTOMATIC句は、アーカイブログの取得ディレクトリを示したlog_archive_dest_n パラメータとアーカイブログのファイル名を指定するlog_archive_formatに、必要なアーカイブログが存在する場合、これらのファイルを自動的に適用してくれます。

　容量圧迫などの理由で、アーカイブログを別のディレクトリに移動した場合は、FROM句で、ディレクトリを指定します。

　AUTOMATIC句がない場合は、適用するアーカイブログについて、1つ1つOracleから問い掛けられます。

　では、全体の流れで確認しましょう。

SYSTEM／UNDO表領域以外のデータファイルが壊れた場合の完全リカバリ

1．該当する表領域をオフラインにします。

SQL> ALTER TABLESPACE 表領域名 OFFLINE IMMEDIATE;

2．修復対象のファイルを、復帰させたい位置にOSコピーで戻します。

3．復帰させたいファイル位置が、元のファイル位置と異なる場合、以下のコマンドを実行します。

SQL> ALTER TABLESPACE 表領域名 RENAME DATAFILE '元ファイル名' TO '新ファイル名';

4．RECOVERコマンドを実行します。

• （AUTOMATIC句を入れ、想定通りにアーカイブログが存在していた場合の出力例）

SQL> RECOVER AUTOMATIC TABLESPACE 表領域名;
メディア・リカバリが完了しました。

• （AUTOMATIC句を入れなかった場合）

SQL> recover tablespace users;
ORA-00279: 変更1078426(MM/DD/YYYY HH:MI:SSで生成)にはスレッド1が必要です
ORA-00289: 検討すべきログ・ファイル:/home/oracle/arch/1_36_750707953.dbf
ORA-00280: 変更1078426(スレッド1)は順序番号36に存在します。
ログの指定: {<RET>=suggested | filename | AUTO | CANCEL}
-- ファイル名など、指示を入力

　AUTOMATIC句を入れなかった場合は、適用すべきファイル名の入力をアーカイブログファイル単位で求められます。

　ORA-00289では、FROM句や関連パラメータに基づいて、適用する候補のファイルが表示されています。このファイル名でよい場合は、ファイル名を入力せず、Enterキーのみで、そのファイルが適用されます。

　ログの適用を中断するには、「CANCEL」と入力します。この場合、完全リカバリ作業が中断されたことになります。

　「AUTO」と入力すると、このアーカイブログ以降、候補のファイルが自動的に適用されます。

5．表領域をオンライン化します。

SQL> ALTER TABLESPACE 表領域名 ONLINE;

SYSTEM／UNDO表領域のデータファイルが壊れた場合の完全リカバリ

　SYSTEM/UNDO 表領域を構成するデータファイルが壊れた場合、インスタンスがダウンします。起動を試みると、マウント状態までしか進まないことが分かります。回復はマウント状態で行います。

1．データベースの起動を試みると、マウント状態になります（インスタンスがダウンしていない場合は SHUTDOWN ABORT の後 起動してください）。

SQL> STARTUP
ORACLEインスタンスが起動しました。
 
Total System Global Area  523108352 bytes
Fixed Size                  1314492 bytes
Variable Size             423625028 bytes
Database Buffers           92274688 bytes
Redo Buffers                5894144 bytes
データベースがマウントされました。
ORA-01157: データファイル1を識別/ロックできません - DBWRトレース・ファイルを参照してください
ORA-01110: データファイル1: '/u01/app/oracle/oradata/orcl/system01.dbf'

2．障害状況を確認します。起動時のメッセージでは1つのファイルが表示されていますが、2つ以上のファイルが壊れている可能性も考慮します。

SQL> SELECT r.file# , d.name AS file_name , t.name AS ts_name , r.error
  2  FROM   v$recover_file r , v$datafile d , v$tablespace t
  3  WHERE  r.file# = d.file#
  4   AND   d.ts# = t.ts#;
FILE# FILE_NAME                                  TS_NAME  ERROR
----- ------------------------------------------ -------- --------------
    1 /u01/app/oracle/oradata/orcl/system01.dbf  SYSTEM   FILE NOT FOUND
    3 /u01/app/oracle/oradata/orcl/undotbs01.dbf UNDOTBS1 FILE NOT FOUND

3．修復対象のファイルを、復帰させたい位置にOSコピーで戻します。

4．復帰させたいファイル位置が、元のファイル位置と異なる場合、以下のコマンドを実行します。マウント時は、前述のコマンドと異なりますので注意してください。

SQL> ALTER DATABASE RENAME FILE '元ファイル名' TO '新ファイル名';

5．RECOVERコマンドを発行します（前述のコマンドと同じです）。

6．データベースをオープンします。

SQL> ALTER DATABASE OPEN;