Microsoft Word - OracleDatabase10gAutomatic_j080421_r3.doc

Transcription

1 日立ディスクアレイディスクアレイのレプリケーションレプリケーション機能機能と Oracle 10g Automatic Storage Management を使ったったバックアップバックアップ リカバリリカバリのベストプラクティス 株式会社日立製作所 SAN ソリューション事業部斉藤聡史株式会社日立製作所 SAN ソリューション事業部渡辺孝 Todd Hanson, Hitachi Data Systems; and Nitin Vengurlekar, Oracle Corporation

2 要旨 今日のエンタープライズは 品質や費用効率の高いよいバックアップソリューションを探求している この問題に答えるべく 日立製作所と日立データシステムズは Hitachi Universal Storage Platform V と Oracle Database のバックアップシステムの最適化を目指し Oracle Database ファイルの管理を簡略化するために Oracle10g からサポートされた機能 Automatic Storage Management(ASM) 環境をターゲットに実機でテストを実施し 結果から本ベストプラクティスをまとめた AMS は Oracle Database の標準機能のため 追加費用なく Oracle のクラスタボリューム管理とファイルシステム機能を提供する AMS により ストレージの利用効率 性能 可用性を上昇させ サードパーティ製のクラスタボリューム管理やファイルシステム機能の必要性が減少する 結果 例えばデータセンタでのコスト削減がされる ASM を業界トップの Hitachi Universal Storage Platform V(USP V) で使う事で 最高レベルのデータファイルのオートメーション性能 複雑性の削減 性能の向上が得られることが実証されている USP V はストレージ統合 仮想化 ストレージ管理のシンプル化において高い価値を提供する 同時に ASM と USP V は強固で高信頼なデータベース 堅実なバックアップやディザスタリカバリ そして充実な管理方法を提供する 2

3 目次 序論 日立ストレージ HITACHI STORAGE SOLUTIONS シリーズで ORACLE ASM を使うには...7 ストレージ側の設定 ( 共有ボリュームの設定 )... 7 HITACHI DYNAMIC LINK MANAGER の概要... 7 HITACHI SHADOWIMAGE の概要... 7 HITACHI TRUECOPY ASYNCHRONOUS と HITACHI UNIVERSAL REPLICATOR の概要... 8 POINT-IN-TIME コピー用のコンシステンシーグループと AT-TIME スプリットオプション... 8 ASM ディスクグループとペアグループ ( コンシステンシーグループ )... 9 ASM の基本的な操作方法 SHADOWIMAGE の設定方法 ペアグループについて ペアグループの操作 RAID MANAGER コマンド説明 SHADOWIMAGE / TRUECOPY / UR を使った ASM バックアップ リカバリ...13 バックアップ概要 ORACLE 10G と ORACLE 9I の比較 コールドバックアップの事前注意事項 ホットバックアップの事前注意事項 データタイプごとのバックアップ要件 リカバリの概要 シナリオ1:SHADOWIMAGE を使った ORACLE DATABASE 10G ASM のバックアップ シナリオ2:SHADOWIMAGE を使った ORACLE 10G ASM のリカバリ シナリオ3:SHADOWIMAGE を使った ORACLE10G ASM のクローニング シナリオ4:SHADOWIMAGE を使った ORACLE10G のコールドバックアップ 別表 A: RMAN リカバリカタログガイドライン 別表 B: TNSNAMES.ORA 構成ファイルファイルの例 別表 C: SHADOWIMAGE の構成定義構成定義ファイルファイルの例 別表 D: 初期化パラメータファイルパラメータファイルの例

4 日立ディスクアレイディスクアレイのレプリケーションレプリケーション機能機能と Oracle 10g Automatic Storage Management を使ったったバックアップバックアップ リカバリリカバリのベストプラクティス 株式会社日立製作所 SANソリューション事業部斉藤聡史株式会社日立製作所 SANソリューション事業部渡辺孝 Todd Hanson, Hitachi Data Systems Oracle Corporation Nitin Vengurlekar 序論 本書では Automatic Storage Management(ASM) 環境での Oracle のバックアップ リカバリについて 日立のレプリケーション技術と組み合わせたときのベストプラクティスを記載する ASM は エンタープライズ IT 企業のために Oracle Database をストレージや管理タスクを簡素化する 日立製作所と日立データシステムズは 最新の Hitachi Storage Solutions(HSS) シリーズのストレージを ASM 環境で使うことは最も実用的であることを実機検証し 本ベストプラクティスを導き出した このベストプラクティスは 日立ストレージと ASM 環境における 高い費用効率 高品質バックアップ DB クローニング リカバリソリューションを探るのを支援する 日立製作所は ヘテロジニアスレプリケーション対応の筐体内 Point-in-Time コピー (Hitachi ShadowImage ) や リモートレプリケーション (Hitachi TrueCopy Synchronous/TrueCopy Asynchronous/Universal Replicator) を提供する また 業務サイトのデータ保護に加え レプリケーション機能同士を組み合わせることで ディザスタリカバリやゼロタイムロスなど高度なビジネス継続性を提供できる Oracle ASM のバックアップ リカバリ方法は 従来のファイルシステムでのバックアップ リカバリ方法と 同じ概念で運用できる しかし 本書で述べているように全く異なる手順や設定方法があるため DBA の方々 には参考にして頂きたい 4

