DataGuard新機能」について検証します。今回は最終回として今までの内容を振り返ってみたいと思います。実際にマルチプラットホームでのDataGuard構成を検証しました。マルチプラットホームのDataGuard構成は、Oracle社がサポートする組み合わせにする必要があります。DataGuardを実際に構築してみました。注意事項は以下のとおりです。[プライマリDBとスタンバイDB間で認証が強化された]Oracle11gよりプライマリDBとスタンバイDB間での通信に認証が必要になりました。認証方法としてSSLプロトコルまたは、リモート・ログイン・パスワードファイルのいずれかを使用する必要があります。今回の検証ではリモート・ログイン・パスワードファイルを使用しました。プライマリDBとスタンバイDB間の認証を有効するには、プライマリDBのリモート・パスワード・ファイルをスタンバイDBにコピーして再起動する必要があります。マルチプラットホームの場合、OSによりリモート・パスワード・ファイルの命名規則が違うので注意が必要です。ファスト・スタート・スタンバイの機能拡充についてOracle11gより機能拡充されたファスト・スタート・スタンバイの検証を行いました。機能拡充により障害時の運用が柔軟に対応し易くなりました。Conditionsの指定が可能になったことにより、各利用ユーザーの要件に応じて設定変更が可能になりました。この機能によりディザスタリカバリの運用が柔軟に対応し易くなりました。[障害に対する原因究明の簡略化]・スタンバイDBの自動復旧が手動で変更可能になったFastStartFailoverShutdown=FALSEOracle10gまでは旧プライマリDBをmountした時点で自動的にスタンバイDB再構築を行ってしまい原因が分からないケースがありました。自動再構築を停止し障害が発生した状態で原因復旧を行うことが出来るようになりました。障害発生原因の分析には10gではアラートログより読み取るしかない状況でした。11gからはV$FS_FAILOVER_STATS、V$FS_FAILOVER_HISTOGRAMなどを参照すれば障害発生の時刻と障害名を参照できるため、原因究明の参考情報として利用できそうです。[解説]●ファスト・スタート・フェイルオーバーとはプライマリDBに障害が発生した場合、複雑な手動手順を実行したフェイルオーバーを起動することなく指定されたスタンバイDBへ自動で素早く確実にフェイルオーバーを行うことができる機能です。性レベル、ならびに障害時のリカバリ時間を短縮することができます。4.スナップショット・スタンバイについてスナップショット・スタンバイをテスト環境としての利用する時の懸念事項について検証しました。スナップショット・スタンバイはプライマリDBと独立したトランザクションを実行出来るため本番データを使用したテスト環境として有効です。確実にスタンバイDBを復旧するためには制限事項を意識することが必要となります。[スナップショット・スタンバイの状態での同期維持可能な操作](1)新規表領域の追加・削除(2)データベースオブジェクトの作成・削除(3)スナップショット・スタンバイ中でのデータの更新(4)スナップショット・スタンバイからフィジカル・スタンバイの復旧に有効期限無くスナップショット・スタンバイの利用が可能[制限事項]フィジカル・スタンバイからスナップショット・スタンバイに変更する以前から存在するの表領域を削除すると同期が維持できない状態になる。同期が維持できない場合は、再度プライマリDBを元にスタンバイDBを作成することが必要です。Windowsでも読み込みできるのでしょうか?。11gの新機能として、そういう機能があるとするならば、どこが(Process?)やっているのでしょうか?回答:Oracle社がサポートする構成であればRMANのバックアップファイルはファイル形式変換の必要はありません。x86(32bit)で読み込み可能であるため、ファイル形式変換の必要はありません。■最後に最後になりましたが読者の皆様、ご愛読ありがとうございました。それでは、また次の検証で逢いましょう。reserved.トップページ企業概要プライバシーポリシ。