トップ > DBA入門 > 13章
13章 バックアップリカバリ
本章ではデータベースの復旧方法について学んでいきます。

データベースに障害が発生した場合、管理者はなるべく早く正常な状態に戻す必要が
あります。データベースにはどのような障害があるのか理解し、データベースの障害
時に対応できる知識をつけていきましょう。

データベース障害の種類


データベースの障害といっても、障害の種類は色々あります。
そして障害のタイプによって対応方法も異なります。
サービスを守るため、即座に障害を解決する技術が必要となります。

それでは障害のタイプを確認していきましょう。

・インスタンス障害
・ユーザ障害
・メディア障害

上記以外の障害もありますが今回はこの3つの障害について
確認していきたいと思います。

インスタンス障害


インスタンス障害はサーバのハード障害によりデータベースが異常停止するような
障害です。

例えば、サーバの物理メモリの故障でサーバがダウンしてしまうとデータベースは
データファイルに書き込みを行う前に強制停止してしまうため、インスタンス上に
あるデータが消失してしまいます。

インスタンス障害

上記の例のようにクライアントからUPDATEによりBに変更し、COMMIT発行しても、 インスタンス障害により、Bという変更はデータファイルに反映されずにDBは
停止してしまいます。

ではインスタンス障害が発生した場合、どのような対応が必要なのでしょうか。

インスタンスリカバリ


インスタンス障害が発生した場合、管理者は停止したデータベースを起動コマンドに
より起動するだけです。

消失してしまった変更後のデータブロックはDB起動時にREDOログの変更情報を使用
し自動的にリカバリを実施します。このリカバリをインスタンスリカバリと言います。
このインスタンスリカバリはDB起動時に自動的に実行されます。

インスタンス障害

上記の例のようにDBAがSTARTUPコマンドを実行すると、自動的に整合性が取れない
データブロックを復旧するため、REDOログの変更情報を使用し、インスタンスリカバリを実施します。

インスタンスリカバリではアーカイブログの変更情報は不要です。
REDOログの変更情報だけでリカバリを実施します。

ユーザ障害


ユーザ障害は人為的なミスによる障害でユーザエラーとも呼ばれます。
例えば、アプリケーションで使用しているテーブルを誤って削除してしまった場合
などがあります。テーブルを削除してしまうと、アプリケーションに異常が発生し、
サービスに影響が出てしまいます。

ユーザエラー時の復旧方法としては2つあります。

・フラッシュバック機能
・バックアップリカバリ

バックアップリカバリはデータベースのサイズにより、多大なサービス影響時間を
かけてしまうため、最終的な状況の場合の選択肢です。
フラッシュバック機能はバックアップリカバリと比較して、復旧時間が短い為、
効果的ですがフラッシュバック機能では復旧できない障害タイプなどもあるため、
管理者は機能を理解し、適切な復旧方法を選択する必要があります。

フラッシュバック機能とバックアップリカバリは次章でご紹介していきます。

メディア障害


メディア障害はデータベースのファイルなどが破損してしまう障害です。
例えばディスク障害により、1部のデータファイルが壊れてしまった場合などが
あります。この場合、データファイルを復旧するにはDBバックアップから
ファイルをリストアする必要があります。

インスタンス障害

上記例のようにメディア障害によりデータベースのファイルが破損してしまった場合、
バックアップから破損したファイルを戻す必要があります。

またリストアしたバックアップは過去の時点である為、上記例の場合、10/10から
10/1のデータに戻ってしまいます。10/10時点までデータファイルを進めたい場合
は、10/1以降に実施されたSQLをすべて実行することで障害直前の状態まで戻すこと
ができます。

変更情報(SQLの情報)を保持しているのが、アーカイブログ&REDOログファイルで
す。この情報を適用することで障害発生直前まで戻すことができます。
変更情報の適用することをロールフォワードといいます。ロールフォワード後、
未COMMITのデータも含まれている状態となりますので、ロールバックが実行され
ます。
上記の様に障害発生まで復旧するリカバリを完全リカバリと呼びます。
また障害直前ではなく、例えば10/8までのアーカイブログを適用し、DBを現在より
過去の状態にするリカバリを不完全リカバリと呼びます。

こちらがメディア障害からの復旧方法となります。

[補足] システム変更番号(SCN)
 SCNとはトランザクションごとに増加していく番号で、
 Oracleではデータベース内の時刻をSCNで管理しています。
 最新のSCNは制御ファイルで管理しており、データファイル
 のSCNは制御ファイルと同じSCNであるかどうかで整合性を
 チェックしています。

アーカイブログモードの有効化


メディア障害についてご紹介していきましたが、メディアリカバリには、
アーカイブログを使用し、障害直前までの状態まで復旧が可能です。