5 日立ディスクアレイサブシステムの高性能 / 高信頼性ボリュームレプリケーション機能 (Hitachi ShadowImage TrueCopy Synchronous TrueCopy Asynchronous Universal Replicator) を使用した Point-in-Time コピーは 高速にデータのコピーを生成する 本書では Oracle Database ASM 環境を ShadowImage や TrueCopy を使ってどのように運用するかについて 以下の 3 点に絞って説明している データベースのバックアップ データベースのリカバリ データベースのクローニング ( バッチ処理 移行検証 開発用途 ) Hitachi Storage Solutions のハードウェアによるレプリケーションは ストレージからサーバへの転送が なくストレージ内で処理されるため サーバベースより効率的である 加えて ストレージによるレプリケ ーションが集中管理化を促進し データ保護に掛かるコスト増加を抑えるのに役立つ Oracle Database には フラッシュバックデータベース (Flashback Database) と呼ばれる Point-in-Time コピー機能がリカバリのために Oracle10g から組み込まれている Oracle フラッシュバックデータベースは 高速な Oracle のリカバリと 論理的なデータ破壊またはユーザエラーが発生した時刻を特定できる 時刻を指定したロールバックでデータベースはエラーが発生する前の状態にリストアが可能である その後 選択的に適用していける 日立のレプリケーション製品は コンシステンシーグループ テクノロジによって Oracle Database 10g/11g ASM のスプリットミラーガイドライン要件を満たしている このため ASM 環境のデータベースを整合性が保 たれた有効な状態のコピーが作成可能である 各 ASMディスクグループに含まれる全 LUでPoint-in-Timeスプリットコピーを生成でき 各 LUのスプリット実施が同じ時刻であること 各 ASMディスクグループに含まれる全 LUが書き込み完了を守りアトミック (atomic) にスプリットされ 書き込み順序性が保たれること データ表領域とアーカイブログはそれぞれ別のASMディスクグループにあること ( レプリケーションを作るタイミングが異なるため ) DATADGディスクグループはデータ表領域を含む FLASHDGディスクグループはアーカイブログ 制御ファイル フラッシュバックログを含む REDODGディスクグループはREDOログファイルを含む ( 通常はバックアップしないため分ける ) 日立レプリケーション機能のペアグループには ASMディスクグループの全ボリュームを含むこと バックアップサーバには 業務サーバと同様なオペレーティングシステム (OS) 環境があり 適切な Oracleバイナリや初期化パラメータファイル パスワードファイル ユーザID/ グループがあること バックアップホストは 適したオペレーションシステム (OS) 環境 Oracle バイナリ 初期化パラメータファイル / パスワードファイル ディレクトリ ユーザ名 / グループ名で構成されていること バックアップサーバは Oracle Recovery Manager(RMAN) のリカバリカタログに接続するための設定が設定されている事こと ASM は サーボパーティ製のボリュームマネージャやクラスタファイルシステムと比較して データファイ ル自動化のための優れた機能 複雑性の軽減 向上した性能を提供する 業界最高の Hitachi Universal Storage Platform V はストレージ統合 仮想化 ストレージ管理のシンプル化において高い価値を提供する Oracle と USP V の業界最高レベルの両プラットフォームが共に結集することで 最高のシステムが実現する USP V が持つ高度なボリューム製品によるパフォーマンスの最適化やシームレスなバックアップによって ASM を完全に補完する 同時に ASM と USP V は強固で高信頼なデータベース 堅実なバックアップやディザ 5

6 スタリカバリ そして充実な管理方法を提供する 本書では ASM と USP V を組み合わせたときのベストプラクティスを紹介している 通常 ベストプラクテ ィスは ASM または USP V 固有のものになりがちで 組み合わせると変更が必要になったり全く使えなくなっ たりすることがある 本書では その点にも注意して記載している 本書では 便宜上 最新の最高性能で主力製品である Hitachi Universal Storage Platform V (USP V) を 取り上げて記載しているが アーキテクチャ ユーザビリティなどが同じため 以下の製品についても同じ 方法でバックアップ リカバリ クローニングが可能である Hitachi Universal Storage Platform V (USP V) Hitachi Universal Storage Platform VM (USP VM) Hitachi Adaptable Modular Storage (AMS) Hitachi Workgroup Modular Storage (WMS) Hitachi Tape Modular Storage (TMS) Hitachi Universal Storage Platform (USP) Hitachi Network Storage Controller (NSC) 6

7 日立ストレージ Hitachi Storage Solutions シリーズで Oracle ASM を使うには ストレージ側の設定 ( 共有ボリュームの設定 ) 共有ボリュームは Real Application Cluster (RAC) データベースを構築するときに必要である OS プラットフォームにボリュームを認識させる設定をすればよく 共有ボリュームへの設定をする以外に特定の設定はない 共有させるためにはボリュームを複数のサーバから認識させる また サーバからボリュームへのパスを複数定義するのにパス冗長化ソフト Hitachi Dynamic Link Manager を使う Hitachi Dynamic Link Manager の概要 Hitachi Dynamic Link Manager (HDLM) はストレージシステムへのアクセスパスを管理する HDLM を使用することで パスに障害が出た場合にアクセスパスを他のパスへフェールオーバーする機能を提供し システムの可用性と信頼性を向上させる HDLM には以下の機能がある : ロードバランシグ (load balancing) 複数のアクセスパスがホストからストレージシステムに接続しているとき HDLM は複数のアクセスパスを使って負荷分散する これは 特定のアクセスパスにデータアクセスが大量に集中することを回避する 障害発生発生でもでもプロセスプロセスを継続継続する (failover) 複数のアクセスパスがホストからストレージシステムに接続しているとき 使用中のアクセスパスに障害が発生すると HDLM によって自動的に他のアクセスパスへ切り替わる 障害に影響されずにプロセスを継続できる エラーからからリカバリリカバリされたされたオンラインパスオンラインパスをおくことがをおくことが可能可能である (failback) ack) 障害からパスを回復するとアクセスパスをオンラインにする 通常 障害があったアクセスパスを回復するタイミングは管理者が業務への影響が小さい時間帯に行うため フェイルバックは手動で行うが フェイルバックを自動で行うことも可能である automatic failback を有効にすると ユーザが物理経路の問題を解決した後に自動的に HDLM がパスを有効化する 常時インターバルインターバルでパスステータスパスステータスを自動自動で確認 (path health checking) HDLM はユーザが定義した時間間隔でアクセスパスのステータスを確認することで 障害を検出できる 既存のパスエラーを確認し 適宜にそれを解決することが可能である Linux では LUN へのそれぞれのパスは /dev/sda /dev/sdb などのデバイス名が割り当てられる HDLM は 同じ LUN へのパスをみつけ /dev/sddlmaa などの共通 HDLM 名を割り当てる Linux の HDLM デバイスフォーマットは /dev/sddlm[a-p][a-p][1-15] である HDLM デバイスパーティションは sddlm*name の後の数で表される 全デバイスは指定の数なしで表される アクティブな HDLM ロードバランシングとパスフェイルオーバー機能の HDLM デバイス名を使用しなければならない 更なる情報に関しては 各 OS プラットフォームの HDLM ユーザーズガイドをご参照のこと Hitachi ShadowImage の概要 ShadowImage は ストレージシステム内の RAID ボリュームや Hitachi Universal Volume Manager を使用して仮想化接続されている外部ストレージのボリュームで使用可能な ストレージによるボリュームレプリ 7

