障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～
Download as PPT, PDF4 likes4,653 views
2015/10/17にJPOUGさんでお話をさせて頂きました、Oracle Databaseのバックアップリカバリのスライドです。
障害とオペミスに備える! ～Oracle Databaseのバックアップを考えよう～
- 1. Session by Shinnosuke Akita 2015.10.17 障害とオペミスに備える ! ～ Oracle Database のバックアップを考えよう～
- 2. Self Introduction Shinnosuke Akita ・ Oracle DBA をやっています。 ・ 今は Exadata の案件に入っています。 ・ 入社 3 年目 ・ 休日はランニングと家族サービス ・ たまに勉強会にでかけたり ・ 大衆酒場めぐりがマイブーム
- 3. What’s Valtech 株式会社バルテック 現在、社員募集中 バルテック 採用 アプリケーション開発技術、データベース技術のサー ビス提供を行っています。 社員数： 130 名 資本金： 3000 万円 ＜研修制度が充実しています＞ 関連企業「 J-SchooL 」での研修制度を受けることが でき、現役エンジニアの講師による実践形式の授業を 受けることができます。
- 4. Today’s Agenda データベースのバックアップを考える ・突然の障害・オペレーションミス ・バックアップ計画を考える どう備えるか？ ・ DataPump ・ OS の機能によるバックアップ ・ RMAN の機能によるバックアップ リカバリを試してみる リカバリのやり直し？
- 5. データベースには日々多くのデータが挿入・更新・削除されて いきます。 中には 24 時間 365 日稼働し続けているシステムもあります。 これらのデータが障害やトラブルによってデータを欠損させてし まったら、業務へのインパクトはどのようなものが考えられるで しょうか。
- 6. 障害やトラブルによって、データの欠損、システムが復旧するまで に売上を上げることができる機会が失われるなどの影響が考えられ ます。 そのため、 24 時間 365 日稼働し続けているシステムなどでは、障 害が発生した時はすぐに復旧できるよう、普段から備える必要があ ります。 データの欠損 機会の損失
- 8. １．いつバックアップを取る？ いつバックアップを取るべきかを検討するためには、リカバリに ついて考える必要があります。 バックアップの指標として、以下のものがあります。 RPO = Recovery Point Objective 目標復旧時点 RTO = Recovery Time Objective 目標復旧時間 いつ時点までに復旧するかによって、バックアップを取得する頻 度が変わってきます。
- 9. １．いつバックアップを取る？ いつバックアップを取るべきかを検討するためには、リカバリに ついて考える必要があります。 バックアップの指標として、以下のものがあります。 RPO = Recovery Point Objective 目標復旧時点 RTO = Recovery Time Objective 目標復旧時間 いつ時点までに復旧するかによって、バックアップを取得する頻 度が変わってきます。
- 10. 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)
- 11. ２．どのようにバックアップを取るか？ データベースのバックアップを取るのにもいくつかの方法がありま す。 どのように復旧をするかによって選ぶ必要があります。 ・ DataPump による論理バックアップ ・ OS の機能による物理バックアップ ・ Recovery Manager による物理バックアップ それぞれのバックアップについて見てみましょう。
- 12. DataPump による論理バックアップ DataPump を使用して論理バックアップを取得することができます 。 論理バックアップとは、データベースの中にあるデータの中身 （バックアップ取得時点の DDL 文や DML 文）を取得することで バックアップを実現しています。 ただし、 DataPump による復旧はバックアップ取得時点までしか戻 すことができず、物理的に同じでないのでアーカイブログを当てる などの対処もできません。バックアップ取得から障害発生時までの データが失われることから、それが許容できる状況でしか使用する ことができません。10/15 17:00 10/16 17:00 RPO:24H 10/16 20:00 Lv0+ LV1 Lv0+ LV1 バックアップファイル ※ オペミス等によるデータ削除には論理バックアップは有効です。
- 13. OS の機能よる物理バックアップ OS のコマンド（ Linux/Unix なら cp ) コマンドを使用して物理バッ クアップを取得することができます。 ただし、物理バックアップを取得するには、起動しているデータ ベースをそのままにコピーしたとしても、常にデータを更新し続け ているため正しいバックアップが取れません。 バックアップを取る前にバックアップモードに変更してから取得す る必要があります。オンラインでバックアップモードにするには アーカイブログモードにする必要があります。 SQL> alter database begin backup; $ cp –p +DG01/user0001.dbf +DG02/XXXXXXX.bak SQL> alter database end backup;
- 14. RMAN の機能よる物理バックアップ RMAN(Recovery Manager) によるバックアップもまた、物理バック アップを取得することができます。 RMAN においても、オンラインでバックアップを取得するにはアー カイブログモードにする必要があります。 RMAN では Lv1 バックアップ（差分増分バックアップ／累積増分 バックアップ）を取得することもできます。 RMAN> backup as copy incremental level 0 database; RMAN> backup as backupset incremental level 1 database;
- 15. 差分増分バックアップと累積増分バックアップ Lv0 バックアップ（全バックアップ）を毎日取得するとなると、 バックアップを保持する容量が多く必要になりますし、バックアッ プの取得時間も長くなってしまいます。増分バックアップの取得で これらを抑えることができます。 差分増分バックアップは前回から (Lv0 、 Lv1 のいずれか）の差分を 、累積増分バックアップは Lv0 からの差分を取得します。 Lv0 Lv1 Lv1 日曜日 月曜日 火曜日 Lv0 Lv1 Lv1 日曜日 月曜日 火曜日 日曜 ~ 火 曜分 差分増分バックアップ 累積増分バックアップ
- 16. 3 ．どこにバックアップを取るか？ 運用中のデータベースと同じサーバにバックアップファイルを置く こともできますが、サーバが物理故障すると復旧ができなくなって しまいます。 同じ拠点の別サーバに置く、可能であれば遠隔地の別サーバに置く ようにすると、災害時にデータベースを復旧するのに有利になりま す。 ４．誰がバックアップを取るか？ バックアップは毎日のことですので、日々エンジニアが手作業で取 得することは現実的ではありません。 Cron によるバックアップシェルの自動起動や Oracle Enterprise Manager など Oracle が提供しているサービスの活用など、取得の為 の選択肢が複数あります。
- 19. そもそも復元に必要な材料に何があるだろう？ データファイル or ベースバックアッ プ 初期化パラメータファイル 制御ファイル アーカイブ REDO ログ／ REDO ロ グ
- 20. それぞれのバックアップについて、 リカバリを考えてみましょう。 ・ DataPump による論理バック アップ ・ OS の機能による物理バック アップ ・ Recovery Manager による物理バック アップ
- 21. DataPump によるリカバリ DataPump を使用して取得した論理バックアップ (expdp) は、別環 境のデータベースに対してリカバリ (impdp) をすることができます 。 出力したダンプファイルを別 DB にインポートすることでリカバリ ができますので、比較的簡単に行えます。 バージョンが異なるデータベース間もデータを移すことができます 。 本番 DB 別 DB expdp impdp
- 22. OS の機能によるバックアップからのリカバリ OS の機能によるバックアップファイルからリカバリをすることもで きます。 コピーしたデータファイルを別のデータベースのデータファイルと して使用し、アーカイブログを適用させていきます。 別 DB は既に起動しているものではなく、新たに作っていきます。 本番 DB 別 DB cp cp
- 23. データファイル shutdown 物理バックアップファイルの Lv0 相当（ベースバックアップ）は、 そのままデータファイルとして使用することができます。 通常、バックアップファイル名はデータファイル名とは異なります ので、それっぽい名前につけかえてあげると良いでしょう。 RMAN バックアップの Lv0 を copy で作成したものでも OK です。 $ cp –p +BKUPDG/XXXXXXX.bak +DATADG/XXXXXXX.dbf
- 24. 初期化パラメータファイル nomount 実運用中のデータベースと同等のもので良いですが、 メモリ関連のパラメータを低めにして低スペックなサーバでも再現 できるようにすると良いかもしれません。 初期化パラメータファイルを用意して nomount 起動することで、 初期化パラメータファイルの読み込み・ SGA メモリ領域確保をしま しょう。
- 25. 制御ファイル mount 実運用中のデータベースより制御ファイルコピーまたは、 制御ファイルトレースにて出力して用意します。 ただし、制御ファイルトレースを元に CREATE CONTROLFILE し た場合は、実運用中のデータベースのリカバリ情報を消失します。 制御ファイルコピー（バイナリ形式） SQL> ALTER DATABASE BACKUP CONTROLFILE TO ‘XXXX’; 制御ファイルトレース SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE as ‘XXXX’;
- 26. 制御ファイル mount 復元先の制御ファイル作成（例） 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 GROUP 2 ‘/u01/app/oracle/oradata/balloons/redo02.log GROUP 3 ‘/u01/app/oracle/oradata/balloons/redo03.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’ ・・・
- 27. リカバリの実施 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’ ・・・
- 28. リカバリの実施 mount 今存在するデータファイルを過去に戻すことはできません。 これ以降にデータを不完全リカバリ／完全リカバリをしてみましょ う。 直前まで戻す場合 SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; 時間指定の場合 SQL> RECOVER DATABASE UNTIL TIME '2015-10-17 13:00:00' USING BACKUP CONTROLFILE;
- 29. データベースのオープン open メディアリカバリが完了したら、最後に RESETLOGS モードで データベースをオープンします。 SQL> ALTER DATABASE OPEN RESETLOGS;
- 30. RMAN によるバックアップからのリカバリ RMAN ではもっと簡単にバックアップファイルからリカバリをする ことができます。 バックアップファイルから別のデータベースのデータファイルとし て使用し、アーカイブログを適用させていきます。 別 DB は既に起動しているものではなく、新たに作っていきます。 本番 DB 別 DB RMAN RMAN
- 31. RMAN では、もっと簡単にリカバリを行うことができます RMAN> SET DBID 886377364 RMAN> startup nomount DBID を設定します。 nomount 起動します。このとき spfile はありませんが、仮の pfile を 使用します。 RMAN> RESTORE SPFILE TO PFILE それから spfile より pfile をリストアします。 nomount 初期化パラメータファイル リストアした PFILE を適宜変更して、再度 NOMOUNT します。
- 32. 制御ファイル mount 制御ファイルも RMAN でバックアップしたものをリストアすること で作成ができます。 ここでは、新しく作成するデータベースのことは考えずにリストア します。 RMAN> RUN{ 2> RESTORE CONTROLFILE FROM AUTOBACKUP; 3> ALTER DATABASE MOUNT; 4> }
- 33. リカバリの実施 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; } リストア先の 切り替え 制御ファイルへの 反映
- 34. データベースのオープン open メディアリカバリが完了したら、最後に RESETLOGS モードで データベースをオープンします。 RMAN> ALTER DATABASE OPEN RESETLOGS;
- 36. インカネーションの指定 制御ファイルに記録されているインカネーション（世代）を RESET することで、リストアのやり直しをすることが可能です。 ただし、リストアに必要なベースバックアップファイル等が残ってい ることが前提です。 Incarnation 2 Incarnation 116 Incarnation 311 2015/10/15 22:00 2015/10/16 22:00
- 37. インカネーションの指定 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; それからインカネーションを指定します。 このあと、リストア作業に入っていきます。