Comments
Description
Transcript
Flashback
Oracle Database Core Tech Seminar - Data Guard, RMAN, Flashback 1 テクノロジー製品事業統括本部 – 基盤技術部 シニアエンジニア 佐々木 亨 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 2 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Russia 17–18 April 2012 India 3–4 May 2012 3 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. San Francisco September 30–October 4, 2012 4 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。 5 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. はじめに 本セッションの内容 • Oracle Maximum Availability Architecture（MAA）を構成するために必 要な下記のテクノロジーを解説します – Active Data Guard – Recovery Manager (RMAN) – Flashback テクノロジー 6 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. はじめに 本セッションの内容 • Oracle Maximum Availability Architecture（MAA）は、 Oracleの実証済み高可用性テクノロジーと成功事例に基づいたOracle のベスト・プラクティスのブループリント • MAAの目的 – すべての停止を回避、検出および修復するためのベスト・プラクティスを提供 – 最適な高可用性アーキテクチャをシンプルに構成すること • ハードウェアやOSの影響を受けない • 高可用性のソリューションと体験をすぐに提供 7 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. はじめに 本セッションの内容 Real Application Clusters データ障害 Flashback RMAN & Oracle Secure Backup ASM Active Data Guard GoldenGate システム変更 Online Reconfiguration Rolling Upgrades データ変更 Online Redefinition アプリ変更 Edition-based Redefinition 8 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Oracle MAA Best Practices ノード障害 計画外停止 計画停止 MAA を構成する機能・製品 はじめに Oracle Maximum Availability Architecture RAC • データ多重化 • 災害対策 Active Data Guard RAC • サーバーの 単一障害点抑止 • 拡張性の確保 RMAN Flashback ASM • ボリューム管理 • 単一障害点抑止 9 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. • 人的ミスからの 迅速復旧 • データバックアップ • 人的ミスの抑制 backup 本日の内容 • Active Data Guard • Recovery Manager (RMAN) • Flashback テクノロジー 10 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Active Data Guard データ保護と可用性の提供と同時に、適切なROIを実現 • REDO転送によって複製データベースを作成、同期を取ることで、 本番データベースを障害およびデータ破損から保護 • 計画停止 / 計画外停止時の切り替えによりシステムのダウンタイムを短縮 • レポーティング、テストやバックアップ用途でスタンバイ・データベースを 活用可能 データベースのREDOを転送 プライマリ・データベース 11 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ・データベース Active Data Guard アーキテクチャ サーバー プロセス ログ バッファ (1). REDO転送サービス ログバッファまたはオンラインREDOログ からREDOを転送、スタンバイ側で受信 NSS/NSA ログ バッファ RFS LGWR データファイル オンライン REDOログ MRP アーカイブ ログ プライマリ・データベース (3). ロール管理サービス 12 (2). REDO適用サービス リカバリの仕組みでREDO を逐次適用 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ REDOログ アーカイブ ログ データファイル スタンバイ・データベース 計画(外)停止時にデータベースを切り替える 本日の内容 • Active Data Guard – REDO 転送サービス – REDO 適用サービス – ロール管理サービス • Recovery Manager (RMAN) • Flashback テクノロジー 13 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送の経路と設定 • REDO転送のネットワーク経路はREDOの宛先で指定可能 • プライマリの log_archive_dest_n パラメータで設定 log_archive_dest_n = ‘SERVICE =<tns名> …’ <tns名> = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = <IP1 or IP2>) (PORT = ポート番号)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = <スタンバイSID>)) ) 14 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. パブリックLAN spfile.ora • クライアント • アプリケーションサーバー IP1 リスナー1 listener.ora tnsnames. ora 管理用LAN リスナー2 IP2 ※ スタンバイ側でも設定しておけば 役割が入れ替わった後の転送も可能 転送方法の選択 同期転送と非同期転送 • 同期 / 非同期転送から選択可能 • 同期転送 – 消失データゼロを実現 – スタンバイへのREDO転送完了を待つため、プライマリデータベースのレスポ ンスに影響する • 非同期転送 – プライマリへの性能の影響はほとんどない – ネットワーク性能が十分であればほぼ最新のデータを送信可能 15 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 同期転送と非同期転送 アーキテクチャ 同期転送 ① サーバー プロセス SQL> COMMIT; ログ バッファ ① ④ 非同期転送 ① サーバー プロセス ログ バッファ ① ③ LGWR RFS ログ バッファ ③ オンライン REDOログ NSA LGWR スタンバイ REDOログ ㋐ RFS データファイル ログ バッファ ㋑ ② データファイル 16 ② ② データファイル SQL> COMMIT; NSS Copyright © 2012, Oracle and/or its affiliates. All rights reserved. オンライン REDOログ スタンバイ REDOログ データファイル 同期転送と非同期転送 同期転送におけるアプリケーションへの影響 同期転送 ① サーバー プロセス NSS LGWR ④ 17 ① コミット処理 開始 SQL> COMMIT; RFS ログ バッファ ③ ② データファイル アプリケーション ② オンライン REDOログ スタンバイ REDOログ ② オンラインREDO ログへ書き込み ② スタンバイ へ転送 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. ② 書き込み 完了通知 ③ スタンバイREDO ログへ書き込み データファイル ④ コミット処理 完了 SQL> COMMIT; ログ バッファ ① 同期転送と非同期転送 非同期転送におけるアプリケーションへの影響 非同期転送 ① サーバー プロセス ③ ① コミット処理 開始 SQL> COMMIT; LGWR RFS ログ バッファ ㋑ オンライン REDOログ ② オンラインREDO ログへ書き込み ㋐ スタンバイ へ転送 18 ㋐ ② データファイル アプリケーション NSA Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ REDOログ ③ コミット処理 完了 SQL> COMMIT; ログ バッファ ① ㋑ スタンバイREDO ログへ書き込み データファイル 同期転送と非同期転送 データ保護の要件と性能要件の選択 同期転送 非同期転送 メリット • ゼロデータロスを実現可能 デメリット • 性能への影響を検討する必 • データロスに関する検討が 要がある 必要 • アプリケーション特性（REDO生成量） • 性能への影響がほぼない • ネットワーク帯域、遅延 • プライマリがmountできれば データロスは回避可能 • スタンバイREDOログファイルのI/O性能 • トランザクション再実行 同期転送と非同期転送の切り替えはオンラインで変更可能 19 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. アプリケーション特性 REDO生成量の確認 Enterprise Manager Cloud Control 12c から REDO生成量を時系列で確認可能 20 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 必要なネットワーク帯域 Data Guard ストレージの リモートミラー ストレージのリモートミラーと Data Guard 制御ファイル オンライン REDOログ アーカイブログ 制御ファイル 広帯域な ネットワーク 回線が必要 オンライン REDOログ アーカイブログ データファイル データファイル 制御ファイル 制御ファイル オンライン REDOログ REDOのみ転送 スタンバイ REDOログ アーカイブログ アーカイブログ データファイル データファイル MRP Data Guard では転送対象が限定されるので、必要な帯域幅が小さくなる 21 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. ネットワーク帯域についての考慮 帯域が十分確保できない場合 • ネットワークの帯域を上回るREDOが長時間生成された場合の動作 – 転送が完了せずトランザクションのコミットがなかなか返らない（同期転送） – 未転送のREDOが増加＝障害発生時の消失データの増加（非同期転送） ログ バッファ NSS/NSA ログ バッファ RFS LGWR MRP 未転送REDO データファイル 22 オンライン REDOログ Copyright © 2012, Oracle and/or its affiliates. All rights reserved. アーカイブ ログ スタンバイ REDOログ アーカイブ ログ データファイル REDO圧縮機能 ※ Advanced Compression オプションがあれば使用可能 転送時に圧縮 サーバー プロセス ログ バッファ 受信時に伸長 NSS/NSA ログ バッファ RFS LGWR MRP ディスク上では 圧縮されない データファイル オンライン REDOログ アーカイブ ログ プライマリ・データベース スタンバイ REDOログ アーカイブ ログ データファイル スタンバイ・データベース 低帯域なネットワーク経由でREDOを転送する際に有効 23 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO圧縮の効果 平均CPU使用率 Node 1 100 Node 2 90 79.479.0 77.677.4 80 70 60 50 40 30 20 10 0 平均REDO転送量 6 REDO転送量 (MB/s) 平均スループット 100 99.39 100 90 80 70 60 50 40 30 20 10 0 非圧縮 圧縮 usr + sys (%) スループット(係数化後) Oracle GRID Center における日立製作所様との共同検証結果 5.32 5 4 3 2.21 2 1 0 非圧縮 圧縮 非圧縮 参考URL : http://www.hitachi.co.jp/Prod/comp/soft1/oracle/pdf/OBtecinfo-08-007.pdf 24 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 約40% まで圧縮！ 圧縮 REDO圧縮導入時の考慮点 • CPUリソースへのオーバーヘッド – 圧縮率が高いほどオーバーヘッドも大きい – 同時処理量（REDO転送量）が多いほどオーバーヘッドが大きい • 圧縮率の考え方 – データに依存するため、一定ではない – gzip コマンドによる圧縮率と近い傾向にある • アーカイブログ・ファイルに対して gzip コマンドを実行しサイズを確認することでラフ な見積もりは可能 25 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送ネットワークの遅延 • 転送距離が長くなるとRTT(Round Trip Time)が長くなる • 一般的に、転送の最大スループットは一度に送るデータ量とRTTで決まる – RTTが長くなると1コネクション当たり（Data Guard の転送ルートにおける）の 転送スループットは悪くなる • 広帯域の回線でも、1コネクションでは帯域を使いきらず転送効率が低下 26 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送ネットワークのチューニング • SDU(Session Data Unit) サイズの増加 – データ転送時に Oracle*Net でバッファに格納する単位を増やして、ネットワー クI/Oの回数を減らす – 推奨値：65535(最大値) 送受信両側で設定する • TCP ソケット・バッファ の増加 – ネットワーク回線上で使用できる帯域幅に関係なく、使用可能な帯域幅を制御 – TCP送信バッファ / 受信バッファサイズの増加により転送効率が向上 – 帯域幅とRTTから最適な値を算出可能： 「帯域幅(バイト) × RTT(秒) ×3」 27 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送ネットワークのチューニング効果 Oracle GRID Center における日立製作所様との共同検証結果 • RTTの増加によって転送効率は低下するが、Oracleの設定によるチュー ニングで改善可能 平均転効率（MB/s） チューニング前 8.6 転送効率 の改善！ 未設定（LANを想定） 12（東京－大阪間想定） Round Trip Time （ミリ秒） 28 チューニング後 10.1 11.1 11.0 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 4.5 転送効率 の改善！ 40（東京－沖縄間想定) REDOの受信 スタンバイREDOログ • プライマリから転送されたREDOをアーカイブ する前に一時的に蓄えるためのファイル • 未アーカイブのREDOも適用でき、 フェイルオーバー時のREDO消失を 少なくできる RFS ログ バッファ • 作成時の注意点 – サイズはプライマリのオンラインREDOログと同じにする – グループ数はプライマリのグループ数＋１以上 – 複数メンバー作成も可能 – I/O性能に対する考慮が必要（特に同期転送時） 29 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ REDOログ データファイル データ保護モード REDO転送が失敗した場合にREDO生成の継続を制御 保護モード 保護モードの効果 ログ転送モード 最大保護モード データ同期化は完全保証。スタンバイ・データベー スでREDO書き込みが終わるまでcommit が完了 しない。スタンバイ・データベースがダウンするとプ ライマリ・データベースも最終的には停止して、デ ータを保護する LGWR,SYNC,AFFIRM 最大可用性モード 通常は最大保護モードと同じ動作で、スタンバイ・ データベースと通信できなくなると最大パフォーマ ンスモードに移行 スタンバイ・データベースがダウンしてもプライマ 最大パフォーマンス リ・データベースは継続稼働。 モード（デフォルト） データが転送されていない可能性がある 30 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. LGWR,SYNC,AFFIRM LGWR,ASYNC データ保護モード 最大パフォーマンスモード • プライマリ・データベースのパフォーマンスに影響しない範囲でデータ保 護を提供するモード – 非同期転送(ASYNC) • トランザクションのコミットと、スタンバイへのREDO書き込みは非同期 • ローカルのオンラインREDOログへの書き込みが行えればコミットを完了 – スタンバイ・データベースがダウンしてもプライマリ・データベースは継続稼働 31 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. データ保護モード 最大可用性モード • プライマリ・データベースの可用性に影響させないレベルで、データ保護を 提供するモード – 同期転送(SYNC) • プライマリ・データベースにアクセスできる状態ではデータロスが発生しないことを保証 • コミット前には、ローカルのオンラインREDOログと1つ以上のスタンバイREDOログに 書き込む必要あり – スタンバイREDOログに書き込めない場合（一定時間書きこめない、スタンバイ のエラー）は、一時的に再同期化モードになる • 最大パフォーマンスモードと同じ動作となる • ベストプラクティスは、二次障害が発生する前に迅速に解決すること 32 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. データ保護モード 最大保護モード • データ損失を発生させないことを保証する最高レベルの保護モード – 同期転送(SYNC) • プライマリ・データベースに障害が発生した状況でもデータロスが発生しないことを 保証 • コミット前には、ローカルのオンラインREDOログと、1つ以上のスタンバイREDOロ グに書き込む必要あり – スタンバイREDOログに書き込めない場合は、プライマリ・データベースのコミ ットが完了しない（一定時間後経過しても書き込めない場合はプライマリ・デ ータベースが安全に速やかに停止される） • ベストプラクティスは、スタンバイを2つ以上持つこと 33 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送遅延時の動作 log_archive_dest_n の属性 • NET_TIMEOUT (デフォルト30秒) – 同期転送時、LGWRがREDO転送先に送信されたREDOの確認待ちをブロッ クする時間を秒数で指定 • NET_TIMEOUTの時間、何も受信されない場合はエラーがログに記録 され、その宛先へのREDO転送セッションは終了(ORA-16198) • NET_TIMEOUT属性の指定がない場合はTCP/IPのタイムアウトまで待 機する動作となる 34 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送失敗時の動作 log_archive_dest_n の属性 • REDO転送失敗の原因 – スタンバイ・データベースがMOUNTで起動していない、リスナーが起動していな いなど • REOPEN (デフォルト300秒) – 転送処理が実行できなかった場合の再試行のタイミングを指定（秒） • MAX_FAILURE (デフォルト無制限) – 再試行の最大回数 • REDO転送失敗時、REOPEN経過後のあるログ・スイッチ時に再開される • 再試行がMAX_FAILUREに達した場合はそれ以上転送は行われない 35 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO転送サービスまとめ • 転送方式の検討 – 同期、非同期 • データの保護モード検討 – 最大保護、最大可用性、最大パフォーマンス • 転送ネットワーク – 経路の検討、チューニングの検討、圧縮の検討 • 各種属性検討 – 可用性の要件に合わせて 36 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 本日の内容 • Active Data Guard – REDO 転送サービス – REDO 適用サービス – ロール管理サービス • Recovery Manager (RMAN) • Flashback テクノロジー 37 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO適用サービス • スタンバイ・サイトに転送されたREDOの 自動適用を制御するサービス ログ バッファ • REDOの自動適用のタイミングは 設定によって変更可能 • 自動適用を行うには、管理リカバリ・モード での起動が必要 – MRP(管理リカバリ・プロセス)が 適用処理を行う – マルチコア環境では自動的に並列化 • スタンバイ側へのオブジェクト作成不可 38 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. MRP アーカイブ ログ スタンバイ REDOログ データファイル REDO適用のタイミング デフォルトの動作 • デフォルトでは、受信したREDOのアーカイブ 完了後、随時適用が開始される • 設定によってタイミングを 変更することも可能 ログ バッファ RFS – リアルタイム適用 – タイム・ディレイ適用 MRP アーカイブ ログ スタンバイ REDOログ データファイル アーカイブログから適用 39 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO適用のタイミング リアルタイム適用 • スタンバイREDOログがアーカイブされる前に適用する • 受信後すぐに適用することで常に 最新状態まで同期完了済み ログ バッファ RFS – スイッチオーバー/フェイルオーバー の高速化 – スタンバイ側で最新の情報を 検索することが可能となる • 設定はスタンバイ側で行う MRP アーカイブ ログ スタンバイ REDOログ データファイル スタンバイREDOログから適用 40 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO適用のタイミング タイム・ディレイ適用 • アーカイブ作成後、一定時間経過後に適用する方法 – タイムラグはスタンバイサイトの アーカイブログ作成完了後から 発生するため、REDO転送処理は 遅延しない – プライマリデータベースで行われた 人的ミスをスタンバイサイトに反映するのを 遅らせることが目的 • 設定はプライマリ側で行う ログ バッファ RFS MRP アーカイブ ログ スタンバイ REDOログ データファイル 一定時間経過後アーカイブログから適用 41 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. REDO適用のタイミング ギャップの自動適用 • 転送、適用に失敗したログを自動取得、適用 スタンバイ プライマリ 時間 10 10 11 ネットワーク障害 再送 12 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 11 適用失敗 12 再送 42 必要なログ を自動転送 リクエスト 13 時間 必要なログ を自動取得 リアルタイム問い合わせ 災害対策機能を維持しながら、最新の結果をスタンバイ側で検索可能 • REDOを適用をしながらスタンバイ・データベース を読み取り専用でオープン可能 ※ Active Data Guard オプション があれば使用可能 • スタンバイ・データベースとの同期状態を保ちながらスタンバイ参照可能 • 検索時に許容可能な適用ラグ（時間）を指定することでデータ品質を保証 検索・更新処理 検索処理 可能（同期転送時） NSA RFS LGWR データファイル 43 オンライン REDOログ Copyright © 2012, Oracle and/or its affiliates. All rights reserved. MRP スタンバイ REDOログ データファイル データベース は読み取り 専用でOPEN 自動ブロックメディアリカバリ Active Data Guard による透過的なブロック修復機能 Requesting Auto BMR for (file# 7, block# 261) SQL> SELECT max(c1) FROM tab1; ①SQL発行 alert ②ブロック破損 の検知 ⑥エラーなく 結果が返る ③スタンバイに正常 ブロックを要求 ⑤自動的に リカバリ ※ Active Data Guard オプション があれば使用可能 alert Waiting Auto BMR response for (file# 7, block# 261) Auto BMR successful ④スタンバイ側の正常な ブロックを自動的に転送 MAX(C1) ----------------5000 破損を自動的に修復し、エラーなく正しい結果をクライアントに返す 44 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 本日の内容 • Active Data Guard – REDO 転送サービス – REDO 適用サービス – ロール管理サービス • Recovery Manager (RMAN) • Flashback テクノロジー 45 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. ロール管理サービス ロールとは • データベースのロール – プライマリ・ロール • ログ転送サービスがプライマリデータベースからスタンバイデータベースへREDOを 転送する – スタンバイ・ロール • ログ適用サービスがスタンバイデータベースにREDOを適用する • ロールの変更方法 – スイッチオーバー – フェイルオーバー 46 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スイッチオーバー • プライマリ・データベースのメンテナンスなど、計画的に行うロール変換 – 各データベースが正常にオープン（またはマウント）されている場合に実施可能 – データ保護モードに関わらずデータ損失はゼロ – いずれのデータベースも再作成なしで、継続運用やロールをもとに戻すことが 可能 降 格 データファイル 47 昇 格 オンライン REDOログ Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ REDOログ データファイル フェイルオーバー • プライマリ・データベースの障害発生時など、計画外に行われるロール変換 – プライマリ・データベースが停止した状態で実行可能 – 最大保護モード以外は、データ損失の可能性あり – フェイルオーバー後に以前のプライマリ・データベースをData Guardに組み込む ために、スタンバイ・データベースの再作成が必要 • Flashback Database を利用することで復旧コストを削減可能 昇 格 データファイル 48 オンライン REDOログ Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ REDOログ データファイル スナップショット・スタンバイ フィジカル・スタンバイを一時的にテスト環境として利用可能 • スタンバイ・データベースを通常モードでOPENするので書き込み可能 • REDOは継続して受信可能なためデータ保護要件は確保 • テスト終了後はスタンバイに戻し、REDO適用を再開 – スタンバイへ戻す際は、内部的に Flashback Database を使用 本番用に使用 NSA 検証テストに使用 LGWR データファイル 49 テスト中もREDO オンライン を継続受信可能 REDOログ Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flash back Log RFS MRP スタンバイ REDOログ データファイル テストによる 書き込みは Flashback Log として 保存 データベース は書き込み 可能でOPEN REDO適用 は停止状態 本日の内容 • Active Data Guard • Recovery Manager (RMAN) • Flashback テクノロジー 50 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. RMANとは Oracleのバックアップ・リカバリツール • データベースのバックアップ、リストア、 リカバリおよびバックアップの管理を 行うためのクライアント・ユーティリティ • 実行方法は2種類 – OSプロンプトからRMANを起動し コマンドラインで実行 – Oracle Enterprise Manager（EM）の GUIを使用して実行 • バックアップ対象ファイル – 制御ファイル、データファイル、アーカイブログ ファイル、サーバー・パラメータファイル 51 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. $ rman target sys/password@tns名 RMAN> BACKUP DATABASE; RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; RMANの構成 Oracleインスタンスの仕組みでファイルにアクセス RMAN サーバー プロセス クライアント バックアップ先ディスク RMANの管理情報をカタログ・データベース に格納すれば、より長期のバックアップ履歴 、多くのターゲット・データベースを管理可能 ターゲット・データベース リカバリ カタログ カタログ・データベース 52 テープライブラリ リカバリ カタログ 制御 ファイル Copyright © 2012, Oracle and/or its affiliates. All rights reserved. アーカイブ ログ データ ファイル 高速リカバリ 領域 RMANを使用すると何ができるか • ホット・バックアップ・モードが不要 – Oracle インスタンスの仕組みでファイルを読む • 運用ミスを減らせる – 操作の大部分を自動化 – データベースのファイル構成が変化しても自動追尾 • バックアップ取得の影響を小さくできる、リストア/リカバリ時間を短縮可能 – Oracleの内部構造を利用するため 53 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. バックアップ、リストア、リカバリ時間を短縮 Oracleの内部構造を利用 • 増分バックアップ – バックアップファイルのサイズを小さく抑える – 頻繁にバックアップを取り、リカバリ時のREDO適用量を減らせる • 高速増分バックアップ – バックアップ取得の影響を小さく • 増分更新バックアップ – リストアを減らす 54 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. バックアップからの時間経過 生成されるREDOログ A A A A A A 更新 最後のバックアップから時間が経過する ほど生成されるREDOログも増えている ⇒ リカバリ時に適用するREDOも増える A B A A B B 更新 A B C A B C データファイル 時間 55 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 最新の状態 頻繁にバックアップを取得すれば リカバリ時間を短くできるのでは 増分バックアップ 累積と差分 A A A A A A BACKUP 更新 A B A A B B A A A A A A A A A A A A 全ブロック(レベル0) 全ブロック(レベル0) BACKUP B B B BACKUP B C B C B B B 更新 A B C A B C 累積増分バックアップ データファイル 時間 C 差分増分バックアップ • レベル0のバックアップからの増分 • 前回のバックアップからの増分 バックアップファイルのサイズを小さく抑えつつ、 リカバリ時のREDO適用量を減らす効果が期待できる 56 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. C 増分バックアップ バックアップの増分の判断 増分バックアップ B B B データベースサーバー A B A A B B データファイル A B A A B B （従来の）増分バックアップ 57 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. フルスキャンし、全データブロックの SCNを調べることで、以前のバックアップ から更新のあるデータブロックを判断 フルスキャンを行うため、 バックアップ取得時の ディスクI/Oの負担は減らない 高速増分バックアップ ブロック・チェンジ・ トラッキング・ファイル 増分バックアップ B データベースサーバー データファイル B B B 以前のバックアップから更新が発生した データブロックをビットマップで記録 B B 010011 110011 001100 110011 A B A A B B 高速増分バックアップ 58 ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'filename' REUSE; Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 更新ブロックのみを読み込むため バックアップ取得時の ディスクI/Oの負担を軽減 増分バックアップ時の読み込みブロック数 SELECT TO_CHAR( COMPLETION_TIME,'YYYY/MM/DD-HH24:MI:SS') as COMPLETION_TIME, FILE#,DATAFILE_BLOCKS,BLOCKS_READ,USED_CHANGE_TRACKING FROM V$BACKUP_DATAFILE ORDER BY COMPLETION_TIME; ブロック・チェンジ・トラッキング無効 同じ COMPLETION_TIME FILE# DATAFILE_BLOCKS BLOCKS_READ USED_CHANGE_TRACKING -------------------- ---------- --------------- ----------- -------------------2008/05/25-16:31:27 2 95528 95528 NO 2008/05/25-16:31:31 4 640 640 NO 2008/05/25-16:31:32 1 89600 89600 NO 2008/05/25-16:31:36 3 30080 30080 NO ブロック・チェンジ・トラッキング有効 減少 COMPLETION_TIME FILE# DATAFILE_BLOCKS BLOCKS_READ USED_CHANGE_TRACKING -------------------- ---------- --------------- ----------- -------------------2008/05/25-16:35:02 2 95528 245 YES 2008/05/25-16:35:06 1 89600 33 YES 2008/05/25-16:35:06 4 640 1 YES 2008/05/25-16:35:10 3 30080 191 YES 59 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 増分バックアップのリストア • データベースにリストアするとき – まずフル・バックアップをデータベースにリストア – その上に増分バックアップをリストア C B C 増分2 リストア3 B B 増分1 リストア2 フル リストア1 A A A A A A データベース 60 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. C B C 増分2 B B 増分1 A A A A A A バックアップ フル 増分バックアップのリストア 増分更新バックアップ • あらかじめ増分を適用したバックアップを作成しておく – 増分適用済みのフル・バックアップをデータベースにリストア C B C 増分2 B B 増分1 A A A A A A A B C A B C データベース 61 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. リストア フル A B C A B C 増分適用済みのバックアップ 増分バックアップのリストア あらかじめ増分バックアップを適用しておく A A A A A A BACKUP 更新 A B A A B B BACKUP B B B A A A A A A RECOVER A B A A B B RECOVER A B C A B C 増分バックアップ 更新 A B C A B C A A A A A A イメージ・コピー （全ブロックのバックアップ） BACKUP C C 増分バックアップ 差分増分バックアップ データファイル 前回のバックアップからの増分 時間 62 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 増分更新バックアップ イメージコピーに増分を適用 増分更新バックアップ (0) BACKUP AS COPY DEVICE TYPE DISK DATABASE; 0. 最初にイメージコピーを取得 (1) BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE DISK TAG ‘tag_name' DATABASE; 1. 増分バックアップ (2) RECOVER COPY OF DATABASE; 2. 増分の適用 基本的な増分バックアップ・コマンドでの手順 (1) BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG ‘tag_name' DATABASE; 1. 増分バックアップ （イメージコピーがなければ取得） (2) RECOVER COPY OF DATABASE; 2. 増分の適用 増分更新バックアップ用の構文での手順 63 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. RMAN まとめ • 増分バックアップ – バックアップファイルのサイズを小さく抑え、リカバリ時のREDO適用量を減らす • 高速増分バックアップ – バックアップ取得のI/Oへの影響を小さく • 増分更新バックアップ – 増分を適用したバックアップを用意しておき、リストア回数を減らす Active Data Guard 環境で上記すべてを行うことができる 64 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. RMANの活用例 スタンバイデータベースで増分更新バックアップ取得 フィジカル・スタンバイ・データベースを 利用してバックアップを取得することが可能 Data Guard RMAN BCT ※ BCT= Block Change Tracking File 高速リカバリ領域 本番 データベース 高速増分 バックアップ RMAN 増分更新 バックアップ ※ Active Data Guard オプションがあれば スタンバイ側で高速増分バックアップを取得可能 65 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. フルバック アップのイ メージコピー テープ装置 イメージコ ピーのバック アップ 本日の内容 • Active Data Guard • Recovery Manager (RMAN) • Flashback テクノロジー 66 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 物理障害と論理障害 • 物理障害： データベース構成ファイルの破損 – 冗長構成を取る – 定期バックアップ • 論理障害：ユーザーやアプリからの誤った変更 – 人が関わる部分のため、発生を抑えることは困難 • 「違うバッチ流してしまった」 • 「違うテーブルを DROP してしまった！」 • 「3時間前の データベースのデータを知りたい！」 発生するという前提に立って 迅速に復旧するための手順を確立しておくことが大事 67 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 論理障害からの復旧 • データベースのPoint-in-Timeリカバリ 1. バックアップ･ファイルからリストア 2. ロールフォワード • Import/Exportによるリカバリ 1. 不整合なオブジェクトの削除 2. Import 3. 処理の再実行 • Flashback によるリカバリ 1. データを取り消す 2. ロールフォワード 68 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. リカバリ時間＝ データベースのサイズやログの適 応量によって長時間になる リカバリ時間＝ 取り消すデータ量 (データベースのサイズと無関係) Flashback 機能のための設定 • データを元に戻すための「ログ」が必要 – 多くの Flashback 機能ではUNDOデータを使用 – UNDO以外の設定が必要な Flashback 機能もある 69 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flashback 機能の種類 参照系 リカバリ系 70 機能名 機能概要 使用する情報 Flashback Query 過去データの参照 UNDO情報 Flashback Version Query 指定した時間間隔のすべての変更履歴を 表示 UNDO情報 Flashback Transaction Query 一定期間ひとつのトランザクションにより行 われた変更を表示 UNDO情報 Flashback Data Archive 一定期間の履歴データを保持して参照 Flashback Archive 領域 Flashback Database データベース全体を過去の特定の時点に 復旧 Flashback Log Flashback Table 表単位でデータを特定の時点に戻す UNDO情報 Flashback Drop 表のDrop操作の取り消し 元の表の領域を残す Flashback Transaction 特定のトランザクションの取り消し REDO情報 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flashback Database によるリカバリ 迅速なリカバリを実現 • Flashback Databaseによるリカバリ方法 – Flashback Log の適用 – REDOログ及びアーカイブログの適用 • Flashback Databaseによるリカバリの特徴 – 迅速なリカバリ • Flashback Databaseはリストアを必要としないため、データファイルのサイズが増大 した場合でもリカバリ時間はほぼ変化なし • Point-in-Time リカバリに比べて適応するREDOログファイル量が少ない – リカバリ操作が簡単 • FLASHBACK DATABASE コマンドひとつで実行可能 71 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flashback Database によるリカバリ 従来のリカバリ機能と比較イメージ Point-in-Timeリカバ リの場合 バックアップファイルのリストア ロールフォワード Flashback Database によるリカバリの場合 Flashback Log の適用 72 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 時間 Flashback Database の制限 可能なオペレーションと不可能なオペレーション • FLASHBACK DATABASE コマンドでリカバリ不可能なオペレーション – 現行のデータファイルが損失/損傷した場合 • Flashback Log を適用できないため – 制御ファイルをリストア/再作成した場合 • 制御ファイルでFlashback Logを管理するため – NOLOGGING 操作実行中 • REDOログやアーカイブログが存在しないため 73 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flashback Database のための設定 1. Flashback Log モードを有効にする Flashback Log モードを有 効にしている期間 2. 保証付きリストアポイントを作成する 保証付きリストアポイントを作成した時点 時間 時間 リカバリ可能 リカバリ可能 • Flashback Log モードが有効である期間内の 任意の時点にリカバリ可能 • 有効期間内の全変更をFlashback Log として 保持（ログ量が多い） • 保証付きリストアポイントを作成した時点にのみ リカバリ可能 • 保証付きリストアポイントに戻るためだけの Flashback Log を保持（ログ量少ない） • OLTP系の処理時など、リカバリ時点を想定で きない場合に有効 • バッチ処理時など、リカバリ時点がある程度決 定している場合に有効 74 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Flashback Database の仕組み バッファ ・キャッシュ Flashback バッファ REDOログ RVWRプロセスが、データ・ブ ロックに対する変更を非同期に 取得、ファイルに書き出す A SCN#110 (09:00) SCN#120 (10:00) A B B B C ③ REDOログを使って リカバリ・ポイントまで ロールフォワード 75 C A B Copyright © 2012, Oracle and/or its affiliates. All rights reserved. SCN#110 (09:00) SCN#120 (10:00) A Flashback Log ファイル RVWR B ① FLASHBACK DATABASE TO TIMESTAMP 09:30 ②データブロックに Flashback Logを適用する 時間 Flashback Database の活用例 本番DB Data Guard プライマリ・サイトのDBサーバーの物理的 な障害（CPUやメモリ、ネットワークの障害） によって、フェイルオーバーを実施 本番DB Flashback Database を利用して 旧本番DBをフェイルオーバー時点に戻す 新本番データベースと旧本番データベース で同期を再開する 時間 本番DB スタンバイ Data Guard 迅速に耐障害性を障害発生前の状態に戻せる 76 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. スタンバイ 本番DB まとめ • Oracle Maximum Availability Architecture（MAA）を構成するために 必要な下記のテクノロジーを解説しました – Active Data Guard – Recovery Manager (RMAN) – Flashback テクノロジー 77 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 参考情報 • MAA(Oracle Maximum Availability Architecture) – http://www.oracle.com/technetwork/jp/content/maa-094615-ja.html • Oracle GRID Center – http://www.oracle.com/jp/gridcenter/index.html • OTN セミナー オンデマンドコンテンツ – http://www.oracle.com/technetwork/jp/content/index-086873-ja.html 78 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 参考情報 • 今日ご紹介した機能をご自身で体験頂けます (Oracle VM Virtual Box 仮想マシンイメージ のダウンロード) – Oracle Data Guard Basic Hands On Training • http://www.oracle.com/technetwork/jp/serverstorage/virtualbox/community/basic-dg-handson-webpage-1413406-ja.html – 壊して体感する！Oracle Data Guard による障害復旧対応ハンズオン • http://www.oracle.com/technetwork/jp/server-storage/virtualbox/community/ddddg-handson-webpage-1413408-ja.html 79 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. ご質問・ご相談はOpenWorld終了後もお受けしております あなたにいちばん近いオラクル Oracle Direct 0120-155-096 （平日9:00-12:00 / 13:00-18:00） http://www.oracle.com/jp/direct/index.html Oracle Direct 検索 各種無償支援サービスもございます。 80 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 81 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. 82 Copyright © 2012, Oracle and/or its affiliates. All rights reserved.