8 ケーション機能である ShadowImage の正ボリューム (P-VOL) は 9 つまで副ボリューム (S-VOL) を生成可能である ShadowImage のレプリケーション機能は 業務サーバからの I/O 操作を止めることなく実施可能である 更に ShadowImage ボリュームはオンラインバックアップ時のアプリケーション要求に対応するために At-time スプリットオプションを実装しており これによりコンシステンシーグループを使った柔軟なバックアップを可能としている Hitachi TrueCopy Asynchronous と Hitachi Universal Replicator の概要 Hitachi TrueCopy Synchronous(TC) と TrueCopy Asynchronous(TCA) Universal Replicator(UR) はリモートコピーを可能とする機能である これらは プライマリサイトのボリュームに対し読み出し / 書き込みの I/O を継続しながらリモートコピーを行うことができる TCA や UR はセカンダリサイトへ非同期でコピーするが 障害が発生してもアプリケーションが書き込み途中のデータを保護するため 書き込み順序性 (write ordering) を保つ 書き込み順序性はコンシステンシーグループごとに保たれる TCA と UR の大きな違いは書き込み情報の格納先の違いである TCA は限られたキャッシュメモリに格納し UR は広大なジャーナルボリュームに格納する TCA や UR は 運用に合わせさまざまなリカバリオプションを提供するため 例えば ShadowImage と連携した構成をとる事が出来る Point-in-Time コピー用のコンシステンシーグループと At-Time スプリットオプション コンシステンシーグループは ShadowImage ペアグループに At-time スプリットオプションを適用する事で作 成できる コンシステンシーグループを使ってペア分割することで Point-in-Time コピーを作成可能であ る ペア分割コマンドが サーバから USP V に RAID Manager を介して行われるとき 同じコンシステンシー グループに含まれる全ての LU は同時に且つアトミック (atomic) にペア分割され S-VOL( 副ボリューム ) のデ ータを確定する S-VOL の内容は ペア分割操作が実行されたときの P-VOL( 正ボリューム ) と同じである コンシステンシーグループは 128 グループまで作成できる コンシステンシーグループ内に 合計 4096 ペアまで ShadowImage ペアを作成できる その他 ShadowImage の詳細な説明や TrueCopy Asynchronous や Universal Replicator についてはそれぞれのユーザーズガイドで確認できる 8

9 ASM ディスクグループとペアグループ ( コンシステンシーグループ ) ASMディスクグループとShadowImageペアグループの対応を表 1に示す 表 1. 3 ディスクグループ構成時構成時の配置 ASM ディスクグループ ShadowImage ペアグループ 用途 ( コンシステンシーグループ ) DATADG DATADG システム表領域 SYSAUX 表領域 UNDO 表領域ユーザ表領域 TEMP 表領域サーバパラメータファイル (spfile spfile) その他の表領域制御ファイル 1 FLASHDG FLASHDG アーカイブログファイルカイブログファイルカイブログカイブログ領域 ( アーカイブログファイル ) Flashback リカバリ領域制御ファイル 2 REDODG REDODG ノード 1 メンバ 1 グループ 1 REDO ログファイル 1~3 ノード 2 メンバ 1 グループ 1 REDO ログファイル 1~3 9

10 ASM の基本的な操作方法 ASM インスタンス起動起動と停止 ASM インスタンスはsrvctlコマンドで起動や停止する このコマンドはどのノードからも実行可能である ASM インスタンスの起動 : $ srvctl start asm -n nodename1 $ srvctl start asm -n nodename2 ASM インスタンスの停止 : $ srvctl stop asm -n nodename1 $ srvctl stop asm -n nodename2 また シングルインスタンスの場合 通常のデータベースインスタンスと同様に SID 環境変数に +ASM を設定して起動 停止を行う ASM インスタンスの起動 ( シングルインスタンス ): $ export ORACLE_SID=+ASM $ sqlplus / as sysdba SQL> startup ASM インスタンスの起動停止 ( シングルインスタンス ): $ export ORACLE_SID=+ASM $ sqlplus / as sysdba SQL> shutdown ASM インスタンスの状態状態を確認 ASM インスタンスが起動しているかどうかは crs_stat コマンドで知ることができる $ crs_stat -t t Name Type Target State Host 通常のDB インスタンスと同様の方法で ASM インスタンスの状態も知ることができる SQL> select instance_name, status from v$instance; 注意 :ASM インスタンスは OPEN にならない MOUNT 状態が通常稼動状態である 10