つまりアーカイブログを作成するアーカイブログモードでないとメディア障害時、
完全リカバリを実施することができません。

アーカイブログモードの詳細は「1章 Oracleデータベースアーキテクチャ」を参照ください。

ではアーカイブログモードにする方法を確認していきましょう。

1.LOG_ARCHIVE_DEST,LOG_ARCHIVE_FORMATパラメータの設定
2.データベースの停止
3.データベースのMOUNT
4.アーカイブログモードの有効化
5.データベースのOPEN

アーカイブログモードの有効化はデータベースをMOUNT状態で実施します。


LOG_ARCHIVE_DESTパラメータ


アーカイブログの格納先はLOG_ARCHIVE_DESTパラメータで指定します。
LOG_ARCHIVE_DESTは2種類あります。

・LOG_ARCHIVE_DEST
・LOG_ARCHIVE_DEST_n

LOG_ARCHIVE_DESTは1つのアーカイブログの出力先を指定します。
LOG_ARCHIVE_DEST_nは複数のアーカイブログの出力先を指定できます。
nは1〜31まで指定できます。ディスク障害に備えて、複数のアーカイブログに
出力したい場合などに使用します。
LOG_ARCHIVE_DEST_nはEnterprise Editionで使用できるパラメータです。


LOG_ARCHIVE_FORMATパラメータ


アーカイブログのファイル名はLOG_ARCHIVE_FORMATパラメータで指定します。
アーカイブログファイルはログスイッチごとに作成されていきます。
同じファイル名で作成してしまうと過去の変更情報がなくなってしまうので注意し
ましょう。
LOG_ARCHIVE_FORMATパラメータでは以下の書式が使用可能です。

%s ログ順序番号
%S 0を埋め込んだログ順序番号
%t スレッド番号
%T 0を埋め込んだスレッド番号
%d データベースID
%r リセットログID

色々な書式がありますが、『%s』『%t』『%r』は最低限使用してください。
この書式を使用するとどんなことがあっても、必ず一意なファイル名を生成できます。

それでは実行例を確認していきましょう。

  $ sqlplus / as sysdba

  SQL*Plus: Release 12.1.0.1.0 Production on XX XX XX XX:XX:XX 2016

  Copyright (c) 1982, 2013, Oracle.  All rights reserved.


  Connected to:
  Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production

  SQL> show parameter log_archive_dest

  NAME                                 TYPE        VALUE
  ------------------------------------ ----------- ---------------------------
  log_archive_dest                     string
  log_archive_dest_1                   string
  …
  log_archive_dest_state_31            string      enable


  SQL> show parameter log_archive_format

  NAME                                 TYPE        VALUE
  ------------------------------------ ----------- ---------------------------
  log_archive_format                   string      %t_%s_%r.dbf


LOG_ARCHIVE_FORMATパラメータはすでにデフォルト値が設定されていたので、
LOG_ARCHIVE_DESTパラメータだけ設定してみたいと思います。

  SQL> alter system set log_archive_dest = '/home/oracle/arch' scope=both;

  System altered.

  SQL> show parameter log_archive_dest

  NAME                                 TYPE        VALUE
  ------------------------------------ ----------- ---------------------------
  log_archive_dest                     string      /home/oracle/arch
 

LOG_ARCHIVE_DESTパラメータが設定できたので、DBをMOUNTモードに
変更します。

  SQL> shutdown immediate
  
  Database closed.
  Database dismounted.
  ORACLE instance shut down.

  SQL> startup mount
  
  ORACLE instance started.

  Total System Global Area  801701888 bytes
  Fixed Size                  2293496 bytes
  Variable Size             327155976 bytes
  Database Buffers          465567744 bytes
  Redo Buffers                6684672 bytes
  Database mounted.
 

ではアーカイブログモードの情報を確認するにはarchie log listコマンドを使用します。 その後、アーカイブログモードを有効化していきます。

  SQL> archive log list
  
  Database log mode              No Archive Mode
  Automatic archival             Disabled
  Archive destination            /home/oracle/arch
  Oldest online log sequence     31
  Current log sequence           33

  SQL> alter database archivelog;

  Database altered.

  SQL> archive log list
  
  Database log mode              Archive Mode
  Automatic archival             Enabled
  Archive destination            /home/oracle/arch
  Oldest online log sequence     31
  Next log sequence to archive   33
  Current log sequence           33

  SQL> alter database open;

  Database altered.
  

上記でアーカイブログモードに変更できました。アーカイブログファイルが作成されるか確認しましょう。

アーカイブログが作成されるタイミングはログスイッチのタイミングなので、
ログスイッチを強制的に発生させて、ログファイルが作成されるか確認します。

