Session by Shinnosuke Akita

2015.10.17

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

Self IntroductionShinnosuke 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 = 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.bakSQL> 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

Lv1Lv1

日曜日 月曜日 火曜日

日曜 ~火曜分

差分増分バックアップ 累積増分バックアップ

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 TRACEas ‘XXXX’;

制御ファイル mount

復元先の制御ファイル作成（例）CREATE CONTROLFILE REUSE DATABASE “BALLOON” RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292LOGFILE GROUP 1 ‘/u01/app/oracle/oradata/balloons/redo01.log GROUP 2 ‘/u01/app/oracle/oradata/balloons/redo02.log GROUP 3 ‘/u01/app/oracle/oradata/balloons/redo03.logDATAFILE‘/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’・・・

リカバリの実施 mount

今存在するデータファイルを過去に戻すことはできません。これ以降にデータを不完全リカバリ／完全リカバリをしてみましょう。

直前まで戻す場合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 します。

制御ファイル mount

制御ファイルも RMAN でバックアップしたものをリストアすることで作成ができます。ここでは、新しく作成するデータベースのことは考えずにリストアします。

RMAN> RUN{2> RESTORE CONTROLFILE FROM AUTOBACKUP;3> ALTER DATABASE MOUNT;4> }

リカバリの実施 mount

リカバリを実施しますが、複製 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 BALLOONList 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;それからインカネーションを指定します。

このあと、リストア作業に入っていきます。