11 ShadowImage の設定方法 ペアグループについて ShadowImage でのバックアップはペアグループと呼ばれる単位で行う また Point-in-Time コピーを行う場 合は このペアグループがコンシステンシーグループになる ペアグループは構成定義ファイル (horcm.conf) を使って設定する 例えば 3ディスクグループ構成 ( データ表領域の DATADG とアーカイブログ領域の FLASHDG REDO ログファイルの REDODG の3つ ) の場合 バックアップが必要なディスクグループは DATADG と FLASHDG であるが この2つのディスクグループをペアグループと一致させる必要がある また ディスクグループに LU 追加または削除する場合は ペアグループの設定も変更する ペアグループの操作 ShadowImage または TrueCopy のペアグループを操作するインターフェースは RAID Manager と呼ばれる CLI またはストレージ管理ソフト Storage Navigator と呼ばれる GUI がある ( 以下 RAID Manager について説明する ) RAID Manager はサーバ上で動作するソフトウェアである サーバにコマンドデバイス (CMD) という特殊な LU を認識させておく事で CMD を介してボリュームを複製したり ペア状態を取得したりする RAID Manager を使うためには 2つのインスタンスを起動させておく必要がある このため構成定義ファイルも2つ必要である 参考までに構成定義ファイル (horcm.conf) の記述例を本書巻末の別表 Cに載せた ( 更なる詳細情報については RAID Manager のマニュアルを参照 ) インスタンス起動の例 ( インスタンス0と1を起動 ): # horcmstart.sh 0 1 一度構成定義ファイルを定義しそのインスタンスが開始すると ShadowImage ペアを作成する準備が整う ペアの作成は paircreate コマンドを使う paircreate コマンドの主なオプションは次の通りである -g オプションは ペアグループ名を指定している -vl オプションは コピーの方向を示す 通常はこれを使う -m grp オプションは ペアグループをコンシステンシーグループとして作成することを指定している ASM 環境ではではペアペアを作成作成するする際 ペアグループペアグループをコンシステンシーグループコンシステンシーグループとしてとして作成作成するする必要必要があるのでがあるので Point-in in-time オプション (-m grp) を付けるける ShadowImage コンシステンシーグループ作成の例 : # paircreate -g DATADG vl m grp # paircreate -g FLASHDG vl m grp 通常 ディスクグループには複数のボリューム (LU) が含まれているが Point-in-Time オプションを付けコンシステンシーグループにする事で ボリューム同士の整合性 (consistency) を保ったまま あたかも 1 つのボリュームかのようにタイミングのずれもなくペア分割することが可能となる Point-in-Time オプションを付けないでペア生成を行った場合 ペア分割する際 各ボリュームのペア分割タイミングにばらつきが出るため 整合性を保てなくなる恐れがある 不整合となってしまったコピーはリカバリに使用できない また 不整合かどうかはリカバリするまで分からない 11

12 Point-in-Time コピーの例 ( コンシステンシーグループ ): # pairsplit -g DATADG # pairsplit -g FLASHDG ペア状態の遷移を確認するには pairevtwait コマンドを使う pairevtwait コマンドの主なオプションは以下の通りである -g オプションは ペアグループ名を指定する -s オプションは 遷移先のペア状態を指定する -t オプションは 秒単位で状態遷移待ち時間 ( タイムアウト ) を指定する サスペンド状態 (PSUS) を確認する例 : # pairevtwait g DATADG s psus t 3600 # pairevtwait g FLASHDG s psus t 3600 RAID Manager コマンド説明 表 2 に基本的な RAID Manager のペア操作コマンドとその機能を示す 表 2. ペアコマンドコマンド名 paircreate pairsplit pairresync pairresync -restore pairsplit S pairevtwait pairdisplay 説明新規にペアペアを生成生成するする 一時的にペアペアを分割分割し 副ボリュームボリュームへのへの更新更新を停止停止させるさせることでことで副ボリュームにバックアップバックアップを作成作成するする 正副正副ボリュームボリュームのペアペア関係関係は維持維持されされ 差分情 報も保持保持されされる ペアサスペンド状態状態からからペアペア再同期再同期するする 差分情報差分情報を使ってって高速高速に再同期再同期しペア状態状態にするにする 差分情報差分情報がないがない場合場合は使えないえない ペアサスペンド状態状態からからペアペアを逆方向逆方向に再同期再同期させさせ バックアップデータバックアップデータのリストアを行う 差分情報差分情報を使ってって高速高速にリストアリストアされるされる 通常通常 リストアリストア後にペアサスペンドさせるさせる ペアの差分情報差分情報を破棄破棄しペアペアを削除削除するする 再度再度 ペアペア状態状態にするにはにするには ペアペア生成をやりをやり直す必要必要があるがある 指定したしたペアペア状態状態になるまでになるまで待ち続け プロンプトプロンプトに返らないらない 確実確実なペアペア状態遷移を実現実現させるためにさせるために使用使用するする ペア状態状態やペアペア進捗率進捗率などをなどを確認確認するする 補足ペア生成 (SMPL SMPL PAIR PAIR) ペア分割 / ペアサスペンド (PAIR/COPY PAIR/COPY PSUS PSUS) ペア再同期 (PSUS PSUS PAIR PAIR) ペアリストア ペア削除 (PAIR/COPY/PSUS PAIR/COPY/PSUS SMPL SMPL) pairvolchk Point-in in-time オプション ( コンシステンシーグループの設定 ) の有無有無を確認確認する 12

