| Oracle® Data Guard概要および管理 11gリリース2 (11.2) B56302-06 |
|
 前 |
 次 |
Oracle Database 10gリリース1(10.1.0.3)からは、ロジカル・スタンバイ・データベースを使用して、Oracle Database 10gソフトウェアのローリング・アップグレードを実行できます。ローリング・アップグレード中は、プライマリ・データベースとロジカル・スタンバイ・データベースで異なるリリースのOracleデータベースを実行しながら、プライマリ・データベースの停止時間を最短に抑えて各リリースを一度に1つずつアップグレードできます。
|
注意: この章では、より停止時間が長い通常のアップグレード手順(付録B「Data Guard構成におけるデータベースのアップグレードおよびダウングレード」を参照)にかわる方法について説明します。この章で説明する方法の手順と、付録Bの手順を組み合せようとしないでください。 |
この章の各手順では、Oracleデータベースのアップグレード中の停止時間を最短に抑える方法について説明します。この章は、次の項目で構成されています。
SQL Applyを使用してローリング・アップグレードを実行する方法には、次のようなメリットがあります。
データベースの停止時間が最短で済みます。停止時間全体がスイッチオーバーの実行所要時間と同様に短時間です。
PL/SQLの再コンパイルによるアプリケーションの停止時間は発生しません。
プライマリ・データベースに影響を与えずに、アップグレード後のデータベース・リリースを検証できます。
ローリング・アップグレード手順の要件は、次のとおりです。
Oracle Databaseリリースxを実行中のプライマリ・データベースとOracle Databaseリリースyを実行中のロジカル・スタンバイ・データベース。
データベースがData Guard Broker構成に含まれていないこと。ブローカ構成からのデータベースの削除の詳細は、『Oracle Data Guard Broker』を参照してください。
Data Guardの保護モードが最大可用性モードまたは最大パフォーマンス・モードに設定されていること。現在の保護モード設定を確認するには、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のローリング・アップグレードを実行するためだけにロジカル・スタンバイ・データベースを作成することを前提にしています。
表12-1に、プライマリ・データベースとスタンバイ・データベースでアップグレードを準備する手順を示します。
プライマリ・データベースでサポートされないデータベース・オブジェクトを識別し、その処理方法を決定する手順は、次のとおりです。
表についてサポートされないデータ型および記憶域属性を識別します。
付録C「ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL」を参照し、サポートされるデータ型および記憶域属性のリストを確認します。
プライマリ・データベースでDBA_LOGSTDBY_UNSUPPORTEDおよびDBA_LOGSTDBY_SKIPビューを問い合せます。プライマリ・データベースで表示された表およびスキーマに対して行われた変更は、ロジカル・スタンバイ・データベースに適用されません。次の問合せを使用して、サポートされない表のリストを確認します。
SQL> SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
次の問合せを使用して、サポートされない内部スキーマのリストを確認します。
SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP - > WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';
サポートされない表の処理方法を決定します。
サポートされないオブジェクトをプライマリ・データベースで変更している場合、アップグレード手順の実行所要時間中、サポートされない表に対する変更を一時的に停止することで、アップグレードを実行できるようになる可能性があります。
サポートされないデータに対する変更を防止できる場合は、SQL Applyを使用してアップグレード手順を実行できることもあります。この方法では、ロジカル・スタンバイ制御ファイルの作成時からアップグレード完了時までは、サポートされない表に対するユーザー変更を禁止する必要があります。たとえば、給与管理部門はオブジェクト表を更新しますが、この部門がデータベースを更新するのは月曜から金曜のみであるとします。一方、カスタマ・サービス部門は1日24時間、1週7日間のデータベース・アクセスを必要としますが、使用するのはサポートされるデータ型および表のみであるとします。この使用例では、週末にアップグレードを実行できます。DBA_LOGSTDBY_EVENTSビューでトランザクション・アクティビティを監視し、最初のスイッチオーバーの実行時までアップグレードを中断できます(必要な場合)。
サポートされない表に対する変更をアップグレード中に防止できない場合、発生したサポートされないトランザクションはロジカル・スタンバイ・データベースのDBA_LOGSTDBY_EVENTS表に記録されます。アップグレードの完了後に、Oracle Data Pumpまたはエクスポート/インポート・ユーティリティを使用して、変更された表をアップグレード後のデータベースにインポートできます。
変更された表のサイズにより、データベース操作が使用できなくなる期間が決定するため、データをエクスポートしてスタンバイ・データベースにインポートするには表が大きすぎないかどうかを判断する必要があります。たとえば、4TBの表は、エクスポート/インポート処理に適した候補ではありません。
|
注意: アプリケーション内のデータ型がサポートされていないためにロジカル・スタンバイ・データベースを使用できない場合、『Oracle Databaseアップグレード・ガイド』に記載の方法に従ってアップグレードを実行します。 |
ロジカル・スタンバイ・データベースを作成するには、第4章の手順に従います。
|
注意: SQL Applyを初めて実行する前に、プライマリ・データベースで実行中の、ロジカル・スタンバイ・データベースではサポートされないトランザクションに関する情報を取得します。次のプロシージャを実行して情報を取得し、DBA_LOGSTDBY_EVENTSビューにイベントとして記録します。
EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',
DBMS_LOGSTDBY.MAX_EVENTS);
EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS',
'TRUE');
|
停止時間を最短に抑えるために、ロジカル・スタンバイ・データベースでスタンバイREDOログを構成することをお薦めします。
ロジカル・スタンバイ・データベースを作成したので、12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明している手順を実行できます。この手順では、ロジカル・スタンバイで同じOracleソフトウェアを実行していることを前提としています。
この項では、ロジカル・スタンバイ・データベースとプライマリ・データベースをアップグレードする手順について説明します。表12-2に手順を示します。
表12-2 既存のロジカル・スタンバイを使用したローリング・アップグレードの実行手順
| 手順 | 説明 |
|---|---|
|
|
|
|
|
|
|
|
アップグレード後のロジカル・スタンバイ・データベースでSQL Applyを再開する |
|
|
アップグレード後のスタンバイ・データベースでイベントを監視する |
|
|
|
|
|
|
|
|
スイッチオーバーを完了してユーザー・アプリケーションをアクティブ化する |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次の手順に従って、Oracleソフトウェアのローリング・アップグレードの実行準備をします。
ロジカル・スタンバイ・データベース(データベースB)で次の文を発行し、SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
必要に応じて、互換性を最高値に設定します。
COMPATIBLE初期化パラメータに、アップグレード前のプライマリ・データベースで実行されているOracle Databaseソフトウェアのリリース番号が指定されていることを確認します。
たとえば、プライマリ・データベースでリリース10.1が実行されている場合は、COMPATIBLE初期化パラメータを両方のデータベースで10.1に設定します。COMPATIBLE初期化パラメータは、必ずスタンバイ・データベースで設定してからプライマリ・データベースで設定してください。
ロジカル・スタンバイ・データベース(データベースB)のOracle Databaseソフトウェアをリリースyにアップグレードします。ロジカル・スタンバイ・データベースでは、アップグレード中、プライマリ・データベースからのREDOデータを受け入れません。
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に示す混合リリースを実行できます。
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文があるかどうかを確認する必要があります。例12-1に、イベントの監視により2つのデータベースにおける潜在的な差異を把握する方法を示します。
例12-1 DBA_LOGSTDBY_EVENTSを使用したイベントの監視
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に再接続する必要があります。
|
注意: 8.3.1項で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。 |
|
注意: データベースAがプライマリ・データベースのときに、そこでサポートされない表またはパッケージに対するアクティビティを一時停止した場合、最終的にデータベースAに切り替える計画であれば、データベースBがプライマリ・データベースになっている間にデータベースBでも引き続き同じアクティビティを一時停止する必要があります。 |
手順4「アップグレード後のスタンバイ・データベースでイベントを監視する」では、変更中のサポートされない表をリストする方法について説明しました。プライマリ・データベースでサポートされないDML文が発行された場合は(例12-1を参照)、Oracle Data Pumpなどのインポート・ユーティリティを使用して、各表の最新バージョンをインポートします。
たとえば、次のインポート・コマンドはscott.emp表を切り捨て、前のプライマリ・データベース(A)と一致するデータを移入します。
IMPDP SYSTEM NETWORK_LINK=DATABASEA TABLES=SCOTT.EMP TABLE_EXIST_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;
|
注意: 8.3.1項で説明した通常の2フェーズ準備済スイッチオーバーは、同じバージョンのOracleソフトウェアの実行にプライマリ・データベースとスタンバイ・データベースの両方が必要であり、この時点でプライマリ・データベースは下位バージョンのOracleソフトウェアを実行しているため、使用できません。かわりに、前述の1フェーズ準備なしスイッチオーバーの手順を使用します。準備なしスイッチオーバーは、ロジカル・スタンバイ・データベースを使用するローリング・アップグレードの場合にのみ使用してください。 |
現在はプライマリ・データベース・ロールで実行中のデータベースBで、ユーザー・アプリケーションとサービスをアクティブ化します。
スイッチオーバー後は、新規データベース・ソフトウェア・リリースを実行中の新規プライマリ・データベース(B)から旧ソフトウェア・リリースを実行中の新規スタンバイ・データベース(A)には、REDOデータを送信できません。これは次のことを意味します。
REDOデータは、新規プライマリ・データベースに蓄積されます。
新規プライマリ・データベースは、この時点では保護されていません。
図12-4に、前はスタンバイ・データベース(リリースyを実行)で現在はプライマリ・データベースになっているデータベースBと、前はプライマリ・データベース(リリースxを実行)で現在はスタンバイ・データベースになっているデータベースAを示します。ユーザーはデータベースBに接続されます。
データベースBがプライマリ・データベースとして適切に機能でき、ビジネスにプライマリ・データベースをサポートするためのロジカル・スタンバイ・データベースが不要な場合、これでローリング・アップグレード処理は完了です。ユーザーにデータベースBへのログインとそこでの作業開始を許可し、問題のない時点でデータベースAを破棄します。それ以外の場合は、手順8に進みます。
データベース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;
|
注意: データベース・リンクを作成し(まだ設定されていない場合)、NEW PRIMARY句を使用する必要があります。これは、手順4で1フェーズ準備なしスイッチオーバーを使用してデータベースAをスタンバイ・データベースに切り替えたためです。
ユーザー |
データベースAでSQL Applyを開始すると、プライマリ・データベース(B)に蓄積されたREDOデータがロジカル・スタンバイ・データベース(B)に送信されます。すべてのREDOデータがスタンバイ・データベースで使用可能になると、プライマリ・データベースはデータ消失から保護されます。
COMPATIBLE初期化パラメータを設定して、両方のデータベースの互換性レベルを上げます。互換性レベルは、ロジカル・スタンバイ・データベースで上げてから、プライマリ・データベースで上げる必要があります。COMPATIBLEパラメータは、スタンバイ・データベースで設定してからプライマリ・データベースで設定します。COMPATIBLE初期化パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください。
Database Bで行ったすべての変更がロジカル・スタンバイ・データベース(A)に正しく適用されていることを確認するには、手順4でDatabase Aに対して行ったように、DBA_LOGSTDBY_EVENTSビューの問合せを頻繁に行う必要があります。(例12-1を参照)。
変更が行われたためにデータベースAが既存のプライマリ・データベースのコピーとして無効になった場合は、データベースAを破棄し、かわりに新規のロジカル・スタンバイ・データベースを作成できます。詳細は、第4章「ロジカル・スタンバイ・データベースの作成」を参照してください。
必要な場合は、データベースAがプライマリ・データベース・ロールで再実行されるように(図12-1を参照)、データベースのスイッチオーバーを再度実行します。
この項の手順では、Oracleソフトウェアのローリング・アップグレードを実行した後に元の構成に戻し、Aがプライマリ・データベース、Bがフィジカル・データベースで、いずれのデータベースもアップグレード後のOracleソフトウェアを実行している状態にする方法について説明します。
|
注意: この項の手順では、プライマリ・データベース(A)とフィジカル・スタンバイ・データベース(B)が設定済で、Oracle Databaseリリース11.1以降を使用していることを前提にしています。 |
表12-3に関係する手順をまとめます。
表12-3 既存のフィジカル・スタンバイを使用したローリング・アップグレードの実行手順
まだ有効でない場合、フラッシュバック・データベースを有効にします。
SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE FLASHBACK ON; SQL> ALTER DATABASE OPEN;
保証付きリストア・ポイントを作成します。
SQL> CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;
次の点を除き、第4章「ロジカル・スタンバイ・データベースの作成」に記載の手順に従います。4.2.4.1項「ロジカル・スタンバイ・データベースへの変換」では、別なコマンドを使用してロジカル・スタンバイ・データベースの変換を行う必要があります。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;
|
関連項目:
|
12.5項「既存のロジカル・スタンバイ・データベースを使用したローリング・アップグレードの実行」で説明されているとおり、手順1から8を実行できるようになりました。これらの手順が完了すると、データベース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;
|
注意: REDO Applyが再開するとき、現行のプライマリ・データベース(データベースB)からの新しいインカネーションが登録されるのを待機します。 |
この時点では、Database Bがプライマリ・データベースでDatabase Aがフィジカル・スタンバイで、両方ともOracleソフトウェアの上位バージョンを実行しています。Database Aをプライマリ・データベースにするには、8.2.1項「フィジカル・スタンバイ・データベースへのスイッチオーバーの実行」に記載の手順を実行します。
ディスク領域を保持するために、既存の保証付きリストア・ポイントを削除します。
SQL> DROP RESTORE POINT PRE_UPGRADE;
|
関連項目: Oracle Maximum Availability Architecture(MAA)のホームページで入手できるベスト・プラクティスに関するホワイト・ペーパー『Database Rolling Upgrade Using Transient Logical Standby: Oracle Data Guard 11g』 |
