障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～

Session by Shinnosuke Akita
2015.10.17
障害とオペミスに備える !
～ Oracle Database のバックアップを考えよう～

Self Introduction
Shinnosuke Akita
・ Oracle DBA をやっています。
・今は Exadata の案件に入っています。
・入社 3 年目
・休日はランニングと家族サービス
・たまに勉強会にでかけたり
・大衆酒場めぐりがマイブーム

What’s Valtech
株式会社バルテック
現在、社員募集中
バルテック　採用
アプリケーション開発技術、データベース技術のサー
ビス提供を行っています。
社員数： 130 名
資本金： 3000 万円
＜研修制度が充実しています＞
関連企業「 J-SchooL 」での研修制度を受けることが
でき、現役エンジニアの講師による実践形式の授業を
受けることができます。

Today’s Agenda
データベースのバックアップを考える
　・突然の障害・オペレーションミス
　・バックアップ計画を考える
どう備えるか？
　・ DataPump
　・ OS の機能によるバックアップ
　・ RMAN の機能によるバックアップ
リカバリを試してみる
リカバリのやり直し？

データベースには日々多くのデータが挿入・更新・削除されて
いきます。
中には 24 時間 365 日稼働し続けているシステムもあります。
これらのデータが障害やトラブルによってデータを欠損させてし
まったら、業務へのインパクトはどのようなものが考えられるで
しょうか。

障害やトラブルによって、データの欠損、システムが復旧するまで
に売上を上げることができる機会が失われるなどの影響が考えられ
ます。
そのため、 24 時間 365 日稼働し続けているシステムなどでは、障
害が発生した時はすぐに復旧できるよう、普段から備える必要があ
ります。
データの欠損機会の損失

データベースのバックアップ計画を考えましょう
何を考えればよいでしょうか。
いつバックアップを取る？いつバックアップを取る？
どこにバックアップを取る？どこにバックアップを取る？
誰がバックアップを取る？誰がバックアップを取る？
どのようにバックアップを取る？どのようにバックアップを取る？

１．いつバックアップを取る？
　いつバックアップを取るべきかを検討するためには、リカバリに
ついて考える必要があります。
　バックアップの指標として、以下のものがあります。
RPO = Recovery Point Objective 　目標復旧時点
RTO = Recovery Time Objective 目標復旧時間
　いつ時点までに復旧するかによって、バックアップを取得する頻
度が変わってきます。

RPO を決めてしまえば、いつバックアップを取るべきかがおのずと
決まってきます。たとえば、前営業日終了時点まで復旧できれば、
それ以降のデータロスは許容できるのであれば、１日１回のバック
アップだけで良いでしょう。
10/15 17:00 10/16 17:00
RPO:24H
RPO: 　
1H
RPO: 　
5M
10/16 20:00
Lv0+
LV1
Lv0+
LV1
Lv0+
LV1
Lv0+
LV1
Arc Arc Arc
ArcArcArcArcArcArcArcArcArcArc
バックアップファイル
＋アーカイブログ (1H)
＋アーカイブログ (5M)

２．どのようにバックアップを取るか？
データベースのバックアップを取るのにもいくつかの方法がありま
す。
どのように復旧をするかによって選ぶ必要があります。
・ DataPump による論理バックアップ
・ OS の機能による物理バックアップ
・ Recovery Manager による物理バックアップ
それぞれのバックアップについて見てみましょう。

DataPump による論理バックアップ
DataPump を使用して論理バックアップを取得することができます
。
論理バックアップとは、データベースの中にあるデータの中身
（バックアップ取得時点の DDL 文や DML 文）を取得することで
バックアップを実現しています。
ただし、 DataPump による復旧はバックアップ取得時点までしか戻
すことができず、物理的に同じでないのでアーカイブログを当てる
などの対処もできません。バックアップ取得から障害発生時までの
データが失われることから、それが許容できる状況でしか使用する
ことができません。10/15 17:00 10/16 17:00
RPO:24H
10/16 20:00
Lv0+
LV1
Lv0+
LV1
バックアップファイル
※ オペミス等によるデータ削除には論理バックアップは有効です。

OS の機能よる物理バックアップ
OS のコマンド（ Linux/Unix なら cp ) コマンドを使用して物理バッ
クアップを取得することができます。
ただし、物理バックアップを取得するには、起動しているデータ
ベースをそのままにコピーしたとしても、常にデータを更新し続け
ているため正しいバックアップが取れません。
バックアップを取る前にバックアップモードに変更してから取得す
る必要があります。オンラインでバックアップモードにするには
アーカイブログモードにする必要があります。
SQL> alter database begin backup;
$ cp –p +DG01/user0001.dbf
+DG02/XXXXXXX.bak
SQL> alter database end backup;