13 ShadowImage / TrueCopy / UR を使った ASM バックアップ リカバリ バックアップの概要 シナリオ1では ShadowImage を使って稼働中の業務サーバをテープバックアップする方法について述べる また シナリオ3では セカンダリサーバでデータベース クローニングのテクニックを述べる このクローニングはデータベースのバックアップにも適用できる Oracle 10g と Oracle 9i の比較 Oracle10g と Oracle9i のバックアップ手順の違いは主に 2 つある 1 つ目は コンシステンシーグループへの意識を要すること 2 つ目は データベースインスタンスだけでなく ASM インスタンスの挙動にも気をつけなければならないことである ホットバックアップ手順手順のフローチャート図 1にホットバックアップ手順のフローチャートを示す 図 1. ホットバックアップ手順のフローチャート RAID Manager SQL*Plus RMAN バックアップ処理の開始 ASM のリバランスの確認 データ表領域 アーカイブログ領域のペアの再同期 (PSUS PAIR) ログスイッチ (REDO ログ アーカイブログ ) バックアップモード開始 (begin backup) データ表領域のバックアップ (PAIR PSUS) バックアップモード終了 (end backup) ログスイッチ (REDO ログ アーカイブログ ) 制御ファイルのバックアップ アーカイブログ領域のバックアップ (PAIR PSUS) 不要なアーカイブログの削除 バックアップ処理の完了 13

14 コールドバックアップの事前注意事項 コールドバックアップを行うときは データベースインスタンスだけでなく ASM インスタンスもあるので併 せて停止させる ホットバックアップの事前注意事項 ホットバックアップを行うときは ペアを作成する際に Point-in-time オプションをつけること ASM 環境下でのホットバックアップは ペアに付加されている Point-in-time オプションが必要になる ペア分割によるバックアップが Point-in-time オプションなしで行われると ディスクグループ内のボリューム間の整合性が保たれない 無効なデータとなるリスクがある 結果 ホットバックアップは本番側データベースの有効なコピーができない データタイプごとのバックアップ要件データ表領域 Oracle9i 以前では 全ての表領域を 1 つずつバックアップモードにしなければならなかった これは 例えば表領域を新たに追加するだけで ホットバックアップスクリプトをメンテナンスしなければならないことを意味する Oracle10g からは データベースを 1 つのコマンドでバックアップモードにできるようになった これによりバックアップが簡素化された バックアップモードの開始 : SQL> alter database begin backup; バックアップモードの終了 : SQL> alter database end backup; 制御ファイル制御ファイルは Oracle Recovery Manager(RMAN) または SQL*Plus を使ってバックアップする コマンドは以下である RMAN> run { allocate channel ctl_file type disk; copy current controlfile to +FLASHDG/control_file/con +FLASHDG/control_file/control_start trol_start ; copy current controlfile to +FLASHDG/control_file/control_bakup +FLASHDG/control_file/control_bakup ; release channel ctl_file; } 制御ファイルは データ表領域をバックアップした後の状態をバックアップする必要があるため このように個別に取得する サーバパラメータファイル (spfile spfile) サーバパラメータファイルは ShadowImage などでバックアップできるため データ表領域などと一緒にバックアップできる ここでは サーバパラメータファイルを DATADG に配置しているため DATADG のバックアップ時に一緒にバックアップされる 14

15 REDO ログファイル REDOログファイルは ShadowImageでバックアップできないため対象にしない リカバリに必要なので REDO ログファイルをバックアップする際は 'alter system archive log current' を使ってアーカイブログ領域にコピーしておく ( アーカイブログ領域のバックアップは次に述べる ) アーカイブログファイル ( アーカイブログ領域 ) 従来ファイルシステム上に生成されていたアーカイブログファイルは ASM 環境では ASM ディスクグループ上に生成される アーカイブログ領域にはバックアップモードがないため アーカイブログファイルの生成中にバックアップを行うことは 無効なアーカイブログの取得になりかねない このため ShadowImage でバックアップ (pair split) する際は 先に 'alter system archive log current' によって強制的に全ノードでアーカイブログファイルを生成させ 完了したことを確認しておく アーカイブログファイルの生成の完了は 各ノードのデータベースインスタンスのアラートログを見て確認できる バックアップが完了したら 必要なくなった古いアーカイブログは削除することができる 古くなったくなったアーカイブログアーカイブログの削除方法生成されてから 2 週間が過ぎたアーカイブログファイルを全て削除する方法は以下の通り RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-14'; 15

16 リカバリの概要シナリオ2では シナリオ1で取得したバックアップを業務サーバへのリカバリする方法について述べる リカバリ手順手順のフローチャート図 2にリカバリ手順を示す 注意 :ASM インスタンスが起動している間にリストアしてしまうと ASM ディスクグループは破壊されること があるので ASM インスタンスを停止または ASM ディスクグループのマウントを解除してから進めること 図 2. リカバリ手順のフローチャート RAID Manager SQL*Plus RMAN リカバリ処理の開始 制御ファイルのバックアップ データベースインスタンスの停止 ASM インスタンスの停止 データ表領域のリストア ( リストアが完了したら ) ペアをサスペンドにする (PAIR PSUS) アーカイブログ領域のリストア 内は必要に応じて実施する ( リストアが完了したら ) ペアをサスペンドにする (PAIR PSUS) ASM インスタンスの起動 データベースインスタンスを MOUNT 制御ファイルのリストア データベースインスタンスの停止 データベースインスタンスを MOUNT メディアリカバリ (recover database) データベースインスタンスを OPEN 一時表領域などを追加 データベースインスタンスを再起動 リカバリ処理の完了 16

