8章 制御ファイルのリカバリ
本章では制御ファイルが破損した場合のリカバリについて確認していきます。
制御ファイルとは
本章では制御ファイルの障害時のリカバリについて学んでいきます。
制御ファイルはデータベースを構成するファイルでした。
制御ファイルはデータベースの物理構造情報を保持するファイルです。
制御ファイルは以下の情報を保持しています。
・データベース名
・データファイル、REDOログファイルの位置情報
・現在のログ順序番号
etc
また制御ファイルのパスは初期化パラメータのCONTROL_FILESで指定されています。
SQL> show parameter control_files
NAME TYPE VALUE
-------------------- ----------- ------------------------------
control_files string /u01/app/oracle/12101/oradata/
ORCL/control01.ctl, /u01/app/o
racle/12101/oradata/ORCL/contr
ol02.ctl, /u01/app/oracle/1210
1/oradata/ORCL/control03.ctl
制御ファイルは多重化が可能です。今回は3つの制御ファイルで多重化しています。
DB起動時はCONTROL_FILESから制御ファイルを読み込み、MOUNT状態となると
制御ファイルからデータファイル、REDOログのパスを確認し、OPEN状態になります。
制御ファイルは
1つでも破損するとデータベースは稼動できません。
ただしすべての制御ファイルが全損するとバックアップを使用してリカバリを実施するのに対し、1つのファイルだけの破損は既存ファイルのコピーで済む為復旧が簡単です。
全損の場合、データベースのりストア作業が必要となる為、リカバリに時間が掛かってしまいます。
その為、制御ファイルは多重化しておく必要があります。
制御ファイルリカバリ
それでは制御ファイルを削除し、復旧してみましょう。
制御ファイル一部破損時のリカバリ
制御ファイルの一部破損時のリカバリは簡単です。破損していない制御ファイルをコピーするだけです。
実際に制御ファイルの1つのファイルを削除して、障害を発生させてみます。
$ sqlplus / as sysdba
SQL> select name from v$controlfile;
NAME
--------------------------------------------------
/u01/app/oracle/12101/oradata/ORCL/control01.ctl
/u01/app/oracle/12101/oradata/ORCL/control02.ctl
/u01/app/oracle/12101/oradata/ORCL/control03.ctl
SQL> !rm /u01/app/oracle/12101/oradata/ORCL/control01.ctl
「v$controlfile」は動的パフォーマンスビューで制御ファイルのパスやステータスなどを確認できます。
rmコマンドで1つの制御ファイルを削除しました。DBを再起動してみましょう。
SQL> startup force
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2296576 bytes
Variable Size 746587392 bytes
Database Buffers 314572800 bytes
Redo Buffers 5480448 bytes
ORA-00205: error in identifying control file, check alert log for more info
SQL> select status from v$instance;
STATUS
------------
STARTED
「startup force」はshutdown abortとstartupを両方実施します。
現在は「STARTED」の状態となる為、NOMOUNT状態であることがわかります。
DB起動時にエラーとなりましたが、具体的にどのファイルが破損しているかは、
上記メッセージだけだと分かりません。
アラートログファイルも確認してみましょう。
SQL> !tail -15 /u01/app/oracle/12101/diag/rdbms/orcl/ORCL/trace/alert*.log
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/app/oracle/12101/oracle
Mon Aug 15 10:09:12 2016
ALTER DATABASE MOUNT
Mon Aug 15 10:09:12 2016
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/12101/oradata/ORCL/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-205 signalled during: ALTER DATABASE MOUNT...
Mon Aug 15 10:09:13 2016
Checker run found 1 new persistent data failures
Mon Aug 15 10:09:15 2016
Using default pga_aggregate_limit of 2048 MB
アラートログにはどのファイルが破損しているかが記載されています。
それではリカバリを実施していきます。
制御ファイルの一部破損時のリカバリ
①DBを停止(DBが起動中の場合)
②破損していない制御ファイルを破損したファイルにコピー
③DBを起動
それではリカバリを実施していきましょう。
$ cd /u01/app/oracle/12101/oradata/ORCL/
$ cp -p control02.ctl control01.ctl
$ sqlplus / as sysdba
SQL> startup
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2296576 bytes
Variable Size 746587392 bytes
Database Buffers 314572800 bytes
Redo Buffers 5480448 bytes
Database mounted.
Database opened.
これだけで復旧は完了です。制御ファイルを多重化しておくことで、
復旧作業が簡単であることが分かりますね。
制御ファイルが全損した場合、DBのリストア作業が必要です。
1部破損時の復旧作業と比較し、作業量も時間も格段と多くなります。
制御ファイルの全損時のリカバリ
①DBを停止(DBが起動中の場合)
②データベースのリストア
③アーカイブログ&REDOログのロールフォワード
③DBを起動
制御ファイルの全損時はデータベースの全体をリストアし、リカバリを実施していきます。
では実際に試して行きましょう。
$ rm control01.ctl control02.ctl control03.ctl
$ sqlplus / as sysdba
SQL> startup
ORACLE instance started.
Total System Global Area 1068937216 bytes
Fixed Size 2296576 bytes
Variable Size 746587392 bytes
Database Buffers 314572800 bytes
Redo Buffers 5480448 bytes
ORA-00205: error in identifying control file, check alert log for more info
$ rman target /
RMAN> restore controlfile from '/u01/app/oracle/backup/ORCL/XXXX.autobkup';
Starting restore at 15-AUG-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=6 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/u01/app/oracle/12101/oradata/ORCL/control01.ctl
output file name=/u01/app/oracle/12101/oradata/ORCL/control02.ctl
output file name=/u01/app/oracle/12101/oradata/ORCL/control03.ctl
Finished restore at 15-AUG-16
RMAN> alter database mount;
Statement processed
RMAN> restore database ;
Starting restore at 15-AUG-16
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=6 device type=DISK
…途中省略…
channel ORA_DISK_1: restore complete, elapsed time: 00:00:25
Finished restore at 15-AUG-16
ではリストアが完了したので、アーカイブログ、REDOログを適用してきます。
RMAN> recover database;
Starting recover at 15-AUG-16
using channel ORA_DISK_1
starting media recovery
･･･途中省略･･･
archived log file name=/home/oracle/arch/1_14_919689022.dbf thread=1 sequence=14
archived log file name=/home/oracle/arch/1_15_919689022.dbf thread=1 sequence=15
archived log file name=/u01/app//oracle/12101/oradata/ORCL/redo01.log thread=1 sequence=16
archived log file name=/u01/app/oracle/12101/oradata/ORCL/redo02.log thread=1 sequence=17
archived log file name=/u01/app/oracle/12101/oradata/ORCL/redo03.log thread=1 sequence=18
media recovery complete, elapsed time: 00:02:07
Finished recover at 15-AUG-16
では最後にデータベースをOPENにします。
完全リカバリの場合、RESETLOGSオプションは不要ですが、
制御ファイルのリカバリはRESETLOGSオプションが必要になります。
RMAN> alter database open resetlogs;
Statement processed
上記が全損時のリカバリの手順となります。一部破損時と比べるとリストア作業が必要となる為、
DBの停止時間が大幅に延びます。停止時間が大きいと影響が大きくなってくる為、
制御ファイルを多重化し、全損を防ぐ構成を心がけましょう。
以上が、RMANバックアップを使用した制御ファイルのリカバリです。
制御ファイルの個別バックアップ
制御ファイルのリカバリはトレースファイルから取得したバックアップの復旧方法もあります。
制御ファイルのバックアップはRMANで取得することが可能ですが、個別にコマンドで取得することも可能です。
[構文] 制御ファイルの個別バックアップ
RMAN> ALTER DATABASE BACKUP CONTROLFILE TO [ 'バックアップ名' | TRACE ];
上記コマンドは制御ファイルのバックアップをバイナリ形式かトレースファイルにSQLとしてバックアップするかを指定することが出来ます。
「TO 'バックアップ名'」の場合はバイナリ形式でバックアップを取得し、「TO TRACE」の場合は制御ファイルを再作成する為のSQL文をトレースファイルに作成します。
トレースファイルのSQLは、NOMOUNT状態でそのSQL文を実行するだけで、制御ファイルを復旧できますが、RMANリポジトリの情報が
消失します。その為、今までRMANで取得していたバックアップの情報が消えてしまう為、必要があればRMANバックアップの情報を追加する必要があります。
以上が制御ファイルのリカバリ手順となります。