[構文] ログスイッチの強制発行
 SQL> ALTER SYSTEM SWITCH LOGFILE;


  SQL> alter system switch logfile;

  System altered.

  SQL> ! ls -l /home/oracle/arch
  
  合計 19024
  -rw-r----- 1 oracle oinstall 19477504  XX XX XX:XX 2016 1_33_915904440.dbf
  

アーカイブログファイルが作成されました。これでアーカイブログモードの設定は
完了です。アーカイブログモードを無効にする場合は、

[構文] NOARCHIVELOGモードの変更
 SQL> ALTER DATABASE NOARCHIVELOG;

で変更できます。

RMANバックアップの取得


ではバックアップの取得方法です。RMANのバックアップの取得はEnterpriseMonitorから GUI画面で取得するか、RMANツールからコマンドラインから取得する方法の2通りあります。

またバックアップにはオンラインバックアップ、オフラインバックアップ
の2通りあります。

一貫性
バックアップ
データベースを停止した状態でバックアップ
を取得
非一貫性
バックアップ
データベースを起動したままバックアップを
取得

非一貫性バックアップはDBを起動している状態でバックアップを取得するため、取得したバックアップは 更新中のデータも含まれている可能性があります。更新中のデータは一貫性がないデータとなっている為、非一貫性バックアップと呼ばれます。
そのバックアップを使用するときにはアーカイブログを使用してリカバリを
する必要があります。そのため、アーカイブログモードであることが前提です。

一貫性バックアップはデータベースを停止した状態でバックアップを取得します。
DBが停止中はデータの更新がないため、そのバックアップは一貫性が取れた状態であるため、一貫性バックアップと呼ばれます。

今回はRMANツールを使用したバックアップを取得します。
RMANはOracleが提供するバックアップリカバリを実施するツールです。

[構文] RMANを使用したデータベース接続
$ rman target /  (OS認証)
$ rman target sys/password@ネットサービス名 (パスワード認証)

ではRMANで接続してみます。

  $ rman target  /

  Recovery Manager: Release 12.1.0.1.0 - Production on XX X XX:XX:XX 2016

  Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

  connected to target database: orcl (DBID=397531058)

  RMAN>
  

次にバックアップを取得する時は以下の構文を使用します。

[構文] RMANでのバックアップ取得
RMAN> BACKUP [ AS COPY | AS BACKUPSET ]
   2> [ DATABASE | DATAFILE ファイル名 | TABLESPACE 表領域名 ];

バックアップタイプ
AS BACKUPSET
(デフォルト)
データファイルなどをまとめてバックアップセットという形式で取得。 未使用ブロックをスキップして取得するメリットがある。
AS COPY データファイルなどをそのままのサイズで取得。
イメージコピーと呼ばれる。 OSコマンドでもリストアが実行できるメリットがある。

データベースの取得範囲
DATABASE すべてのデータファイル、制御ファイル、
初期化パラメータファイル のバックアップを取得
DATAFILE 特定のデータファイルのみのバックアップを取得
TABLESPACE 特定の表領域のみバックアップを取得

その他のオプション
PLUS ARCHIVELOG アーカイブログを取得。
PLUS ARCHIVELOG DELETE ALL INPUT アーカイブログを取得。バックアップにアーカイブログを取得した為、既存のアーカイブログを削除

その他のオプションもたくさんありますので、詳細はマニュアルを参照ください。
「 バックアップおよびリカバリ・ユーザーズ・ガイド 12cリリース1 (12.1)」

では実際に取得してみます。

  RMAN> backup database;

  Starting backup at 05-SEP-16
  using target database control file instead of recovery catalog
  allocated channel: ORA_DISK_1
  channel ORA_DISK_1: SID=57 device type=DISK
  channel ORA_DISK_1: starting full datafile backup set
  channel ORA_DISK_1: specifying datafile(s) in backup set
  input datafile file number=003 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
  input datafile file number=001 name=/u01/app/oracle/oradata/orcl/system01.dbf
  input datafile file number=004 name=/u01/app/oracle/oradata/orcl/undotbs.dbf
  input datafile file number=005 name=/u01/app/oracle/oradata/orcl/test3.dbf
  input datafile file number=006 name=/u01/app/oracle/oradata/orcl/users01.dbf
  channel ORA_DISK_1: starting piece 1 at 05-SEP-16
  …省略…
  Finished backup at 05-SEP-16

  Starting Control File and SPFILE Autobackup at 05-SEP-16
  piece handle=/u01/app/oracle/product/12.0.1/dbhome_1/dbs/
  c-1443685173-20160905-00 comment=NONE
  Finished Control File and SPFILE Autobackup at 05-SEP-16

  RMAN>
  