17 シナリオ 1:ShadowImage を使った Oracle Database 10g ASM のバックアップ この手順では 業務サーバ上で稼動している Oracle Database 10g ASM をホットバックアップモードに変更し ShadowImage を使って短時間且つボリューム間の整合性を保ったまま At-time スプリットコピーで副ボリューム (S-VOL) を作成し バックアップサーバで RMAN を使って S-VOL からテープにバックアップするものである ShadowImage を使ったコピーは 業務サーバやデータベースへの影響を与えることなく バックアップが可能である この例では 最小構成の 3 つの ASM ディスクグループ環境 (DATADG FLASHDG REDODG) を使っている また ShadowImage は常時サスペンド方式を使用する 業務サーバサーバにて (S-VOL の作成 ) まだ ShadowImage のコンシステンシーグループのペアを作成していなければここで作成する (paircreate) 作成後ペアはサスペンド (pairsplit) させておく # paircreate g g DATADG vl m grp # paircreate g g FLASHDG vl m m grp # pairsplit g g DATADG # pairsplit g g FLASHDG 既に作成されていれば ペアがペア状態 (PAIR) でなければペア再同期 (pairresync) をする # pairresync g g DATADG # pairresync g g FLASHDG ペア状態 (PAIR) になったことを確認する # pairevtwait g g DATADG s s pair t t 9999 # pairevtwait g g FLASHDG s s pair t t 9999 バックアップ中にログスイッチが発生しないようにするため ログスイッチを行う SQL> alter system archive log current; 業務サーバの Oracle をバックアップモードにする (begin backup) SQL> alter database begin backup; DATADG をペア分割する (pairsplit) コンシステンシーグループを使って作成されているため ペアは整合性を保ったまま分割される # pairsplit g DATADG サスペンド状態 (PSUS) になったことを確認する # pairevtwait g DATADG s psus t t 9999 Oracle のバックアップモードを終了する (end backup) SQL> alter database end backup; 17

18 ログスイッチを行う SQL> alter system archive log current; 制御ファイルのバックアップを2つ作成する 1つは (control_start) バックアップサーバで Oracle を MOUNT 状態にするのに使い もう1つは テープにバックアップするのに使う Oracle を MOUNT すると制御ファイルが変更されてしまうため 変更されていない制御ファイルが必要なためである RMAN> run { allocate channel ctl_file type disk; copy current controlfile olfile to +FLASHDG/control_file/control_start +FLASHDG/control_file/control_start ; copy current controlfile to +FLASHDG/control_file/control_bakup +FLASHDG/control_file/control_bakup ; release channel ctl_file; } バックアップ情報をリカバリカタログに記憶させる こうすることで RMAN に最新のアーカイブログを記憶させる RMAN> resync catalog; 最新のアーカイブログを持った FLASHDG をペア分割する # pairsplit g FLASHDG サスペンド状態 (PSUS) になったことを確認する # pairevtwait g FLASHDG s psus t t 9999 不要になったになったアーカイブログファイルアーカイブログファイルの削除不要になったアーカイブログファイルを削除する ここでは 二週間以上前に作成されたアーカイブログファイルを全て削除する $ export ORACLE_SID=db10asm $ rman target / nocatalog RMAN> delete archivelog all completed before 'SYSDATE-14'; 以上で業務サーバ側の処理は完了である 18

19 バックアップサーバにて (S-VOL からテープテープにバックアップ ) バックアップサーバは ShadowImage で複製された S-VOL を使うことができる まず ASM インスタンスを起動する 作成した S-VOL をバックアップサーバに認識させると raw デバイス名や HDLM 名が再度つけられるため変更されてしまう事があるが ASM インスタンスは業務サーバと異なるデバイス名でも ASM ディスクグループを見つけようとする Oracle ASM は これらの候補ボリュームから正しいディスクグループを識別し マウントできる $ export ORACLE_SID=+ASM $ sqlplus /as sysdba SQL> startup バックアップサーバの S-VOL を使ってデータベースを起動させる RMAN バックアップについては以下に述べる 以下の例では バックアップサーバ上のデータベースを RMAN でバックアップする方法である スタートアップ制御ファイル (control_start) を使ってデータベースを MOUNT する 次に バックアップ制御ファイル (control_bakup) を RMAN バックアップの一部としてバックアップする init.ora file control_files = +FLASHDG/control_file/control_start バックアップサーバでデータベースインスタンスを MOUNT する : $ export ORACLE_SID=db10asm $ sqlplus /as sysdba SQL> startup mount RMAN を使ってバックアップを実施する : RMAN> run { allocate channel t1 type sbt_tape backup format ctl %d/%s/%p/%t controlfilecopy +FLASHDG/control_file/control_bakup +FLASHDG/control_file/control_bakup ; backup full format al %d/%s/%p/%t (archive all); release channel t1 } 19

