11gリリース1（11.1）
E05755-03
 目次 |
 索引 |
| Oracle Data Guard 概要および管理 11gリリース1（11.1） E05755-03 |
|
Oracle Database 10gリリース1（10.1.0.3）からは、ロジカル・スタンバイ・データベースを使用して、Oracle Database 10gソフトウェアのローリング・アップグレードを実行できます。ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースのOracleデータベースを実行しながら、プライマリ・データベースの停止時間を最短に抑えて各リリースを一度に1つずつアップグレードできます。
|
注意 この章では、より停止時間が長い通常のアップグレード手順（付録B「Data Guard構成におけるデータベースのアップグレード」を参照）にかわる方法について説明します。この章で説明する方法の手順と、付録Bの手順を組み合せようとしないでください。 |
この章の各手順では、Oracleデータベースのアップグレード中の停止時間を最短に抑える方法について説明します。この章は、次の項目で構成されています。
SQL Applyを使用してローリング・アップグレードを実行する方法には、次のように複数のメリットがあります。
ローリング・アップグレード手順の要件は、次のとおりです。
V$DATABASEビューのPROTECTION_LEVEL列を問い合せます。
LOG_ARCHIVE_DEST_n初期化パラメータがMANDATORYに設定されていないこと。
COMPATIBLE初期化パラメータがアップグレード前のソフトウェア・リリースと一致していること。つまり、リリースxからリリースyへのローリング・アップグレードでは、プライマリ・データベースとスタンバイ・データベースの両方でCOMPATIBLE初期化パラメータをリリースxに設定する必要があります。
図12-1に、アップグレード開始前のData Guard構成を示します。この例では、プライマリ・データベースとロジカル・スタンバイ・データベースで同じリリースのOracle Databaseソフトウェアが実行されています。
アップグレード処理中に、Data Guard構成は何度か混合データベース・リリースで動作します。リリース間にまたがるデータ保護は使用できません。これらの手順では、データ保護を提供するためにData Guard構成に第2のスタンバイ・データベースがある場合を考えます。
アップグレード手順と図では、データベースを「プライマリ・データベース」と「スタンバイ・データベース」ではなく「データベースA」および「データベースB」と呼びます。これは、アップグレード手順の実行中にデータベースのロールが切り替わるためです。最初は、図12-1に示すようにデータベースAがプライマリ・データベースでデータベースBがロジカル・スタンバイ・データベースです。
次の各項では、SQL Applyのローリング・アップグレード手順を使用できる例について説明します。
この使用例では、既存のData Guard構成がなく、Oracle Databaseのローリング・アップグレードを実行するためだけにロジカル・スタンバイ・データベースを作成することを前提にしています。
プライマリ・データベースとスタンバイ・データベースをアップグレードできるように準備する手順は、次のとおりです。
プライマリ・データベースでサポートされないデータベース・オブジェクトを識別し、その処理方法を決定する手順は、次のとおりです。
DBA_LOGSTDBY_UNSUPPORTEDおよびDBA_LOGSTDBY_SKIPビューを問い合せます。プライマリ・データベースで表示された表およびスキーマに対して行われた変更は、ロジカル・スタンバイ・データベースに適用されません。次の問合せを実行すると、サポートされない表のリストの例が表示されます。
SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED; OWNER TABLE_NAME ---------- ----------------- OE CATEGORIES_TAB OE CUSTOMERS OE WAREHOUSES PM ONLINE_MEDIA PM PRINT_MEDIA SCOTT MYCOMPRESS SH MVIEW$_EXCEPTIONS 7 rows selected. SQL> SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP 2 WHERE STATEMENT_OPT = 'INTERNAL SCHEMA'; OWNER ------------------------------ CTXSYS DBSNMP DIP ORDPLUGINS ORDSYS OUTLN SI_INFORMTN_SCHEMA SYS SYSTEM WMSYS 10 rows selected.
サポートされないオブジェクトをプライマリ・データベースで変更している場合、アップグレード手順の実行所要時間中、サポートされない表に対する変更を一時的に停止することで、アップグレードを実行できるようになる可能性があります。
サポートされない表に対する変更を防止できる場合は、SQL Applyを使用してアップグレード手順を実行できる場合があります。この方法では、ロジカル・スタンバイ制御ファイルの作成時からアップグレード完了時までは、サポートされない表に対するユーザー変更を禁止する必要があります。たとえば、給与管理部門はオブジェクト表を更新しますが、この部門がデータベースを更新するのは月曜から金曜のみであるとします。一方、カスタマ・サービス部門は1日24時間、1週7日間のデータベース・アクセスを必要としますが、使用するのはサポートされるデータ型および表のみであるとします。この使用例では、週末にアップグレードを実行できます。DBA_LOGSTDBY_EVENTSビューでトランザクション・アクティビティを監視し、最初のスイッチオーバーの実行時までアップグレードを中断できます（必要な場合）。
サポートされない表に対する変更をアップグレード中に防止できない場合、発生したサポートされないトランザクションはロジカル・スタンバイ・データベースのDBA_LOGSTDBY_EVENTS表に記録されます。アップグレードの完了後に、Oracle Data Pumpまたはエクスポート/インポート・ユーティリティを使用して、変更された表をアップグレード後のデータベースにインポートできます。
変更された表のサイズにより、データベース操作が使用できなくなる期間が決定するため、データをエクスポートしてスタンバイ・データベースにインポートするには表が大きすぎないかどうかを判断する必要があります。たとえば、4TBの表は、エクスポート/インポート処理に適した候補ではありません。
ロジカル・スタンバイ・データベースを作成するには、第4章の手順に従います。
停止時間を最短に抑えるために、ロジカル・スタンバイ・データベースでスタンバイREDOログを構成することをお薦めします。
ロジカル・スタンバイ・データベースを作成したので、12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明している手順を実行できます。この手順では、ロジカル・スタンバイで同じOracleソフトウェアを実行していることを前提としています。
この項では、ロジカル・スタンバイ・データベースとプライマリ・データベースをアップグレードする手順について説明します。表12-1に手順を示します。
| 手順 | 説明 |
|---|---|
次の手順に従って、Oracleソフトウェアのローリング・アップグレードの実行準備をします。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
COMPATIBLE初期化パラメータに、アップグレード前のプライマリ・データベースで実行されているOracle Databaseソフトウェアのリリース番号が指定されていることを確認します。
たとえば、プライマリ・データベースでリリース10.1が実行されている場合は、COMPATIBLE初期化パラメータを両方のデータベースで10.1に設定します。COMPATIBLE初期化パラメータは、必ずスタンバイ・データベースで設定してからプライマリ・データベースで設定してください。
ロジカル・スタンバイ・データベース（データベースB）のOracle Databaseソフトウェアをリリースyにアップグレードします。ロジカル・スタンバイ・データベースでは、アップグレード中、プライマリ・データベースからのREDOデータを受け入れません。
データベースBで、PL/SQLプロシージャDBMS_LOGSTDBYを使用して、プライマリ・データベースで実行中の、ロジカル・スタンバイ・データベースではサポートされないトランザクションに関する情報を取得します。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTS表にイベントとして記録します。
EXEC DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);
EXEC DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');
Oracle Databaseソフトウェアをアップグレードするには、該当するOracle Databaseリリースの『Oracle Databaseアップグレード・ガイド』を参照してください。
図12-2に、リリースxを実行中のデータベースAとリリースyを実行中のデータベースBを示します。アップグレード中は、REDOデータがプライマリ・システムに蓄積されます。
|
関連項目
|
SQL Applyを再開し、データベースAではリリースx、データベースBではリリースyで動作させます。SQL Applyを開始するには、データベースBで次の文を発行します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
プライマリ・システムに蓄積されたREDOデータは、新しくアップグレードしたロジカル・スタンバイ・データベースに自動的に転送され、適用されます。Data Guard構成では、アップグレード後のOracle Databaseソフトウェア・リリースが本番環境で正常に実行されるかどうかを確認するために、任意の期間だけ図12-3に示す混合リリースを実行できます。
データベースBがデータベースAとどの程度迅速に一致するかを監視するには、次のようにデータベース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文があるかどうかを確認する必要があります。例12-1に、イベントの監視により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
前述の例で、各エラーの意味は次のとおりです。
この種のエラーは、データベースAで発生した変更の一部がデータベースBに適用されなかったことを示します。この時点で、アップグレード手順を続行するかどうかを判断する必要があります。ロジカル・スタンバイ・データベースとプライマリ・データベース間で、この差異が許容可能であることが確実な場合は、アップグレード手順を続行します。不確実な場合は、アップグレード手順を中断してデータベースBを再インスタンス化し、別の時点でアップグレード手順を実行します。
アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、データベースAで次の文を発行してスイッチオーバーを実行し、データベース・ロールを元に戻します。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
この文は、既存のトランザクションが完了まで待機する必要があります。スイッチオーバーの完了所要時間を最短に抑えるには、データベースAにまだ接続されているユーザーがすぐにログオフし、データベースBに再接続する必要があります。
手順5の「アップグレード後のスタンバイ・データベースでイベントを監視する」では、変更中のサポートされない表をリストする方法について説明しました。プライマリ・データベースでサポートされないDML文が発行された場合は（例12-1を参照）、Oracle Data Pumpなどのインポート・ユーティリティを使用して、各表の最新バージョンをインポートします。
たとえば、次のインポート・コマンドはscott.emp表を切り捨て、前のプライマリ・データベース（A）と一致するデータを移入します。
IMPDP SYSTEM NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_ACTION=TRUNCATE
このコマンドは、実行前にimpdpパスワードの入力を求めてくることに注意してください。
アップグレード後のデータベース・ソフトウェアが正常に動作していることを確認した後、スイッチオーバーを完了してデータベース・ロールを元に戻します。
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 LOGICAL PRIMARY;
スイッチオーバー後は、新規データベース・ソフトウェア・リリースを実行中の新規プライマリ・データベース（B）から旧ソフトウェア・リリースを実行中の新規スタンバイ・データベース（A）には、REDOデータを送信できません。これは次のことを意味します。
図12-4に、前はスタンバイ・データベース（リリースyを実行）で現在はプライマリ・データベースになっているデータベースBと、前はプライマリ・データベース（リリースxを実行）で現在はスタンバイ・データベースになっているデータベースAを示します。ユーザーはデータベースBに接続されます。
データベースBがプライマリ・データベースとして適切に機能でき、ビジネスにプライマリ・データベースをサポートするためのロジカル・スタンバイ・データベースが不要な場合、これでローリング・アップグレード処理は完了です。ユーザーにデータベースBへのログインとそこでの作業開始を許可し、問題のない時点でデータベースAを破棄します。それ以外の場合は、手順9に進みます。
データベースAでは引き続きリリースxが実行されており、アップグレードしてSQL Applyを開始するまでは、データベースBからのREDOデータを適用できません。
Oracle Databaseソフトウェアのアップグレードの詳細は、該当するOracle Databaseリリースの『Oracle Databaseアップグレード・ガイド』を参照してください。
図12-5に、両方のデータベースがアップグレードされた後のシステムを示します。
データベースAで次の文を発行してSQL Applyを開始し、必要に応じてデータベースBへのデータベース・リンクを作成します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NEW PRIMARY db_link_to_b;
データベースAでSQL Applyを開始すると、プライマリ・データベース（B）に蓄積されたREDOデータがロジカル・スタンバイ・データベース（B）に送信されます。すべてのREDOデータがスタンバイ・データベースで使用可能になると、プライマリ・データベースはデータ消失から保護されます。
COMPATIBLE初期化パラメータを設定して、両方のデータベースの互換性レベルを上げます。互換性レベルは、ロジカル・スタンバイ・データベースで上げてから、プライマリ・データベースで上げる必要があります。COMPATIBLEパラメータは、スタンバイ・データベースで設定してからプライマリ・データベースで設定します。COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
データベースBで実行されるすべての変更がロジカル・スタンバイ・データベース（A）に適切に適用されることを確認するために、手順5でデータベースAに対して実行した場合と同様に、DBA_LOGSTDBY_EVENTSビューを頻繁に問い合せる必要があります。（例12-1を参照。）
変更が行われたためにデータベースAが既存のプライマリ・データベースのコピーとして無効になった場合は、データベースAを破棄し、かわりに新規のロジカル・スタンバイ・データベースを作成できます。詳細は、第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。
必要な場合は、データベースAがプライマリ・データベース・ロールで再実行されるように（図12-1を参照）、データベースのスイッチオーバーを再度実行します。
この項の手順では、Oracleソフトウェアのローリング・アップグレードを実行した後に元の構成に戻し、Aがプライマリ・データベース、Bがフィジカル・データベースで、いずれのデータベースもアップグレード後のOracleソフトウェアを実行している状態にする方法について説明します。
表12-2に手順を示します。
| 手順 | 説明 |
|---|---|
|
1 |
|
|
2 |
フィジカル・スタンバイ・データベースをロジカル・スタンバイ・データベースに変換する（データベースBでこの手順を実行する） |
|
3 |
ロジカル・スタンバイ・データベースをアップグレードしてプライマリ・データベースと一致させる（データベースBでこの手順を実行する） |
|
4 |
|
|
5 |
|
|
6 |
|
|
7 |
|
|
8 |
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN;
SQL> CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;
ALTER DATABASE RECOVER TO LOGICAL STANDBY db_nameのかわりに、次のコマンドを発行します。
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY; SQL> ALTER DATABASE OPEN;
SQL> execute DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE'); SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
これで、12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」に示した手順1〜6を実行できます。これらの手順が完了すると、データベースBはアップグレードされたバージョンのOracleソフトウェアを実行するプライマリ・データベースになり、データベースAはロジカル・スタンバイ・データベースになります。
次の手順に進んで、データベースAをデータベースBのフィジカル・スタンバイにします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> FLASHBACK DATABASE TO RESTORE POINT pre_upgrade; SQL> SHUTDOWN IMMEDIATE;
この時点で、上位バージョンのOracleソフトウェアを使用できるように、データベースAでOracleバイナリを切り替える必要があります。データベースAはフィジカル・スタンバイに切り替えられており、データベースBによって生成されたREDOデータを適用して自動的にアップグレードされるため、アップグレード・スクリプトは実行しないでください。
次のようにして、データベースAをマウントします。
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> SHUTDOWN IMMEDIATE;
データベースAは、データベースBにより生成されたREDOデータを適用して、自動的にアップグレードされます。管理リカバリは、プライマリからの新しいインカネーション・ブランチが登録されるまで待機した後、REDOの適用を開始します。
SQL> STARTUP MOUNT; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
この時点で、データベースBはプライマリ・データベース、データベースAはフィジカル・スタンバイです。どちらも上位バージョンのOracleソフトウェアを実行しています。データベースAをプライマリ・データベースにするには、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」の手順に従います。
|
 Copyright © 1999, 2008 Oracle Corporation. All Rights Reserved. |
|