これでバックアップは完了です。簡単ですね。
次に取得したバックアップの情報を確認してみます。

  RMAN> list backupset;

  List of Backup Sets
  ===================

  BS Key  Type LV Size       Device Type Elapsed Time Completion Time
  ------- ---- -- ---------- ----------- ------------ ---------------
  1       Full    1.32G      DISK        00:01:45     05-SEP-16
          BP Key: 1   Status: AVAILABLE  Compressed: NO  Tag: TAG20160905021415
          Piece Name: /u01/app/oracle/product/12.0.1/dbhome_1/dbs/01rf0obn_1_1
    List of Datafiles in backup set 1
    File LV Type Ckp SCN    Ckp Time  Name
    ---- -- ---- --------- --------- ----
    1       Full 2642912   05-SEP-16 /u01/app/oracle/oradata/orcl/system01.dbf
    3       Full 2642912   05-SEP-16 /u01/app/oracle/oradata/orcl/sysaux01.dbf
    4       Full 2642912   05-SEP-16 /u01/app/oracle/oradata/orcl/undotbs01.dbf
    6       Full 2642912   05-SEP-16 /u01/app/oracle/oradata/orcl/users01.dbf
    15      Full 2642912   05-SEP-16 /u01/app/oracle/oradata/orcl/test3.dbf
    
  …省略…

   BS Key  Type LV Size       Device Type Elapsed Time Completion Time
  ------- ---- -- ---------- ----------- ------------ ---------------
  4       Full    17.20M     DISK        00:00:01     05-SEP-16
          BP Key: 4   Status: AVAILABLE  Compressed: NO  Tag: TAG20160905021807
          Piece Name: /u01/app/oracle/product/12.0.1/dbhome_1/dbs/c-1443685173
          -20160905-00
    SPFILE Included: Modification time: 04-SEP-16
    SPFILE db_unique_name: ORCL
    Control File Included: Ckp SCN: 2643006      Ckp time: 05-SEP-16
    

今回はデータベース全体のバックアップを取得したので、データファイル、制御ファイル、 SPFILEが取得されていることがわかります。

[補足] RMANでREDOログファイルが取得されない理由
 RMANバックアップではREDOログファイルを取得しません。
 REDOログファイルは最新の更新情報が格納されています。
 もしREDOログは破損していなく、データファイルのみの障害
 の場合、REDOログファイルもバックアップから戻すと、
 最新のREDOログがバックアップに上書きされ、完全リカバリ
 ができなくなります。このようなことを防ぐため、RMANでは
 REDOログファイルのバックアップを取得しません。

上記コマンドを使用してRMANツールのバックアップを取得できます。

高速リカバリ領域


さて最後にUSE_DB_RECOVERY_FILE_DESTパラメータについてご紹介します。

LOG_ARCHIVE_DESTパラメータにUSE_DB_RECOVERY_FILE_DESTという設定
ができます。USE_DB_RECOVERY_FILE_DESTを指定すると、高速リカバリ領域にアーカイブログファイルを格納するように設定できます。

高速リカバリ領域とは、バックアップ領域やアーカイブログ領域を格納するディレクトリを決めておくだけで、 その領域内の制限サイズを超えないようバックアップの管理をOracleが自動的に行います。

バックアップの管理とは不要なバックアップファイルやアーカイブログを削除することです。 バックアップやアーカイブログは日々増えていくため、そのままにしておくと
領域が圧迫されていきます。
その為、不要なファイルは日々削除していく必要があります。

しかし高速リカバリの設定をしておくと、Oracleが自動的に指定されたサイズ内になるように不要なバックアップを自動的に削除してくれます。

高速リカバリ領域の構成


高速リカバリ領域を設定するには以下の初期化パラメータを設定する必要があります。

DB_RECOVERY
_FILE_DEST
高速リカバリ領域の場所を指定します。
ファイル・システム・ディレクトリまたは
Oracle ASMディスク・グループを指定できますが、RAWディスクは指定できません。
DB_RECOVERY
_FILE_DEST_SIZE
高速リカバリ領域のサイズをバイト数で
指定します。

上記2つのパラメータを設定することで、高速リカバリを設定できます。
これにより、今までバックアップの管理が必要だったものが自動的に管理されるよう
になります。

RMANでのバックアップは高速リカバリ領域が構成されていると特にバックアップの
指定がされていない場合は、デフォルトで高速リカバリ領域に取得するようになります。

また不要なバックアップを削除するポリシーは以下の方針で設定できます。

■最新の3世代分だけ残しておく

  RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
    

■7日前までの不完全リカバリに対応できるようバックアップを残しておく

  RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
    

保存ポリシーは上記の様にバックアップの数による世代管理もしくは、不完全リカバリが実施できるよう、 にバックアップを保持しておく方法が設定できます。

以上がバックアップの章となります。本章は長くなってしまったので
次章はリカバリについてご紹介していきます。