| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
|
前 |
次 |
SOA SuiteおよびBPM 12cの標準アップグレード・プロセスでは、オープンおよびクローズされたSOAインスタンスの自動アップグレード・ソリューションを提供します。閉じているインスタンスのアップグレードは、次の各項で説明する管理スクリプトで監視および管理できます。
アップグレード・アシスタントのフレームワークでは、スキーマのアップグレードは各コンポーネントのインストール(MDS、ORASDPM、OPSS、SOAなど)に委託します。12c SOAのアップグレード時に、アップグレード・アシスタントでインスタンスをアップグレードすることもできます。
アップグレードされる内容
SOAのインストールでは、アップグレード・プロセスの一環として各種コンポーネント(_MDSスキーマや_SOAINFRAスキーマなどを含む)もアップグレードされます。_SOAINFRAスキーマには、次のスキーマ・コンポーネントが格納されています。
スキーマの定義: 表や索引など
メタデータ: SOAサーバーとSOAコンポジットの実行に必要になるデータ
注意:
BPMメタデータのアップグレードは、Business Process Composer 12c (12.2.1)に最初にログインすると(アップグレード完了後)開始されます。
Business Process Composerの使用の詳細は、Oracle Business Process Composerを使用したビジネス・プロセスの開発を参照してください。
インスタンス・データ: 各種コンポーネントで作成されたデータ。インスタンスは、オープンまたはクローズのどちらかになります。
これらのコンポーネントのアップグレード方法
12cスキーマのアップグレード・プロセス時に、これらのコンポーネントがどのような順序でUAによってアップグレードされるかについて理解することが重要です。
アップグレードは、次に示す4つの異なる段階で行われます。
アップグレード・アシスタントにより、11gスキーマの定義がアップグレードされます。
その後、アップグレード・アシスタントにより、11gメタデータがアップグレードされ、オープン・インスタンスをアップグレードするためのバックグラウンド制御ジョブが作成されます。
注意: このプロセスには時間がかかることがあります。これは、最後のデータベース・ジョブがオープン・インスタンスのアップグレードを完了するまで、各ジョブがUAで実行され続けるためです。最後のジョブが完了するまで、アップグレード・アシスタントを終了しないことが重要になります。
たとえば、インスタンスのアップグレードに必要な時間は、次の項目に応じて異なります。
接頭辞_SOAINFRAスキーマのサイズ(オープンおよびクローズされたインスタンス数)
システム構成(CPIの数(コア数)、メモリーの使用状況、ディスクI/O構成)。
システムの速度とドライバ表のサイズ
すべてのオープン・インスタンスのアップグレードが完了すると、クローズされたインスタンスをアップグレードするバックグラウンド・ジョブが開始されます。クローズされたインスタンスのアップグレードは、アップグレード・アシスタントのクローズ後も、バックグラウンドで継続される点に注意してください。ただし、バックグラウンド・ジョブが停止されたときに、アップグレード対象のクローズされたインスタンスが残っている場合は、管理スクリプトを使用してこれらを再開する必要があります。
最終的に、最後のジョブがオープン・インスタンスのアップグレードを完了すると、アップグレード・アシスタントによりアップグレード・ステータスが示され、アップグレード・プロセスの後続の手順がリストされます。
アップグレード・アシスタントの「アップグレード成功」画面に示された情報を基にして、次に実行する手順を判断してください。注意: -response (サイレント)モードで実行すると、この情報はUAのstdoutファイルにリストされます。
アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。
アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。
アップグレード・アシスタントの終了後には、クローズしたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。
Oracle SOA 1. The Upgrade Assistant has successfully upgraded all open instances. You can now close the Upgrade Assistant. 2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy. Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.
注意:
クローズされたインスタンスのアップグレードは、すべてのインスタンスのアップグレードが完了するか、中間層(SOA管理対象サーバーなど)が開始されるまで継続されます。
すべてのクローズされたインスタンスのアップグレードが完了する前に中間層が開始されると、アップグレード・ジョブは停止します。管理スクリプトを使用して、手動でアップグレードを再開する必要があります。
バックグラウンド・ジョブは、_SOAINFRAスキーマのアップグレード時に、アップグレード・アシスタントによって作成されます。このようなジョブは、バックグラウンドで実行され、オープンおよびクローズされたインスタンス・データを自動的にアップグレードします。このようなジョブがアップグレード・プロセスで動作する方法と、そのジョブを管理する方法について理解することが重要になります。次のリストでは、このようなジョブに関する重要な情報について説明します。
ジョブの作成はアップグレード・アシスタント(UA)で行いますが、ジョブの管理は管理スクリプトで行います。管理スクリプトを使用することで、たとえば、このようなジョブを実行する方法や時期を構成できます。
ジョブは、スキーマのアップグレード・プロセス後に、自動的に開始されます。
UAから開始されたジョブは、次のいずれかの状況が発生すると自動的に停止します。
ジョブが完了して、クローズされたすべてのインスタンスが12cに移行された
中間層アプリケーションが開始された(管理対象サーバーなど)
ジョブ停止スクリプト(オプション8)が開始された
クローズされたインスタンスのアップグレードが完了していない場合は、アップグレード・アシスタントの終了後も、バックグラウンド・ジョブがバックグラウンドで続行されます。
ジョブが停止されたときに、アップグレード対象のインスタンスが残っている場合は、管理スクリプトを使用することで、別のときにジョブを実行することも、ジョブを実行するようにスケジュールすることもできます。
バックグラウンド・ジョブの構成の詳細は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」、「アップグレードのセッションとジョブの停止」および「不完全なアップグレードの再開」を参照してください。
12c SOAでは、インスタンスがECIDではなくflowIDを使用して制御されます。アップグレード・アシスタントでインスタンスを11g SOAから12c SOAにアップグレードすると、アップグレードした11gのフロー・インスタンスと新しく作成した12cインスタンスには、いくつかの相違点があります。このような相違点がフロー・トレースの機能性に影響を与えることはありませんが、その相違点に注意することは重要です。
後述するフロー・トレースXMLの例には、次のような相違点が示されています。
ActionType属性とActionName属性は、新しく12cに導入されたもので、アップグレードした11gインスタンスでは使用できません。
アップグレードした11gインスタンスの場合、DateとlastUpdatedDateは同じです。
アップグレードした11gインスタンスの場合、Entry Instance IdのElapsedTimeは0になります。
11gから12cにアップグレードしたインスタンスのフロー・トレースXML:
================================ <audit_trail ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e" flowId="96102" flowCorrelationId="null" activeInstances="0" date="2013-09-02 00:09:52.133 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT" elapsedTime="23"> <entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02 00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT" elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel" type="component"> ... </entry> </audit_trail>
新しく作成した12cインスタンスのフロー・トレースXML:
====================================
<audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a" flowId="6"
flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M" activeInstances="0"
date="2013-10-28 05:35:12.738 PDT" lastUpdatedDate="2013-10-28 05:35:12.825
PDT" elapsedTime="87">
<entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
...
</entry>
</audit_trail>
さらに、BPELで捕捉されたフォルトについて、12cで作成した新しいインスタンスのリカバリ・ステータスは、図9-1に示すようにrecoveredと表示されます。
Nonrecoverableと表示されます。注意:
11gのフォルトから渡された情報は、フォルトの状態を正しく識別するのに十分ではありません。これに対処するために、11gから取得された実際のフォルトはすべて、最初はリカバリ不能として識別されます。その後、ダミーのフォルトが作成されて、適切な状態(BPEL_invoke_recovery、Bpel_activity_recovery)に設定されます。 したがって、11gのフォルトがリカバリ不能であるという警告が表示された場合や、そのことに気づいた場合、警告を無視してかまいません。インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。12cパージ・スクリプトには、移行対象外のクローズされたインスタンスが含まれています。つまり、アップグレード後、12cパージ・スクリプトの実行をスケジュールすると、移行対象外のクローズされたインスタンスがスクリプトでパージされます。パージ・スクリプトを使用してクローズされたインスタンスを削除すると、アップグレードの全体的なパフォーマンスを向上できます。
注意:
オープン・インスタンスのみをアップグレードすると、中断されたステータス・フローが表示されることがあります。子フローが11gで中断されていると、フローは中断状態になります。
このECIDに関連付けられたすべてのコンポジット・インスタンスは、終了状態を維持します。
自動パージまたはパージ・スクリプトの使用の詳細は、「データベース増分の管理」を参照してください。
注意:
アップグレード・アシスタントのバックグラウンド・ジョブの実行中に、パージ・ジョブを実行するようにスケジュールしないでください。アップグレード・アシスタントの実行中にスクリプトを実行すると、パージまたはアップグレードが失敗することがあります。
Upgrade Assistantの実行中にパージ・スクリプトを実行するように構成すると、ORA-20099: ERROR 11gから12cへのアップグレードが進行中ですというメッセージが表示されます。
パージ・スクリプトの実行中にUAを実行すると、SQLException: ORA-00054: リソース・ビジー。NOWAITが指定されているか、タイムアウトしましたというメッセージが表示されます。
アップグレード管理スクリプトは、SOA Suiteのインストールに付属するUpgrade Assistant機能の一部として含まれています。このようなPL/SQLスクリプトは、インスタンスのアップグレード全体に追加的な管理制御を提供します。アップグレードが完了すると、Oracle Enterprise Manager Consoleでインスタンスを表示できるようになります。さらに詳しいアップグレード・プロセスの情報が必要な場合は、追加のレポートおよび構成オプションに対応した管理スクリプトを使用してください。
注意:
管理アップグレード・スクリプトにより、アップグレードに関する詳細情報が示されます。このようなスクリプトにより、インスタンス・アップグレードに対する追加の構成、管理および監視機能が得られます。このようなスクリプトは、独自の要件に基づいて実行するように(または実行しないように)構成できます。
Fusion Middleware Control Consoleを使用してアップグレード・プロセスを管理および監視することもできますが、管理スクリプトを使用するほうが管理オプションが多くなります。
クローズされたインスタンスのアップグレードを監視するためにアップグレード・アシスタントを使用した後には、Report Upgrade Summary(オプション1)スクリプトを実行することをお薦めします。
アップグレードの進行状況の監視にFusion Middleware Controlコンソールを使用する方法の詳細は、「Fusion Middleware Controlによるアップグレード・ステータスの監視」を参照してください。
インスタンス・アップグレードを構成、管理および監視するために使用できるスクリプトは複数あります。これらのスクリプトへのアクセスには、soa_upgrade_menu PL/SQLスクリプトを使用できます。
アップグレード・スクリプト・メニューにアクセスするには:
SOAホームの/adminディレクトリに移動します。
次に例を示します。
cd <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/upgrade/admin
SQL* Plusを使用して、スキーマ所有者の名前とパスワードで_SOAINFRAスキーマにアクセスします。
次に例を示します。
sqlplus dev_soainfra/<welcome1>
devは、SOAINFRAスキーマの作成時に使用したスキーマ所有者の接頭辞、welcome1は、スキーマのパスワードになります。
注意:
<接頭辞>_SOAINFRA以外のユーザーを使用して、管理スクリプトにアクセスしようとすると、次のエラー メッセージが表示されます。
ERROR at line 24: ORA-06550: line 24, column 3: PLS-00201: identifier 'CONTROL_MIGRATION.UPGRADE_STATUS_INFO' must be declared
soa_upgrade_menu.sqlスクリプトを実行して、アップグレードの管理オプション・メニューを表示します。
SQL> @soa_upgrade_menu.sql ================================================== 1: Report upgrade summary. 2: Report upgrade database sessions (Running sessions). 3: Report upgrade database background jobs (Completed jobs). 4: Report background control job parameters. 5: Change background control job execution schedule. 6: Enable/Disable background control job. . Advanced Options: . 7: Change background control job parameters. 8: Stop upgrade database background sessions and jobs. 9: Reset errored 11g instances. 10: Report Current job run log (Oracle Internal Use). . 11: EXIT. . . (NOTE: for error SP2-0309, please restart menu) . Enter option : ***********************************************************************************************
表9-1では、各スクリプトの機能について説明しています。
管理スクリプトのメイン・メニューには、バックグラウンド制御ジョブとその他の管理タスク(トラブルシューティングなど)の監視と管理に必要になるすべてのオプションが表示されます。
注意:
拡張オプションは、アップグレードのトラブルシューティングを行う場合や、特定のアップグレード要件に基づいてアップグレード・プロセスに変更を加える場合にのみ使用します。多くの場合、このようなスクリプトは、指名されたシステム管理者またはOracleサポートのみが実行します。
管理スクリプトのいずれかを実行するには、プロンプトが表示されているときにオプション番号を入力します。表9-1では、各スクリプトの機能について説明しています。
表9-1 アップグレード管理スクリプトのメニュー・オプション
| オプション番号 | スクリプト名 | このオプションの用途 | 説明 |
|---|---|---|---|
1 |
Report Upgrade Summary |
アップグレードの全体的なステータスを表示します。 |
このレポートは、サブセクションに分割されていて、アップグレード全体の概要と現在の実行が示されます。
さらに、次の事項についての説明されています。
レポート・データは、次のように示されます。 ============================================= Report Upgrade Summary (Please wait for report to generate) ============================================= . . METADATA : COMPLETE . OPEN FLOWS : COMPLETE . ALL FLOWS : COMPLETE . . ------------------------------------------ . Date of last upgraded and closed 11g Flows . ------------------------------------------ . DATE : NOT AVAILABLE OR ALL DATA UPGRADED . . NOTE: Closed 11g flows prior to this date . may not be visible on the EM console . until they are upgraded. . . --------------------- . UPGRADE ERROR COUNT . --------------------- . COUNT : 0 PL/SQL procedure successfully completed. Enter to continue.. . --------------------------------------------- Upgrade Start Date and Initial Instance Count --------------------------------------------- . Upgrade Start Date : 06/MAY/2014:04/50 . Initial Instance Count : 1881 . Outstanding Instances Count : 0 . ------------------------------------ CURRENT RUN STATISTICS (run#: 1) ------------------------------------ . Note: 1/ Statistics maybe from previous run . until new statistics are generated. . 2/ Statistics can take 10mins to refresh. . . STARTED: 06/MAY/2014:04/50 . ENDED: 06/MAY/2014:04/52 . START COUNT: 1881 . PROCESSED COUNT: 1881 . REMAINING COUNT: 0 . ========= End of Report ===================== Upgrade Counter (Oracle Internal Use): < 300 |
2 |
Report upgrade database sessions (実行中のセッション) |
現在実行中のジョブを特定します。 この情報は、手動でジョブを強制終了するために使用しないでください。 |
このオプションにより、実行中のセッションのデータがModule、Inst、SidおよびSerialの各列に返されます。 次に例を示します。 ====================================================== Report Upgrade Database Sessions (Running) ====================================================== . Module Inst Sid Serial --- -- -- ---- SOAUPGRADECONTROLMAIN 1 122 16535 SOAUPGRADEDATA_0 1 228 14557 SOAUPGRADEDATA_1 1 64 46683 SOAUPGRADEDATA_2 1 180 621 SOAUPGRADEDATA_3 1 130 61577 SOAUPGRADESUBMITJOBS 1 172 66 ジョブの完了は、データベース・スケジューラのジョブ・ログで監視します。 注意: この情報はセッションを停止するために使用しないでください。「アップグレードのセッションとジョブの停止」の説明に従って、管理スクリプトを使用してください。 |
3 |
Report upgrade database background jobs (完了済ジョブ)。 |
アップグレードが完了したジョブを特定します。 |
インスタンス・アップグレードを実行するデータベース・セッションは、データベース・ジョブとして実行されます。ジョブが完了すると、このオプションでステータスを確認できます。ユーザーが各ジョブの実行内容を理解することを期待しているのではなく、エラーなく成功していることがステータスに示されていることを確認できるようにするものです。 このレポ－トには、制御ジョブのパラメータ値、発行されたアップグレード・ジョブ、ジョブの現行ステータス(発行済、待機中、実行中)およびジョブのスレッド番号(該当する場合)が表示されます。 次に例を示します。 ====================================================== Report Upgrade Database Background Jobs (Completed) ====================================================== . . State of last 15 completed Jobs in descending order . Log_date Job_name Status ERROR ---- ---- --- ---- 21-FEB-2014 03:07:36 UPGRADE_SOA_METADATA_JOB SUCCEEDED 0 |
4 |
Report background control job parameters |
現行のバックグラウンド制御ジョブのパラメータを表示します。 |
このオプションにより、インスタンスのアップグレードを調整する制御ジョブに渡されたパラメータがレポートされます。 ====================================================== Report Backgrond Control Job Parameters ------------------------------------------------------ BATCH_SIZE : 10000 MAX_COUNT : 100000 JOB_MAX_RUNTIME : 240 DOP : 4 METADATA_JOB_COMPLETE : TRUE OPEN_ECIDS_COMPLETE : FALSE DATA_JOB_COMPLETE : FALSE CTL_MAX_RUNTIME : 1 FIRST_TIME : FALSE FIRST_CTL_MAX_RUNTIME : 0 FIRST_JOB_MAX_RUNTIME : 0 SQL_TRACE : FALSE METRICS : TRUE ASYNC : TRUE ----------------------- ENABLE : FALSE REPEAT INTERVAL : freq=daily; byhour=3; byminute=0; bysecond=0 |
5 |
Change background control job execution schedule |
バックグラウンド制御ジョブの繰り返し間隔と継続時間を変更します。 |
デフォルトでは、バックグラウンド制御ジョブの間隔は、クローズされたすべてのインスタンスのアップグレードが完了するまで、毎日午前3時(ローカル時間)に開始され4時間(240分)実行されます(具体的な設定は、freq=daily; byhour=3; byminute=0; bysecond=0です)。このジョブを別の時間に実行するには、このオプションを使用して繰り返し間隔を変更します。 Change Background Control Job Execution Schedule - Repeat Interval ================================================================== The repeat interval determines when the control procedure is executed by the database scheduler. Examples of repeat intervals can be found in the Oracle Database Administors Guide. Enter REPEAT INTERVAL: 詳細は、「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照してください。 注意: 実行の継続時間(デフォルトは240分)を変更するには、Change Background Control Job Parameters (オプション7)を使用して、 |
6 |
Enable/Disable background control job |
バックグラウンド・ジョブを有効または無効にします。 |
デフォルトでは、Enable/Disable background control jobは無効にされています( この設定は、サマリー・レポートでは 現在の設定を維持するには、N (No)を入力します。 ENABLE/DISABLE CONTROL JOB SCHEDULE =================================== Disabling the Control Schedule will stop the Control job from executing at the specified Repeat Interval. Change ENABLE Y/N: 詳細は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」を参照してください。 |
7 |
Change background control job parameters |
BATCH_SIZE、MAX_COUNT、JOB_MAX _RUNTIMEまたはDOP (並列度)を変更します(オプション1-4)。 拡張オプション(オプション5-14)は、アップグレードのトラブルシューティングのために、Oracleサポートによる指示があった場合を除いて変更しないでください。 |
ほとんどのアップグレードに対して、バックグラウンド制御ジョブのパラメータはデフォルトの値で十分です。それでも変更が必要な場合は、「制御ジョブ・パラメータの設定(オプション7)」のパラメータの説明を確認してください。 1: Set BATCH_SIZE 2: Set MAX_COUNT 3: Set JOB_MAX_RUNTIME 4: Set DOP . Advanced Options: . (Options below for Oracle Internal Use) . (Please contact Oracle Support) . 5: Set METADATA_JOB_COMPLETE 6: Set DATA_JOB_COMPLETE 7: Set OPEN_ECIDS_COMPLETE 8: Set CTL_MAX_RUNTIME 9: Set FIRST_TIME 10: Set FIRST_CTL_MAX_RUNTIME 11: Set FIRST_JOB_MAX_RUNTIME 12: Set SQL_TRACE 13: Set METRICS 14: Set ASYNC . 15: MAIN MENU . Enter option : |
8 |
Stop upgrade database background sessions and jobs |
現行のデータベースのセッションまたはジョブを停止します。 |
このオプションを使用して、「アップグレードのセッションとジョブの停止」の説明に従い、現行のバックグラウンド・ジョブまたはセッションを正常に停止します。 Stop Upgrade Database Background Sessions/Jobs ============================================== All upgrade sessions and jobs should stop but this may require 5 minutes to take affect. There will be a one minute wait before this procedure returns. Are you sure Y/N: Y Enter for MENU |
9 Reset errored 11g instances |
アップグレードの実行後、upgrade_error_logを確認して、報告されたエラーを修正します。その後で、このオプションを使用して、次回のアップグレード・ジョブで再度処理されるように該当するインスタンスを再発行します。 |
このオプションにより、エラーの発生したインスタンスを次回のアップグレード・ジョブで再処理できるようになります。このオプションを使用する前に、upgrade_error_logで報告されたエラーを必ず修正しておいてください。 Reset errored 11g instances ======================= The 11g instances which have encountered an error will have their flow_id set to -1. This reset updates the flow_id back to null so they can be processed in the next exection of the background job. . The rows in the upgrade_error_log table will have their type column set to zero. The rows in this table are not removed so that history is not lost. . NOTE: Ensure to schedule and enable the background job. Are you sure Y/N: |
|
10 Report Current job run log (Oracleの内部使用) |
現行の実行で使用されているパラメータを示す、Oracleサポート向けのレポートを生成します。 |
このレポートの出力は、アップグレードのトラブルシューティング時にOracleサポートに送信できます。 また、このレポートは、制御ジョブのパラメータに加えた変更が正しいことを確認するためにも使用できます。 Example: ====================================================== Report Current RUN log (Oracle Internal Use) ====================================================== . Module Type Comment --- --- ----- CONTROL PARM batch_size => 10000 CONTROL PARM max_count => 100000 CONTROL PARM use_ctl_max_runtime => 0 CONTROL PARM use_job_max_runtime => 0 CONTROL PARM DOP => 4 CONTROL PARM metadata_job_complete => FALSE CONTROL PARM data_job_complete => FALSE CONTROL PARM open_ecids_complete => FALSE CONTROL PARM first_time => TRUE CONTROL PARM sql_trace => FALSE CONTROL PARM metrics => TRUE CONTROL PARM async => TRUE CONTROL PARM ctl_stoptime_d => NULL CONTROL PARM job_stoptime_d => NULL CONTROL INFO UPGRADE jobs submitted ASYNCRONOUS METADATA INFO UPGRADE submitting: UPGRADE_SOA_METADATA_JOB CONTROL INFO CONTROL procedure waiting for (metadata and/or open ecids) METADATA INFO UPGRADE UPGRADE_SOA_JOB will wait for UPGRADE_SOA_METADATA_J DATA INFO UPGRADE submitting: UPGRADE_SOA_JOB0 DATA INFO UPGRADE submitting: UPGRADE_SOA_JOB1 DATA INFO UPGRADE submitting: UPGRADE_SOA_JOB2 DATA INFO UPGRADE submitting: UPGRADE_SOA_JOB3 DATA INFO UPGRADE will wait if UPGRADE_SOA_JOB running |
|
11 Exit |
スクリプト管理メニューを閉じます。 |
このオプションで、メニューが閉じられます。 |
この項では、アップグレード管理スクリプトの構成に必要な手順について説明します。
バックグラウンド制御ジョブの実行スケジュールを変更するには、オプション5を使用します。
次に示す例では、ジョブの開始時間が午前3時から午前4時(ローカル時間)に変更されています。
Change Background Control Job Execution Schedule - Repeat Interval ================================================================== The repeat interval determines when the control procedure is executed by the database scheduler. Examples of repeat intervals can be found in the Oracle Database Administors Guide. Enter REPEAT INTERVAL: freq=daily; byhour=4; BEFORE Change : freq=daily; byhour=3;byminute=0; bysecond=0 AFTER Change : freq=daily; byhour=4
Enable/Disable Background Control Jobスクリプト(オプション6)を使用すると、バックグラウンド制御ジョブの開始を有効にしたり、スケジュールされた制御ジョブの開始を禁止したりできます。T
注意:
バックグラウンド制御ジョブは、デフォルトで無効にされています(ENABLE: FALSE)。このジョブを手動で有効にする(ENABLE: TRUE)場合は、ジョブの無効化も手動で行う必要があります。
ENABLE/DISABLE CONTROL JOB SCHEDULE =================================== Disabling the Control Schedule will stop the Control job from executing at the specified Repeat Interval. Change ENABLE Y/N:
Set Control Job Parametersスクリプト(option 7)を使用すると、表9-2で説明するパラメータを構成できます。
表9-2 バックグラウンド制御ジョブのパラメータ
| パラメータ | デフォルト値 | 説明 |
|---|---|---|
BATCH_SIZE |
10000 |
実行のため、一度にデータベースに送信する更新(挿入、更新および削除)の数を決定します。 |
MAX_COUNT |
100000 |
別のMAX_COUNT相当のインスタンス数がフェッチされる前に、アップグレードのためにフェッチされるインスタンス数(ECID)を決定します。 |
JOB_MAX_RUNTIME |
240分(4時間) |
バックグラウンド制御ジョブが実行される最大の分数です。 |
DOP |
4 |
1つの操作に関連付けられるパラレル実行サーバーの数は、並列度 (DOP)と呼ばれます。パラレル実行は複数のCPUを効率よく使用するためのものです。 注意: 並列度の変更は拡張オプションになります。各自のデプロイメントに適した並列度の設定の詳細は、データベース管理ドキュメントを参照してください。 |
SQL_TRACE |
FALSE |
注意: を $ sqlplus / as sysdba SQL> grant alter session to <soainfra>; |
ジョブ制御パラメータを変更するには:
実行中にアップグレードのエラーが発生した場合は、問題を解決してから、エラーのflow_idを(-1)からNullにリセットすることでエラーが発生したインスタンスを再発行します。このインスタンスは、次回にスケジュールされたバックグラウンド制御ジョブの実行で処理されます。
詳細は、「インスタンス・アップグレードのエラーの解決」を参照してください。
Reset errored 11g instances ======================= The 11g instances which have encountered an error will have their flow_id set to -1. This reset updates the flow_id back to null so they can be processed in the next exection of the background job. . The rows in the upgrade_error_log table will have their type column set to zero. The rows in this table are not removed so that history is not lost. . NOTE: Ensure to schedule and enable the background job. Are you sure Y/N:
管理スクリプトを使用すると、実行中のセッションまたはジョブを停止できます。
注意:
実行中のアップグレードジョブを完了前に停止すると、Enterprise Managerコンソールを使用して残りのデータの問合せや表示ができなくなります。
バックグラウンド・ジョブでは、最新のインスタンスを最初にアップグレードするため、Upgrade Summary Report (Option 1)のMaximum Upgrade Date for Closed 11g instancesセクションで、最後にアップグレードされたインスタンスのタイムスタンプを調べることで、アップグレードの進行状況を確認できます。
次に示すように、読取り専用インスタンスのアップグレードを停止する方法は2通りあります。
バックグラウンドのデータベース制御ジョブが開始されていたら、Stop Upgrade Database Background Sessions and Jobスクリプト(オプション8)を使用して、現在実行中のアップグレード・セッションとジョブをすべて停止します。すべてのジョブが停止するまでに、数分かかることがあります。
Stop Upgrade Database Background Sessions/Jobs ============================================== All upgrade sessions and jobs should stop but this may require 5 minutes to take affect. There will be a one minute wait before this procedure returns. Are you sure Y/N: Y Enter for MENU
Report Upgrade Database Sessions (オプション2)を使用して、実行中のジョブがないことを確認します。アップグレード・ジョブは、ユーザーが定義した時間にジョブを実行するようにスケジュールすることで、必要に応じて再開できます。この方法を使用することをお薦めします。
中間層アプリケーション(SOA管理対象サーバーなど)を起動します。
中間層アプリケーション(管理対象サーバーなど)が起動されると、クローズされたインスタンスのアップグレードが自動的に停止されます。管理スクリプトを使用すると、アップグレード・ジョブを別のときに実行するようにスケジュールできます。
この項では、管理スクリプトとともに、アップグレードの監視と検証に使用できるSQL問合せについて説明します。
| 検証内容 | 使用する問合せ | 詳細 |
|---|---|---|
アップグレード中にフロー・インスタンスにエラーが発生した(flowIdが-1または-2に設定されている)。 |
Select count (*) from composite_instance where flow_id=-1; select count(*) from composite_instance where flow_id = -1; select count(*) from cube_instance where flow_id = -2 select count(*) from dlv_message where flow_id = -2; select count(*) from mediator_instance where flow_id = -2; |
アップグレード・アシスタントによるオープン・インスタンスのアップグレードが完了したら、SOAINFRAスキーマのUPGRADE_ERROR_LOG表に含まれる行を確認することをお薦めします。この表には、エラーが発生して12cにアップグレードされていないデータが格納されています。列typeでは、発生したエラーのタイプを特定します。UPGRDAE_ERROR_LOG表では、次に示す各タイプのエラーが報告されます。
これらの表にエラーが発生したレコードが存在していないことを確認することが重要です。 詳細は、「エラーが発生した11gインスタンスのリセット(オプション9)」を参照してください |
すべてのオープン・インスタンスがアップグレードされた。 |
select count (*) from cube_instance where state < 5 and flow_id = -1; select count (*) from dlv_message where state in (0,1,4) and flow_id = -1 select count (*) from mediator_instance where component_state between 4 and 15 and flow_id is null; |
これらの問合せは、アップグレード後に実行して検証を行います。すべてのオープン・インスタンスが移行されている場合は、0行が返されます。 |
管理スクリプトに加えて、アップグレードの一般的なステータスを表示するには、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用することもできます。管理スクリプトでは、アップグレード・ジョブを詳細に管理制御できますが、次に示す事項はFusion Middleware Controlコンソールで監視できます。
注意:
アップグレードの際に高度な管理タスク(アップグレードのスケジュールや時間間隔の変更など)を実行する必要がある場合は、「アップグレード管理スクリプトの使用」に記載されている管理スクリプトを使用する必要があります。
Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックし、次に示すように、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。
「データ移行の完了」をクリックして、次のメッセージが表示されることを確認します。
「OK」をクリックして、「移行完了」ダイアログ・ボックスを閉じます。「SOAランタイム・ヘルス」の移行ステータス・メッセージが表示されます(図9-5)。
「このメッセージを閉じる」をクリックします。次の確認ダイアログが表示されます。
「はい」をクリックして、データ移行完了アラートを非表示にします。「SOAランタイム・ヘルス」セクションから、「このメッセージを閉じる」ボタンの表示がなくなります。
「いいえ」をクリックすると、「SOAランタイム・ヘルス」セクションにアラートが表示されたままになります。
Fusion Middleware Controlを使用して、不完全なアップグレードを管理できます。不完全なアップグレードは次の状況で発生します。
オープンまたはクローズされたインスタンスが一切アップグレードされていない。
一部のオープン・インスタンスがアップグレードされている。たとえば、オープン・インスタンスのアップグレード中に、管理スクリプトのオプション8(Stop upgrade database background sessions and jobs)を使用して、手動でバックグラウンド制御ジョブを停止した場合です。
オープン・インスタンスのみがアップグレードされている。
クローズされたインスタンスの一部がアップグレードされているか、まったくアップグレードされていない。
注意:
インスタンスのアップグレードが完了する前にSOA管理対象サーバーを起動すると、Fusion Middleware Controlに「データの移行が完了していません」というアップグレード・ステータスが表示され、「不完全なアップグレードの再開」の説明に従ってアップグレードを手動で再開する必要があります。
アップグレードが未完了の場合、Fusion Middleware Controlでは、アップグレードが未完了のすべての11gインスタンスの最も新しい作成日を表示できます。最も新しい作成日は、12c Enterprise Managerコンソールに一部のインスタンスが表示されない原因を特定する際にも役立つため重要です。たとえば、一部の古い11gのクローズされたインスタンスがFusion Middleware Controlコンソールに表示されないことに気付いたときには、アップグレードされていないすべてのインスタンスの最も新しい作成日を調べると、アップグレードが該当するインスタンスに到達していないためかどうかを判断するのに役立ちます。
Middleware Controlを使用して、不完全な(停止された)アップグレードのステータスを確認するには、次の手順を実行します。
Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックします。この画面の「SOAランタイム・ヘルス」セクションに、現在のアップグレード・ステータスが表示されます。不完全なアップグレードの場合、ステータスは「データの移行が完了していません」になります。この画面は、5分ごとにリフレッシュできます。
「データの移行が完了していません」をクリックすると、次のメッセージが表示されます。
データ移行のステータス:
アクティブ・インスタンス: アップグレードされたオープン・インスタンスのステータスが示されます。前掲の例では、オープン・インスタンスはアップグレードが完了しています(ステータスは、「完了」になります)。
非アクティブ・インスタンス: アップグレードされたクローズ済インスタンスのステータスが示されます。前掲の例では、2013年7月9日より古いクローズ済インスタンスは、まだアップグレードされていません。アップグレードは最新のものから古いものへの順で実行されます。アップグレードが済んでいないインスタンスは、Fusion Middleware Controlのレポートやビューに表示されません。レポートは、5分ごとにリフレッシュできます。
注意:
実行中のアップグレードの詳細なレポートは、Report Upgrade Summaryスクリプト(オプション1)を実行します(「管理スクリプトの実行」を参照)。
すべてのクローズ済インスタンスがアップグレードされると、リンクは「データ移行の完了」に変化します(図9-4を参照)。
アップグレードに多数のインスタンス(クローズおよびオープン)の移行が含まれる場合は、Enterprise Managerフロー・トレースのロード時にパフォーマンスの問題が発生することがあります。パフォーマンスの低下を防ぐには、次の手順で説明するように索引を作成します。
アップグレード中に失敗した11gインスタンスは、コンポジット・レベルでのみアップグレード後に表示できます。このようなインスタンスは、パーティション・レベルでは表示されません。
このようなインスタンスを表示するには、デプロイ済コンポジットの「フロー・インスタンス」タブに移動します(図9-9を参照)。
注意: 「検索オプション」を使用すると、特定のインスタンス作成時間または作成日の範囲を指定できます。
コンポジットが同一のアップグレード前リビジョンで再デプロイされている場合、該当するインスタンスを表示するには、パーティション・レベル(コンポジット・レベルではありません)に移動する必要があります(図9-10を参照)。
ただし、アップグレード後に作成されたインスタンスは、12cのコンポジット・レベルで表示できます。
アップグレードが失敗した場合や、Report Upgrade Summaryレポート(オプション1)のUPGRADE ERROR COUNTセクションに、現在の実行でのエラー発生が示されている場合は、アップグレードに向けてインスタンスを再発行する前に、エラーを解決する必要があります。
upgrade_error_logは、エラーの状況を診断するために使用でき、問題を解決する手がかりを示すこともあります。一般的なアップグレード・エラーの解決方法の詳細は、「失敗したアップグレードからのリカバリ」を参照してください。
次の表では、各エラーと考えられる解決方法について説明します。
| エラー・タイプ | 説明 | エラー・メッセージ | 解決方法 |
|---|---|---|---|
0 |
これらのエラーは、前回のアップグレード実行で報告されています。 タイプは、エラーが発生したインスタンスをリセットすると0に設定されます(「エラーが発生した11gインスタンスのリセット(オプション9)」を参照)。 |
エラー・メッセージには、前回のエラー・タイプに基づいて、発生したエラーに関する詳細が示されます。 |
前回の実行からのエラーを修正し、管理スクリプトを使用してリセットします。 |
1 |
インスタンスのアップグレード中にエラーが発生しました。 |
エラー・メッセージには、アップグレード・スクリプトからスローされた実際のエラーが含まれています。また、エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースも示されます。 |
根本原因のデバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。 Info列に移入されたECIDは、失敗したインスタンスのデータを取得する場合に役立ちます。 |
2 |
EDNエラー・イベント・ストアまたはアダプタ拒否メッセージのアップグレード中にエラーが発生しました。 |
エラー・メッセージには、失敗したコンポーネントを特定するための文字列 これには、失敗したメッセージのIDとともに、失敗の理由が含まれています。 |
デバッグは、エラーの実際の理由を分析することで実行できます。失敗したアダプタ/EDNメッセージの詳細を取得するために、ERROR_MSGの一部としてログ出力されたIDを使用できます。 |
9 |
メタデータのアップグレード中にエラーが発生しました。 |
メタデータのアップグレードに失敗した エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。 |
デバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。Info列では、メタデータのアップグレードに失敗した |
12 |
データのアップグレード・プロセス中に一般エラーが発生しました。これは、単一のインスタンスに関するものではありません。 |
Infoには、文字列 エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。 |
このエラー・タイプは、アップグレードの実行中に、データのアップグレードが全体として失敗したときに、失敗が必ずしも特定のインスタンスに関連しない場合に報告されます。 このタイプのエラーの一例として、TEMP表領域の問題が考えられます。 |
エラーを解決したら、次の手順を実行してアップグレードを再開します。
upgrade_error_logに表示されたエラー条件を修正します。「エラーが発生した11gインスタンスのリセット(オプション9)」の説明に従って、upgrade_error_logからエラー・フラグを削除します。これにより、エラーが発生したインスタンスを後続の実行で再発行できるようになります。 UPGRADE ERROR COUNTセクションに、エラーが0個と示される必要があります。エラーが残っている場合は、問題を解決してから、ここに示した手順を繰り返します。