20 シナリオ 2:ShadowImage を使った Oracle 10g ASM のリカバリ 前項でのホットバックアップを使って ShadowImage は取得したデータを高速にリストアするリカバリ方法 を提供する 差分ビットマップによって変更ブロックは管理され 必要最小限のデータのみがプライマリ LU にリストアされるため ダウンタイムは最小化される データファイルをリストアした後 アーカイブログでデータベースのインスタンスリカバリを実施する 業務サーバに残っている REDO ログファイル (REDODG) やアーカイブログ (FLASHDG) をリストアなどでリストアする際は注意する REDODG や FLASHDG には 障害が起こる直前までにコミットされたトランザクションを含むため 完全リカバリできなくなる可能性がある もし REDODG が破損してしまったら ディスクグループを再作成し データベースを RESETLOGS で OPEN する FALSHDG が破損してしまったら ShadowImage でバックアップしたディスクグループをリストアできる もしシャットダウンされていなければ 業務サーバ上のデータベースインスタンスをシャットダウンする : $ export ORACLE_SID=db10asm $ sqlplus /as sysdba SQL> shutdown ShadowImage でディスクグループをリストアするため ASM インスタンスをシャットダウンする もし 他のデータベースが稼動していて ASM インスタンスをシャットダウンできない場合は リストアするデータベースだけが使用している全てのディスクグループを DISMOUNT する $ export ORACLE_SID=+ASM $ sqlplus /as sysdba SQL> shutdown または SQL> alter diskgroup DATADG dismount; ペアリストア (pairresync -restore) を実施する サスペンド状態 (PSUS) からペア状態 (PAIR) になる # pairresync g DATADG D restore ペア状態 (PAIR) になったことを確認する # pairevtwait g DATADG s pair t t 9999 ペア状態 (PAIR) のままだと副ボリュームの内容が変更される恐れがあるので ペアをサスペンド状態 (PSUS) にする # pairsplit g DATADG サスペンド状態 (PSUS) になったことを確認する # pairevtwait g DATADG s psus t t 9999 AMS インスタンスが起動していない場合は起動 (startup) する ディスクグループが MOUNT されていない場合は MOUNT する $ export ORACLE_SID=+ASM $ sqlplus /as sysdba SQL> startup 20

21 または SQL> alter diskgroup DATADG mount; 業務サーバにリストアしたデータベースを MOUNT で起動する 完全リカバリまたは不完全リカバリ (Point-in-time リカバリ ) を選択する Point-in-time リカバリは "until SCN" または "until time" で指定できる $ RMAN> run { recover database; } または $ RMAN run { set until time may may-06 15:30 ; recover database; } データベースを起動 (OPEN) する $ RMAN> alter database open; 不完全リカバリや制御ファイルを再作成した場合は データベースを RESETLOGS で起動 (OPEN) する RESETLOGS を実施した場合 通常はバックアップを取得してから業務を再開する $ RMAN> alter database open resetlogs; シナリオ 3:ShadowImage を使った Oracle10g ASM のクローニング ここでの手順は ホットバックアップモードを使わずに Oracle10g ASM データベースのクローンを作成するものである Point-in-Time コピーと呼ばれることもある このコピーは 例えば 本番業務と全く同じデータベースを他のサーバの開発環境の構築に使用可能である クローンを作成するために ShadowImage グループには データファイル 制御ファイル REDO ログファイル Flashback ログファイルが含まれている必要がある この データベースのクローニングは ShadowImage のコンシステント At-Time スプリット機能を使って作成する PAIR 状態から開始する 必要に応じてペア生成 (paircreate) またはペア再同期 (pairresync) する # paircreate g SIALLDB vl m m grp または # pairresync g SIALLDB ペアスプリットする ペアグループは コンシステンシーグループで作られているため整合性を保ったままのスプリットとなる # pairsplit g SIALLDB 21

22 ペアがサスペンド状態 (PSUS) であることを確認する # pairevtwait g SIALLDB s psus t t 9999 テストサーバでASMインスタンスを起動する テストサーバ上の ShadowImage の副ボリュームに対し 正しくパーミッションを設定されているか ASM_DISKSTRING や ASM_DISKGROUPS の指定が正しいかを確認する $ export ORACLE_SID=+ASM $ sqlplus /as sysdba SQL> startup テストサーバ上でクローンデータベースを MOUNT する $ export ORACLE_SID=db10asm $ sqlplus /as sysdba SQL> startup mount SQL> recover database; SQL> exit この時点で データベース名 (ORACLE_SID) を変更できる 変更する場合は nid ユーティリティを使う $ nid target=sys/manager1@test DBNAME=oratest クローンデータベースを RESETLOGS で OPEN する $ export ORACLE_SID=oratest $ sqlplus /as sysdba SQL> startup mount SQL> alter database open resetlogs; テストサーバ上に複製されたデータベースはこれで使えるようになった データベースはまるで電源障害によって強制的にシャットダウンされたデータ状態になっているため 通常のリカバリ方法によって回復するのである シナリオ 4:ShadowImage を使った Oracle10g のコールドバックアップ Oracle10g ASM のコールドバックアップの手順は 1 つの例外を除き Oracle10g 非 ASM や Oracle9i の手順と同じである それは コールドバックアップの取得する前に ASM インスタンスを停止させることである ( 図 3を参照 ) ShadowImage のコマンドを示す これらは TrueCopy や UR 単体で あるいは TrueCopy や UR と遠隔地の ShadowImage のカスケード構成で使うこともできる この手順は 業務サーバのデータベースをシャットダウンし停止している間にコピーを作成するものである コンシステンシーグループ (At-time スプリットオプション ) は必要ない ShadowImage のペアグループには データファイル 制御ファイル REDO ログファイル フラッシュバックログなどすべてのファイルを含める 22

