Oracle11g DataGuard新機能 その８
＜Oracle 11g検証 第4弾 新機能：Oracle11g DataGuard その８＞
ペンネーム： オレンジみかん
先週に引き続き「Oracle11g DataGuard新機能」について検証します。
今回は最終回として今までの内容を振り返ってみたいと思います。
■検証まとめ
1. マルチプラットホーム対応について
Oracle11gから異なるOS間の、いわゆるマルチプラットフォーム構成が可
能となりました。実際にマルチプラットホームでのDataGuard構成を検証し
ました。
マルチプラットホームのDataGuard構成は、Oracle社がサポートする組み
合わせにする必要があります。（METALINK NOTE:413484.1）
マルチプラットフォームの注意点として
・商用UNIXとLinux又はWindowsとの組み合わせは不可
・Big EndianとLittle Endianの組み合わせは不可
[解説]
●Big Endian
例えば16進数で 0x1234ABCD という4バイトのデータを、データの上位バ
イトからメモリに「12 34 AB CD」と並べる方式
IBM系のメインフレーム/汎用機、SunのSPARC、MotorolaのMC68000等は
「ビッグエンディアン」を採用
●Little Endian
データの下位バイトから「CD AB 34 12」と並べる方式
インテルのx86系などは「リトルエンディアン」を採用
※出展：Wikipedia
2. Oracle11g DataGuard構築時の注意事項
Oracle11g DataGuardを実際に構築してみました。注意事項は以下のとお
りです。
[プライマリDBとスタンバイDB間で認証が強化された]
Oracle11gよりプライマリDBとスタンバイDB間での通信に認証が必要にな
りました。認証方法としてSSLプロトコルまたは、リモート・ログイン・パ
スワードファイルのいずれかを使用する必要があります。
今回の検証ではリモート・ログイン・パスワードファイルを使用しました。
プライマリDBとスタンバイDB間の認証を有効するには、プライマリDBのリ
モート・パスワード・ファイルをスタンバイDBにコピーして再起動する必要
があります。
マルチプラットホームの場合、OSによりリモート・パスワード・ファイル
の命名規則が違うので注意が必要です。
例）
※プライマリDB（Linux）
$ORACLE_HOME/dbs/orapw[インスタンス名].ora
※スタンバイDB（Windows）
$ORACLE_HOMEdatabasePWD[インスタンス名].ora
3. ファスト・スタート・スタンバイの機能拡充について
Oracle11gより機能拡充されたファスト・スタート・スタンバイの検証を
行いました。機能拡充により障害時の運用が柔軟に対応し易くなりました。
[ファスト・スタート・フェイルオーバーの条件の有効/無効化設定]
Health Conditionsの指定が可能になったことにより、各利用ユーザーの
要件に応じて設定変更が可能になりました。この機能により
ディザスタリカバリの運用が柔軟に対応し易くなりました。
[障害に対する原因究明の簡略化]
・スタンバイDBの自動復旧が手動で変更可能になった
FastStartFailoverShutdown=FALSE
Oracle10gまでは旧プライマリDBをmountした時点で自動的にスタンバイDB
再構築を行ってしまい原因が分からないケースがありました。
この点に於いて、FastStartFailoverShutdown=FALSE にすることにより、
自動再構築を停止し障害が発生した状態で原因復旧を行うことが出来るよう
になりました。
・障害分析の補助情報として活用
障害発生原因の分析には10gではアラートログより読み取るしかない状況で
した。11gからはV$FS_FAILOVER_STATS、V$FS_FAILOVER_HISTOGRAMなどを
参照すれば障害発生の時刻と障害名を参照できるため、原因究明の参考情報
として利用できそうです。
[解説]
●ファスト・スタート・フェイルオーバーとは
プライマリDBに障害が発生した場合、複雑な手動手順を実行したフェイル
オーバーを起動することなく指定されたスタンバイDBへ自動で素早く確実に
フェイルオーバーを行うことができる機能です。これにより、稼働時間を透
過的に維持し、システム障害、データ障害およびサイト停止に対する高可用
性レベル、ならびに障害時のリカバリ時間を短縮することができます。
4.スナップショット・スタンバイについて
スナップショット・スタンバイをテスト環境としての利用する時の懸念事項
について検証しました。
スナップショット・スタンバイはプライマリDBと独立したトランザクションを
実行出来るため本番データを使用したテスト環境として有効です。ただし、
確実にスタンバイDBを復旧するためには制限事項を意識することが必要となり
ます。
[スナップショット・スタンバイの状態での同期維持可能な操作]
(1)新規表領域の追加・削除
(2)データベースオブジェクトの作成・削除
(3)スナップショット・スタンバイ中でのデータの更新
(4)スナップショット・スタンバイからフィジカル・スタンバイの復旧に
有効期限無くスナップショット・スタンバイの利用が可能
[制限事項]
フィジカル・スタンバイからスナップショット・スタンバイに変更する
以前から存在するの表領域を削除すると同期が維持できない状態になる。
同期が維持できない場合は、再度プライマリDBを元にスタンバイDBを作成
することが必要です。
（スタンバイDBの再構築時は、プライマリDBの停止は必要無し）
■寄せられた質問事項のご回答
質問:
RMANでスタンバイデータベースを構築する時にバックアップファイルは
convertする必要はないのでしょうか？また、Linuxのバイナリが Windowsでも
読み込みできるのでしょうか？。
11gの新機能として、そういう機能があるとするならば、どこが(Process?)
やっているのでしょうか?
回答：
Oracle社がサポートする構成であればRMANのバックアップファイルはファイ
ル形式変換の必要はありません。
例）
Linux x86(32bit) ⇔ Microsoft Windows x86(32bit)
RMANからのバックアップピースはLinux x86(32bit)とMicrosoft Windows x86
(32bit)で読み込み可能であるため、ファイル形式変換の必要はありません。
■訂正事項
第７話の訂正事項：[シナリオ４]
図の表領域名を訂正
[スナップショット・スタンバイ中に表領域を追加した場合の動作検証]
スナップショット・スタンバイ中に表領域：TEMP02を追加、削除する
プライマリDB スタンバイDB スタンバイDB
--------- --------- ---------
| TEMP01 | ⇒ | TEMP01 | ・・・|TEMP01 |
| | | TEMP02 | | |
---------- ----------- ----------
TEMP02 を削除
[スナップショット・スタンバイ中に表領域を追加した場合の動作検証]
スナップショット・スタンバイ中に表領域：TEMP02を追加、削除する
プライマリDB スタンバイDB スタンバイDB
--------- --------- ---------
| | ⇒ | | ・・・| |
| | | TEMP02 | | |
---------- ----------- ----------
TEMP02 を削除
===
図の表領域名を訂正
[プライマリDBにもある表領域を削除した場合の動作検証]
既存の表領域：TEST01を削除して、プライマリDBとスタンバイDBの表領域の
相違が発生する場合はフィジカル・スタンバイへの復旧が可能か？
(1)プライマリDBで新しい表領域する
プライマリDB スタンバイDB スタンバイDB
--------- --------- ---------
| TEMP01 | ⇒ | TEMP01 | ・・・| |
| | | TEMP02 | |TEMP02 |
---------- ---------- ----------
TEMP01を削除
[プライマリDBにもある表領域を削除した場合の動作検証]
既存の表領域：TEST01を削除して、プライマリDBとスタンバイDBの表領域の
相違が発生する場合はフィジカル・スタンバイへの復旧が可能か？
(1)プライマリDBで新しい表領域を作成する
プライマリDB スタンバイDB スタンバイDB
--------- --------- ---------
| TEST01 | ⇒ | TEST01 | ・・・| |
| | | | | |
---------- ---------- ----------
TEST01を削除
■最後に
最後になりましたが
読者の皆様、ご愛読ありがとうございました。
それでは、また次の検証で逢いましょう。
買い物癖が辛い今日この頃 恵比寿にて