| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1) E77369-01 |
|
|
前 |
次 |
注意:
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。
潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。
-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。このフローチャートおよび付随するテキストで、Oracle Fusion Middleware SOA Suite 11gを12c (12.2.1.1)にアップグレードするための大まかな手順を示します
既存のドメインをアップグレードするために実行する手順は、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当する手順にのみ従ってください。
表3-1 Oracle SOA Suiteのアップグレード・タスクの説明
| 説明 | 詳細 |
|---|---|
必須 アップグレードするコンポーネントに必要なアップグレード前タスクをすべて実行します(まだそうしていない場合)。 |
必要なすべてのアップグレード前タスクについては、「Oracle Fusion Middleawareアップグレード前のチェックリスト」を参照してください Oracle BAMを含むSOAドメインについては、「Oracle BAMのアップグレード前タスクの実行」を参照してください Oracle Service Busをアップグレードする場合(Oracle SOAを含む場合も含まない場合も)、「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください |
必須 アップグレードを開始する前に、11g本番デプロイメントと同じホスト上の新しいOracleホームに、Fusion Middleware Infrastructure 12c (12.2.1.1)をインストールする必要があります。 12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。 |
「Infrastructureソフトウェアのインストール」を参照してください このリンクを使用すると、『Oracle Fusion Middleware Infrastructureのインストールと構成』ガイドにアクセスできます。 注意: インストールしますが、新しくインストールしたドメインの構成に構成ウィザードを使用しないでください。アップグレード中、再構成ウィザードを使用して既存の11gドメインを構成します。 |
必須 SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)と、統合されたSOA統合ディストリビューション(Oracle HTTP Server、Oracle Service Busなど)を、新しく作成したOracleホームにインストールします。 |
「Oracle SOA SuiteおよびBusiness Process Management 12cのインストール」 (12.2.1.1)を参照 注意: Fusion Middleware 12c (12.2.1.1)ディストリビューションは、アップグレードするSOA統合製品ごとにインストールする必要があります。たとえば、Oracle Service Busを含むSOA 11g環境をアップグレードする場合は、Oracle SOA SuiteおよびBPM 12c (12.2.1.1)ディストリビューションのほかに、Oracle Service Bus 12c (12.2.1.1)ディストリビューションも入手する必要があります。 |
必須 11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。 警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 |
|
必須 12c (12.2.1.1)リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cスキーマを新しく作成します。 |
|
必須 Upgrade Assistantを実行して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブな(進行中の)インスタンス・データを移行します。 |
「Upgrade Assistantを使用したスキーマのアップグレード」を参照してください 注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12.2.1環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。 詳細は、「SOAインスタンスのアップグレードの管理と監視」を参照してください。 |
オプション アップグレード中、SOAインスタンスが自動的に移行されます。ただし、進行中のクローズ済インスタンスのアップグレードは、管理SQLスクリプトまたはOracle Fusion Middleware Enterprise Manager Controlを使用してアクティブに管理できます。 |
|
Oracle BAMがアップグレードの一部である場合のみ、必須。 アップグレードする11g SOAドメインにOracle Business Activity Monitoring (BAM)が含まれる場合、再構成ウィザードを実行する前に、BAMに固有のアップグレード前タスクをすべて完了する必要があります。これらの手順を再構成ウィザードの実行前に完了していないと、アップグレードに失敗します。 |
「Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード」を参照してください 注意: 12cのBusiness Activity Monitoring (BAM)は完全に再設計されており、ドメインの再構成前とアップグレードの後に追加の手順が必要になります。 |
必須 再構成ウィザードを実行して、ドメインとノード・マネージャを再構成します。 |
|
必須 アップグレード・アシスタントを(再度)実行して、ドメイン構成をアップグレードします。 |
|
各自の構成に該当するタスクが存在する場合のみ、必須。 必要なアップグレード後の構成タスクを実行します(必要な場合)。 |
「アップグレード後タスクの実行」を参照してください |
必須 アップグレード検証プロセスの一部として、新しい管理サーバー、管理対象サーバーおよびノード・マネージャを起動して、問題がないか確認することをお薦めします。 |
「サーバーの起動と停止」を参照 |
必須 アップグレード検証プロセスの一部として、アップグレードしたすべてのコンポーネントが期待どおりに動作しているか確認することをお薦めします。 |
既存のSOAおよびBusiness Process Management (BPM)のコンポーネントをアップグレードする前に、まず、Oracle Fusion Middleware InfrastructureとOracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)製品ディストリビューションをインストールする必要があります。
12c (12.2.1.1)製品ディストリビューションを新しいOracleホーム・ディレクトリにインストールします。インストールに既存のOracleホーム・ディレクトリを使用しないでください。
前提条件となるソフトウェアがすべてインストールされていることを確認します。Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。詳細は、「Infrastructureソフトウェアのインストール」を参照してください
使用するSOAドメインに別のSOA統合コンポーネントがある場合は、それらのディストリビューションもインストールする必要があります。各製品ディストリビューションのインストール・ガイドの完全なリストについては、Oracle Fusion Middlewareドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。
サポートされている11gリリースからアップグレードする場合、アップグレードする前に、サポートされているデータベースで新しい12c必須スキーマを作成することが必要になる場合があります。
注意:
OIDベースのセキュリティ・ストア・ユーザーのみ: 11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマ_STBおよび_OPSSスキーマを作成する必要があります。
アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。Upgrade Assistantでスキーマをアップグレードする場合、新しいOPSSスキーマを選択します(Upgrade AssistantによってOIDベースのセキュリティ・ストアが自動的にアップグレードされます)。
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
表3-2 SOAおよびSOA統合製品に必要なスキーマ
| アップグレードする内容 | アップグレード前に作成する12cのスキーマ |
|---|---|
SOA Suite (SOA) |
Service Table (_STB) Audit Services (_IAU) |
Business Process Monitoring (BPM) |
Service Table (_STB) Audit Services (_IAU) |
Business Activity Monitoring(BAM) |
SOA Suiteに必要なスキーマ および WebLogic Services (_WLS) |
| Managed File Transfer (MFT) | Service Table (_STB) Audit Services (_IAU) |
Oracle Service Bus(OSB) Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.1)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。 |
SOAインフラストラクチャ(_SOAINFRA) Service Table (_STB) ユーザー・メッセージング(_UMS) 注意: Oracle SOAを実行しなくてもOracle Service Busはインストールできますが、_SOAINFRAスキーマと_STBスキーマを作成する必要があります。 |
ユーザー・メッセージング・サービス(UMS) |
Service Table (_STB) Audit Services (_IAU) |
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。
11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。
アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択します。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。
注意:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。
準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。
ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックは使用率の低い期間に実行することをお薦めします。-readinessモードでアップグレード・アシスタントを起動します。binディレクトリに移動します。
UNIXオペレーティング・システムの場合:
ORACLE_HOME/oracle_common/upgrade/bin
Windowsオペレーティング・システムの場合:
ORACLE_HOME\oracle_common\upgrade\bin
次のコマンドを入力してアップグレード・アシスタントを起動します。
UNIXオペレーティング・システムの場合:
./ua -readiness
Windowsオペレーティング・システムの場合:
ua.bat -readiness
次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。
./ua [-logLevel <log_level] [-logDir <log_directory>]
TRACE
NOTIFICATION
WARNING
ERROR
INCIDENT_ERROR
NOTIFICATIONです。トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。
注意:
サービス表スキーマを作成していない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。この場合、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。
表3-3 Upgrade Assistant画面: 準備状況チェック
| 画面 | 画面が表示されるタイミング | 説明 |
|---|---|---|
| ようこそ | 常時。 |
この画面には、準備状況チェックの概要が示されます。 |
準備状況チェックのタイプ:
|
常時。 |
準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。
|
| 使用可能なコンポーネント | 「個別に選択されたスキーマ」が選択されている場合。 |
この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。 |
| すべてのスキーマのコンポーネント・リスト | スキーマの準備状況チェックが実行されるたび。 |
この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。 |
| スキーマ資格証明 | 常時。 |
この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。 DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください |
| 準備状況サマリー | 常時。 |
この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。 Upgrade Assistantを |
| 準備状況チェック | 常時。 |
この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。 詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。 注意: パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。 |
| 準備状況成功 | 準備状況チェックが正常に完了した場合。 |
これで、完全なレポートをレビューできるようになります。 準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。 デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。
|
アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止する必要があります。
注意:
サーバーやプロセスの停止に失敗すると、結果としてアップグレードが不完全になったり、失敗したりする場合があります。WebLogic Server管理対象サーバーを停止するには、次のスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
SOAサーバーおよびプロセスは、次の順番で停止してください。
Business Activity Monitoring (BAM)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Web Services Manager (OWSM)管理対象サーバー
管理サーバー
ノード・マネージャ
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。
Web層(Oracle HTTP Serverを含む)
Upgrade Assistantとスキーマをアップグレードするには、このタスクに従います。
アップグレードのトラブルシューティングを容易にするために、_SOAINFRA スキーマのアップグレード時にログ・ファイルを生成することをお薦めします。デフォルトでは、ロギングは無効になっています。
ロギングを有効化するには:
UPGRADE_DIRという名前で作成します。set_LogLevel(1)または ALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';関数を呼び出して、デバッグ・ログを有効化します。次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。
./ua [-logLevel <log_level>] [-logDir <log_directory>]
アップグレードを開始する前に、スキーマ・バージョン・レジストリを問い合せることによって、使用可能なスキーマのリストを確認します。
このオプションの手順は、アップグレード・プロセスを開始する前に手動でschema_version_registry表を問い合せる場合にのみ使用できます。アップグレードに使用できるすべてのスキーマがUpgrade Assistantによって特定されるため、アップグレードする個々のスキーマを選択したり、Upgrade Assistantでドメイン内のスキーマ全部をアップグレードすることができます。また、Upgrade Assistantを—readinessモードで実行すると、すべてのスキーマおよびそれぞれの現在のアップグレード前バージョンを示すレポートが発行されます。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。
VERSIONの数値が11.1.1.7.0以上で、STATUS列がVALIDであれば、そのスキーマはアップグレードでサポートされます。
schema_version_registry表には、アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。ヒント:
スキーマ・バージョン・レジストリから収集した情報を対応するスキーマと比較し、まだアップグレードできないスキーマがドメイン内にあるかどうかを確認します。
アップグレードが必要なスキーマに関する注意
ほとんどのコンポーネントで、アップグレードできるスキーマ・バージョンの開始点は、11gリリース1 (1.1.1.7.0、11.1.1.8.0または11.1.1.9.0)または12c (12.1.2、12.1.3または12.2.1.0)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。
Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。
アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。
11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に必ず、新しい12c (12.2.1.1) OPSSスキーマを作成してください。このOPSSスキーマは、アップグレード後もLDAPベースのストアのままです。
Oracle Fusion Middleware 12c (12.2.1.1)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.1)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします
Upgrade Assistantでは、スキーマのアップグレード時に、次に示す一連の画面が表示されます。各画面でアクションを実行します。
表3-4 Upgrade Assistant画面: スキーマのアップグレード
| 画面 | 説明および必要なアクション |
|---|---|
ようこそ |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 |
スキーマ |
「個別に選択されたスキーマ」を選択します。 |
使用可能なコンポーネント |
この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。 たとえば、Oracle SOAを選択した場合、Oracle SOA ( Managed File Transferを選択した場合、監査サービス(_IAU)、Enterprise Scheduler (_ESS)およびPlatform Security Services (OPSS)がアップグレードに含まれます。 |
ドメイン・ディレクトリ |
この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。 既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します。 |
前提条件 |
スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。 注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。 |
スキーマ資格証明 |
この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。
注意:
|
調査 |
各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。 スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。 |
| アップグレード・サマリー | スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。 「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。 |
アップグレードの進行状況 |
現在のアップグレード・プロセスのステータスを確認します。 注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。 アップグレードが完了したら「次へ」をクリックします。 |
アップグレード成功 |
アップグレードが成功していれば「閉じる」をクリックします。 アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。 |
次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しく更新されていることを検証します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。「アップグレードが必要なスキーマ」を参照して、スキーマの更新されたバージョン番号が正しいことを確認します。
問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
スキーマのアップグレードの一部としてインスタンスをアップグレードした場合は、インスタンスにエラーがないことを確認します。
アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。
アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。詳細は、「インスタンス・アップグレードのエラーの解決」を参照してください。
アップグレード対象のクローズされたインスタンスが残っている場合は、アップグレード・アシスタントの終了後に、クローズされたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。
Oracle SOA 1. The Upgrade Assistant has successfully upgraded all active 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.
Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。
SQL>@?/rdbms/admin/utlrp.sql
これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。
その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
この時点では、アップグレードされたスキーマに、無効になっているデータベース・オブジェクトはないはずです。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。
Oracle SOA Suite 11gの管理ガイドの説明に従ってパーティション化されたスキーマを含むOracle SOA 11gインストールをアップグレードしようとする場合、SOA 12c (12.2.1.1)でもこの特定の表パーティション化戦略を使用するには、これらの必要な手順を完了して、パーティション化されたスキーマ表をアップグレードする必要があります。
注意:
この手順は、アップグレード済の12c環境で既存のOracle SOA 11g表パーティション化戦略を使用しようとする場合にのみ必要です。以前の12cリリースからアップグレードする場合は、この手順を完了する必要はありません。パーティション化されたスキーマ表のアップグレードの理解
COMPOSITE_INSTANCEパーティションに基づいて新しいファブリック12c表パーティションがモデル化されます(他の既存のパーティションはすべて調整済です)。均等パーティション化戦略を実施する新しい12cファブリック表は、SCA_FLOW_INSTANCEという名前です。始める前に
新しいSOA 12cファブリック表を調整するために、現在非推奨となった11g composite_instance表に基づいてモデル化された、ダミーで空のRANGEパーティションが追加されます。つまり、約10個の新しいファブリック表が再作成されて、パーティション化された表になります。
このプロセス中に、RANGEパーティション化をINTERVAL-RANGEパーティション化に変換できます(Oracle Fusion Middleware SOA Suite 12cでは両方のパーティション化がサポートされるようになりました)。
引き続きRANGEパーティション化を使用するか、このプロセスの一部としてINTERVAL-RANGEパーティション化に変換するかを選択できます。INTERVAL-RANGE表は、RANGEパーティションとINTERVAL-RANGEパーティションの両方を格納でき、最初のパーティションは常に(遷移ポイントと呼ばれる)RANGEパーティションになります。表がINTERVAL-RANGEに変換されても、新しいINTERVAL-RANGEパーティションが自動的に割り当てられるまで、既存のRANGEパーティションは残ります。
11g SOA戦略では、MAXVALUEパーティションの使用に関する推奨は提供されませんでした。INTERVAL-RANGEパーティション化への変換を選択した場合、MAXVALUEパーティションが空でなければ、表を再ビルドする必要があります。ただし、MAXVALUEパーティションが空の場合は、INTERVAL-RANGEへの変換の一部として削除されます。ただし、MAXVALUEパーティションが空の場合は、変換の一部として削除されます。(INTERVAL-RANGEパーティション化では、パーティションが自動的に割り当てられるため、MAXVALUEパーティションは許可されません。)
このプロセスでは、TRS (Table Recreation Scripts)ユーティリティが使用されます。生成されたスクリプトの一部を編集する必要があります。生成されたDDLは個々のインストールやRDBMSバージョン間で異なっていたり、カスタマイズされた可能性もあるため、DDL構文を修正するために編集が必要です。
12.2.1.1の検証スクリプトはアップグレードに対応しており、12c sca_flow_instance表と11g composite_instance表の両方のインスタンスが考慮されます。
注意:
このプロセスを開始する前に、スキーマおよびデータベースの完全バックアップを作成することをお薦めします。また、本番での試行前に、テスト環境でこの手順を実行しておくこともお薦めします(検証スクリプトを含む)。プロセスの概要
パーティション化されたスキーマ表のアップグレードは、次の2つのフェーズで行われます。
フェーズ1: DDLスクリプトを生成します。
パーティション・キーを修正します
DDL変更を受け入れます
新しい12cファブリック表をパーティション化します
composite_instanceに基づいてモデル化されたダミーのRANGEパーティションが作成されます。
MAXVALUEパーティションを処理します(間隔が必要な場合)
フェーズ2: DDLスクリプトを編集し、実行します。
DDLスクリプトを編集します。
DDLスクリプトを実行します。
ログ・ファイルを確認します。
フェーズ1: DDLスクリプトの生成
SQL > create directory TRS_DIR as ‘/../../..’; SQL> grant read,write on directory TRS_DIR to <soainfra>
デバッグ・モードを有効化します。
ALTER PROCEDURE debug_purge COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' ║ REUSE SETTINGS; ALTER PROCEDURE log_info COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' REUSE ║ SETTINGS;
12C_mwhome/soa/common/sql/soainfra/sql/oracle/122110/trs12/
| パラメータ | オプション |
| range_interval | R (レンジ)またはI (間隔) |
| interval_clause | 'NUMTOYMINTERVAL(1, ''MONTH'')‘ SQL変換関数によって指定します
|
| partition | G (グループ1または2)またはP (一部) 11gパーティション化戦略を識別します |
| drop_flag | 元の表を削除します(true、false) |
| redo_flag | REDOを生成します(true、false) |
| DOP | 並列度 |
| sql_trace | SQLトレース(true、false) trueの場合、soainfraユーザーに"alter session"権限が付与されていることを確認してください。 |
set echo on; set serverout on; DECLARE range_interval varchar2(1) := 'I'; interval_clause varchar2(40) := 'NUMTOYMINTERVAL(1, ''MONTH'')'; partition varchar2(1) := 'G'; drop_flag boolean := true; redo_flag boolean := false; DOP number := 0; sql_trace boolean := false; BEGIN trs_mig.trs_migrate (range_interval, interval_clause, partition, drop_flag, redo_flag, DOP, sql_trace); END; /
trs_migrate_exec.sqlを実行して、DDLスクリプトを生成します。
フェーズ2: DDLスクリプトの編集および実行
スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。
再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。
WLSコア・インフラストラクチャ
ドメイン・バージョン
注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしたことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。
表3-5 再構成ウィザードの画面
| 再構成ウィザードの画面 | 説明および必要なアクション |
|---|---|
| ドメインの選択 | 既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。 |
再構成セットアップの進行状況 |
再構成テンプレートの適用の進行状況が表示されます。 |
ドメイン・モードおよびJDK |
ドメイン・モードは変更できません。 ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。 Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、「動作保証およびシステム要件の確認」を参照してください。 |
データベース構成タイプ |
「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。 注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。 |
JDBCデータ・ソース |
この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。 この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。 |
JDBCデータ・ソース・テスト |
「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。 |
JDBCコンポーネント・スキーマ |
各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。 今アップグレードしたスキーマに対して、11gスキーマ詳細を指定する必要があります。それ以外については、12.2.1.1スキーマの詳細を指定します。 |
JDBCコンポーネント・スキーマ・テスト |
前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。 テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。 |
ノード・マネージャ |
この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。 |
拡張構成 |
この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。 たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。
「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。 |
管理対象サーバー |
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。 デフォルトの 実際のホスト名を、hostname.company.comのように指定する必要があります。 12.1.3から12.2.1.1にアップグレードする場合、サーバーを適切なサーバー・グループに割り当てる必要があります。「再構成ウィザードを使用したサーバー・グループのターゲット指定」を参照してください |
サーバーのマシンへの割当て |
アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。 そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。 |
| サーバーのクラスタへの割当て | クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。 「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。
注意: SOAアップグレードのみ: OWSMPMがそれ自身のクラスタにあり、SOAまたはOSBクラスタの一部ではない場合は、SOAクラスタへはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲット指定し、OSBクラスタへはOSB-MGD-SVRS-ONLYのみをターゲット指定し、OWSMへはWSMPM-MAN-SVERサーバー・グループをターゲット指定してください。12.1.3を12.2.11にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタにターゲット指定することも必要です。 |
構成のサマリー |
構成のサマリーを確認します。 「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。 |
再構成の進行状況 |
再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。 |
再構成に成功しました |
再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。 |
Upgrade Assistantを使用して、残りのドメイン内WebLogicコンポーネント構成をすべて更新します。
アップグレード・アシスタントを使用して追加ドメイン・コンポーネント構成をアップグレードするには、次の各項の手順に従います。
注意:
アップグレード・アシスタントを起動する前に、管理サーバーを起動しないでください。
Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。
注意:
Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。スキーマのアップグレードに必要な権限を持つユーザーを作成する手順は、「非SYSDBAユーザーの作成」で説明されています。WebLogicコンポーネント構成のアップグレード時のUpgrade Assistantの画面を示しています。
注意: 表示される画面は、使用している環境に基づいています。次に示す画面は、すべてが表示されない場合もあります。Upgrade Assistant画面の使用の詳細は、オンライン・ヘルプを参照してください。
注意:
追加の構成タスクが必要になる場合があります。
Upgrade Assistantによるスキーマとコンポーネント構成のアップグレードが正常に完了したら、「アップグレード後のタスクの実行」で説明されているタスクを実行して、コンポーネントが引き続き期待どおりに機能していることを確認する必要がある場合があります。
表3-6 アップグレード・アシスタント画面: WebLogicコンポーネント構成のアップグレード
| 画面 | 説明および必要なアクション |
|---|---|
ようこそ |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 「次へ」をクリックして続行します。 |
WebLogicコンポーネント |
管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「ドメインによって使用されるすべての構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。 「次へ」をクリックします。 |
OWSMポリシー・マネージャ |
この画面は、11g環境に複数のWebLogic Serverドメインがある場合に、OWSMポリシー・マネージャが1つのWLSドメインのみにあり、他のドメインにはOWSMエージェントがあるときに表示されます。 Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を指定します。 このページのフィールドの詳細は、「ヘルプ」をクリックするか、OWSMポリシー・マネージャに関する項を参照してください。 |
コンポーネント・リスト |
この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。 |
前提条件 |
コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。 注意: Upgrade Assistantは、これらの前提条件が実行されたことを確認しません。 |
UMS構成 |
この画面は、UMS 11g構成ファイルをホストする、リモートの管理対象サーバーがある場合に表示されます。アップグレード・アシスタントで構成ファイルにアクセスするには、これらのサーバーに資格証明を指定する必要があります。 注意: アップグレード・アシスタントでUMS構成ファイルを見つけられない場合は、それらのファイルを手動でコピーする必要があります。アップグレード・アシスタント: UMS構成ファイルのコピーを参照してください。 |
調査 |
各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。 |
アップグレード・サマリー |
スキーマ・アップグレードのために選択したオプションのサマリーを確認します。 「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。 |
アップグレードの進行状況 |
アップグレード処理のステータスを確認します。 アップグレードが完了したら「次へ」をクリックします。 |
アップグレード成功 |
アップグレードが成功していれば「閉じる」をクリックします。 アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。 |
表3-7に、アップグレード後に実行することが多い一般的な管理タスクを示します。また、コンポーネント固有の管理ガイドでは、アップグレード後に実行する追加の構成タスクについても説明している場合があります。
表3-7 基本的な管理タスク
| タスク | 説明 | 詳細 |
|---|---|---|
コンポーネントの追加のアップグレード後構成手順の実行 |
「アップグレード後のタスクの実行」で説明しているアップグレード後のタスクに加えて、追加の構成タスクを実行し、新しくアップグレードしたコンポーネントが期待どおりに機能することを確認する必要もあります。 |
|
Fusion Middleware管理ツールについての学習 |
環境の管理に使用できる各種ツールについて習熟します。 |
Oracle Fusion Middlewareの管理ツールの概要 |
Secure Sockets Layer (SSL)の構成 |
Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。 |
Oracle Fusion MiddlewareでのSSLの構成 |
Oracle Fusion Middlewareのモニタリング |
Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。 |
Oracle Fusion Middlewareのモニタリング |
