| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
ロジカル・スタンバイ・データベースを使用して、Oracle Databaseソフトウェアのローリング・アップグレードを実行できます。ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースのOracleデータベースを実行しながら、プライマリ・データベースの停止時間を最短に抑えて各リリースを一度に1つずつアップグレードできます。
Oracle Database 12cリリース1 (12.1)の最初のパッチ・セットで開始しているデータベースで、既存のフィジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行する望ましい方法は、DBMS_ROLLINGを使用したローリング・アップグレードの実行で説明しているように、DBMS_ROLLING PL/SQLパッケージを使用する方法です。
次の各項では、Oracleデータベースのアップグレード中の停止時間を最短に抑える方法について説明します。
注意:
これらの項では、より停止時間が長い通常のアップグレード手順(「Oracle Data Guard構成におけるデータベースのアップグレードおよびダウングレード」を参照)にかわる方法について説明します。2つの手順のステップを組み合せようとしないでください。
SQL Applyを使用してローリング・アップグレードを実行する方法には、次のようなメリットがあります。
本番データベースの停止時間が最短で済みます。停止時間全体がスイッチオーバーの実行所要時間と同様に短時間です。
PL/SQLの再コンパイルによるアプリケーションの停止時間は発生しません。
プライマリ・データベースに影響を与えずに、アップグレード後のデータベース・リリースを検証できます。
ロジカル・スタンバイはアップグレードが実行されている間、アーカイブされたログを受け入れます。これにより障害保護のレベルが上がります。
注意:
Oracle Database 12c リリース1 (12.1)現在、Oracle XML DB RepositoryではOracle Data Guardのローリング・アップグレードをサポートしています。このサポートに関して注意が必要な考慮事項および制限事項の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
ローリング・アップグレード手順の要件は、次のとおりです。
データベースがOracle Data Guard Broker構成の一部の場合、ローリング・アップグレードの前にブローカ構成を無効にします。ブローカ構成の無効化の詳細は、『Oracle Data Guard Broker』を参照してください。
Oracle Data Guardの保護モードが最大可用性モードまたは最大パフォーマンス・モードに設定されていること。現在の保護モード設定を確認するには、V$DATABASEビューのPROTECTION_LEVEL列を問い合せます。
ロジカル・スタンバイ・データベースのアップグレード中もプライマリ・データベースで処理を進行できるようにするために、ロジカル・スタンバイ・データベースの宛先のLOG_ARCHIVE_DEST_n初期化パラメータがMANDATORYに設定されていないこと。
プライマリ・データベースに設定されたCOMPATIBLE初期化パラメータが、アップグレード前のソフトウェア・リリースと一致していること。したがって、リリースxからリリースyへのローリング・アップグレードでは、プライマリ・データベースでCOMPATIBLE初期化パラメータをリリースxに設定する必要があります。 ローリング・アップグレード・スタンバイ・データベースでは、COMPATIBLE初期化パラメータをx以上に設定する必要があります。
図13-1に、アップグレード開始前のOracle Data Guard構成を示します。この例では、プライマリ・データベースとロジカル・スタンバイ・データベースで同じリリースのOracle Databaseソフトウェアが実行されています。
アップグレード処理中に、Oracle Data Guard構成は何度か混合データベース・リリースで動作します。リリース間にまたがるデータ保護は使用できません。これらの手順では、データ保護を提供するためにOracle Data Guard構成に第2のスタンバイ・データベースがある場合を考えます。
アップグレード手順と図では、データベースを「プライマリ・データベース」と「スタンバイ・データベース」ではなく「データベースA」および「データベースB」と呼びます。これは、アップグレード手順の実行中にデータベースのロールが切り替わるためです。最初は、図13-1に示すようにデータベースAがプライマリ・データベースでデータベースBがロジカル・スタンバイ・データベースです。
次の各項では、SQL Applyのローリング・アップグレード手順を使用できる例について説明します。
この使用例では、既存のOracle Data Guard構成がなく、Oracle Databaseのローリング・アップグレードを実行するためだけにロジカル・スタンバイ・データベースを作成することを前提にしています。
表13-1に、プライマリ・データベースとスタンバイ・データベースでアップグレードを準備する手順を示します。
表13-1 ロジカル・スタンバイの新規作成によってローリング・アップグレードを実行する手順
| 手順 | 説明 |
|---|---|
手順1 |
サポートされないデータ型および記憶域属性を識別する |
手順2 |
ロジカル・スタンバイ・データベースを作成する |
手順3 |
ローリング・アップグレードを実行する |
この項では、ロジカル・スタンバイ・データベースとプライマリ・データベースをアップグレードする手順について説明します。表13-2に手順を示します。
表13-2 既存のロジカル・スタンバイを使用したローリング・アップグレードの実行手順
| 手順 | 説明 |
|---|---|
手順1 |
ローリング・アップグレードの準備をする |
手順2 |
ロジカル・スタンバイ・データベースをアップグレードする |
手順3 |
アップグレード後のロジカル・スタンバイ・データベースでSQL Applyを再開する |
手順4 |
アップグレード後のスタンバイ・データベースでイベントを監視する |
手順5 |
スイッチオーバーを開始する |
手順6 |
アップグレード中に変更されたすべての表をインポートする |
手順7 |
スイッチオーバーを完了してユーザー・アプリケーションをアクティブ化する |
手順8 |
古いプライマリ・データベースをアップグレードする |
手順9 |
古いプライマリ・データベースでSQL Applyを開始する |
手順10 |
必要な場合は、両方のデータベースの互換性レベルを上げる |
手順11 |
新規ロジカル・スタンバイ・データベースでイベントを監視する |
手順12 |
必要な場合は、再度スイッチオーバーを実行する |
次の手順に従って、Oracleソフトウェアのローリング・アップグレードの実行準備をします。
ロジカル・スタンバイ・データベース(データベースB)で次の文を発行し、SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
必要に応じて、互換性を最高値に設定します。
COMPATIBLE初期化パラメータに、アップグレード前のプライマリ・データベースで実行されているOracle Databaseソフトウェアのリリース番号が指定されていることを確認します。
たとえば、プライマリ・データベースでリリース11.1が実行されている場合は、COMPATIBLE初期化パラメータを両方のデータベースで11.1に設定します。COMPATIBLE初期化パラメータは、必ずスタンバイ・データベースで設定してからプライマリ・データベースで設定してください。
ロジカル・スタンバイ・データベース(データベースB)のOracle Databaseソフトウェアをリリースyにアップグレードします。ロジカル・スタンバイ・データベースでは、アップグレード中、プライマリ・データベースからのREDOデータを受け入れません。
Oracle Databaseソフトウェアをアップグレードするには、該当するOracle Databaseリリースの『Oracle Databaseアップグレード・ガイド』を参照してください。
図13-2に、リリースxを実行中のデータベースAとリリースyを実行中のデータベースBを示します。アップグレード中は、REDOデータがプライマリ・システムに蓄積されます。
SQL Applyを再開し、データベースAではリリースx、データベースBではリリースyで動作させます。SQL Applyを開始するには、データベースBで次の文を発行します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
プライマリ・システムに蓄積されたREDOデータは、新しくアップグレードしたロジカル・スタンバイ・データベースに自動的に転送され、適用されます。Oracle Data Guard構成では、アップグレード後のOracle Databaseソフトウェア・リリースが本番環境で正常に実行されるかどうかを確認するために、任意の期間のみ図13-3に示す混合リリースを実行できます。
Database BがDatabase Aにどの程度速く追いつくのかを監視するには、Database BのV$LOGSTDBY_PROGRESSビューの問合せを行います。次に例を示します。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS'; Session altered. SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS; SYSDATE APPLIED_TIME ------------------ ------------------ 27-JUN-05 17:07:06 27-JUN-05 17:06:50
頻繁にDBA_LOGSTDBY_EVENTSビューを問い合せ、データベースBに適用されなかったDDL文とDML文があるかどうかを確認することをお薦めします。この項の末尾にある例で、イベントの監視により2つのデータベースにおける潜在的な差異を把握する方法を示します。
SQL> SET LONG 1000 SQL> SET PAGESIZE 180 SQL> SET LINESIZE 79 SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS - > ORDER BY EVENT_TIMESTAMP; EVENT_TIMESTAMP --------------------------------------------------------------------------- EVENT -------------------------------------------------------------------------------- STATUS -------------------------------------------------------------------------------- … 24-MAY-05 05.18.29.318912 PM CREATE TABLE SYSTEM.TST (one number) ORA-16226: DDL skipped due to lack of support 24-MAY-05 05.18.29.379990 PM "SYSTEM"."TST" ORA-16129: unsupported dml encountered
前述の例で、各エラーの意味は次のとおりです。
ORA-16226エラーは、サポートできないDDL文を示します。この場合は、内部スキーマに属しているためにサポートできません。
ORA-16129エラーは、適用されなかったDML文を示します。
この種のエラーは、データベースAで発生した変更の一部がデータベースBに適用されなかったことを示します。この時点で、アップグレード手順を続行するかどうかを判断する必要があります。ロジカル・スタンバイ・データベースとプライマリ・データベース間で、この差異が許容可能であることが確実な場合は、アップグレード手順を続行します。不確実な場合は、アップグレード手順を中断してデータベースBを再インスタンス化し、別の時点でアップグレード手順を実行します。
アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、データベースAで次の文を発行してスイッチオーバーを実行し、データベース・ロールを元に戻します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文は、既存のトランザクションが完了まで待機する必要があります。スイッチオーバーの完了所要時間を最短に抑えるには、データベースAにまだ接続されているユーザーがすぐにログオフし、データベースBに再接続する必要があります。
注意:
「ロジカル・スタンバイ・データベースへのスイッチオーバーの実行」で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。
注意:
データベースAがプライマリ・データベースのときに、そこでサポートされない表またはパッケージに対するアクティビティを一時停止した場合、最終的にデータベースAに切り替える計画であれば、データベースBがプライマリ・データベースになっている間にデータベースBでも引き続き同じアクティビティを一時停止する必要があります。
手順4では、変更中のサポートされない表をリストする方法について説明しました。プライマリ・データベースでサポートされないDML文が発行された場合は、Oracle Data Pumpなどのインポート・ユーティリティを使用して、各表の最新バージョンをインポートします。
たとえば、次のインポート・コマンドはscott.emp表を切り捨て、前のプライマリ・データベース(A)と一致するデータを移入します。
impdp SYSTEM NETWORK_LINK=databasea TABLES=scott.emp TABLE_EXISTS_ACTION=TRUNCATE
このコマンドは、実行前にimpdpパスワードの入力を求めてきます。
アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、スイッチオーバーを完了してデータベース・ロールを元に戻します。
データベースBで、次のようにV$DATABASEビューのSWITCHOVER_STATUS列を問い合せます。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS -------------------- TO PRIMARY
SWITCHOVER_STATUS列にTO PRIMARYが表示される場合は、データベースBで次の文を発行してスイッチオーバーを完了します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
注意:
「ロジカル・スタンバイ・データベースへのスイッチオーバーの実行」で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。
現在はプライマリ・データベース・ロールで実行中のデータベースBで、ユーザー・アプリケーションとサービスをアクティブ化します。
スイッチオーバー後は、新規データベース・ソフトウェア・リリースを実行中の新規プライマリ・データベース(B)から旧ソフトウェア・リリースを実行中の新規スタンバイ・データベース(A)には、REDOデータを送信できません。これは次のことを意味します。
REDOデータは、新規プライマリ・データベースに蓄積されます。
新規プライマリ・データベースは、この時点では保護されていません。
図13-4に、前はスタンバイ・データベース(リリースyを実行)で現在はプライマリ・データベースになっているデータベースBと、前はプライマリ・データベース(リリースxを実行)で現在はスタンバイ・データベースになっているデータベースAを示します。ユーザーはデータベースBに接続されます。
データベースBがプライマリ・データベースとして適切に機能でき、ビジネスにプライマリ・データベースをサポートするためのロジカル・スタンバイ・データベースが不要な場合、これでローリング・アップグレード処理は完了です。ユーザーにデータベースBへのログインとそこでの作業開始を許可し、問題のない時点でデータベースAを破棄します。それ以外の場合は、手順8に進みます。
データベースAでは引き続きリリースxが実行されており、アップグレードしてSQL Applyを開始するまでは、データベースBからのREDOデータを適用できません。
Oracle Databaseソフトウェアのアップグレードの詳細は、『Oracle Databaseアップグレード・ガイド』を参照してください。
図13-5に、両方のデータベースがアップグレードされた後のシステムを示します。
データベースAで次の文を発行してSQL Applyを開始し、必要に応じてデータベースBへのデータベース・リンクを作成します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b;
注意:
データベース・リンクを作成し(まだ設定されていない場合)、NEW PRIMARY句を使用する必要があります。これは、手順4で1フェーズ準備なしスイッチオーバーを使用してデータベースAをスタンバイ・データベースに切り替えたためです。
ユーザーSYSTEMとして接続するか、同様のレベルの権限を持つアカウントで接続する必要があります。
データベースAでSQL Applyを開始すると、プライマリ・データベース(B)に蓄積されたREDOデータがロジカル・スタンバイ・データベース(B)に送信されます。すべてのREDOデータがスタンバイ・データベースで使用可能になると、プライマリ・データベースはデータ消失から保護されます。
COMPATIBLE初期化パラメータを設定して、両方のデータベースの互換性レベルを上げます。互換性レベルは、ロジカル・スタンバイ・データベースで上げてから、プライマリ・データベースで上げる必要があります。COMPATIBLEパラメータは、スタンバイ・データベースで設定してからプライマリ・データベースで設定します。COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
Database Bで行ったすべての変更がロジカル・スタンバイ・データベース(A)に正しく適用されていることを確認するには、手順4でDatabase Aに対して行ったように、DBA_LOGSTDBY_EVENTSビューの問合せを頻繁に行う必要があります。
変更が行われたためにデータベースAが既存のプライマリ・データベースのコピーとして無効になった場合は、データベースAを破棄し、かわりに新規のロジカル・スタンバイ・データベースを作成できます。詳細は、「ロジカル・スタンバイ・データベースの作成」を参照してください。
必要な場合は、データベースAがプライマリ・データベース・ロールで再実行されるように(図13-1を参照)、データベースのスイッチオーバーを再度実行します。
注意:
この時点で、データベースAとデータベースBはいずれも同じバージョンのOracleソフトウェアを実行しているため、ロジカル・スタンバイ・データベースへのスイッチオーバーの実行で説明した2フェーズ準備済スイッチオーバーを使用します。
この項の手順では、Oracleソフトウェアのローリング・アップグレードを実行した後に元の構成に戻し、Aがプライマリ・データベース、Bがフィジカル・データベースで、いずれのデータベースもアップグレード後のOracleソフトウェアを実行している状態にする方法について説明します。
注意:
この項の手順では、プライマリ・データベース(A)とフィジカル・スタンバイ・データベース(B)が設定済で、Oracle Databaseリリース11.1以降を使用していることを前提にしています。
表13-3に関係する手順をまとめます。
表13-3 既存のフィジカル・スタンバイを使用したローリング・アップグレードの実行手順
| 手順 | 説明 |
|---|---|
手順1 |
ローリング・アップグレードのためにプライマリ・データベースを準備する(データベースAでこの手順を実行する) |
手順2 |
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する(データベースBでこの手順を実行する) |
手順3 |
ロジカル・スタンバイ・データベースをアップグレードしてプライマリ・データベースと一致させる(データベースBでこの手順を実行する) |
手順4 |
データベースAを保証付きリストア・ポイントにフラッシュバックする(データベースAでこの手順を実行する) |
手順5 |
新しいバージョンのOracleソフトウェアを使用して、データベースBをマウントする |
手順6 |
データベースAをフィジカル・スタンバイに変換する |
手順7 |
データベースAで管理リカバリを開始する |
手順8 |
スイッチオーバーを実行してデータベースAをプライマリ・データベースにする |
手順9 |
データベースAに作成された保証付きリストア・ポイントをクリーンアップする |
ローリング・アップグレードのためにプライマリ・データベースを準備する(データベースAでこの手順を実行する)
まだ有効でない場合、フラッシュバック・データベースを有効にします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN;
保証付きリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;
(オプション)プライマリ・データベースで次のSQL問合せを実行することで、サポートされないデータ型を識別します。
SELECT * FROM DBA_LOGSTDBY_EDS_SUPPORTED;
サポートされないデータ型を含む戻された表に対し、拡張データ型サポート(EDS)機能を使用してレプリケートできます。これを行うには、EDSを使用してレプリケートするそれぞれの表に対して次のPL/SQLプロシージャを実行します。
SQL> EXECUTE DBMS_LOGSTDBY.EDS_ADD_TABLE(schema_name, table_name);
これらの手順はプライマリで実行されるので、フィジカル・スタンバイでプロシージャを起動する必要はありません。EDS_ADD_TABLEにより作成されたEDSオブジェクトはフィジカル・スタンバイにレプリケートされるからです。フィジカル・スタンバイがロジカル・スタンバイに変換されると、EDSレプリケーションは自動的に有効になり、表はSQL Applyにより保持されます。
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する(データベースBでこの手順を実行する)
次の点を除き、「ロジカル・スタンバイ・データベースの作成」に記載の手順に従います。「ロジカル・スタンバイ・データベースへの変換」では、別なコマンドを使用してロジカル・スタンバイ・データベースの変換を行う必要があります。ALTER DATABASE RECOVER TO LOGICAL STANDBY db_nameのかわりに、次のコマンドを実行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY; SQL> ALTER DATABASE OPEN;
初めてSQL Applyを実行する場合は、その前に次のアクションを行う必要があります。
次のようにして、ロジカル・スタンバイで外部アーカイブ・ログの自動削除を無効にします。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');
注意:
ロジカル・スタンバイ・データベース(データベースB)で処理されたリモート・アーカイブ・ログは削除しないでください。これらのリモート・アーカイブ・ログは、後でローリング・アップグレード処理の際に必要になります。リカバリ領域を使用してリモート・アーカイブ・ログを格納している場合は、ロジカル・スタンバイ・データベースの通常動作を妨げることなくこれらのログを収容するのに十分な領域があることを確認してください。
プライマリ・データベースで実行されていて、ロジカル・スタンバイ・データベースでサポートされないトランザクションに関する情報が取得されていることを確認します。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS表にイベントとして記録します。
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED', -
> DBMS_LOGSTDBY.MAX_EVENTS);
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');
次のようにして、初めてのSQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
関連項目:
DBA_LOGSTDBY_EVENTSビューの詳細は、「DBA_LOGSTDBY_EVENTSビューでのイベントのロギングのカスタマイズ」を参照してください
DBMS_LOGSTDBYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明されているとおり、手順1から7を実行できるようになりました。これらの手順が完了すると、データベースBはアップグレードされたバージョンのOracleソフトウェアを実行するプライマリ・データベースになり、データベースAはロジカル・スタンバイ・データベースになります。
手順1でDBMS_LOGSTDBY.EDS_ADD_TABLEを実行した場合、現在のプライマリ・データベース(データベースB)でDBMS_LOGSTDBY.EDS_REMOVE_TABLEを実行できます。
次の手順に進んで、データベースAをデータベースBのフィジカル・スタンバイにします。
データベースAを保証付きリストア・ポイントにフラッシュバックする(データベースAでこの手順を実行する)
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO RESTORE POINT pre_upgrade; SQL> SHUTDOWN IMMEDIATE;
この時点で、上位バージョンのOracleソフトウェアを使用できるように、データベースAを切り替えます。データベースAはフィジカル・スタンバイに切り替えられており、データベースBによって生成されたREDOデータを適用して自動的にアップグレードされるため、アップグレード・スクリプトは実行しないでください。
次のようにして、データベースAをマウントします。
SQL> STARTUP MOUNT;
データベースAをフィジカル・スタンバイに変換する
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> SHUTDOWN IMMEDIATE;
データベースAで管理リカバリを開始する
データベースAは、データベースBにより生成されたREDOデータを適用して、自動的にアップグレードされます。管理リカバリは、プライマリからの新しいインカネーション・ブランチが登録されるまで待機した後、REDOの適用を開始します。
SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE - > DISCONNECT FROM SESSION;
注意:
REDO Applyが再開するとき、現行のプライマリ・データベース(データベースB)からの新しいインカネーションが登録されるのを待機します。
この時点では、Database Bがプライマリ・データベースでDatabase Aがフィジカル・スタンバイで、両方ともOracleソフトウェアの上位バージョンを実行しています。Database Aをプライマリ・データベースにするには、「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」に記載の手順を実行します。
ディスク領域を保持するために、データベースAで作成された既存の保証付きリストア・ポイントを削除します。
SQL> DROP RESTORE POINT PRE_UPGRADE;
関連項目:
Oracle Maximum Availability Architecture(MAA)のホームページで入手できるベスト・プラクティスに関するホワイト・ペーパー『Database Rolling Upgrade Using Transient Logical Standby: Oracle Data Guard 11g』
