13 SQL Applyを使用したOracle Databaseのアップグレード
ロジカル・スタンバイ・データベースを使用して、Oracle Databaseソフトウェアのローリング・アップグレードを実行できます。
ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースのOracleデータベースを実行しながら、プライマリ・データベースの停止時間を最短に抑えて各リリースを一度に1つずつアップグレードできます。
Oracle Database 12cリリース1 (12.1)の最初のパッチ・セットで開始しているデータベースで、既存のフィジカル・スタンバイ・データベースを使用してローリング・アップグレードを実行する望ましい方法は、DBMS_ROLLINGを使用したローリング・アップグレードの実行で説明しているように、DBMS_ROLLING
PL/SQLパッケージを使用する方法です。
次の各項では、Oracleデータベースのアップグレード中の停止時間を最短に抑える方法について説明します。
ノート:
これらの項では、より停止時間が長い通常のアップグレード手順(「Oracle Data Guard構成におけるデータベースのアップグレードおよびダウングレード」を参照)にかわる方法について説明します。2つの手順のステップを組み合せようとしないでください。
13.1 SQL Applyを使用するローリング・アップグレードのメリット
SQL Applyを使用してローリング・アップグレードを実行すると、次のようなメリットがあります。
-
本番データベースの停止時間が最短で済みます。停止時間全体がスイッチオーバーの実行所要時間と同様に短時間です。
-
PL/SQLの再コンパイルによるアプリケーションの停止時間は発生しません。
-
プライマリ・データベースに影響を与えずに、アップグレード後のデータベース・リリースを検証できます。
-
ロジカル・スタンバイはアップグレードが実行されている間、アーカイブされたログを受け入れます。これにより障害保護のレベルが上がります。
ノート:
-
Oracle Database 12c リリース1 (12.1)現在、Oracle XML DB RepositoryではOracle Data Guardのローリング・アップグレードをサポートしています。このサポートに関して注意が必要な考慮事項および制限事項の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
-
Oracle Database 12cリリース1 (12.1)以降では、Oracle Database Vaultを使用するデータベースを、Oracle Data Guardデータベースのローリング・アップグレードを一時ロジカル・スタンバイおよびPL/SQLパッケージ
DBMS_ROLLING
とともに使用して、新しいOracleデータベースのリリースおよびパッチ・セットにアップグレードできます。 -
Oracle Database 12cリリース1 (12.1)以降では、Oracle Label Security (OLS)を使用するデータベースを、一時ロジカル・スタンバイ・データベースおよびPL/SQLパッケージ
DBMS_ROLLING
を使用するOracle Data Guardデータベースのローリング・アップグレードを使用して、新しいOracleデータベースのリリースおよびパッチ・セットにアップグレードできます。
13.2 SQL Applyを使用してローリング・アップグレードを実行するための要件
SQL Applyを使用してローリング・アップグレードを実行するための要件は、次のとおりです。
-
データベースが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.3 アップグレード手順に使用する図と表記規則
この背景情報は、アップグレードの実行手順を理解するのに役立ちます。
図13-1に、アップグレード開始前のOracle Data Guard構成を示します。この例では、プライマリ・データベースとロジカル・スタンバイ・データベースで同じリリースのOracle Databaseソフトウェアが実行されています。
アップグレード処理中に、Oracle Data Guard構成は何度か混合データベース・リリースで動作します。リリース間にまたがるデータ保護は使用できません。これらのステップでは、データ保護を提供するためにOracle Data Guard構成に第2のスタンバイ・データベースがある場合を考えます。
アップグレード手順のステップと図では、データベースを「プライマリ・データベース」と「スタンバイ・データベース」ではなく「データベースA」および「データベースB」と呼びます。これは、アップグレード手順の実行中にデータベースのロールが切り替わるためです。最初は、図13-1に示すようにデータベースAがプライマリ・データベースでデータベースBがロジカル・スタンバイ・データベースです。
次の各項では、SQL Applyのローリング・アップグレード手順を使用できる例について説明します。
13.4 ロジカル・スタンバイ・データベースの新規作成によるローリング・アップグレードの実行
この使用例では、既存のOracle Data Guard構成がなく、Oracle Databaseのローリング・アップグレードを実行するためにのみロジカル・スタンバイ・データベースを作成することを前提にしています。
表13-1に、プライマリ・データベースとスタンバイ・データベースでアップグレードを準備するステップを示します。
表13-1 ロジカル・スタンバイの新規作成によってローリング・アップグレードを実行するステップ
ステップ | 説明 |
---|---|
ステップ1 |
サポートされないデータ型および記憶域属性を識別する |
ステップ2 |
ロジカル・スタンバイ・データベースを作成する |
ステップ3 |
ローリング・アップグレードを実行する |
13.5 既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行
このステップでは、ロジカル・スタンバイ・データベースおよびプライマリ・データベースでOracle Databaseのローリング・アップグレードを実行する方法について説明します。
表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文があるかどうかを確認することをお薦めします。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フェーズ準備済スイッチオーバーを使用します。
13.6 既存のフィジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行
このステップでは、Oracle Databaseソフトウェアのローリング・アップグレードを実行した後に元の構成に戻し、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;
-
-
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する(データベース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はロジカル・スタンバイ・データベースになります。
次のステップに進んで、データベース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』