RMAN の機能よる物理バックアップ
RMAN(Recovery Manager) によるバックアップもまた、物理バック
アップを取得することができます。
RMAN においても、オンラインでバックアップを取得するにはアー
カイブログモードにする必要があります。
RMAN では Lv1 バックアップ（差分増分バックアップ／累積増分
バックアップ）を取得することもできます。
RMAN> backup as copy incremental level 0
database;
RMAN> backup as backupset incremental level 1
database;

差分増分バックアップと累積増分バックアップ
Lv0 バックアップ（全バックアップ）を毎日取得するとなると、
バックアップを保持する容量が多く必要になりますし、バックアッ
プの取得時間も長くなってしまいます。増分バックアップの取得で
これらを抑えることができます。
差分増分バックアップは前回から (Lv0 、 Lv1 のいずれか）の差分を
、累積増分バックアップは Lv0 からの差分を取得します。
Lv0
Lv1 Lv1
日曜日月曜日火曜日
Lv0
Lv1
Lv1
日曜日月曜日火曜日
日曜 ~ 火
曜分
差分増分バックアップ累積増分バックアップ

3 ．どこにバックアップを取るか？
運用中のデータベースと同じサーバにバックアップファイルを置く
こともできますが、サーバが物理故障すると復旧ができなくなって
しまいます。
同じ拠点の別サーバに置く、可能であれば遠隔地の別サーバに置く
ようにすると、災害時にデータベースを復旧するのに有利になりま
す。
４．誰がバックアップを取るか？
バックアップは毎日のことですので、日々エンジニアが手作業で取
得することは現実的ではありません。
Cron によるバックアップシェルの自動起動や Oracle Enterprise
Manager など Oracle が提供しているサービスの活用など、取得の為
の選択肢が複数あります。

ところで・・・
　取ったバックアップが使えるか心配だ。
　手順は正しいだろうか？
　実運用中だが、同等の環境で手順検証
　できないだろうか？
　心配に思ったことはありませんか？

いざというときのために、
チェックしておきたい！
リカバリに必要なデータが足りなかった
手順が誤っていた／足りなかった
・・・

そもそも復元に必要な材料に何があるだろう？
データファイル or ベースバックアッ
プ
初期化パラメータファイル
制御ファイル
アーカイブ REDO ログ／ REDO ロ
グ

それぞれのバックアップについて、
リカバリを考えてみましょう。
・ DataPump による論理バック
アップ
・ OS の機能による物理バック
アップ
・ Recovery Manager による物理バック
アップ

DataPump によるリカバリ
DataPump を使用して取得した論理バックアップ (expdp) は、別環
境のデータベースに対してリカバリ (impdp) をすることができます
。
出力したダンプファイルを別 DB にインポートすることでリカバリ
ができますので、比較的簡単に行えます。
バージョンが異なるデータベース間もデータを移すことができます
。
本番 DB 別 DB
expdp impdp

OS の機能によるバックアップからのリカバリ
OS の機能によるバックアップファイルからリカバリをすることもで
きます。
コピーしたデータファイルを別のデータベースのデータファイルと
して使用し、アーカイブログを適用させていきます。
別 DB は既に起動しているものではなく、新たに作っていきます。
本番 DB 別 DB
cp cp

データファイル
shutdown
物理バックアップファイルの Lv0 相当（ベースバックアップ）は、
そのままデータファイルとして使用することができます。
通常、バックアップファイル名はデータファイル名とは異なります
ので、それっぽい名前につけかえてあげると良いでしょう。
RMAN バックアップの Lv0 を copy で作成したものでも OK です。
$ cp –p +BKUPDG/XXXXXXX.bak
+DATADG/XXXXXXX.dbf

初期化パラメータファイル nomount
実運用中のデータベースと同等のもので良いですが、
メモリ関連のパラメータを低めにして低スペックなサーバでも再現
できるようにすると良いかもしれません。
初期化パラメータファイルを用意して nomount 起動することで、
初期化パラメータファイルの読み込み・ SGA メモリ領域確保をしま
しょう。

制御ファイル mount
実運用中のデータベースより制御ファイルコピーまたは、
制御ファイルトレースにて出力して用意します。
ただし、制御ファイルトレースを元に CREATE CONTROLFILE し
た場合は、実運用中のデータベースのリカバリ情報を消失します。
制御ファイルコピー（バイナリ形式）
SQL> ALTER DATABASE BACKUP CONTROLFILE TO ‘XXXX’;
制御ファイルトレース
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE
as ‘XXXX’;

復元先の制御ファイル作成（例）
CREATE CONTROLFILE REUSE DATABASE “BALLOON” RESETLOGS
ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 ‘/u01/app/oracle/oradata/balloons/redo01.log
DATAFILE
‘/u01/app/oracle/oradata/balloons/system01.dbf’
‘/u01/app/oracle/oradata/balloons/sysaux01.dbf’
‘/u01/app/oracle/oradata/balloons/undotbs01.dbf’
‘/u01/app/oracle/oradata/balloons/users01.dbf’
・・・

リカバリの実施 mount
いよいよリカバリの実施です。
まずは、必要なデータファイルが認識できているか見てみましょう
。
SQL> SELECT NAME FROM v$datafile;
NAME
===============================
‘/u01/app/oracle/oradata/balloons/system01.dbf’
‘/u01/app/oracle/oradata/balloons/sysaux01.dbf’
‘/u01/app/oracle/oradata/balloons/undotbs01.dbf’
‘/u01/app/oracle/oradata/balloons/users01.dbf’
・・・

今存在するデータファイルを過去に戻すことはできません。
これ以降にデータを不完全リカバリ／完全リカバリをしてみましょ
う。
直前まで戻す場合
SQL> RECOVER DATABASE USING BACKUP
CONTROLFILE UNTIL CANCEL;
時間指定の場合
SQL> RECOVER DATABASE UNTIL TIME '2015-10-17
13:00:00' USING BACKUP CONTROLFILE;

データベースのオープン open
メディアリカバリが完了したら、最後に RESETLOGS モードで
データベースをオープンします。
SQL> ALTER DATABASE OPEN RESETLOGS;

RMAN によるバックアップからのリカバリ
RMAN ではもっと簡単にバックアップファイルからリカバリをする
ことができます。
バックアップファイルから別のデータベースのデータファイルとし
て使用し、アーカイブログを適用させていきます。
別 DB は既に起動しているものではなく、新たに作っていきます。
本番 DB 別 DB
RMAN RMAN

RMAN では、もっと簡単にリカバリを行うことができます
RMAN> SET DBID 886377364
RMAN> startup nomount
DBID を設定します。
nomount 起動します。このとき spfile はありませんが、仮の pfile を
使用します。
RMAN> RESTORE SPFILE TO PFILE
それから spfile より pfile をリストアします。
nomount
初期化パラメータファイル
リストアした PFILE を適宜変更して、再度 NOMOUNT します。

制御ファイルも RMAN でバックアップしたものをリストアすること
で作成ができます。
ここでは、新しく作成するデータベースのことは考えずにリストア
します。
RMAN> RUN{
2> RESTORE CONTROLFILE FROM AUTOBACKUP;
3> ALTER DATABASE MOUNT;
4> }

リカバリを実施しますが、複製 DB のデータファイル／ REDO ログ
が元の DB と異なる場合は、 SET NEWNAME 句で変更してから行
います。
RUN{
SET NEWNAME FOR DATAFILE 1 TO ‘ 新しいパス’
SET NEWNAME FOR DATAFILE 2 TO ‘ 新しいパス’
・・ ( 略 )
SQL ALTER DATABASE RENAME FILE ‘ 新しい REDO ログ’
SET UNTIL TIME 2015/10/16 22:00:00
RESTORE DATABASE;
SWITCH DATAFILE ALL;
RECOVER DATABASE;
}
リストア先の
切り替え
制御ファイルへの
反映

データベースのオープン open
メディアリカバリが完了したら、最後に RESETLOGS モードで
データベースをオープンします。
RMAN> ALTER DATABASE OPEN RESETLOGS;

リカバリのやり直し
リカバリポイントを間違えてしまったら・・・

インカネーションの指定
制御ファイルに記録されているインカネーション（世代）を
RESET することで、リストアのやり直しをすることが可能です。
ただし、リストアに必要なベースバックアップファイル等が残ってい
ることが前提です。
Incarnation 2
Incarnation 116 Incarnation 311
2015/10/15 22:00 2015/10/16 22:00

インカネーションの指定
RMAN> LIST INCARNATION OF DATABASE BALLOON
List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ------------- ------- ---------- ----------
1 2 TRGT 1334358386 PARENT 154381 OCT 30 2007 16:02:12
1 116 TRGT 1334358386 CURRENT 154877 OCT 30 2007 16:37:39
インカネーションを確認します。
RMAN> RESET DATABASE TO INCARNATION 2;
それからインカネーションを指定します。
このあと、リストア作業に入っていきます。

障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to 障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～

Similar to 障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～ (20)

Recently uploaded

Recently uploaded (9)

障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～