23 図 3. コールドバックアップ手順手順のフローチャート RAID Manager SQL*Plus RMAN コールドバックアップ処理の開始 データ表領域のペア再同期 (PSUS PAIR) 制御ファイルのバックアップ データベースインスタンスの停止 データ表領域のバックアップ (PAIR PSUS) ASM インスタンスの停止 ASM インスタンスの起動 データベースインスタンスの起動 不要になったアーカイブの削除 コールドバックアップ処理の完了 まず ShadowImageペアを作成する (paircreate) ペア状態がサスペンド(PSUS) であればペア再同期 (pairresync) をする # paircreate g SIALLDB vl または # pairresync g SIALLDB データベースインスタンスを停止し 続いてASMインスタンスを停止する $ export ORACLE_SID=db10asm $ sqlplus / as sysdba SQL> shutdown $ export ORACLE_SID=+ASM $ sqlplus / as sysdba SQL> shutdown ペア分割 (pairsplit) を実施し サスペンド状態 (PSUS) にする # pairsplit g SIALLDB サスペンド状態 (PSUS) になったことを確認する # pairevtwait g SIALLDB s psus t t 9999 これで ShadowImage の副ボリュームはデータベースの有効なコピーとなった 作成したコピーは 業務サーバへのリストアによる高速リカバリや バックアップサーバでの RMAN を使ったテープバックアップ またはほかのサーバでのテスト環境などに使用できる 23

24 別表 A: RMAN リカバリカタログガイドライン Oracle Recovery Manager (RMAN) でよく使用されているコマンドとその使用例をこの項にまとめる リカバリカタログ (recovery catalog) は 業務サーバのデータベースとバックアップサーバのデータベースを管理できる 作業しているサーバが業務サーバ バックアップサーバに関わらず 目的とするリカバリカタログに接続する必要があるため その方法を以下に示す 業務サーバ (prod) のデータベースとリカバリカタログ (rcat) に接続する方法 $ rman target system/manager1@prod catalog rman/rman@rcat バックアップサーバ (bkup) のデータベースとリカバリカタログ (rcat) に接続する方法 $ rman target system/manager1@bkup catalog rman/rman@rcat 以下は リカバリカタログの作成例である $ rman catalog rman/rman@rcat RMAN> create catalog; RMAN> exit データベースとリカバリカタログに接続する $ rman target t prod catalog rman/rman@rcat 接続しているリカバリカタログにデータベースを登録する RMAN> register database; Database registered in recovery catalog Starting full resync of recovery catalog Full resync complete 正常に登録された事を確認する RMAN> report schema; List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name SYSTEM YES +DATADG/db10asm/datafile/system UNDOTBS1 YES +DATADG/db10asm/datafile/undotbs SYSAUX NO +DATADG/db10asm/datafile/sysaux USERS NO +DATADG/db10asm/datafile/users EXAMPLE NO +DATADG/db10asm/datafile/example List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name TEMP DATADG/db10asm/tempfile/temp

25 別表 B: TNSNAMES.ORA 構成ファイルの例 以下に tnsnames.oraファイルの例を示す tnsnames.ora # PROD= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=PRODHOST)) ) (CONNECT_DATA=(SID_NAME=PROD))) BKUP= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=BKUPHOST)) ) (CONNECT_DATA= (SID_NAME=BKUP))) RCAT= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=BKUPHOST)) ) (CONNECT_DATA= (SID_NAME=RCAT))) 25

26 別表 C: ShadowImage の構成定義ファイルの例 以下に ShadowImage の構成定義ファイルの例を示す /etc/horcm0.conf HORCM_MON #ip_address service poll(10ms) timeout(10ms) HORCM_CMD #dev_name dev_name dev_name /dev/sdx HORCM_LDEV #dev_group dev_name Serial# CU:LDEV(LDEV#) MU# DATADG 0070_ :70 0 DATADG 0071_ :71 0 DATADG 0072_ :72 0 FLASHDG 0073_ :73 0 FLASHDG 0074_ :74 0 SIALLDG 0070_ :70 1 SIALLDG 0071_ :71 1 SIALLDG 0072_ :72 1 SIALLDG 0073_ :73 1 SIALLDG 0074_ :74 1 SIALLDG 0080_ :80 1 SIALLDG 0081_ :81 1 HORCM_INST #dev_group ip_address service DATADG FLASHDG SIALLDG /etc/horcm1.conf HORCM_MON #ip_address service poll(10ms) timeout(10ms) HORCM_CMD #dev_name dev_name dev_name /dev/sdx HORCM_LDEV #dev_group dev_name Serial# CU:LDEV(LDEV#) MU# DATADG 0070_ :50 0 DATADG 0071_ :51 0 DATADG 0072_ :52 0 FLASHDG 0073_ :53 0 FLASHDG 0074_ :54 0 SIALLDG 0070_ :30 0 SIALLDG 0071_ :31 0 SIALLDG 0072_ :32 0 SIALLDG 0073_ :33 0 SIALLDG 0074_ :34 0 SIALLDG 0080_ :40 0 SIALLDG 0081_ :41 0 HORCM_INST #dev_group ip_address service DATADG FLASHDG SIALLDG

27 別表 D: 初期化パラメータファイルの例 以下に データベースインスタンスと ASM インスタンスの初期化パラメータファイルのうち キーとなるパラメータを示す init+asm.ora INSTANCE_TYPE=ASM ASM_DISKSTRING= /dev/sddlm* ASM_DISKGROUPS= DATADG, FLASHDG, REDODG initdb db10 10asm.ora db_name=db10asm control_files=+datadg/control_001 DB_RECOVERY_FILE_DEST=+FLASHDG LOG_ARCHIVE_DEST_1= LOCATION=USE_DB_RECOVERY_FILE_DEST 著作権表示および免責 株式会社日立製作所 Copyright (c) 2008 Hitachi, Ltd. All Rights Reserved. 無断転載を禁ずこの文書はあくまでも参考資料であり 掲載されている情報は予告なしに変更されることがあります 日立製作所は本書の内容に関していかなる保証もいたしません また 本書の内容に関連したいかなる損害についても責任を負いかねます すべての企業名と製品名は 識別のためにのみ掲載されており それぞれの所有者の商標の場合があります 27