Oracle® Fusion Middleware

SOA SuiteおよびBusiness Process Managementのアップグレード

12c (12.2.1.1)

E77369-01(原本部品番号:E71493-01)

2016年6月

このガイドでは、Oracle SOA Suite 11gアプリケーションをOracle SOA Suite 12cにアップグレードし、再デプロイする手順について説明します。

Oracle Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.1)

E77369-01

Copyright © 2014, 2016, Oracle and/or its affiliates All rights reserved.

原本主著者: Lisa Jamen

原本協力者: Jay Kasi、Robert Donat、Vamsee Goruganthu、Subramanian Hariharan、Suresh Krishnaswamy、William Norcott、Renga Rengarajan、Michael Rubino、Sitaraman Swaminathan

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- 関連ドキュメント

- 表記規則

1 Oracle SOA SuiteおよびBusiness Process Managementのアップグレードの概要

- 1.1 Oracle SOA SuiteおよびBusiness Process Managementの12cへのアップグレードの理解(12.2.1.1)

- 1.2 SOA Suite 12c (12.2.1.1)アップグレードの開始点の理解

- 1.3 アップグレード前の相互運用性および互換性の制約の理解

- 1.4 SOAドメイン・アップグレードの制限の理解

- 1.5 標準SOAアップグレード・トポロジの理解

- 1.6 アップグレードのためのこのガイドの使用方法の理解

2 Oracle Fusion Middlewareのアップグレード前タスク

- 2.1 Oracle Fusion Middlewareのアップグレード前チェックリスト

- 2.2 完全なバックアップの作成

- 2.2.1 スキーマ・バージョン・レジストリ表のバックアップ

- 2.2.2 カスタム・ドメイン環境設定の保持

- 2.3 テストのための本番環境のクローニング

- 2.4 動作保証およびシステム要件の確認

- 2.4.1 環境が動作保証要件を満たしていることの確認

- 2.4.2 システム要件と仕様の確認

- 2.4.3 Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認

- 2.4.4 Oracle Fusion Middlewareのこのリリースに対してJDKが動作保証されているかどうかの確認

- 2.5 強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新

- 2.6 未使用データのパージ

- 2.7 エディション・ベースの再定義のためのサーバー上でのエディションの作成

- 2.8 Upgrade Assistantを実行するための非SYSDBAユーザーの作成

- 2.9 SOA固有のアップグレード前タスクの実行

- 2.9.1 SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

- 2.9.1.1 SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加

- 2.9.2 アップグレード前のSOA Composerの変更のコミット

- 2.9.3 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

- 2.9.4 cloudsdkアプリケーションの削除

- 2.9.5 ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

- 2.9.6 Oracle Service Bus (OSB)のアップグレード前タスクの実行

- 2.9.7 スタンドアロンOracle HTTP Serverのアップグレード

3 SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のアップグレード

- 3.1 SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解

- 3.2 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

- 3.3 11gからアップグレードする前の必須SOAスキーマの作成

- 3.3.1 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

- 3.4 アップグレード前の準備状況チェックの実行

- 3.5 SOAサーバーとプロセスの停止

- 3.6 Upgrade Assistantを使用したスキーマのアップグレード

- 3.6.1 SOAINFRAスキーマのアップグレード中のログ・ファイルの生成(推奨)

- 3.6.2 Upgrade Assistantでアップグレードできるスキーマの識別

- 3.6.3 アップグレード・アシスタントの起動

- 3.6.4 Upgrade Assistantを使用したSOAスキーマのアップグレード

- 3.6.5 スキーマのアップグレードの確認

- 3.6.6 インスタンスのアップグレードの確認(該当する場合)

- 3.6.7 無効なデータベース・オブジェクトの確認

- 3.6.8 11gからのパーティション化されたスキーマ表のアップグレード

- 3.7 再構成ウィザードを使用したドメインの再構成

- 3.7.1 ドメインのバックアップ

- 3.7.2 再構成ウィザードの起動

- 3.7.3 ドメインの再構成

- 3.8 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

- 3.8.1 GUIモードでのUpgrade Assistantの起動

- 3.8.2 SOAコンポーネント構成のアップグレード

- 3.9 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

4 以前の12cリリースからのOracle SOA SuiteおよびBusiness Process Managementのアップグレード

- 4.1 以前の12cリリースからSOA SuiteおよびBusiness Process Management 12c (12.2.1.1)へのアップグレード

- 4.1.1 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

- 4.1.2 アップグレード前の準備状況チェックの実行

- 4.1.3 SOAサーバーとプロセスの停止

- 4.1.4 アップグレード・アシスタントの起動

- 4.1.5 Upgrade Assistantを使用したSOAスキーマのアップグレード

- 4.1.6 再構成ウィザードを使用したドメインの再構成

- 4.1.6.1 ドメインのバックアップ

- 4.1.6.2 再構成ウィザードの起動

- 4.1.6.3 ドメインの再構成

- 4.1.7 SOAコンポーネント構成のアップグレード

- 4.2 以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード

- 4.3 再構成ウィザードを使用したサーバー・グループのターゲット指定

5 クラスタ化されたSOA環境のアップグレード

- 5.1 SOAクラスタ・アップグレード・トポロジの理解

- 5.2 クラスタ化トポロジでの保護されたタスク・フォームの使用

- 5.3 クラスタ化トポロジのアップグレード

- 5.4 SOAHOST2でのドメイン構成の伝播

- 5.4.1 管理サーバーといずれかの管理対象サーバーがインストールされているサーバーでのpackコマンドの実行

- 5.4.2 前の手順で作成したテンプレート・ファイルのSOAHOST2へのコピー

- 5.4.3 SOAHOST2の12c Oracleホームからのunpackコマンドの実行

- 5.4.4 unpack後の次の確認手順の完了

- 5.5 クラスタ・アップグレードのアップグレード後タスク

- 5.5.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- 5.5.2 SOAおよびOSBクラスタからのOWSMターゲットの削除

- 5.5.3 OWSMクロス・コンポーネント・ワイヤリングの更新

- 5.5.4 クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

- 5.5.5 JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

6 Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード

- 6.1 12cにおけるBusiness Activity Monitoringのアップグレードの理解

- 6.2 Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解

- 6.3 Oracle BAMのアップグレード前タスクの実行

- 6.3.1 アップグレード前の新しいOracle BAM 11gドメインの作成

- 6.3.2 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

- 6.3.3 Oracle BAM 11gアーティファクトの新しいOracle BAM 11gドメインへのインポート

- 6.3.4 Oracle BAM 11gドメインの完全なバックアップの作成

- 6.4 Oracle BAMドメインを含むSOAの12cへのアップグレード

- 6.4.1 サーバーとプロセスの停止

- 6.4.2 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

- 6.4.3 リポジトリ作成ユーティリティ(RCU)を使用した新規12cスキーマの作成

- 6.4.4 11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更

- 6.4.5 アップブレード・アシスタントの実行によるスキーマのアップグレード

- 6.4.6 再構成ウィザードを使用した11gドメインの再構成

- 6.4.7 Upgrade Assistantの実行によるコンポーネント構成のアップグレード

- 6.5 Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

- 6.5.1 管理(Admin)サーバーの起動

- 6.5.2 WebLogic Server管理12cコンソールの起動

- 6.5.3 Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除

- 6.5.4 Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除

- 6.5.5 ドメインからのOracle BAMサーバーおよびクラスタの削除

- 6.5.6 アップグレードされたドメインからの不要なOracle BAM 11gファイルの削除

- 6.5.7 クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止

- 6.5.8 管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行

- 6.5.9 クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート

- 6.5.10 管理サーバーの再起動

- 6.5.11 SOA 12cドメインで動作する11g Oracle BAMアダプタの構成

- 6.5.12 SOA管理対象サーバーの再起動

- 6.5.13 SOAドメインからの既存のUMS電子メール・ドライバの削除

- 6.6Oracle BAM 12cを含むSOAドメインの拡張

- 6.6.1 管理サーバーおよびSOA管理対象サーバーを停止する

- 6.6.2 Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張

- 6.6.3 Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成

- 6.6.4 Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート

- 6.6.5 BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成

- 6.6.6 11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)

- 6.6.6.1 タスク1: プロセス・メトリックを無効にします。

- 6.6.6.2 タスク2: 移行に使用するexportTypeを決定します。

- 6.6.6.3 タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。

- 6.6.6.4 タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。

- 6.6.6.5 タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。

- 6.6.6.6 タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。

- 6.6.6.7 タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。

- 6.6.6.8 タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。

- 6.6.6.9 タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。

- 6.6.7 11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)

- 6.6.7.1 プロセス・メトリックを無効にします。

- 6.6.7.2 Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。

- 6.6.7.3 BPMデータをOracle BAM 12cにインポートします。

- 6.6.7.4 BAM 12cへのパブリッシュを有効化します。

- 6.6.8 12cでの11g互換プロセス・スター・スキーマのデータ・ビューの生成(オプション)

- 6.6.8.1 タスク1: クラスパスを更新してインタフェースJARファイルを含める

- 6.6.8.2 タスク2: 標準のビューを再作成する

- 6.6.8.3 タスク3: プロセス固有のビューを再作成する

- 6.7 失敗したOracle BAMアップグレードからのリカバリ

- 6.7.1 CFGFWK-60950エラーの解決

- 6.7.2 エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

- 6.7.3 UNIXオペレーティング・システムのエラー処理

- 6.7.4 Windowsオペレーティング・システムのエラー処理

7 Oracle Service Busのアップグレード

- 7.1 Oracle Service Busの12cへのアップグレードの理解

- 7.2 単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)

- 7.3 Oracle Service Bus (OSB)のアップグレード前タスクの実行

- 7.3.1 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

- 7.3.2 Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

- 7.3.3 すべてのサービス、プロジェクトおよびリソースの削除

- 7.3.4 以前のリリースからのOracle Service Busリソースの移行

- 7.4 WebLogic ServerおよびJRF Infrastructureのインストール

- 7.5 Oracle Service Busのインストール

- 7.6 Oracle Service Busのスキーマの作成

- 7.6.1 11gからアップグレードする前の必須SOAスキーマの作成

- 7.7 OSBドメインのアップグレード(SOAを含まない場合)

- 7.8 OSBドメインの再構成

- 7.9 WebLogicコンポーネント構成のアップグレード

- 7.10 Oracle Service Busのアップグレード後タスクの実行

- 7.10.1 ドメイン構成データのインポート

- 7.10.2 セキュリティ構成のインポート

- 7.10.3 XQueryリソースのアップグレード

- 7.10.4 12cの分割-結合の理解

- 7.11 Oracle Service Busアップグレードのトラブルシューティング

- 7.11.1 クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラーの解決

- 7.11.2 OSBコンソールへのアクセス時のHTTP 404エラーの解決

8 アップグレード後タスクの実行

- 8.1 アップグレード後タスクの実行

- 8.1.1 JVMの開始スクリプトのプロパティの再適用

- 8.1.2 setDomainEnvへのカスタマイズの再適用

- 8.1.3 XEngine構成ファイルへのカスタマイズの再適用

- 8.1.4 カスタムのXPathクラスのコピー

- 8.1.5 アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

- 8.1.6 サーバーの起動と停止

- 8.1.7 Business Process Management (BPM)メタデータのアップグレード

- 8.1.8 Oracle Fusion Middleware 12c監査データ・ストアの構成

- 8.1.9 リモート・クライアントによるServerSocketのアップグレード

- 8.1.10 SOA 12cのスレッドの再構成

- 8.2 アップグレードしたコンポーネントが期待どおりに動作していることの確認

- 8.2.1 ドメイン・コンポーネント構成のアップグレードの確認

- 8.2.2 データベース・スキーマのアップグレード成功の確認

- 8.2.3 フロー・トレースの12cでの変更内容の理解

9 SOAインスタンスのアップグレードの管理と監視

- 9.1 インスタンス・アップグレードのプロセスの理解

- 9.2 インスタンス・アップグレードのバックグラウンド・ジョブの理解

- 9.3 アップグレード前のパージ・スクリプトの使用

- 9.4 アップグレード管理スクリプトの使用

- 9.4.1 アップグレード・スクリプト・メニューへのアクセス

- 9.4.2 管理スクリプトの実行

- 9.5 管理スクリプトの構成

- 9.5.1 バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

- 9.5.2 バックグラウンド制御ジョブの有効化と無効化(オプション6)

- 9.5.3 制御ジョブ・パラメータの設定(オプション7)

- 9.5.4 エラーが発生した11gインスタンスのリセット(オプション9)

- 9.6 アップグレードのセッションとジョブの停止

- 9.7 不完全なアップグレードの再開

- 9.8 SQL問合せによるアップグレード・ステータスの監視

- 9.9 Fusion Middleware Controlによるアップグレード・ステータスの監視

- 9.9.1 データ移行の完了の確認

- 9.9.2 不完全な(停止された)アップグレードの管理

- 9.9.3 Enterprise Managerでのインスタンスの表示最適化

- 9.9.4 アップグレード時に失敗したインスタンスの表示

- 9.9.5 コンポジットの再デプロイ前に作成されたインスタンスの表示

- 9.10 インスタンス・アップグレードのエラーの解決

- 9.11 失敗したアップグレードの再試行

A アップグレードのトラブルシューティング

- A.1 リリース・ノートの確認

- A.2 サーバー起動エラーの解決

- A.3 失敗したアップグレードからのリカバリ

- A.4 アップグレード時のOWSMデータ・ソース接続障害 (12.1.3から12.2.1へ)

- A.5 失敗したBAMアップグレードのトラブルシューティング

- A.6 アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

- A.7 Oracle Service Busのトラブルシューティング

- A.8 Oracle Managed File Transfer (MFT)アップグレードの問題点のトラブルシューティング

- A.9 12cへのアップグレード後のOWSM起動エラー

- A.10 アップグレード時の暗号化の問題

- A.11 アップグレード・アシスタントによるサポート対象外ドメインのアップグレード

- A.12 インスタンスのアップグレード後に表示されなくなるビジネス・ルールの監査証跡

- A.13 Coherenceキャッシュ例外の解決

- A.14 WSDLで生じるカスタム例外の欠落要素

- A.15 リモート・クライアントを介したServerSocketへの接続

はじめに

次の各トピックでは、対象読者、表記規則、およびアップグレード・プロセス中に役立つ可能性のある追加リソースを示します。

- 対象読者

- 関連ドキュメント

- 表記規則

対象読者

このドキュメントは、Oracle Fusion Middlewareのインストール、アップグレードおよび管理タスクの知識がある管理者を対象としています。

関連ドキュメント

次のドキュメントには、アップグレード前の重要な情報が記載されているため、このガイドの情報と合せて使用してください。

- Oracle Fusion Middlewareのアップグレードのプランニング

- Oracle Fusion Middlewareの理解

- Upgrade Assistantによるアップグレード

- Oracle WebLogic Serverのアップグレード

- Oracle Fusion Middleware Infrastructureへのアップグレード

- Oracle User Messaging Serviceの管理

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle SOA SuiteおよびBusiness Process Managementのアップグレードの概要

Oracle Fusion Middleware SOA SuiteおよびBusiness Process Management 12cへのアップグレードの実行方法について学習します。この手順では、本番バージョンのOracle SOA Suite 11gまたは以前の12cリリースを、そのドメイン内のOracle Fusion Middlewareコンポーネント構成も含めて、このリリースにアップグレードする方法について説明します。

- Oracle SOA SuiteおよびBusiness Process Managementの12cへのアップグレードの理解 (12.2.1.1)

- SOA Suite 12c (12.2.1.1)アップグレードの開始点の理解

- アップグレード前の相互運用性および互換性の制約の理解

- SOAドメイン・アップグレードの制限の理解

- 標準SOAアップグレード・トポロジの理解

- アップグレードのためのこのガイドの使用方法の理解
アップグレード前の環境を構成する要素に応じて、様々なアップグレード・パスがあります。このガイドではサポートされているアップグレード・パスのすべてを記載するため、どの手順に従うかを理解しておくことが重要です。

1.1 Oracle SOA SuiteおよびBusiness Process Managementの12cへのアップグレードの理解 (12.2.1.1)

既存のSOA Suite 11gまたは12c環境をSOA SuiteおよびBusiness Process Management 12c (12.2.1.1)にアップグレードする場合、アップグレードがアップグレード前の環境にどのような影響を与えるかを理解する必要があります。たとえば、アップグレード時に既存の11gファイルを更新するスキーマおよびドメイン・ディレクトリのアップグレードは、「インプレース」で実行されます。12c (12.2.1.1)のOracleホーム・バイナリは新しいディレクトリにインストールされるため、「アウトオブプレース」でアップグレードされます。

12c (12.2.1.1)へのアップグレードには、中間層およびスキーマが含まれます。中間層のみ、またスキーマのみのアップグレードはできません。

次のリストで、InfrastructureおよびSOA Suiteコンポーネントに、どのようにアップグレードが実行されるかについて説明します。

- Oracle WebLogic Server、JRFおよびSOA Oracleホーム・バイナリ - アウトオブプレース・アップグレード
Oracle Infrastructure 12c (12.2.1.1) (WebLogic ServerとJRFを含む)と、SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のディストリビューション・バイナリを、新しいOracleホームにインストールします。11gバイナリは上書きされないため、バイナリのアップグレードは「アウトオブプレース」と考えられます。

- スキーマ - インプレースでアップグレード
11gスキーマは12c「インプレース」でアップグレードされるため、Upgrade Assistantはアップグレード処理時にスキーマを更新および上書きします。この処理の間は、サーバーを停止する必要があります。

- インスタンス - スキーマのアップグレード中に移行
アクティブ・インスタンスおよびクローズされたインスタンスの11gから12cへのアップグレードは、スキーマのアップグレードの一環として自動的に実行されます。管理スクリプトを使用してアップグレードを管理できます。

- ドメイン・ディレクトリ再構成 - インプレースでアップグレード
既存のSOAドメインは「インプレース」でアップグレードされます。アップグレード時に、11g SOAドメインの場所を指定し、11gドメインは新しいSOA 12c (12.2.1.1)のホーム・ディレクトリを指すように再構成されます。

- ドメイン・コンポーネント構成 - インプレースでアップグレード
11g SOAドメインを再構成した後、アップグレード・アシスタントを再度使用して、新しいSOA 12c (12.2.1.1)ホーム・ディレクトリ内で、アップグレードが必要な残りのドメイン・コンポーネント構成をアップグレードします。

注意:

ドメインのアップグレードはインプレースで実行することをお薦めします。ただし、アウトオブプレース・ドメイン・アップグレードが必要な場合は、「アウトオブプレース・ドメイン・ディレクトリ・アップグレードの実行」を参照してください。

1.2 SOA Suite 12c (12.2.1.1)アップグレードの開始点の理解

次の本番開始ポイントから、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)にアップグレードできます。

- SOA SuiteおよびBusiness Process Management 12c (12.1.3)および12c (12.2.1.0)

- SOA Suite 11g (11.1.1.9、11.1.1.7)

注意:
SOA 11g (11.1.1.6)以前を実行している場合は、アップグレードする前にSOA 11g (11.1.1.7または11.1.1.9)にアップグレードしておく必要があります。詳細は、Oracle Fusion Middleware 11g (11.1.1.7)アップグレード・ドキュメント・ライブラリのOracle Fusion Middleware Oracle SOA Suite、WebCenter PortalおよびADFのアップグレード・ガイドを参照してください。

1.3 アップグレード前の相互運用性および互換性の制約の理解

SOA SuiteおよびBPM 11gから12cへのアップグレード・プロセスを開始する前に、アップグレードが11gドメインのすべてのコンポーネントにどのような影響を与えるかを理解する必要があります。相互運用性および互換性の理解には、同時にアップグレードできるコンポーネントと、アップグレードできないコンポーネントについての詳細なマトリックスが掲載されています。通常、Oracle Fusion Middleware 12c (12.2.1.1)ではまだ使用できないコンポーネントを含むドメインはアップグレードできません。12c (12.2.1.1)にアップグレードできるコンポーネントには、別の制約もあります。これについての情報は、アップグレードを実行する前に慎重に確認する必要があります。

関連項目:SOAドメイン・アップグレードの制限の理解

1.4 SOAドメイン・アップグレードの制限の理解

既知の制限および以前のFusion Middlewareリリースからの構造の変更により、12c (12.2.1.1)にアップグレードできないドメインもあります。次の項目を確認し、ドメインがこれらの制約の影響を受けないことを確認します。これらの制約の影響を受けるドメインはアップグレードできません。

サポートされていないドメインはアップグレードしないでください。

次のリストは、SOAドメイン・アップグレードの既知の制約事項の説明です。

- SOAコア拡張機能を含むドメインは12.2.1.1にインプレース・アップグレードできません。
アップグレード前環境にSOAコア拡張機能が含まれる場合、このリリースのOracle Fusion Middlewareにはアップグレードできません。SOAコア拡張機能のアップグレードは、12c (12.2.1.1)ではサポートされていません。12.2.1.1ドメインにSOAコア拡張機能を含めるには、ファイルを手動で移行する必要があります。詳細は、Oracleサポートに連絡してください。

- クラウド・アダプタ・パックを含むドメインを12.2.1.1にアップグレードしないでください。
アップグレード前のドメインにクラウド・アダプタ・パックが含まれる場合、12.2.1.1にはアップグレードできません。

- Oracle Enterprise Repositoryを含むドメインは12.2.1.1にアップグレードできません

アップグレード前のドメインにOracle Enterprise Repository (OER)が含まれる場合、12.2.1.1にはアップグレードできません。

1.5 標準SOAアップグレード・トポロジの理解

このアップグレード・ドキュメントでは、2つの一般的なSOA Suite構成をアップグレードするための詳細な手順が説明されています。これらのトポロジを、Oracle Fusion Middleware 12cの標準アップグレード・トポロジと呼びます。具体的には、標準的なインストール・トポロジは、このガイドの目的に合わせて、1つの管理サーバーと1つのクラスタ(2つの管理対象サーバーが含まれている)を含む1つのWebLogic Serverドメイン、または1つのスタンドアロン・ドメインで構成されています。

スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。Oracle WebLogic Serverドメインに似たディレクトリ構造を持っていますが、管理サーバーや管理対象サーバーは含んでいません。スタンドアロン・ドメインには、同一タイプのシステム・コンポーネント(Oracle HTTP Serverなど)、またはタイプの混在したシステム・コンポーネントの1つ以上のインスタンスが含まれます。スタンドアロン・トポロジの詳細は、スタンドアロン・ドメインに関する項を参照してください。

実際のトポロジは異なる場合がありますが、このガイドで説明するトポロジは、同様のSOA Suiteコンポーネント・トポロジをアップグレードする際の参考として使用できるサンプルを示しています。

12c SOA Suiteトポロジの設定の詳細は、次を参照してください。

- Oracle SOA SuiteおよびBusiness Process Managementのインストールおよび構成

- Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド

1.6 アップグレードのためのこのガイドの使用方法の理解

アップグレード前環境に何があるかにより、アップグレード・パスは異なります。このガイドではサポートされているアップグレード・パスのすべてを記載するため、どの手順に従うかを理解しておくことが重要です。

次の表に、アップグレード前環境に基づく使用手順を示します。アップグレード前環境に、OracleWebCenterなど、他のOracle Fusion Middlewareコンポーネントが含まれる場合、詳細はコンポーネント固有のアップグレード・ガイドを参照する必要があります。このリリースで利用できるアップグレード・ガイドの完全なリストについては、Oracle Fusion Middleware 12cのアップグレード・ドキュメントを参照してください。

アップグレード前環境に含まれるもの

参照するアップグレード手順:

Oracle SOA SuiteおよびBusiness Process Management (BPM) 11g

SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のアップグレード

Oracle SOA SuiteおよびBusiness Process Management (BPM) 12c

以前の12cリリースからのOracle SOA SuiteおよびBusiness Process Managementのアップグレード

クラスタ化されたSOAおよびBPM環境

クラスタ化されたSOA環境のアップグレード

Oracle Business Activity Monitoring (BAM) 11gを含むOracle SOA Suite

Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード

Oracle Business Activity Monitoring (BAM) 12cを含むOracle SOA Suite

以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード

Oracle Business Activity Monitoring 11gのみを含むドメイン

BAMのみのドメインはアップグレードできませんが、BAMオブジェクトを12cにインポート/エクスポートすることができます。

既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

SOA Suiteを含むOracle Service Bus (OSB) 11g

Oracle Service Busのアップグレード

SOA Suiteを含まないOracle Service Bus (OSB)

OSBドメインのアップグレード(SOAを含まない場合)

Oracle User Messaging Service 11gまたは12c

ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

AIAFP 11gまたはSOA Core Extension 12cを含むSOAドメイン

未サポート - アップグレードするには、AIAFP 11gまたはSOA Core Extensionをアンインストールする必要があります。

2 Oracle Fusion Middlewareのアップグレード前タスク

アップグレード・プロセスを開始する前に、必ず、ご使用のコンポーネントおよび環境に必要なアップグレード前タスクを完了てください。

アップグレードを開始する前に、必要なアップグレード前タスクを完了しておく必要があります。必要なタスクを完了しないと、アップグレードが失敗したり、システムの停止時間が長引いたりする可能性があります。各自のデプロイメントに該当するタスクのみを完了してください。

注意:

アップグレードするOracle SOA製品によっては、追加のアップグレード前タスクを実行する必要がある場合があります。Oracle Service Busやユーザー・メッセージング・サービスなどの製品には、アップグレード前およびアップグレード後の追加構成タスクが必要になることがあります。

- Oracle Fusion Middlewareアップグレード前のチェックリスト
Oracle Fusion Middlewareアップグレード前のチェックリストでは、限られた停止時間でアップグレードを正常に行うために、アップグレードの開始前に実行できるタスクを示しています。

- 完全なバックアップの作成
新しい12c (12.2.1.1)ディストリビューションをインストールして、既存のOracle Fusion Middlewareデプロイメントのアップグレードを開始する前に、必ず、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なすべてのファイルをバックアップしておきます。

- テストのための本番環境のクローニング
実際の本番環境のコピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが期待どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることを強くお薦めします。

- 動作保証およびシステム要件の確認
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをあわせて使用する必要があります。

- 強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新
アップグレード後の環境で、強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定がある場合は、オプションの手順を実行します。アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

- 未使用データのパージ
アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。

- エディション・ベースの再定義のためのサーバー上でのエディションの作成
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。

- Upgrade Assistantを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するには、FMWという名前の非SYSDBAユーザーを作成することをお薦めします。FMWユーザーはスキーマの変更に必要な権限を持ちますが、完全な管理者権限を持ちません。

- SOA固有のアップグレード前タスクの実行
アップグレード前の環境によっては、Oracle Fusion Middlewareアップグレード前の要件に加えて、SOA固有の追加アップグレード・タスクを完了しておく必要がある場合もあります。

2.1 Oracle Fusion Middlewareアップグレード前のチェックリスト

Oracle Fusion Middlewareアップグレード前のチェックリストでは、限られた停止時間でアップグレードを正常に行うために、アップグレードの開始前に実行できるタスクを示しています。

アップグレードはサーバーが停止している間に実行されます。このチェックリストでは、停止時間を抑えるためにアップグレード前に実行できる、重要であるが時間がかかることが多いアップグレード前タスクを示します。アップグレード・プロセスの開始前に行える準備が多いほど、オフラインでかかる時間が少なくなります。

注意:
実行するアップグレード前手順は、既存のシステムの構成、アップグレードするコンポーネント、およびアップグレードと構成プロセスの最後に作成する環境によって異なります。各自の構成やユースケースに該当するタスクのみを完了してください。

表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク

タスク

説明

ドキュメント

既存の環境の完全なバックアップを作成します。

必須

アップグレードを開始する前に、アップグレードしようとしているスキーマを含めてシステムに重要なファイルとデータベースをすべてバックアップします。

アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再開できます。

完全なバックアップの作成。

既存のドメイン内の起動スクリプトのいずれかを変更した場合、アップグレード中にそれらを(既存ドメインの外部にある)一時ディレクトリの場所にコピーし、アップグレード後に再デプロイする必要があります。

カスタム・ドメイン環境設定のメンテナンス

使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。

オプション

システム・ファイルの完全なバックアップを作成するだけでなく、本番環境をクローニングしておくことも強くお薦めします。この環境は、アップグレードをテストするために使用されます。

テストのための本番環境のクローニング。

サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。

サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。

必須

(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。

動作保証の要件は頻繁に更新されるため、アップグレードの開始直前にこの情報を確認することをお薦めします。

アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。

また、12c製品ディストリビューションをインストールする前に、サポートされているJDKバージョンを使用していることを確認してください。

動作保証およびシステム要件の確認

32ビットのオペレーティング・システムを現在実行している場合は、アップグレード前に64ビット・オペレーティング・システムに移行する必要があります。

32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSを使用している場合のみ必須)

強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。

オプション

強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新

アップグレードする前に、期限切れまたは未使用のデータをパージします。

オプション

パフォーマンスの最適化のために、アップグレードされた環境で使用しないデータおよびオブジェクトをパージすることを検討してください。

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。

未使用データのパージ

Oracle Databaseユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.1)のデータベース・サーバーにエディションを作成する必要があります。

EBRデータベースを使用している場合のみ必須

エディション・ベースの再定義(EBR)データベースを使用している場合、アップグレードの開始前にエディションを作成する必要があります。

エディション・ベースの再定義のためのサーバー上でのエディションの作成

Upgrade Assistantを実行するために非SYSDBAユーザーを作成します。

オプション
Upgrade Assistantを実行するには、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理権限なしでUpgrade Assistantを実行できます。

Upgrade Assistantを実行するための非SYSDBAユーザーの作成

2.2 完全なバックアップの作成

新しい12c (12.2.1.1)ディストリビューションをインストールして、既存のOracle Fusion Middlewareデプロイメントのアップグレードを開始する前に、必ず、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含む、システムに重要なすべてのファイルをバックアップしておきます。

スキーマ・アップグレードを実行する前に完全データベース・バックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

詳細は、「Oracle Fusion Middleware環境のバックアップ」および「12cのためのOracle Databaseのアップグレードおよび準備」を参照してください。

注意:
システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

- スキーマ・バージョン・レジストリ表のバックアップ
システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

- カスタム・ドメイン環境設定のメンテナンス
各ドメインには、動的に生成されるドメインおよびサーバーの起動スクリプト(setDomainEnvなど)が含まれます。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

2.2.1 スキーマ・バージョン・レジストリ表のバックアップ

システム・バックアップにSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

SYSTEM.SCHEMA_VERSION_REGISTRY$表に、各Fusion Middlewareスキーマに対応する行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。必ず、既存のデータベース・スキーマをバックアップしてから、Upgrade Assistantを実行してください。

注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

2.2.2 カスタム・ドメイン環境設定のメンテナンス

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

カスタム・ドメイン・レベルの環境設定を維持するには、アップグレードの前に、カスタム・ドメイン情報を格納するファイルを別途作成してください。

たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。

# add custom libraries to the WebLogic Server system claspath
if [ "${POST_CLASSPATH}" != "" ] ; then
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
else
POST_CLASSPATH="${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
fi

# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。

注意:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

2.3 テストのための本番環境のクローニング

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。潜在的なアップグレードの問題を開発環境で特定しておくと、無駄な停止時間を排除できます。

注意:
このドキュメントでは、すべてのコンポーネントおよびオペレーティング・システムのクローニング手順を記載していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有です。大まかに言えば、コンポーネント・ドメインのアップグレード前バージョンをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成して、アップグレードを実行します。

本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

- アップグレードに関する問題を明らかにし、修正します。

- エンドツーエンドのアップグレードを完了させる練習をします。

- アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

- アップグレードの完了までに必要な時間を理解します。

- データベース・リソースの使用(一時表領域、PGAなど)について理解します。

注意:
クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。

2.4 動作保証およびシステム要件の確認

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントを併せて使用する必要があります。

注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。

警告:
アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。

- 環境が動作保証要件を満たしていることの確認
Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

- システム要件と仕様の確認
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

- Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認
Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

- Oracle Fusion Middlewareのこのリリースに対してJDKが動作保証されているかどうかの確認
汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、インストーラを実行する前に、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

2.4.1 環境が動作保証要件を満たしていることの確認

Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.2 システム要件と仕様の確認

ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、この動作保証に関するドキュメントに、ご使用の製品を64ビットOracle Linux 7上にインストールすることが動作保証されていると示されている場合、このドキュメントを使用して、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは必要に応じて更新され、ドキュメント・ライブラリの外部に置かれています。最新バージョンは、Oracle Technology Networkから入手できます。

Oracle Fusion Middleware 12cのインストールおよび12cへのアップグレードの詳細は、「システム要件と仕様のレビュー」を参照してください。

注意:
アップグレード準備としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、既存のアップグレード前のOracle Fusion Middlewareソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。

- 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSを使用している場合のみ必須)
この手順は、32ビット環境を実行している場合にのみ必要です。32ビットのOSを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

2.4.2.1 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSを使用している場合のみ必須)

この手順は、32ビット環境を実行している場合にのみ必要です。32ビットのOSを使用している場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。

注意:
これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。

オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

注意:
これらの手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。

- アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する
アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

- すべてのプロセスを停止する
アップグレード前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。

- 32ビット・ホスト・マシンからすべてのファイルをバックアップする
アップグレード・プロセスを開始する前に、11gデプロイメント全体の完全バックアップを作成したことを確認してください。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

- 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する
ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

- 11gバックアップを32ビット・ホストから64ビット・ホストにリストアする
11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

- 12c製品ディストリビューションをターゲット・マシンにインストールする
アップグレードはホーム外で実行することをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

- 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

2.4.2.1.1 アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する

アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

2.4.2.1.2 すべてのプロセスを停止する

アップグレード前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。

たとえば、管理サーバーを停止するには、次のコマンドを入力します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2.4.2.1.3 32ビット・ホスト・マシンからすべてのファイルをバックアップする

11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

注意:
同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。

11gのファイルのバックアップの詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

アップグレード時に、次のコンテンツにアクセスする必要があります。

- 11gドメイン・ホーム

- 11g /nodemanager directory located in $ORACLE_HOME/wlserver/common/

『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。

2.4.2.1.4 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する

ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。

2.4.2.1.5 11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

64ビットターゲット・マシンに11gファイルをリストアする方法の詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

2.4.2.1.6 12c製品ディストリビューションをターゲット・マシンにインストールする

アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

12cディストリビューションの入手方法の詳細な説明は、「製品ディストリビューションの理解と入手」を参照してください。インストール・ユーザーを指定するには、「インストール・ユーザーの選択」を参照してください。インストールおよび構成用のディレクトリ構造について理解するには、「インストールおよび構成のためのディレクトリの理解」を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

2.4.2.1.7 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする

ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

注意:
ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。「32ビット・ホスト・マシンからすべてのファイルをバックアップする」の一部として32ビット・ソース・マシンからバックアップした11gノード・マネージャ・ファイルを使用します。

2.4.3 Oracle Fusion Middlewareをホストするデータベースがサポートされているかどうかの確認

Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.4 Oracle Fusion Middlewareのこのリリースに対してJDKが動作保証されているかどうかの確認

汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

このマニュアルの発行時点で動作保証されているJDKは、1.8.0_77です。

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスしてJava SE JDKをダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。このため、JDKは/home/oracle/products/jdkディレクトリにインストールすることをお薦めします。

汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの汎用とプラットフォーム固有のディストリビューションとの相違点の理解に関する項を参照してください。

2.5 強化された暗号化(AES 256)の使用時のポリシー・ファイルの更新

アップグレード後の環境で、強化された暗号化(Advanced Encryption Standard (AES) 256など)を使用する予定がある場合は、オプションの手順を実行します。アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用せずに強化された暗号化を使用しようとすると、アップグレードに失敗することがあり、その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。

2.6 未使用データのパージ

アップグレード前に未使用データをパージしてパージ方法を管理すると、アップグレード・プロセスを最適化できます。

注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

一部のコンポーネントには自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。

SOA Suiteコンポーネントの場合:

クローズされた11gインスタンス・データを移行する場合は、アップグレードの実行前にインスタンス・パージ・スクリプトを実行します。「インスタンス・データ・パージ・スクリプトの使用」を参照してください。

2.7 エディション・ベースの再定義のためのサーバー上でのエディションの作成

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。

エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。

注意:
このタスクは、DBA権限を持つOracle Databaseユーザーのみが実行する必要があります。

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11gまたは12cエディションの子である必要があります。

データベース・サーバーにエディションを作成するには、SYSユーザー(またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを入力します。

create edition Oracle_FMW_12_2_1 as child of Oracle_FMW_11_1_1_7_0;

ここで、Oracle_FMW_11_1_1_7_0が、11.1.1.7スキーマを作成したときにRCU 11.1.1.7で指定したエディション名の例です。エディションを作成する際は、実際に使用する名前を入力してください。

エディションが正常に作成されると、次のメッセージが表示されます。

エディションが作成されました。

アップグレードの間、再構成ウィザードを実行して既存のドメインを再構成するよう要求されます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のようなSQLを使用して、データベースのデフォルト・エディション名を手動で次のように設定します。

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1;

2.8 Upgrade Assistantを実行するための非SYSDBAユーザーの作成

Upgrade Assistantを実行するには、FMWという名前の非SYSDBAを作成することをお薦めします。FMWユーザーはスキーマの変更に必要な権限を持ちますが、完全な管理者権限を持ちません。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。したがって、スキーマをアップグレードするには、非SYSDBAユーザーを作成することをお薦めします。アップグレード・アシスタントを起動する前に、このトピックにリストされている権限を付与する必要があります。

注意:
v$xatrans$表は、デフォルトでは存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。また、v$xatrans$表に対する権限付与が必要なのはOracle Identity Managerの場合のみです。構成にOracle Identity Managerが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

grant select on v$xatrans$ to FMW with grant option;

次の例では、welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

create user FMW identified by welcome1;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option;
grant execute on SYS.DBMS_ASSERT to FMW with grant option;

注意:

Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。

2.9 SOA固有のアップグレード前タスクの実行

アップグレード前の環境によっては、Oracle Fusion Middlewareアップグレード前の要件に加えて、SOA固有の追加アップグレード・タスクを完了しておく必要がある場合もあります。

この項では、12c (12.2.1.1)にアップグレードするSOA、Business Process Managementまたは統合製品に適用するアップグレード前のタスクについて説明しています。各自の環境に当てはまるタスクのみを実行してください。

注意:

アップグレードの準備を適切に行わないことが、リカバリ不能なエラーやアップグレードの失敗につながります。アップグレードの開始前に、該当するすべてのアップグレード前タスクが完了していることを確認してください。

アップグレード前タスク

詳細

必須

環境がOracle SOA SuiteおよびBPM 12c (12.2.1.1)へのアップグレードのOracle Database要件を満たしていることを確認します

SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

必須

表領域のサイズが適切に設定されていることを確認します(不十分なサイズに設定すると、アップグレードは失敗します)。

SOAINFRAおよびIAS_TEMP表領域へのデータ・ファイルの追加

SOA Composerユーザーのみ: コミットされていない変更はアップグレード後には使用できないことに注意してください。

アップグレード前のSOA Composerの変更のコミット

以前の12cリリースからアップグレードする場合にのみ必要です。
アップグレード前に、ドメインから既存のcloudsdkデプロイメントを削除します。

cloudsdkアプリケーションの削除

ユーザー・メッセージング・サービス(UMS)をアップグレードする場合にのみ必要です

SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

Oracle Service Bus (OSB)をアップグレードする場合にのみ必要です

SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行します。

Oracle Service Bus (OSB)のアップグレード前タスクの実行

オプション

スタンドアロンOracle HTTP Serverをアップグレードします。これは、アップグレードの前でも後でも実行できます。

スタンドアロンOracle HTTP Serverのアップグレード

- SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備
Fusion Middleware 12c (12.2.1.1)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。

- アップグレード前のSOA Composerの変更のコミット
アップグレードする前にSOA Composerサンドボックスへの変更をコミットまたはロールバックしない場合、変更が新しい環境に伝播されないことがあります。

- Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード
カスタム・アプリケーションをSOA 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。

- cloudsdkアプリケーションの削除
アップグレード前の環境にcloudsdkをインストールした場合は、アップグレードの開始前にそれを削除する必要があります。

- ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行
SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

- Oracle Service Bus (OSB)のアップグレード前タスクの実行
SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行する必要があります。

- スタンドアロンOracle HTTP Serverのアップグレード
スタンドアロンのOracle HTTP Serverをアップグレードする場合は、「Oracle HTTP Serverのアップグレード」の説明に従ってください。

2.9.1 SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

Fusion Middleware 12c (12.2.1.1)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。

Oracle SOA SuiteおよびBPM 12c (12.2.1.1)にアップグレードする場合のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認することが重要です。Fusion Middleware 12c (12.2.1.1)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。最新の情報については、常に最新のデータベースの動作保証マトリックスを参照してください。

Fusion Middlewareアップグレード前プロセスの一部として、データベースがサポートされていることを確認しました。しかし、Oracle SOA Suiteで使用するデータベースをインストールまたは確認する場合は、データベースのサイズおよびプロファイル、多数のOracle SOA Suiteコンポジット・アプリケーションのデータを格納する能力など、追加の考慮事項があります。詳細は、次のリソースを参照してください。

- 『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のデータベース・プロファイルのカスタム変数に関する項

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のSOAコンポジット・アプリケーションの概要に関する項

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベースのプロファイルまたはサイズの確認に関する項

- SOAINFRAおよびIAS_TEMP表領域へのデータ・ファイルの追加
アップグレードの失敗を防止するために、既存のSOAデータベース表領域に、データ・ファイルをさらに追加することをお薦めします。

2.9.1.1 SOAINFRAおよびIAS_TEMP表領域へのデータファイルの追加

アップグレードの失敗を防止するために、既存のSOAデータベース表領域に、データ・ファイルをさらに追加することをお薦めします。

すべての表領域にとって重要なことですが、11g SOAINFRA表領域とIAS_TEMP表領域のサイズをアップグレードが成功するように設定することが特に重要です。

注意:

サイズ設定のエラーが原因でデータベース・スキーマのアップグレードに失敗すると、ディスク領域を追加するだけではアップグレードを再試行できません。スキーマが不整合な状態になり、「INVALID」としてマークされた可能性があります。元の、アップグレード前の環境をバックアップからリストアしないと、このエラーからはリカバリできません。

2つのサンプル・コマンドを次に示します。自分のユース・ケース・シナリオに合せて、ファイルのサイズを設定してください。

SOAINFRA表領域にデータファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。

alter tablespace <PREFIX>_SOAINFRA add datafile '<DB_HOME>/oradata/orcl/<New_SoaInfra_DBF_FileName>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

IAS_TEMP表領域に一時ファイルを追加するには:

sysdbaとしてデータベースに接続して、次のコマンドを実行します。

alter tablespace PREFIX_IAS_TEMP add tempfile '<DB_HOME>/oradata/orcl/<New_iastemp_dbf_filename>' size 1000M autoextend on next 30M maxsize unlimited;
commit;

アップグレード前の表領域のサイズ設定の詳細は、データ・ファイルの作成および表領域への追加に関する項を参照してください。

2.9.2 アップグレード前のSOA Composerの変更のコミット

アップグレードする前にSOA Composerサンドボックスへの変更をコミットまたはロールバックしない場合、変更が新しい環境に伝播されないことがあります。

アップグレードを開始する前に、アップグレードされた環境に伝播するすべての変更をコミットし、伝播したくない変更をロールバックしていることを確認します。

2.9.3 Oracle JDeveloper 12cを使用したカスタム・アプリケーションのアップグレード

カスタム・アプリケーションをSOA 11gドメインにデプロイしていた場合、アップグレード手順の実行後、アプリケーションのデプロイメントはOracle Fusion Middleware 11gでの場合と同様に機能します。

新しいOracle 12c機能を利用するには、Oracle SOA SuiteまたはOracle Business Process ManagementのQuick Start for Developersをダウンロードしてインストールします。

Quick Start for Developersディストリビューションには、Oracle JDeveloper 12cユーザーに、Oracle SOA SuiteおよびOracle Business Process Managementのアプリケーションを開発するために必要な拡張機能を提供します。

詳細は、「Oracle SOA Suite Quick Start for Developersのインストール」を参照してください。

注意:
新しいOracle SOA 12c機能を使用するには、Oracle QuickStartが必要です。

2.9.4 cloudsdkアプリケーションの削除

アップグレード前の環境にcloudsdkをインストールした場合は、アップグレードの開始前にそれを削除する必要があります。

この手順は、以前の12cリリースでcloudsdkがデプロイされた場合にのみ必要です。

cloudsdkの12c (12.2.1.1)バージョンは自動的にサーバーにデプロイされ、ネーミング規則の変更によって、以前にデプロイされたアプリケーションと競合する可能性があります。

1. Oracle WebLogicコンソールにログインします。
WebブラウザにURLを入力します。次に例を示します。
http://host1.example.com:7001/em

Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。

2. コンソールの「ドメイン構成」パネルから、「デプロイメント」をクリックします。
(オプション)必要に応じて、手順の結果を入力します。明白な結果は記述しないでください。タスクはできるかぎり正確にする必要があります。

3. 「制御」タブをクリックします。

4. 「cloudsdk」を選択し、「停止」→「ただちに強制停止」をクリックします。

5. 「構成」をクリックします。

6. 「cloudsdk」を選択し、「削除」を選択します。

7. 「構成の解放」をクリックします。

2.9.5 ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクの実行

SOA Suiteのアップグレードの一部としてUMSをアップグレードする場合は、ユーザー・メッセージング・サービス(UMS)に必要なアップグレード前タスクを実行します。

ユーザー・メッセージング・サービスを11gから12cにアップグレードする場合は、追加のアップグレード前タスク(構成ファイルを手動で管理対象サーバーから管理サーバーにコピーするなど)を実行する必要がある場合があります。以前の12cリリースからUMSをアップグレードする場合、このタスクをもう一度実行する必要はありません。

詳細は、「ユーザー・メッセージング・サービスのアップグレード」を参照してください。

2.9.6 Oracle Service Bus (OSB)のアップグレード前タスクの実行

SOA Suiteのアップグレードの一部としてOracle Service Bus (OSB)をアップグレードする場合は、OSBに必要なアップグレード前タスクを実行する必要があります。

Oracle Service Busを含むSOAドメインをアップグレードする場合は、必須のアップグレード前タスクをいくつか実行する必要があります。「Oracle Service Bus (OSB)のアップグレード前タスクの実行」を参照してください。

2.9.7 スタンドアロンOracle HTTP Serverのアップグレード

スタンドアロンのOracle HTTP Serverをアップグレードする場合は、「Oracle HTTP Serverのアップグレード」の説明に従ってください。

このオプションの手順は、アップグレードの前でも後でも実行できます。

スタンドアロンOracle HTTP Serverインスタンス(11gドメインに関連付けられていないもの)をアップグレードする場合や、HTTP Serverを別の機会にアップグレードする場合は、『Oracle HTTP Serverのアップグレード』を参照してください。

注意:
既存のドメインに関連付けられた管理対象Oracle HTTP Serverは、Infrastructureのアップグレード・プロセス中に自動的にアップグレードされます。管理対象HTTP Serverを個別にアップグレードする必要はありません。

3 SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のアップグレード

この項では、単一ノードの本番SOA SuiteおよびBusiness Process Management 11g本番インストールを、SOA SuiteおよびBusiness Process Management 12c(12.2.1.1)にアップグレードする詳しい手順について説明します。

注意:

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。

- SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解
このフローチャートおよび付随するテキストで、Oracle Fusion Middleware SOA Suite 11gを12c (12.2.1.1)にアップグレードするための大まかな手順を示します

- Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のインストール
既存のSOAおよびBusiness Process Management (BPM)のコンポーネントをアップグレードする前に、まず、Oracle Fusion Middleware InfrastructureとOracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)製品ディストリビューションをインストールする必要があります。

- 11gからアップグレードする前の必須SOAスキーマの作成
サポートされている11gリリースからアップグレードする場合、アップグレードする前に、サポートされているデータベースで新しい12c必須スキーマを作成することが必要になる場合があります。

- アップグレード前の準備状況チェックの実行
Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

- SOAサーバーとプロセスの停止
アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止する必要があります。

- Upgrade Assistantを使用したスキーマのアップグレード
Upgrade Assistantとスキーマをアップグレードするには、このタスクに従います。

- 再構成ウィザードを使用したドメインの再構成
スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

- Upgrade Assistantを使用したドメイン・コンポーネント構成のアップグレード
Upgrade Assistantを使用して、残りのドメイン内WebLogicコンポーネント構成をすべて更新します。

- アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

3.1 SOA SuiteおよびBPMのアップグレード・プロセス・フローの理解

このフローチャートおよび付随するテキストで、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環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

「SOAサーバーとプロセスの停止」を参照

必須

12c (12.2.1.1)リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cスキーマを新しく作成します。

「11gからのアップグレード前の必要なSOAスキーマの作成」を参照

必須

Upgrade Assistantを実行して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブな(進行中の)インスタンス・データを移行します。

「Upgrade Assistantを使用したスキーマのアップグレード」を参照してください

注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12.2.1環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

詳細は、「SOAインスタンスのアップグレードの管理と監視」を参照してください。

オプション

アップグレード中、SOAインスタンスが自動的に移行されます。ただし、進行中のクローズ済インスタンスのアップグレードは、管理SQLスクリプトまたはOracle Fusion Middleware Enterprise Manager Controlを使用してアクティブに管理できます。

「SOAインスタンスのアップグレードの管理と監視」を参照

Oracle BAMがアップグレードの一部である場合のみ、必須。

アップグレードする11g SOAドメインにOracle Business Activity Monitoring (BAM)が含まれる場合、再構成ウィザードを実行する前に、BAMに固有のアップグレード前タスクをすべて完了する必要があります。これらの手順を再構成ウィザードの実行前に完了していないと、アップグレードに失敗します。

「Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード」を参照してください

注意: 12cのBusiness Activity Monitoring (BAM)は完全に再設計されており、ドメインの再構成前とアップグレードの後に追加の手順が必要になります。

必須

再構成ウィザードを実行して、ドメインとノード・マネージャを再構成します。

「再構成ウィザードを使用したドメインの再構成」を参照

必須

アップグレード・アシスタントを(再度)実行して、ドメイン構成をアップグレードします。

「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」を参照

各自の構成に該当するタスクが存在する場合のみ、必須。

必要なアップグレード後の構成タスクを実行します(必要な場合)。

「アップグレード後タスクの実行」を参照してください

必須

アップグレード検証プロセスの一部として、新しい管理サーバー、管理対象サーバーおよびノード・マネージャを起動して、問題がないか確認することをお薦めします。

「サーバーの起動と停止」を参照

必須

アップグレード検証プロセスの一部として、アップグレードしたすべてのコンポーネントが期待どおりに動作しているか確認することをお薦めします。

「ドメイン・コンポーネント構成のアップグレードの確認」を参照

3.2 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

既存の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ドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。

1. ターゲットのシステムにログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。

- UNIXオペレーティング・システムの場合: /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

- Windowsオペレーティング・システムの場合: C:\home\Oracle\Java\jdk1.8.0_77\bin\java -jar <component_name>.jarfmw_12.2.1.0.0_PRODUCT.jar

例: cd /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

4. 「インストール画面のナビゲート」の手順に従います。このリンクを使用すると、サポートされているすべてのトポロジに対応するインストール手順が記載されたOracle SOA SuiteおよびBusiness Process Managementのインストレーション・ガイドにアクセスできます。

5. インストールの終わりに、構成ウィザードを起動して12c (12.2.1.1)に新しいドメインを構成するように要求されます

3.3 11gからアップグレードする前の必須SOAスキーマの作成

サポートされている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)

RCUを使用してスキーマを作成する手順は次のとおりです。

1. JAVA_HOME環境変数を設定し、$JAVA_HOME/binを$PATHに追加します(まだそうしていない場合)。現在サポートされているJDKバージョンは、jdk1.8.0_77です

2. ご使用のシステムの12c ORACLE_HOME/oracle_common/binディレクトリに移動します。

3. RCUを起動します。
UNIXオペレーティング・システムでは、次のようにします。
./rcu

Windowsオペレーティング・システムの場合:
rcu.bat

4. RCU画面をナビゲートして、スキーマ作成を完了します。アップグレード用に新しいスキーマを作成する際は、「既存の接頭辞の選択」を選択して、既存のスキーマの作成に使用した接頭辞を見つけます。
注意: デフォルトで、Common Infrastructure Services (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

。

詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください

- OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。

3.3.1 OIDベースのセキュリティ・ストアのための12c OPSSスキーマの作成

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。

11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマを作成する必要があります。

アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択します。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。

注意:

12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

3.4 アップグレード前の準備状況チェックの実行

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックは使用率の低い期間に実行することをお薦めします。

アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

1. binディレクトリに移動します。
UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/upgrade/bin

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\upgrade\bin

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
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を-response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

準備状況チェック

常時。

この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

注意:
パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。

準備状況成功

準備状況チェックが正常に完了した場合。

これで、完全なレポートをレビューできるようになります。

準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

ORACLE_HOME/oracle_common/upgrade/logs

3.5 SOAサーバーとプロセスの停止

アップグレード・アシスタントを実行する前に、すべての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サーバーおよびプロセスは、次の順番で停止してください。

1. Business Activity Monitoring (BAM)管理対象サーバー

2. Oracle Service Bus (OSB)管理対象サーバー

3. サービス指向アーキテクチャ(SOA)管理対象サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. 管理サーバー

6. ノード・マネージャ
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

7. Web層(Oracle HTTP Serverを含む)

3.6 Upgrade Assistantを使用したスキーマのアップグレード

Upgrade Assistantとスキーマをアップグレードするには、このタスクに従います。

- SOAINFRAスキーマのアップグレード中のログ・ファイルの生成(推奨)

- Upgrade Assistantでアップグレードできるスキーマの特定
アップグレードを開始する前に、スキーマ・バージョン・レジストリを問い合せることによって、使用可能なスキーマのリストを確認します。

- Upgrade Assistantの起動

- Upgrade Assistantを使用したSOAスキーマのアップグレード
Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします

- スキーマのアップグレードの確認

- インスタンスのアップグレードの確認(該当する場合)

- 無効なデータベース・オブジェクトのチェック

- 11gからのパーティション化されたスキーマ表のアップグレード
Oracle SOA Suite 11gの管理ガイドの説明に従ってパーティション化されたスキーマを含むOracle SOA 11gインストールをアップグレードしようとする場合、SOA 12c (12.2.1.1)でもこの特定の表パーティション化戦略を使用するには、これらの必要な手順を完了して、パーティション化されたスキーマ表をアップグレードする必要があります。

3.6.1 SOAINFRAスキーマのアップグレード中のログ・ファイルの生成(推奨)

アップグレードのトラブルシューティングを容易にするために、_SOAINFRA スキーマのアップグレード時にログ・ファイルを生成することをお薦めします。デフォルトでは、ロギングは無効になっています。

ロギングを有効化するには:

1. soainfraユーザー・ディレクトリをUPGRADE_DIRという名前で作成します。

2. set_LogLevel(1)または ALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';関数を呼び出して、デバッグ・ログを有効化します。

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level>] [-logDir <log_directory>]

3.6.2 Upgrade Assistantでアップグレードできるスキーマの識別

アップグレードを開始する前に、スキーマ・バージョン・レジストリを問い合せることによって、使用可能なスキーマのリストを確認します。

このオプションの手順は、アップグレード・プロセスを開始する前に手動で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)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

3.6.3 Upgrade Assistantの起動

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

1. UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level] [-logDir <log_directory>]

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

注意:
トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

3.6.4 Upgrade Assistantを使用したSOAスキーマのアップグレード

Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします

Upgrade Assistantでは、スキーマのアップグレード時に、次に示す一連の画面が表示されます。各画面でアクションを実行します。

表3-4 Upgrade Assistant画面: スキーマのアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「個別に選択されたスキーマ」を選択します。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、Oracle SOAを選択した場合、Oracle SOA (_SOAINFRA)、Audit Services (_IAU)、Metadata Service (_MDS)、Oracle Platform Security Services(_OPSS)およびUser Messaging Services (_UMS)スキーマがアップグレードに含まれます。

Managed File Transferを選択した場合、監査サービス(_IAU)、Enterprise Scheduler (_ESS)およびPlatform Security Services (OPSS)がアップグレードに含まれます。

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

1. 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

2. データベース接続の詳細を入力して、「接続」をクリックします。

3. 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。
場合によっては(_ORASDPMなど)、スキーマ・ユーザー名とパスワードを手動で入力する必要があります。

11gから12cへのアップグレードのみ: UCSUMSスキーマは自動的には移入されません。ユーザーとして、接頭辞_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSスキーマと見なされます。

4. 「次へ」をクリックします。

注意:

- スキーマ資格証明画面のタイトルは、アップグレードするスキーマに応じて変化します。たとえば、_SOAINFRAスキーマをアップグレードする場合、画面のタイトルはSOAINFRAスキーマと表示されます。

- データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックします。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

3.6.5 スキーマのアップグレードの確認

次の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」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

3.6.6 インスタンスのアップグレードの確認(該当する場合)

スキーマのアップグレードの一部としてインスタンスをアップグレードした場合は、インスタンスにエラーがないことを確認します。

- アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントの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.

3.6.7 無効なデータベース・オブジェクトのチェック

Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。

SQL>@?/rdbms/admin/utlrp.sql

これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。

その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

この時点では、アップグレードされたスキーマに、無効になっているデータベース・オブジェクトはないはずです。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。

3.6.8 11gからのパーティション化されたスキーマ表のアップグレード

Oracle SOA Suite 11gの管理ガイドの説明に従ってパーティション化されたスキーマを含むOracle SOA 11gインストールをアップグレードしようとする場合、SOA 12c (12.2.1.1)でもこの特定の表パーティション化戦略を使用するには、これらの必要な手順を完了して、パーティション化されたスキーマ表をアップグレードする必要があります。

注意:
この手順は、アップグレード済の12c環境で既存のOracle SOA 11g表パーティション化戦略を使用しようとする場合にのみ必要です。以前の12cリリースからアップグレードする場合は、この手順を完了する必要はありません。

パーティション化されたスキーマ表のアップグレードの理解

Oracle SOA Suite 12cでは、均等パーティション化戦略の基礎となる新しいファブリック表セットが導入されています。次に説明する手順を実行すると、依存するサービス・エンジン表(BPELなど)を再ビルドせずに、既存の11g戦略を新しい12cファブリックに合せて調整できます。このパーティション調整により、現在非推奨となった11g 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スクリプトの生成

1. SYSDBAとして、TRS_DIRを作成し、<soainfra>への読取りおよび書込みを許可します。

SQL > create directory TRS_DIR as ‘/../../..’;
SQL>  grant read,write on directory TRS_DIR to <soainfra>

2. デバッグ・モードを有効化します。

ALTER PROCEDURE debug_purge  COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' ║ REUSE SETTINGS;
ALTER PROCEDURE log_info COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE' REUSE  ║  SETTINGS;

3. 次のディレクトリに移動します。

12C_mwhome/soa/common/sql/soainfra/sql/oracle/122110/trs12/

4. 必要な変更があれば、trs_migrate_exec.sqlを編集します。次の表は、パラメータおよび使用可能なオプションを示しています。

パラメータ

オプション

range_interval

R (レンジ)またはI (間隔)

interval_clause

'NUMTOYMINTERVAL(1, ''MONTH'')‘
SQL変換関数によって指定します

- NUMTODSINTERVALは、nをINTERVAL DAY TO SECONDリテラルに変換します。

- NUMTOYMINTERVALは、数値nをINTERVAL YEAR TO MONTHリテラルに変換します。

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;
/

5. trs_migrate_exec.sqlを実行して、DDLスクリプトを生成します。

フェーズ2: DDLスクリプトの編集および実行

DDLスクリプトが生成されたら、そのスクリプトを実行する前に編集する必要があります。

1. 生成されたDDLスクリプトを開いて、COMPOSITE_INSTANCEパーティションに関するコメントを検索します。新しいファブリック表それぞれのDDLを更新し、これらのコメントが見つかった箇所すべてにこれらのパーティションを追加する必要があります。

CREATE TABLE "PART_SOAINFRA"."SCA_FLOW_INSTANCE_M"
(    "FLOW_ID" NUMBER(*,0),
"FLOW_CORRELATION_ID" VARCHAR2(100),
….
TABLESPACE "DEV12_SOAINFRA" ;    <REMOVE SEMICOLON
/*                                 <REMOVE COMMENTS (if any)
REM The RANGE partitions are based on COMPOSITE_INSTANCE
REM    INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
REM    (PARTITION p0 VALUES LESS THAN (TO_DATE('2007-02-01', 'YYYY-MM-DD')),
REM    (PARTITION p1 VALUES LESS THAN (TO_DATE('2007-03-01', 'YYYY-MM-DD')));
*/
PARTITION BY RANGE (CREATED_TIME)
INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
(
PARTITION P0 VALUES LESS THAN (TO_DATE(TIMESTAMP' 2007-02-01 00:00:00' ,'YYYY-MM-DD')),,    <REMOVE TIMESTAMP, 00:00:00 and LAST COMMA

編集後のスクリプトは次のようになります:

CREATE TABLE "PART_SOAINFRA"."SCA_FLOW_INSTANCE_M"
(    "FLOW_ID" NUMBER(*,0),
"FLOW_CORRELATION_ID" VARCHAR2(100),
….
TABLESPACE "DEV12_SOAINFRA"
PARTITION BY RANGE (CREATED_TIME)
INTERVAL(NUMTOYMINTERVAL(1, 'MONTH'))
(
PARTITION P0 VALUES LESS THAN (TO_DATE('2007-02-01' ,'YYYY-MM-DD')),
PARTITION P1 VALUES LESS THAN (TO_DATE('2007-03-01' ,'YYYY-MM-DD')));
。

2. まず、テスト環境で編集済のDDLスクリプトを実行およびテストします。

3. TRS_DIRで、エラーに関するログを確認します。

4. 検証スクリプトをテストします。

3.7 再構成ウィザードを使用したドメインの再構成

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

- WLSコア・インフラストラクチャ

- ドメイン・バージョン

注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

具体的には、ドメインを再構成する場合、次のことが発生します。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしたことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを変更するには、次の説明に従ってください。ドメイン再構成の一般情報については、WebLogicドメインの再構成に関する項を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- ドメインの再構成

3.7.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

1. ソース・ドメインを別の場所へコピーしてコンテンツを保存します。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. バックアップされたバージョンのドメインが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

3.7.2 再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

1. ドメインが存在するシステムにログインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

edition_nameは、子エディションの名前です。

4. 次のディレクトリに移動します。

(UNIXオペレーティング・システム) ORACLE_HOME/oracle_common/common/bin

(Windowsオペレーティング・システム) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEは12c Oracleホーム・ディレクトリです。

5. 次のコマンドを実行します。

(UNIXオペレーティング・システム) ./reconfig.sh -log=log_file -log_priority=ALL

(Windowsオペレーティング・システム) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ -log_priority=ALLは、ログを詳細モードで出力します。

注意:

reconfig.cmdまたはreconfig.shを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

3.7.3 ドメインの再構成

次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、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」を選択します。

- 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

- クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、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)」をクリックして再構成ウィザードを終了します。

3.8 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

Upgrade Assistantを使用して、残りのドメイン内WebLogicコンポーネント構成をすべて更新します。

アップグレード・アシスタントを使用して追加ドメイン・コンポーネント構成をアップグレードするには、次の各項の手順に従います。

注意:

アップグレード・アシスタントを起動する前に、管理サーバーを起動しないでください。

- GUIモードでのUpgrade Assistantの起動
Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

- SOAコンポーネント構成のアップグレード

3.8.1 GUIモードでのUpgrade Assistantの起動

Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:
Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。スキーマのアップグレードに必要な権限を持つユーザーを作成する手順は、「非SYSDBAユーザーの作成」で説明されています。

Upgrade Assistantを起動するには、次の手順に従います。

1. UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level] [-logDir <log_directory>]

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

注意:
トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

3.8.2 SOAコンポーネント構成のアップグレード

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.9 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

表3-7に、アップグレード後に実行することが多い一般的な管理タスクを示します。また、コンポーネント固有の管理ガイドでは、アップグレード後に実行する追加の構成タスクについても説明している場合があります。

表3-7 基本的な管理タスク

タスク

説明

詳細

コンポーネントの追加のアップグレード後構成手順の実行

「アップグレード後のタスクの実行」で説明しているアップグレード後のタスクに加えて、追加の構成タスクを実行し、新しくアップグレードしたコンポーネントが期待どおりに機能することを確認する必要もあります。

- 『Oracle Fusion Middlewareの管理』

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- Oracle Service Busの管理

- Oracle User Messaging Serviceの管理

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のモニタリング

4 以前の12cリリースからのOracle SOA SuiteおよびBusiness Process Managementのアップグレード

アップグレード手順は、開始ポイントや既存のドメイン内のコンポーネントにより異なります。以前の12cリリースからアップグレードする場合、次の手順を使用してこのリリースにアップグレードします。

次のいずれかのアップグレード・パスを選択します。

- 以前の12cリリースからSOA SuiteおよびBusiness Process Management 12c (12.2.1.1)へのアップグレード
この手順に従って、Oracle SOA SuiteおよびBusiness Process Management 12cデプロイメントをこの12cリリースにアップグレードします。

- 以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード
既存の12cデプロイメントにBusiness Activity Monitoring (BAM)を含むSOA Suiteが含まれる場合、次のタスクを完了して、12c (12.2.1.1)リリースにアップグレードする必要があります。

- 再構成ウィザードを使用したサーバー・グループのターゲット指定
以前の12cリリースからアップグレードする場合、再構成ウィザードを使用して、適切なサーバー・グループに、サーバーを手動でターゲット指定する必要があります。

4.1 以前の12cリリースからSOA SuiteおよびBusiness Process Management 12c (12.2.1.1)へのアップグレード

Oracle SOA SuiteおよびBusiness Process Managementの12cデプロイメントをこの12cリリースにアップグレードするには、この手順に従います。

1. すべての必要なアップグレード前タスクが完了していることを確認します。
このプロセスを開始する前に、アップグレード前タスクを完了します。「Oracle Fusion Middlewareアップグレード前のチェックリスト」と、デプロイされたアプリケーションに必要となる可能性があるSOA固有のタスクを参照してください。リストアの必要が生じた場合のために、使用可能な完全なバックアップ・バージョンが存在することを確認します。

2. 新しいOracleホームに12c (12.2.1.1)製品ディストリビューションをインストールします。Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

3. Upgrade Assistantを-readinessモードで使用して、アップグレード前の準備状況チェックを実行します。
12c (12.2.1.1) OracleホームからreadinessモードでUpgrade Assistantを起動して、12.1.3または12.2.1ドメインに、アップグレードの失敗の原因となる可能性のある問題がないか確認します。
UNIXオペレーティング・システムのユーザーは、12c (12.2.1.1) Oracleホームのoracle_common/upgrade/binに移動します

次のコマンドを実行します。 ./ua — readiness

Windowsオペレーティング・システムのユーザーは、12c (12.2.1.1) Oracleホームのoracle_common\upgrade\binに移動します

次のコマンドを実行します。ua.bat — readiness

4. すべての管理サーバーおよび管理対象サーバーを停止します。SOAサーバーとプロセスの停止

5. Upgrade Assistant 12c (12.2.1.1)を使用して、12.1.3または12.2.1.0スキーマを12c (12.2.1.1)にアップグレードします。
12c (12.2.1.1) OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1.0スキーマをアップグレードします。
UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します

次のコマンドを実行します。 ./ua

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します

次のコマンドを実行します。ua.bat

注意:
デフォルトのロギング・レベルはNOTIFICATIONです。(必要な場合)トラブルシューティングの際に役立つように、ロギング・レベルをWARNINGまたはERRORに設定することを検討します。例: ./ua -logLevel ERROR

6. 標準アップグレード・プロセス「Upgrade Assistantを使用したSOAスキーマのアップグレード」の説明に従って、Upgrade Assistantの各画面を完了します

7. 再構成ウィザードを使用したドメイン構成のアップグレード

再構成ウィザードを起動してドメインを再構成します。

UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/common/bin

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEは、12c (12.2.1.1) Oracleホーム・ディレクトリです。

UNIXオペレーティング・システムの場合:

./reconfig.sh -log=<log_file> -log_priority=ALL

Windowsオペレーティング・システムの場合:

reconfig.cmd -log=<log_file> -log_priority=ALL

12c (12.2.1.1) Oracleホームから再構成ウィザードを起動して、12.1.3または12.2.1ドメインをアップグレードします。

8. 標準再構成プロセス「ドメインの再構成」の説明に従って、再構成ウィザードの各画面を完了します
再構成プロセスの間、サーバーを正しいサーバー・グループにターゲット指定する必要があります(詳細は「再構成ウィザードを使用したサーバー・グループのターゲット指定」を参照)

- Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のインストール
既存のSOAおよびBusiness Process Management (BPM)のコンポーネントをアップグレードする前に、まず、Oracle Fusion Middleware InfrastructureとOracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)製品ディストリビューションをインストールする必要があります。

- アップグレード前の準備状況チェックの実行
Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

- SOAサーバーとプロセスの停止
アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止する必要があります。

- Upgrade Assistantの起動

- Upgrade Assistantを使用したSOAスキーマのアップグレード
Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします

- 再構成ウィザードを使用したドメインの再構成
スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

- SOAコンポーネント構成のアップグレード

4.1.1 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

既存の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ドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。

1. ターゲットのシステムにログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。

- UNIXオペレーティング・システムの場合: /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

- Windowsオペレーティング・システムの場合: C:\home\Oracle\Java\jdk1.8.0_77\bin\java -jar <component_name>.jarfmw_12.2.1.0.0_PRODUCT.jar

例: cd /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

4. 「インストール画面のナビゲート」の手順に従います。このリンクを使用すると、サポートされているすべてのトポロジに対応するインストール手順が記載されたOracle SOA SuiteおよびBusiness Process Managementのインストレーション・ガイドにアクセスできます。

5. インストールの終わりに、構成ウィザードを起動して12c (12.2.1.1)に新しいドメインを構成するように要求されます

4.1.2 アップグレード前の準備状況チェックの実行

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックは使用率の低い期間に実行することをお薦めします。

アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

1. binディレクトリに移動します。
UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/upgrade/bin

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\upgrade\bin

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
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スキーマを作成する必要があります。

表4-1 Upgrade Assistant画面: 準備状況チェック

画面

画面が表示されるタイミング

説明

ようこそ

常時。

この画面には、準備状況チェックの概要が示されます。

準備状況チェックのタイプ:

- 個別に選択されたスキーマ

- ドメイン・ベース

常時。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。

- 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

- 「ドメイン・ベース」オプションを使用して、ドメインごとに準備状況チェックが実行されるようにします。

使用可能なコンポーネント

「個別に選択されたスキーマ」が選択されている場合。

この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。

すべてのスキーマのコンポーネント・リスト

スキーマの準備状況チェックが実行されるたび。

この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。

スキーマ資格証明

常時。

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。

DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください

準備状況サマリー

常時。

この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

Upgrade Assistantを-response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

準備状況チェック

常時。

この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

注意:
パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。

準備状況成功

準備状況チェックが正常に完了した場合。

これで、完全なレポートをレビューできるようになります。

準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

ORACLE_HOME/oracle_common/upgrade/logs

4.1.3 SOAサーバーとプロセスの停止

アップグレード・アシスタントを実行する前に、すべての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サーバーおよびプロセスは、次の順番で停止してください。

1. Business Activity Monitoring (BAM)管理対象サーバー

2. Oracle Service Bus (OSB)管理対象サーバー

3. サービス指向アーキテクチャ(SOA)管理対象サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. 管理サーバー

6. ノード・マネージャ
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

7. Web層(Oracle HTTP Serverを含む)

4.1.4 Upgrade Assistantの起動

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

1. UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level] [-logDir <log_directory>]

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

注意:
トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

4.1.5 Upgrade Assistantを使用したSOAスキーマのアップグレード

Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします

Upgrade Assistantでは、スキーマのアップグレード時に、次に示す一連の画面が表示されます。各画面でアクションを実行します。

表4-2 Upgrade Assistant画面: スキーマのアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「個別に選択されたスキーマ」を選択します。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、Oracle SOAを選択した場合、Oracle SOA (_SOAINFRA)、Audit Services (_IAU)、Metadata Service (_MDS)、Oracle Platform Security Services(_OPSS)およびUser Messaging Services (_UMS)スキーマがアップグレードに含まれます。

Managed File Transferを選択した場合、監査サービス(_IAU)、Enterprise Scheduler (_ESS)およびPlatform Security Services (OPSS)がアップグレードに含まれます。

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

1. 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

2. データベース接続の詳細を入力して、「接続」をクリックします。

3. 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。
場合によっては(_ORASDPMなど)、スキーマ・ユーザー名とパスワードを手動で入力する必要があります。

11gから12cへのアップグレードのみ: UCSUMSスキーマは自動的には移入されません。ユーザーとして、接頭辞_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSスキーマと見なされます。

4. 「次へ」をクリックします。

注意:

- スキーマ資格証明画面のタイトルは、アップグレードするスキーマに応じて変化します。たとえば、_SOAINFRAスキーマをアップグレードする場合、画面のタイトルはSOAINFRAスキーマと表示されます。

- データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックします。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

4.1.6 再構成ウィザードを使用したドメインの再構成

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

- WLSコア・インフラストラクチャ

- ドメイン・バージョン

注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

具体的には、ドメインを再構成すると、次のようになります。

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。

注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成ウィザードの実行中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

- ドメインのバックアップ

- 再構成ウィザードの起動

- ドメインの再構成

4.1.6.1 ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

3. ドメインのバックアップしたバージョンが完全であることを確認します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

4.1.6.2 再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

1. ドメインが存在するシステムにログインします。

2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

次のSQLコマンドを実行して、デフォルト・エディションを設定します。

ALTER DATABASE DEFAULT EDITION = edition_name;

edition_nameは、子エディションの名前です。

4. 次のディレクトリに移動します。

(UNIXオペレーティング・システムの場合) ORACLE_HOME/oracle_common/common/bin

(Windowsオペレーティング・システムの場合) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEは12c Oracleホーム・ディレクトリです。

5. 次のコマンドを実行します。

(UNIXオペレーティング・システム) ./reconfig.sh -log=log_file -log_priority=ALL

(Windowsオペレーティング・システム) reconfig.cmd -log=log_file -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ -log_priority=ALLは、ログを詳細モードで出力します。

注意:

reconfig.cmdまたはreconfig.shを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: can't create package cache dir

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

4.1.6.3 ドメインの再構成

次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。

表4-3 再構成ウィザードの画面

再構成ウィザードの画面

説明および必要なアクション

ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよび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」を選択します。

- 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

- クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

12.1.3から12.2.1.1にアップグレードするときは、適切なサーバー・グループにサーバーを割り当てる必要があります。「再構成ウィザードを使用したサーバー・グループのターゲット指定」を参照してください

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
SOA UPGRADES ONLY: 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)」をクリックして再構成ウィザードを終了します。

4.1.7 SOAコンポーネント構成のアップグレード

WebLogicコンポーネント構成のアップグレード時のUpgrade Assistantの画面を示しています。

注意: 表示される画面は、使用している環境に基づいています。次に示す画面は、すべてが表示されない場合もあります。Upgrade Assistant画面の使用の詳細は、オンライン・ヘルプを参照してください。

注意:

追加の構成タスクが必要になる場合があります。

Upgrade Assistantによるスキーマとコンポーネント構成のアップグレードが正常に完了したら、「アップグレード後のタスクの実行」で説明されているタスクを実行して、コンポーネントが引き続き期待どおりに機能していることを確認する必要がある場合があります。

表4-4 Upgrade Assistant画面: 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構成ファイルのコピーを参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

アップグレード処理のステータスを確認します。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

4.2 以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード

既存の12cデプロイメントに、Business Activity Monitoring (BAM)を含むSOA Suiteが含まれる場合、12c (12.2.1.1)リリースにアップグレードするには、次のタスクを完了する必要があります。

1. 必須のアップグレード前タスクをすべて完了します。
このプロセスを開始する前に、アップグレード前タスクを完了します。アップグレード前チェックリストと、デプロイされたアプリケーションによって必須となる場合があるすべてのSOA固有のタスクを参照してください。リストアの必要が生じた場合のために、使用可能な完全なバックアップ・バージョンが存在することを確認します。

2. Upgrade Assistantを-readinessモードで使用して、アップグレード前の準備状況チェックを実行します。
12.2.1.1 OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1ドメインのアップグレードの準備状況を確認します。
UNIXオペレーティング・システムのユーザーは、12.2.1.1 Oracleホームのoracle_common/upgrade/binに移動します

次のコマンドを実行します。 ./ua — readiness

3. Upgrade Assistant 12c (12.2.1.1)を使用して、12.1.3または12.2.1スキーマを12.2.1.1にアップグレードします。
12.2.1 OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1スキーマをアップグレードします。
UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します

次のコマンドを実行します。 ./ua

Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します

次のコマンドを実行します。ua.bat

4. 標準アップグレード・プロセス「Upgrade Assistantを使用したスキーマのアップグレード」の説明に従って、Upgrade Assistantの各画面を完了します

5. 再構成ウィザード12c (12.2.1)を使用したドメイン構成のアップグレード
12.2.1.1 Oracleホームから再構成ウィザードを起動して、12.1.3または12.2.1ドメインをアップグレードします。
UNIXオペレーティング・システム・ユーザーは、次に移動します。

12.2.1.1 Oracleホームのoracle_common/common/bin

次のコマンドを実行します。 ./reconfig.sh

標準再構成プロセス「再構成ウィザードを使用したドメインの再構成」の説明に従って再構成ウィザード画面を完了します

重要: 再構成ウィザードの実行時には、次の追加のタスクを完了する必要があります。

a. 「コンポーネント・データソース」画面で、BAMリース・スキーマの「スキーマ所有者」のフィールドの<prefix>_WLS_RUNTIMEを<prefix>_WLSに変更します。スキーマ所有者名に、DEV_WLS_RUNTIMEが不正確に表示される場合があります。

b. 「再構成ウィザードを使用したサーバー・グループのターゲット指定」の説明に従って、再構成ウィザードの「管理対象サーバー」画面を完了します

4.3 再構成ウィザードを使用したサーバー・グループのターゲット指定

以前の12cリリースからアップグレードする場合、再構成ウィザードを使用して、適切なサーバー・グループに、サーバーを手動でターゲット指定する必要があります。

以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

1. 再構成ウィザードを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin

(Windows) ORACLE_HOME\oracle_common\common\bin

ORACLE_HOMEはOracleホーム・ディレクトリです。

(UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL

(Windows) reconfig.cmd -log=<log_file> -log_priority=ALL

2. 「拡張構成」画面に移動し、「管理対象サーバー、クラスタおよびCoherence」を選択します。

3. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

注意:
OWSMPMがそれ自身のクラスタにあり、SOAまたはOSBクラスタの一部ではない場合は、SOAクラスタへはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲット指定し、OSBクラスタへはOSB-MGD-SVRS-ONLYのみをターゲット指定し、OWSMへはWSMPM-MAN-SVERサーバー・グループをターゲット指定してください。12.1.3を12.2.1.1にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタにターゲット指定することも必要です。

コンポーネントとサーバー

サーバー・グループ

SOA (soa_server1)

SOA-MGD-SVRS-ONLY

Oracle Service Bus — OSB (osb_server1)

OSB-MGD-SVRS-ONLY

Business Activity Monitoring — BAM (bam_server1)

BAM-MGD-SVRS-ONLY

Managed File Transfer — MFT (mft_server1)

MFT-MGD-SVRS-ONLY

これで各サーバーは正しいサーバー・グループにターゲット指定されたはずであり、「未指定」とは表示されないはずです。

5 クラスタ化されたSOA環境のアップグレード

クラスタ化されたSOA環境へのアップグレード・プロセスと、アップグレード後の構成タスクを実行するプロセスについて説明します。

- SOAクラスタ・アップグレード・トポロジの理解

- クラスタ化トポロジでの保護されたタスク・フォームの使用
タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。

- クラスタ化トポロジのアップグレード

- SOAHOST2でのドメイン構成の伝播
ここに示す手順を実行して、もう一方のホストに新しくアップグレードしたファイルを伝播します。

- クラスタ・アップグレードのアップグレード後タスク

5.1 SOAクラスタ・アップグレード・トポロジの理解

図5-1は、クラスタ化されたOracle SOA Suiteデプロイメントのサンプル・トポロジを示しています。このトポロジでは、SOA、Oracle Web Services Manager (OWSM)、Oracle Service Bus (OSB)およびOracle Business Activity Monitoring (Oracle BAM)が、2つのアプリケーション・ホスト(SOAHOST1とSOAHOST2)に渡る個別のクラスタに含まれています。Oracle HTTP Server、管理サーバー、Oracle Enterprise Manager Fusion Middleware Controlおよびデータベースは、両方のホストで共有されています。

この章では、特に、複数のホスト・コンピュータにスケール・アウトされた複数のWebLogic Serverクラスタが含まれているWebLogicドメインのアップグレードに必要な手順を説明します。この章の概念と手順は、ユーザー独自のOracle SOA Suite環境に適用できます。

このサンプル・トポロジのアップグレードに必要な手順は、次の項の表5-1で説明しています。

注意:

SOAを含むOracle BAMをアップグレードする場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照してください。

図5-1 クラスタ化されたSOAのトポロジ

5.2 クラスタ化トポロジでの保護されたタスク・フォームの使用

タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。

SOAコンポジットにヒューマン・タスク・フォームが含まれている場合や、タスク・フォームが非SOAサーバーにデプロイされている場合は、アップグレード後にタスク・フォームを保護する必要があります。

5.3 クラスタ化トポロジのアップグレード

表5-1は、クラスタ化された複数ホストのOracle SOA Suiteサンプル・トポロジ(図5-1)をアップグレードするために必要な手順を示しています。

表5-1 Oracle SOA SuiteおよびBPMクラスタのアップグレード・ロードマップ

タスク

参照先

アップグレード・トポロジを確認して、設定でSOAHOST1およびSOAHOST2を特定します。

「SOAクラスタ・アップグレード・トポロジの理解」を参照

SOAHOST1またはSOAHOST2で実行中の管理サーバー、すべての管理対象サーバーおよびノード・マネージャを停止します。

「SOAサーバーとプロセスの停止」を参照

SOAHOST1の新しいOracleホーム・ディレクトリに、Infrastructure (WebLogic Server、OWSMおよびJRF)およびOracle SOA Suite製品をインストールします。

「Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のインストール」を参照

SOAHOST1で、11gデプロイメントの完全アップグレードを実行します。環境に適用するアップグレード後の構成を実行します。

「SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のアップグレード」を参照

関連項目:

BAMがドメインの一部に含まれる場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照

OSBがドメインの一部に含まれる場合は、「Oracle Service Busのアップグレード」を参照

SOAHOST1のドメイン構成をSOAHOST2に伝播します。

これを行うには、 SOAHOST1でドメインをパックして、それをSOAHOST2で解凍する必要があります。

「SOAHOST2へのドメイン構成の伝播」を参照

SOAHOST1とSOAHOST2で、管理サーバーと管理対象サーバーを起動します。

「サーバーの起動と停止」を参照

アップグレード後に必要なタスクを実行します。

「アップグレード後タスクの実行」を参照してください

5.4 SOAHOST2でのドメイン構成の伝播

次の手順を使用して、新しくアップグレードされたファイルを別のホストに伝播します。

SOAHOST1で単一ノードのアップグレードを完了したら、ここに示す手順を実行して、もう一方のノード(SOAHOST2)に新しくアップグレードしたファイルを伝播します。

- 管理サーバーといずれかの管理対象サーバーがインストールされているサーバーでのpackコマンドの実行

- 前の手順で作成したテンプレート・ファイルのSOAHOST2へのコピー

- SOAHOST2の12c Oracleホームからのunpackコマンドの実行

- unpack後の次の確認手順の完了

5.4.1 管理サーバーといずれかの管理対象サーバーがインストールされているサーバーでのpackコマンドの実行

このサンプル・トポロジの場合は、SOAHOST1で次を実行します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12c (12.2.1.1)ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

5.4.2 前の手順で作成したテンプレート・ファイルのSOAHOST2へのコピー

次のコマンドを使用して、domainupgradetemplate.jarファイルをSOAHOST2にコピーします。

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

5.4.3 SOAHOST2の12c Oracleホームからのunpackコマンドの実行

管理サーバーと管理対象サーバーが停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用する完全ドメインまたはドメインのサブセットを作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

サンプルのunpackコマンドのコード・スニペットを次に示します。これは例としてのみ使用します。 unpackには、"-overwrite_domain=true"フラグを指定する必要がある点に注意してください。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.2.1ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

5.4.4 unpack後の次の確認手順の完了

1. 11gドメインからのsetDomainEnv.shスクリプトのWL_HOME、SOA_ORACLE_HOME、UMS_ORACLE_HOMEが、12cを指していることを確認します。
「setDomainEnvへのカスタマイズの再適用」を参照してください。

2. SOAHOST1とSOAHOST2のノード・マネージャ、WebLogic管理サーバーおよび管理対象サーバーを次の順序で起動します。

a. SOAHOST1とSOAHOST2で、ノード・マネージャを起動します。

b. SOAHOST1で、WebLogic管理サーバーを起動します。

c. SOAHOST1とSOAHOST2で、管理対象サーバーを起動します。

詳細は、「サーバーの起動と停止」を参照してください。管理対象サーバーを起動する順序を十分に確認してください。

サーバーを起動できない場合や、その他の技術的問題が発生した場合は、「アップグレードのトラブルシューティング」を参照してください

注意:

アップグレード時に、ノード・マネージャ構成ファイル(nodermanager.propertiesなど)が、11g_DOMAIN_HOME/wlserver_10.3/の場所から、11g_ORACLE_HOME/ domains/DOMAIN_HOME/nodemanagerの場所に移動されます。そのため、12cのノード・マネージャは、11g_DOMAIN_HOMEドメイン・ディレクトリから起動する必要があります。

5.5 クラスタ・アップグレードのアップグレード後タスク

クラスタのアップグレードが正常に完了した後で、追加のアップグレード後構成タスクを実行する必要があります。目的のクラスタ化環境に当てはまるタスクのみを実行してください。

- WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

- SOAおよびOSBクラスタからのOWSMターゲットの削除

- OWSMクロス・コンポーネント・ワイヤリングの更新

- クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

- JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

5.5.1 WLS_OSB管理対象サーバーのOracle HTTP Serverの構成

Oracle Service BusコンソールおよびOracle Service BusサービスにOracle HTTP Serverからルーティングできるようにするため、WebLogicClusterパラメータをこのクラスタにあるノードのリストに設定します。

詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』のOracle Service Bus用のOracle HTTP Serverの構成に関する項を参照してください。

5.5.2 SOAおよびOSBクラスタからのOWSMターゲットの削除

12cドメインの専用クラスタにOracle Web Services Manager (OWSM)が含まれていて、そのドメインをSOAクラスタとOSBクラスタで拡張している場合は、アップグレード後に、SOAクラスタとOSBクラスタからwsm-pmのターゲット設定を手動で解除する必要があります。

SOAクラスタとOSBクラスタからowsm-pmターゲットを削除するには:

1. WebLogic Server管理コンソール12cにログインします。
ブラウザに次のURLを入力します。

http://host name:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. 「ドメイン構造」で「デプロイメント」を選択します。

3. 「デプロイメント」からwsm-pmを選択します。

4. 「wsm-pmの設定」で、「ターゲット」を選択します。

5. タイプが「エンタープライズ・アプリケーション」のwsm-pmコンポーネントを選択して、「ターゲットの変更」を選択します。

6. SOAクラスタとOSBクラスタの選択を解除します。

7. プロンプトが表示されたら、「はい」をクリックして変更内容を適用します。

8. 必須: wsm-pmのターゲットをOWSMクラスタのみに設定した後、「OWSMクロス・コンポーネント・ワイヤリング」の説明に従ってコンポーネントを再接続する必要があります。

5.5.3 OWSMクロス・コンポーネント・ワイヤリングの更新

「SOAおよびOSBクラスタからのOWSMターゲットの削除」で説明しているように、SOAおよびOSBクラスタからOWSMターゲットを削除した後、次に説明するようにOWSMポリシー・マネージャを再接続する必要があります。

1. 管理(admin)サーバーと1つのOWSMサーバーを起動します。

2. Oracle Enterprise Manager Fusion Middleware Control 12cコンソールにログインし、「クロス・コンポーネント・ワイヤリング」→「コンポーネント」オプションに移動します。

3. 使用可能なコンポーネントの一覧からOWSM Policy Managerを選択します。

4. 「サービス・エンド・ポイント」表から、OWSM Policy Manager t3接続エントリを選択し、「公開」をクリックします。ステータスが「同期外れ」から「公開」に変更されます。

5. 「コンポーネント・タイプ」リストからOWSM Agentを選択します。t3接続エントリを選択し、「バインド」をクリックします。

6. サービス・エンドポイントの「サービス・タイプ」がOWSM Policy Managerであることを確認します。

7. ステップ5と6を繰り返して残りのコンポーネント・タイプをバインドします。この例では、com.oracle.essとFusion Middleware Controlを選択します。

5.5.4 クラスタ・アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

SOAクラスタ・ドメインを12.2.1にアップグレードすると、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

EDNTopicの再適用の詳細は、管理コンソールのオンライン・ヘルプを参照してください。

5.5.5 JMSトランスポート・プロキシ・サービス使用時のメッセージの重複防止

12cクラスタ・ドメインのjmsServerは、移行可能なターゲットに向けてターゲット設定されています。これは、jmsServerが個別のサーバーに向けてターゲット設定されていた、11gのデフォルト動作とは異なります。

JMSトランスポートに基づいて12cプロキシ・サービスを構成するときには、トピック分散モードをOne-Copy-Per-ApplicationまたはOne-Copy-Per-Serverに設定します。重複メッセージを防止するために、クラスタ化環境では互換性モードを使用しないでください。

6 Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード

Business Activity Monitoring (Oracle BAM)が含まれているサポート対象のOracle SOA Suite 11g環境から、新たに再設計されたOracle BAM 12cが含まれるSOA 12c (12.2.1.1)環境にアップグレードするプロセスについて説明します。

注意:
BAM 12cリリースを含む以前のOracle SOA Suiteからアップグレードする場合、「以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード」を参照してください

- 12cにおけるBusiness Activity Monitoringのアップグレードの理解
Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

- Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解

- Oracle BAMのアップグレード前タスクの実行

- Oracle BAMドメインを含むSOAの12cへのアップグレード
Oracle BAM 11gを含むSOAドメインをアップグレードする場合、この手順を使用します。

- Oracle BAM 12cを含むOracle SOAでのアップグレード後タスクの実行
最終的にOracle BAM 12cを含むSOA 12cドメインを実行するには、アップグレード後に追加の構成タスクを実行する必要があります。

- Oracle BAM 12cを含むSOAドメインの拡張
アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。

- 失敗したOracle BAMアップグレードからのリカバリ

6.1 12cにおけるBusiness Activity Monitoringのアップグレードの理解

Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

次の各項で説明している手順は、11gからのアップグレードにのみ適用されます。アップグレードされた12cドメインをこの12cリリースにアップグレードする場合、「SOA SuiteおよびBusiness Process Management 12c (12.2.1)のアップグレード」で説明されている標準アップグレード手順に従います。

Oracle Business Activity Monitoring (BAM) 12cは、Oracle SOA Suite 12cと併用するように完全に再設計されているため、ダイレクト・アップグレード・パスはありません。Oracle BAM 12cで使用するスキーマ、バイナリおよびディレクトリ構造は、Oracle BAM 11gで使用するものとは異なります。そのため、Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

BAM 12cドメインで使用できるOracle BAM 11gオブジェクトのみが、データ・オブジェクト(DO)であり、エンタープライズ・メッセージ・ソース(EMS)であることを理解することも重要です。これらのオブジェクトは、手動でXMLファイルにエクスポートしてから、BAM 12cドメインにインポートする必要があります。その他のOracle BAM 11gアーティファクト(ダッシュボードなど)は、Oracle BAM 12cドメインに手動で再作成する必要があります。

Oracle BAM 11gドメインは、アップグレード後も続けて使用することをお薦めします。これにより、必要になるすべてのアーティファクトを作成およびテストする機会が得られます。そのため、Oracle BAMを含むSOAのアップグレード・プロセスを開始する前に、Oracle BAM 11gドメインを別個の場所にインストールしておくことで、ドメインの再構成中にソース・ファイルが改変されないようにすることを強くお薦めします。アップグレード後に、この新しい11gドメインを指すようにSOA 12cを構成します。これは、既存の11g Oracle BAMドメインは変更され、SOA 12cでは機能しなくなるためです。

注意:

Oracle BAMのみのドメイン(SOAのないドメイン)のアップグレードはサポートされていません。BAM専用ドメインがあり、Oracle BAM 12cへのアップグレードが必要になる場合は、新しいOracle BAM 12cドメインを作成し、データ・オブジェクトをインポートしてから、すべてのダッシュボードとアラートを再作成する必要があります。

6.2 Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解

次のフローチャートは、Oracle BAMを含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。

6.3 Oracle BAMのアップグレード前タスクの実行

この項のタスクは、Oracle BAM 11gを含むSOAドメインを12cにアップグレードするときに実行してください。

1. アップグレード前の新しいOracle BAM 11gドメインの作成

2. 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

3. 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート

4. Oracle BAM 11gドメインの完全なバックアップの作成

6.3.1 アップグレード前の新しいOracle BAM 11gドメインの作成

既存のOracle BAM 11gドメインはアップグレード後も継続使用することになるため、アップグレード前にBAM 11gを新しいドメイン・ホームにインストールする必要があります。新しい(別個の) BAM 11gドメインを作成しないと、アップグレード後に機能するBAMドメインがなくなり、アーティファクトや構成の多くが失われてしまいます。

注意:

Oracle BAM 11gに別個のドメインを作成しないと、BAMアーティファクトとBAM関連の構成のみが失われます(SOAアーティファクトには影響しません)。

さらに、BAMアーティファクトを参照するコンポジット(アダプタなど)や新しいインスタンスは、実行時に失敗するようになります。

『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』のバージョン11gのインストール手順を使用してください。

既存の11g BAM環境を保持するには、11g ICommandを使用して、Oracle BAM 11gアーティファクトのすべて(DOとEMSにかぎらず)をエクスポートして、それを新しいOracle BAM 11gドメインにインポートします。これにより、アップグレード後にも完全に機能するOracle BAM 11gドメインを用意できます。

- 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

- 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート

Oracle BAM 11gドメインは、アップグレードの後も継続使用できます。別の方法として、Oracle BAM 12cを含む12c SOAドメインを拡張し、11gドメインからDOとEMSアーティファクトをエクスポートして、それらを拡張したOracle BAM 12cドメインにインポートすることもできます。詳細は、「Oracle BAM 12cを含むSOAドメインの拡張」を参照してください。

6.3.2 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート

新しいOracle BAM 11gドメインを新しい場所にインストールして構成したら、アップグレード前に、11g Oracle BAM ICommandユーティリティを使用して既存の(旧) Oracle BAM 11gドメインからデータをエクスポートし、そのデータを新しいOracle BAM 11gドメインにインポートする必要があります。

11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。

6.3.3 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート

Oracle BAM 11gアーティファクト(DOとEMSにかぎらず)の完全なエクスポートXMLを作成した後で、そのXMLファイルを新しく作成したOracle BAM 11gドメインにインポートする必要があります。これにより、アップグレードとドメイン再構成の後も、完全に機能するOracle BAMドメインを維持できるようになります。

11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のインポートに関する項を参照してください。

6.3.4 Oracle BAM 11gドメインの完全なバックアップの作成

アップグレードが失敗した場合は、バックアップ・バージョンを使用して、アップグレード前の環境全体をリストアする必要があります。アップグレード・プロセスを続行する前に、Oracle BAM 11g環境全体のバックアップ・バージョンを必ず作成してください。バックアップのドメインは、「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成した新しいOracle BAM 11gドメインとは異なります。

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。

6.4 Oracle BAMドメインを含むSOAの12cへのアップグレード

この手順を使用して、Oracle BAM 11gを含むSOAドメインをアップグレードします。

この項では、Oracle BAMが含まれているSOA 11gドメインを、Oracle BAMが含まれるSOA 12c (12.2.1.1)ドメインにアップグレードするプロセスについて説明します。これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。

1. サーバーとプロセスの停止

2. Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のインストール
既存のSOAおよびBusiness Process Management (BPM)のコンポーネントをアップグレードする前に、まず、Oracle Fusion Middleware InfrastructureとOracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)製品ディストリビューションをインストールする必要があります。

3. リポジトリ作成ユーティリティ(RCU)を使用した新規の12cスキーマの作成
これが最初の12cアップグレードである場合、SOAおよびOracle BAM 12c (12.2.1.1)の新しいスキーマを作成することが必要になる場合があります。

4. 11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更

5. Upgrade Assistantの実行によるスキーマのアップグレード

6. 再構成ウィザードを使用した11gドメインの再構成

7. Upgrade Assistantの実行によるコンポーネント構成のアップグレード

6.4.1 サーバーとプロセスの停止

アップグレードを開始する前に、現在実行中のサーバーとプロセスをすべて停止します。

Oracle Fusion Middleware環境を停止する手順は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware環境の停止に関する項に記載されています。

6.4.2 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

既存の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ドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。

1. ターゲットのシステムにログインします。

2. インストール・プログラムがダウンロードされたディレクトリに移動します。

3. ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。

- UNIXオペレーティング・システムの場合: /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

- Windowsオペレーティング・システムの場合: C:\home\Oracle\Java\jdk1.8.0_77\bin\java -jar <component_name>.jarfmw_12.2.1.0.0_PRODUCT.jar

例: cd /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

4. 「インストール画面のナビゲート」の手順に従います。このリンクを使用すると、サポートされているすべてのトポロジに対応するインストール手順が記載されたOracle SOA SuiteおよびBusiness Process Managementのインストレーション・ガイドにアクセスできます。

5. インストールの終わりに、構成ウィザードを起動して12c (12.2.1.1)に新しいドメインを構成するように要求されます

6.4.3 リポジトリ作成ユーティリティ(RCU)を使用した新規12cスキーマの作成

これが最初の12cアップグレードである場合、SOAおよびOracle BAM 12c (12.2.1.1)の新しいスキーマを作成することが必要になる場合があります。

Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.1)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。

注意:
必要なスキーマをまだ作成していないコンポーネントを含むように12cドメインを拡張するのでないかぎり、以前の12cリリースからアップグレードする場合には新しいスキーマを作成する必要はありません。

Oracle BAMが含まれているSOAのアップグレードでは、次に示すスキーマを作成する必要があります(事前に作成していない場合)。

- サービス表(_STB)

- 監査サービス(_IAU)

- WebLogic Services (_WLS): Oracle BAMにはOracle WebLogic Servicesスキーマが必要です(ただし、11gではOracle BAMに専用の個別のスキーマはありません)。

- Managed File Transfer (_MFT) このスキーマはリリース12c (12.1.3)で導入されたもので、MFTがドメインの一部になっている場合にのみ必要です。

- Oracle Platform Security Services (_OPSS) このスキーマは、11gでOracle Internet Directory (OID)ベースのセキュリティ・ストアを使用する場合、必須です。

RCUを使用してスキーマを作成する手順は次のとおりです。

1. JAVA_HOME変数を設定し、JAVA_HOME/binを$PATHに追加します(まだそうしていない場合)。

2. ご使用のシステムの12c_ORACLE_HOME/oracle_common/binディレクトリに移動します。

3. RCUを起動します。
UNIXシステムの場合は、次のように入力します。
./rcu

Windowsシステムの場合は、次のように入力します。
.\rcu.bat

4. RCU画面をナビゲートして、スキーマ作成を完了します。
詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください。

6.4.4 11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更

アップグレード・アシスタントで11gスキーマをアップグレードする前に、次のOracle BAM再構成テンプレートの名前を変更する必要があります。そうしないと、アップグレードは失敗します。

この手順を完了する前に、11g Oracle BAMデータがエクスポート済になっていることを確認してください。よくわからない場合は、既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポートを参照してください。

テンプレートは、12cのディレクトリ$ORACLE_HOME/soa/common/templates/wlsにあります。

テンプレート名

変更後の名前

oracle.bam.reconfig_template_12.2.1.jar

oracle.bam.reconfig_template_12.2.1.jar.old

oracle.bam.reconfig.template_12.2.1.jar.rename

oracle.bam.reconfig_template_12.2.1.jar

6.4.5 アップブレード・アシスタントの実行によるスキーマのアップグレード

アップグレード・アシスタントを使用したスキーマのアップグレードの、標準の手順に従います。詳細は、「アップグレード・アシスタントを使用したSOAスキーマのアップグレード」を参照してください。

Oracle BAM 11gスキーマを使用するSOA SuiteおよびBPMをアップグレードする場合は、「使用可能なコンポーネント」画面(それぞれのスキーマ名がリストされる)で次のオプションを選択します。

- Oracle Platform Security Services (_OPSS)

- Oracle SOA (_SOAINFRA)

- Oracle Managed File Transfer (_MFT)

Oracle Platform Security ServicesとOracle SOAを選択した場合は、次の依存関係も選択します。

- Oracle Audit Services(_IAU)

- Oracle Metadata Services (_MDS)

- ユーザー・メッセージング・サービス(_ORASDPM)
注意: 11g _ORASDPMスキーマは、12cでは名前が_UMSに変更されています。ただし、アップグレード・アシスタントで要求された場合は、11gのスキーマ名、接頭辞_ORASDPMを入力する必要があります。スキーマ名はアップグレード・アシスタントでは変更できないため、アップグレードしたドメインのスキーマは、<接頭辞>_ORASDPMのままになります。

6.4.6 再構成ウィザードを使用した11gドメインの再構成

Oracle BAM再構成テンプレートの名前を変更したら、再構成ウィザードを起動して、「再構成ウィザードを使用したドメインの再構成」の手順に従います。

再構成ウィザードにより、Oracle BAM 11gアプリケーション、ライブラリ、BAMDataSource、BAMJMSSserverおよびBAMJmsSystemResourceがドメインから削除されます。

注意: アップグレード後に、Oracle BAMサーバーとクラスタを手動で削除する必要があります(「ドメインからのOracle BAMサーバーおよびクラスタの削除」を参照)。

6.4.7 Upgrade Assistantの実行によるコンポーネント構成のアップグレード

ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。

詳細は、「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」を参照してください。

6.5 Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

最終的にOracle BAM 12cを含むSOA 12cドメインを実行するには、アップグレード後に追加の構成タスクを実行する必要があります。

アップグレードが正常に完了したら、次のタスクを実行して、最終的にOracle BAM 12cが含まれるSOA 12cドメインを実行します。

注意:

Oracle BAM 11gを含む12c SOA環境を最初に実行することをお薦めします。環境が期待どおりに機能することを確認したら、Oracle BAM 12cを含むドメインを拡張します(「Oracle BAM 12cを含むSOAドメインの拡張」を参照)。

1. 管理(Admin)サーバーの起動

2. WebLogic Server管理12cコンソールの起動

3. Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除
ここに示す手順は、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加の手順が必要になります。

4. Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除
Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。

5. ドメインからのOracle BAMサーバーおよびクラスタの削除
管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。

6. アップグレードされたドメインからファイルの不要なOracle BAM 11gファイルの削除
domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。

7. クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止
クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、packコマンドとunpackコマンドを実行する必要があります。

8. クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行
クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、リモート・ノードで解凍します。

9. クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート
管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します

10. 管理サーバーの再起動
残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。

11. SOA 12cドメインで動作するような11g Oracle BAMアダプタの構成
SOA 12cドメインのアップグレードが完了したら、このSOA 12cドメインを構成して、Oracle BAM 11gドメインを使用するようにします

12. SOA管理対象サーバーの再起動
SOA管理対象サーバーを再起動して、構成後のタスクを完了する必要があります。

13. SOAドメインからドライバの既存のUMS電子メール・ドライバの削除
メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。

6.5.1 管理(Admin)サーバーの起動

Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

6.5.2 WebLogic Server管理12cコンソールの起動

管理コンソールを表示する手順は次のとおりです。

1. ブラウザに次のURLを入力します。

http://hostname:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. インストール時に指定したユーザー名とパスワード、作成した別の管理ユーザーのユーザー名とパスワードを使用してログインします。

あるいは、管理サーバーや管理対象サーバーなどのターゲットのホームページから、Fusion Middleware Controlの管理コンソールにアクセスすることもできます。

6.5.3 Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除

ここに示す手順は、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加の手順が必要になります。

1. Oracle BAMサーバーまたはOracle BAMクラスタに向けてターゲット設定されているJMSサーバー名を特定します。複数のJMSサーバーがある場合は、Oracle BAMサーバーまたはクラスタに向けてターゲット設定されているサーバーをメモしてから、作業を進めることが重要になります。所有するUMS JMSサーバーが1つのみの場合、デフォルト名はUMSJMSServer_auto_1になります。選択したUMS JMSサーバーのターゲットが、Oracle BAMサーバーまたはOracle BAMクラスタであることを必ず確認してください。

「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。Oracle BAMサーバーに向けてターゲット設定されているUMSJMSServerを見つけます。

次の例では、UMSJMSServer_auto_3はOracle BAMサーバーにターゲット設定されたサーバーです。

2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバー(この例では、UMSJMSServer_auto_3)のローカル・キューを削除します。

「JMSモジュールのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「JMSモジュール」を選択します。UMSJMSSystemResourceを見つけてクリックすることで、「UMSJMSSystemResourceの設定」画面にローカル(および分散)キューを表示します。この結果にフィルタを適用すると、UMS JMSサーバーにターゲット設定したキューのみを表示できます。

3. Oracle BAMクラスタのみ: Oracle BAMサーバーまたはクラスタ(この例では、UMSJMSServer_auto_3)のみをターゲットに設定した共通分散キューをすべて選択します。(タイプ「共通分散キュー」でフィルタ処理できます)。「削除」をクリックします。

注意: Oracle BAM以外のサーバー・ターゲットを含む分散キューは、削除しないでください。その他のターゲット対象サーバーがある場合は、まず、分散キューからOracle BAMサーバーを削除(ターゲット設定解除)しておく必要があります(手順4を参照)。

4. 分散キューからOracle BAMサーバーのターゲット設定を解除します(必要な場合)。

分散キューからOracle BAMサーバーのターゲット設定を解除するには、「UMSJMSSystemResourceの設定」画面で「ターゲット」タブをクリックします。Oracle BAMサーバーの横のチェックマークを削除して、「保存」をクリックします。これで、手順3の説明に従って、分散キューを安全に削除できます。

5. UMS JMSサーバーに向けてターゲット設定されているローカル・キューを削除します。

「UMSJMSSystemResourceの設定」画面で、Oracle BAMに向けてターゲット設定されているUMS JMSサーバー(UMSJMSServer_auto_3)にターゲット設定されたローカル・キューをすべて選択します(次を参照)。

6. 「削除」をクリックします。

6.5.4 Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除

Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。

1. UMS JMSサーバーから、サブデプロイメントのリソースを削除します。

「UMSJMSSystemResourceの設定」画面で、「サブデプロイメント」タブをクリックします。

2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバーを選択します(次の例では、UMSJMSServer_auto_3)。

3. 「削除」をクリックします。

6.5.5 ドメインからのOracle BAMサーバーおよびクラスタの削除

管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。

注意:

Fusion Middleware Controlコンソールを介した操作の詳細は、「Oracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイド」を参照してください。

1. 「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。

2. リストから、UMSJMSServer_auto_x を選択します。「現在のターゲット」が、Oracle BAMサーバーであることを確認します。

3. 「削除」をクリックします。

4. 永続ストアのサマリー画面に移動します(次の図を参照)。

5. リストから、UMSJMSFileStore_auto_xを選択します。(「ターゲット」が、Oracle BAMサーバーであることを確認します。)

6. 「削除」をクリックします。

7. 「クラスタのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「クラスタ」を選択します。

8. クラスタのリストで、bam_clusterを選択します。

9. 「削除」をクリックします。

10. 「サーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「サーバー」を選択します。

11. リストから、Oracle BAMサーバーを選択します。

12. 「削除」をクリックします。

6.5.6 アップグレードされたドメインからの不要なOracle BAM 11gファイルの削除

domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。

1. 12c管理サーバーを停止します。

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

2. SOA 12cホームからdomainupdaterスクリプトを実行して、アップグレードしたドメインから不要なレガシー11gファイルを削除します。

(UNIX) cd ORACLE_HOME/soa/bam/bin
./domainupdater.sh
Enter the 11g domain path: (ex:)/soa11g/user_projects/domains/soa_domain

(Windows) cd ORACLE_HOME\soa\bam\bin
domainupdater.cmd
Enter the 11g domain path: (ex:)\soa11g\user_projects\domains\soa_domain

3. 12c管理サーバーを再起動します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

6.5.7 クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止

クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、packコマンドとunpackコマンドを実行する必要があります。

WebLogic Serverを停止するには:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

SOAサーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

6.5.8 クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行

クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、リモート・ノードで解凍します。

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

注意: packおよびunpackコマンド・ユーティリティは、アップグレード済の11gドメインを指す12cインストール・ディレクトリから実行する必要があります。

packコマンドは、管理サーバーといずれかの管理対象サーバーがインストールされているサーバーで実行します。

この例では、SOAHOST1で次を実行します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.2.1ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

6.5.9 クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート

管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します

リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用されるフル・ドメインまたはドメインのサブセットを作成できます。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

サンプルのunpackコマンドのコード・スニペットを次に示します。これは例としてのみ使用します。 unpackには、"-overwrite_domain=true"フラグを指定する必要がある点に注意してください。

packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=11g_DOMAIN_HOME -overwrite_domain=true

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.2.1ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

6.5.10 管理サーバーの再起動

残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。

管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、「Oracle Fusion Middlewareの開始と停止」を参照してください。

6.5.11 SOA 12cドメインで動作する11g Oracle BAMアダプタの構成

SOA 12cドメインのアップグレードが完了したら、このSOA 12cドメインを構成して、Oracle BAM 11gドメインを使用するようにします

「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成したOracle BAM 11gドメインを使用します。

この設定の構成方法の詳細は、11gバージョンの『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle BAMアダプタの構成に関する項を参照してください。

6.5.12 SOA管理対象サーバーの再起動

SOA管理対象サーバーを再起動して、構成後のタスクを完了する必要があります。

SOAサーバーを起動するには:

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

6.5.13 SOAドメインからの既存のUMS電子メール・ドライバの削除

メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。

新しいドライバは、SOA 12cドメインをOracle BAM 12cテンプレートで拡張した後に作成します。

1. 管理サーバーと、すべての管理対象サーバーがSOAドメインで実行しているときに、「ユーザー・メッセージング・サービス」に移動し、soa_serverに向けてターゲット設定されたusermessagingdriver-mailサービスを選択します。

「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで、「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「ターゲット・ナビゲーション」ペインで、「ユーザー・メッセージング・サービス」の電子メール・ドライバ名を選択します。

3. 「削除」をクリックします。

4. ドメイン内にある別のクラスタにも、このプロセスを繰り返します。

6.6 Oracle BAM 12cを含むSOAドメインの拡張

アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。

その場合、次の手順に従います。一部のタスクはオプションです。

1. 管理サーバーおよびSOA管理対象サーバーを停止する

2. Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張

3. Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成

4. Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート

5. BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成

6. 11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)

7. 11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)

8. 12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)

6.6.1 管理サーバーおよびSOA管理対象サーバーを停止する

ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。

WebLogic Serverを停止するには:

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

SOAサーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
soa_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
soa_server_name admin_url

正しい順序でサーバーを停止する方法の詳細は、「サーバーの起動と停止」を参照してください。

6.6.2 Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張

構成ウィザードを使用して、Oracle BAM 12cで既存のSOAドメインを拡張します。

1. 構成ウィザードを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin
./config.sh

(Windows) ORACLE_HOME\oracle_common\common\bin
config.cmd

2. 要求されたら、「既存のドメインの拡張」を選択します。

3. 「テンプレート」画面で、次のテンプレートを選択します。

- Oracle WSMポリシー・マネージャ - 12.2.1.0

- Oracle User Messaging Service - 12.2.1.0

- Oracle BAM Client - 12.2.1.0

- Oracle Enterprise Manager Plugin for BAM - 12.2.1.0

4. 『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のOracle SOA SuiteおよびBusiness Activity Monitoring (BAM)トポロジの構成に関する項の説明に従って、構成ウィザードの残りの画面を完了します。

注意:

SOA、OSB、BAMなど特定のFusion Middlewareコンポーネントは、12cではUMSに依存しています。単一の12.2.1ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります 。「クラスタ化されたSOA環境のアップグレード」の図5-1を参照してください。

構成ウィザードの「拡張構成」画面に進んだら、「管理対象サーバー、クラスタおよびCoherence」を選択して、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項の説明に従い、BAMクラスタを作成します。

6.6.3 Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成

Oracle BAMサーバーがクラスタで実行されているときに、Fusion Middleware Controlコンソールを使用して、次のタスクを完了します。

1. 「電子メール・ドライバ・プロパティ」 画面に移動します。

「ターゲット・ナビゲーション」ペインで「ユーザー・メッセージング・サービス」を選択し、「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「作成」をクリックして、新しいUMS電子メール・ドライバを追加します。

3. 次に示すように、「名前」フィールドで新しい電子メール・ドライバの一意の名前を指定します。UMSは、12cドメイン内の各クラスタに対して構成する必要があります。そのため、イメージに示すように「クラスタ」として「構成レベル」のデフォルト選択を維持します。

4. デフォルトの送信者アドレスの使用を選択して、EMAIL:emailid@company.comと入力します。このフィールドには、EMAIL:という接頭辞が必須になります。

5. 「OK」をクリックして、指定したプロパティで新しいドライバを作成します。

6.6.4 Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート

BAM 12cが含まれるようにドメインを拡張した後で、SOA 12cで使用しているBAM 11g環境から、データ・オブジェクトとEMSデータをエクスポートする必要があります。その後で、BAM 12cを含むSOA環境に、このデータをインポートします。

1. 11g ICommandコマンドライン・ユーティリティを使用して、データ・オブジェクトとEMSデータを11g BAMドメインからエクスポートします。(EMS定義は標準アップグレード・プロセスの一部としてアップグレードされているため、インポートする必要はありません。)

次の例では、Oracle BAMサーバーの1つ以上のオブジェクトに関する情報をXMLファイルにエクスポートする、ICommand 11gの使用方法を示しています。

$11g_ORACLE_HOME/soa/bam/bin/icommand -cmd export -name "/Samples/Call Center" -type dataobject -file C:\CallCenter.xml

注意: スクリプトを実行する前に、ICommand構成ファイルに変更を加えることが必要になる場合があります。具体的には、正しいユーザー名とパスワードが入力されていることを確認してください。BAMICommandConfig.xmlファイルは、WLS_HOME/user_projects/domains/base_domain/config/fmwconfig/servers/bam_server1/applications/oracle-bam_11.1.1/config/にあります。

構成ファイルの例を、次に示します。

<host>www.example.com</host>
<port>7001</port>
<username>weblogic</username>
<password>welcome1</password>
<dbusername>SOAINFRA</dbusername>
<dbpassword>welcome1</dbpassword>
<dburl>jdbc:oracle:thin:@localhost:1521:orcl</dburl>

2. 12cのBAMCommandコマンドライン・ユーティリティを使用して、前述の手順で作成したXMLファイルをインポートします。

次の例は、12cのBAMCommandを使用して情報をインポートする方法を示しています。

$12c_ORACLE_HOME/soa/bam/bin/bamcommand -cmd import -file BPELOrderBookingDataObject.xml -upgrade 1 -username weblogic -port 7001 -host server.yourcompany.com

注意:

importコマンドを-upgradeパラメータとともに使用して、Oracle BAM 11gアーティファクトをOracle BAM 12cに移行すると、一部の情報が変更されます。

6.6.5 BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成

BAM 11gドメインで使用したダッシュボード、アラート、ビューなどは、BAM 12cドメインで再作成する必要があります。

BAMユーザー・ガイド、Oracle BAMによるビジネス・アクティビティの監視の、次に関する項を参照してください。

- ダッシュボードの作成

- アラートの作成

- パラメータの作成

- ビジネス・ビューの作成と使用

6.6.6 11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)

アップグレード済のBPM 12cドメインをBAM 12cで拡張した後には、プロセス・キューブの移行を実行することを強くお薦めします。この移行により、BPMエンティティに必要なすべての12cデータ・オブジェクトが作成されるようになります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。

各アーカイブをエクスポートおよびインポートするときに、SOAINFRAスキーマのユーザー名とパスワードに加えて、サーバー管理者(admin)のユーザー名とパスワードを指定する必要があります。

注意:

プロセス・キューブの移行は、Monitor Expressの移行(「11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行」を参照)を開始する前の必須の前提条件です。

この手順は、BPM 11gでOracle BAM 11g Monitor Expressを使用していなかった場合でも必要になります。

1. タスク1: プロセス・メトリックを無効にします。

2. タスク2: 移行に使用するexportTypeを決定します。

3. タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。

4. タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。

5. タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。

6. タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。

7. タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。

8. タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。

9. タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。

6.6.6.1 タスク1: プロセス・メトリックを無効にします。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle SOA 12cサーバーがインストールされているドメインを選択します。

たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

システムMBeanブラウザ・ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。

analytics属性がリストされます。

10. trueに設定されていない場合は、DisableProcessMetrics属性の値をtrueに変更します。

11. 「適用」をクリックします。

6.6.6.2 タスク2: 移行に使用するexportTypeを決定します。

exportTypeは、移行前に決定しておく必要があります。アクティブ・インスタンスの移行が完了して、プロセス分析が有効化されると、後戻りして完了インスタンス・データを移行できなくなってしまいます。

有効なexportTypeの値は、次のとおりです。

- INFLIGHT_WITH_DIMENSION_AND_DEFINITION (デフォルト): アクティブ・インスタンスのファクト・データ・アーカイブのみを移行します

- ALL: すべてのアクティブ・インスタンスと完了インスタンスのファクト・データ・アーカイブを移行します

6.6.6.3 タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。

migrateBPMProcessCubesシェル・スクリプトは、エクスポートとインポートの2フェーズで移行を実行します。最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートします。2番目のフェーズでは、エクスポートしたアーカイブをBAM 12cにインポートします。

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)

migrateBPMProcessCubesスクリプトを実行する前に、次の環境変数を設定する必要があります。

環境変数

説明

場所の例

JAVA_HOME

サポートされているJava Development Kit (JDK)のインストール先。

/u01/oracle/products/jdk_version

ORACLE_HOME

Oracle Fusion Middleware全製品用にホスト・コンピュータに作成されるOracleホーム。この読取り専用ディレクトリには、バイナリ・ファイルとライブラリ・ファイル、Oracle共通ホーム・ディレクトリ、およびインストールするOracle Fusion Middlewareの各製品ごとの個別の製品ディレクトリが含まれています。
注意: これは、11gではミドルウェア・ホームと呼ばれていました。

/install_location/Oracle_Home。

PROD_DIR

論理製品またはフィーチャー・セットに関連付けられているバイナリ・ファイルが含まれている、Oracleホーム内のディレクトリ。Oracleホーム内の各製品ディレクトリの名前はインストーラによって事前定義され、変更できません。

install_location/Oracle_Home/SOA

UNIXオペレーティング・システムの場合:

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

ここで:

serverUrl      (mandatory) : BAM 12c Server URL
serverPort     (mandatory) : BAM 12c Server Port
serverUserName (mandatory) : BAM 12c Server  admin user
dbUrl          (mandatory) : SOA DB jdbc URL
dbUserName     (mandatory) : SOAINFRA schema username
exportDir      (mandatory) : A writable Directory where exported archives will be written
exportType     (optional ) : Export Type.  Valid values are
a)INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default):  Migrates only Active instance fact data archives
b)ALL                                             :  Migrates all Active and Completed instance fact data archives
importOnly     (optional ) : If specified, data object definition and data archive export phase is skipped and only import is performed. It is assumed that archives are already present under "exportDir"

注意:

移行中にエラーが発生した場合は、手動で問題を修正して、スクリプトを再度開始する必要があります。詳細は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6.6.6.4 タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。

データ・オブジェクト定義の移行は、2つの手順で実行されます。手順1では11gプロセス・キューブからデータをエクスポートし、手順2ではデータを12cにインポートします。

最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートし、2番目のフェーズでは、それらをBAM 12cにエクスポートします。後述するエクスポート・コマンドにより、次のアーカイブ・ファイルが<exportDir>ディレクトリに生成されます。

- DefinitionExport.zip

- DimensionExport.zip

- ActiveFactDataExport.zip

- CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)

1. データ・オブジェクトと定義を、次のコード例を使用してエクスポートします(必ず実際のディレクトリ名を指定してください)。

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

2. データ・オブジェクト定義(DefinitionExport.zip)をBAMサーバーにインポートします。

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DefinitionExport.zip> -mode update

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6.6.6.5 タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。

このコマンドは、-datamodeおよび-migrateパラメータを使用します。

次のコード例を使用して、ディメンション・データをインポートします。

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  DimensionExport.zip>  -datamode update -migrate 1

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6.6.6.6 タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。

このコマンドは、-datamodeおよび-migrateパラメータを使用します。

cd %ORACLE_HOME%\bam\bin\

bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

6.6.6.7 タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。

このコマンドは、-datamodeおよび-migrateパラメータを使用します。

このコマンドは、BAM 11gプロセス・キューブのデータ・オブジェクト定義を移行したときに、exportTypeにALLを使用した場合にのみ使用します。

cd %ORACLE_HOME%\bam\bin\

run the following command
bamcommand.cmd  -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url>
-dbusername <bam database db user>  -cmd import -file <Path to  ActiveFactDataExport.zip>  -datamode update -migrate 1

注意: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6.6.6.8 タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
bam_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
bam_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

6.6.6.9 タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。

たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

システムMBeanブラウザ・ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。

analytics属性がリストされます。

10. DisableProcessMetrics属性の値をfalseに変更します。

11. 「適用」をクリックします。

6.6.7 11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)

前提条件: 「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」の手順を実行します。

このオプションのタスクは、BAM 11gの履歴データをBAM 12cのプロセス分析ダッシュボードから分析できるようにする場合にのみ実行します。これを行うには、BAM 11gのMonitor Expressデータ・オブジェクトの11gプロセス分析データを、BAM 12cのプロセス・スター・スキーマのデータ・オブジェクトに移行する必要があります。

11g Monitor ExpressのデータをBAM 12cのプロセス・スター・スキーマにアップグレードする前に、11gプロセス・キューブをBAM 12cスター・スキーマに移行して、BPMのエンティティに必要なすべての12cデータ・オブジェクトが作成されるようにする必要があります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。

注意:

アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。

BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。

sql> @rollbackMonitorExpressMigration.sql

その他のエラー処理手順の詳細は、「処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

1. プロセス・メトリックを無効にします。

2. Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。

3. BPMデータをOracle BAM 12cにインポートします。

4. BAM 12cへのパブリッシュを有効化します。

6.6.7.1 プロセス・メトリックを無効にします。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。

たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

システムMBeanブラウザ・ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。

analytics属性がリストされます。

10. DisableProcessMetrics属性の値をtrueに変更します。

11. 「適用」をクリックします。

6.6.7.2 Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。

データ・オブジェクトとデータ・オブジェクト定義は、「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で移行済です。

次のコマンドにより、BPMデータのデータ・エクスポートがzip圧縮されたCSVファイルで作成されます。

java -cp
$DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.interface.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc6.jar:
$ORACLE_HOME/bam/modules/oracle.bam.client/bam-client.jar:
$ORACLE_HOME/bam/lib/bam-schema.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.hwfanalytics.dataobject.jar:
$ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.model.jar    oracle.bpm.metrics.dataobject.migration.application.Migrate11gBAMBPMTo12cDO  PropertyFiles

このコマンドにより、<PATH>ディレクトリに、FactDataExport.zipファイルが作成されます。

注意: プロパティ・ファイルで、コンポジット名を指定できます。コンポジット名を指定すると、該当するコンポジットのみのデータが移行されるようになります。プロパティ・ファイルでコンポジット名を定義していないと、すべてのコンポジット・データが移行されます。

#*************************************
#Mandatory Fields
#*************************************
#11g User Name
BAM_11g_USER_NAME= <<11gUserName>>
#12c User Name
BAM_12c_SOURCE_NAME = <<12cUserName>>

#11g URL
BAM_11g_URL=jdbc:oracle:thin:@<<11gBAMSchemaDatabaseIP>>:<<Port>>:<<SID>>
#12c URL
BAM_12c_URL=jdbc:oracle:thin:@<<12cDatabaseIP>>:<<Port>>:<<SID>>

#Path where data to be exported
PATH = <<Path where data need to be exported>>
#*************************************
#Optional Fields
#************************************

COMPOSITE_LIST = <<List of Composite for which data needs to be exported. This is ':' separated>>
#If above mention configurable is missing then all the composite data will be migrated.
DATAOBJECT_FOLDER_PATH = <<DataObject Path If this field is absent then default path will taken as Samples/Monitor Express/BI_>>
#************************************

6.6.7.3 BPMデータをOracle BAM 12cにインポートします。

この手順により、事前にエクスポートしたBPM Monitor Expressデータが、確実にBAM 12cにインポートされます。

cd $DOMAIN_HOME/bam/bin

./bamcommand -host <<host>> -protocol t3 -dbusername <<DbUserName>>  -dburl jdbc:oracle:thin:@<<DBIP>>:<<Port>><<SID>> -username  <<weblogicUserName>> -cmd import  -file <<Path of BPM FactDataExport zip file >> -mode update -migrate 1

6.6.7.4 BAM 12cへのパブリッシュを有効化します。

移行が完了したら、BAM 12cへのパブリッシュを有効にするために、DisableProcessMetricsパラメータをfalseに設定します。

1. Fusion Middleware Controlコンソールにログインします。

2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。

3. Oracle BAMサーバーがインストールされているドメインを選択します。

たとえば、ドメインはsoainfraまたはbase_domainです。

4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

システムMBeanブラウザ・ページが表示されます。

5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。

6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。

7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。

8. Server: server_nameの下のAnalyticsConfigノードを開きます。

9. AnalyticsConfigの下で、analyticsをクリックします。

analytics属性がリストされます。

10. DisableProcessMetrics属性の値をfalseに変更します。

11. 「適用」をクリックします。

注意:

アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。

BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。

sql> @rollbackMonitorExpressMigration.sql

その他のエラー処理手順の詳細は、「処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

6.6.8 12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)

11gのプロセス・スター・スキーマ・ビューを基にして構築されたOracle Fusion Middleware 11gアプリケーションがあるときに、そのアプリケーションを12cでも継続して使用する場合は、そのビューをアップグレード後に再作成する必要があります。12cのスター・スキーマ・データベース・ビューは、11gのビューとは異なっていて、自動的にアップグレードできません。

つまり、12cのスター・スキーマ・データベース・ビューには異なる名前が付けられていて、Oracle BAMデータ・オブジェクトを基にしており(プロセス・キューブ表を基にしていない)、コンポジット・レベルで作成されている(11gのようにプロセス・レベルではない)ということです。Oracle 12c環境で使用するビュー(標準およびプロセス固有の両方)の再作成を支援するために、自動化されたユーティリティが用意されています。

1. タスク1: クラスパスを更新してインタフェースJARファイルを含める

2. タスク2 標準のビューを再作成する

3. タスク3 プロセス固有のビューを再作成する

6.6.8.1 タスク1: クラスパスを更新してインタフェースJARファイルを含める

CLASSPATHを更新して、SOAホームにあるoracle.bpm.analytics.interface.jarファイルの場所が含まれるようにする必要があります。

次に例を示します。

DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar

6.6.8.2 タスク2: 標準のビューを再作成する

標準ビュー11g移行ユーティリティを使用して、次に示す11g標準ビューの12c互換バージョンを作成します。

- BPM_ACTIVITY_DEFINITION_V

- BPM_ACTIVITY_INSTANCE_V

- BPM_ACTIVITY_PERFORMANCE_V

- BPM_PROCESS_DEFINITION_V

- BPM_PROCESS_INSTANCE_V

- BPM_PROCESS_PERFORMANCE_V

- BPM_ROLE_DEFINITION_V

次のコマンドを使用して、ユーティリティを実行します。

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.util.StandardView11gMigrationUtil <initialContextFactory> <protocol> <hostname> <soa-port> <username>[]

説明:

- initialContextFactoryはJNDI初期コンテキスト・ファクトリです(weblogic.jndi.WLInitialContextFactoryなど)。

- protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。

- hostnameは、ホストのフル・ネームです(soa.mycompany.comなど)。

- soa-portは、SOAのリスニング・ポートです(7001など)。

- usernameは、サーバーのログイン名です(weblogicなど)。

6.6.8.3 タスク3: プロセス固有のビューを再作成する

プロセス固有ビュー11g移行ユーティリティを使用して、次に示す11gプロセス固有ビューの12c互換バージョンを作成します。

- BPM_ACTV_INST_<viewIdentifier>_V

- BPM_ACTV_PERF_<viewIdentifier>_V

- BPM_PRCS_INST_<viewIdentifier>_V

- BPM_PRCS_PERF_viewIdentifier>_V

次のコマンドを使用して、ユーティリティを実行します。

java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.utill.ProcessSpecificView11gMigrationUtil <initialContextFactory> <protocol> <hostname> <soa-port> <username > [<composite-name>]

説明:

- initialContextFactoryはJNDI初期コンテキスト・ファクトリです(weblogic.jndi.WLInitialContextFactoryなど)。

- protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。

- hostnameは、ホストのフル・ネームです(soa.mycompany.comなど)。

- soa-portは、SOAのリスニング・ポートです(7001など)。

- usernameは、サーバーのログイン名です(weblogicなど)。

- composite-name(オプション)は、ビューを作成する単一のコンポジットの名前です。

6.7 失敗したOracle BAMアップグレードからのリカバリ

この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。

- CFGFWK-60950エラーの解決

- エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

- UNIXオペレーティング・システムのエラー処理

- Windowsオペレーティング・システムのエラー処理

6.7.1 CFGFWK-60950エラーの解決

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

6.7.2 エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。

すべてのデータ変更内容のロールバック:

1. SOAデータベースでSQLセッションを開きます。

2. SOAINFRAスキーマ・ユーザーとしてログインし、次のスクリプトを実行して、すべてのデータ変更内容をロールバックします。

"<exportDir>/rollBackBPMProcessCubesMigration.sql"

使用しているオペレーティング・システムの推奨事項を確認してください。

- UNIXオペレーティング・システムのエラー処理

- Windowsオペレーティング・システムのエラー処理

6.7.3 UNIXオペレーティング・システムのエラー処理

移行時に予期しないエラーが発生した場合は、問題を修正するために次の手順を実行してみてください。

インポート・フェーズで発生したエラーの場合:

BAM 12cにアーカイブをインポートしているときにエラーが発生した場合は、「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明するように、スクリプトmigrateBPMProcessCubes.shを再実行します。ただし、-importOnlyオプションを追加してください。エクスポートの手順を省略することで、時間を節約できます。

次に例を示します。

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]

エクスポート・フェーズで発生したエラーの場合:

BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。

2. <exportDir>の内容を削除します。

3. シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-importOnlyオプションは削除してください。

次に例を示します。

cd $ORACLE_HOME/bam/bin
./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL]

追加情報:

問題の解決を支援するために、次の作業も実行してみてください。

- BAM 12cに各アーカイブをインポートした後で、$ORACLE_HOME/bam/binディレクトリにあるbamcommond.log.*ファイルを調べて、エラーが発生していないことを確認します。

- <exportDir>/MigrationLogs.*にある移行のログを調べます。

6.7.4 Windowsオペレーティング・システムのエラー処理

前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。

インポート・フェーズで発生したエラーの場合:

次の各項で説明しているとおりに、アーカイブを再インポートします。

- タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。

- タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。

- タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。

エクスポート・フェーズで発生したエラーの場合:

BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。

2. <exportDir>の内容を削除します。

3. シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-importOnlyオプションは削除してください。

次に例を示します。

java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\bam\lib\bam-schema.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.dataobject.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.hwfanalytics.dataobject.jar

oracle.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]

4. 「11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)」の残りの移行手順を繰り返します。

7 Oracle Service Busのアップグレード

Oracle SOA SuiteおよびBusiness Process Managementを含まないOracle Service Busをアップグレードする際の、アップグレード固有のタスクについて説明します。

Oracle Service Bus 11gをリリース12cにアップグレードするときには、この章で説明するアップグレード前タスクとアップグレード後タスクを実行する必要があります。これを実行しないと、アップグレード後環境が機能しなくなる可能性があります。

- Oracle Service Busの12cへのアップグレードの理解
SOA Suiteを含まないOracle Service Busデプロイメントをアップグレードする場合は、このプロセス・フローに従います。

- 単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)
Oracle Service Bus 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.2.1.1)にアップグレードできません。

- Oracle Service Bus (OSB)のアップグレード前タスクの実行

- WebLogic ServerおよびJRF Infrastructureのインストール
アップグレードする前に、まず12c (12.2.1.1) Infrastructureディストリビューションを使用してOracle WebLogic ServerおよびJRFをインストールする必要があります。

- Oracle Service Busのインストール

- Oracle Service Busのスキーマの作成
Oracle Service Bus 12cには、 <prefix>_SOAINFRA、<prefix>_UMSおよび<prefix>_STBスキーマが必要です。Upgrade Assistantを起動する前に、これらのスキーマを作成する必要があります。

- OSBドメインのアップグレード(SOAを含まない場合)

- OSBドメインの再構成

- WebLogicコンポーネント構成のアップグレード

- Oracle Service Busのアップグレード後タスクの実行

- Oracle Service Busアップグレードのトラブルシューティング

7.1 Oracle Service Busの12cへのアップグレードの理解

SOA Suiteを含まないOracle Service Busデプロイメントをアップグレードする場合は、このプロセス・フローに従います。

Oracle Service Bus (OSB)は、Oracle SOA SuiteおよびBusiness Process Managementの有無にかかわらず12c (12.2.1.1)にアップグレードできます。この章のアップグレード手順では、SOAを含まないOracle Service Busのアップグレード方法について説明します。

OSBがSOA 11gまたは以前の12cドメインに含まれており、SOA Suiteの12c (12.2.1.1)へのアップグレードの一部としてOSBをアップグレードする場合は、「SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)のアップグレード」で説明している標準アップグレード・プロセスに従います。

SOAを含まないOracle Service Busをアップグレードする場合は、この章で説明するアップグレード手順を使用してください。ドメインにSOAが含まれていない場合でも、OSBデータをアップグレードするには、_SOAINFRAスキーマをアップグレードする必要があります。OSBには、個別のスキーマがありません。

注意:

必ず、Oracle Service Busに固有のアップグレード前手順およびアップグレード後手順すべてを確認してください。12c (12.2.1.1)へのアップグレード時には、すべてのService Busアップグレード(SOAの有無にかかわらず)でこれらの追加手順が必要になります。

手順

説明

詳細

OSBドメインをホストするWebLogicサーバーとJRFをアップグレードします。

12cインフラストラクチャをインストールして、インフラストラクチャ・ドメインをアップグレードしてから、Oracle Service Busをアップグレードする必要があります。

WebLogic ServerおよびJRF Infrastructureのインストール

Oracle Service Busをインストールします。

Oracle Service Busディストリビューションを入手して、その内容を新しいOracleホームにインストールします。

Oracle Service Busのインストール

Oracle Service Busをアップグレードします。

既存のOracle Service Busドメインをアップグレードします。

OSBドメインのアップグレード(SOAを含まない場合)

アップグレード後タスクをすべて実行します。

標準の12cアップグレード後タスクと、各自のデプロイメントに該当するOSB固有のアップグレード後タスクをすべて実行します。

アップグレード後タスクの実行

Oracle Service Busのアップグレード後タスクの実行

Oracle Service Busのトラブルシューティング

7.2 単一OSBドメイン内でUMSを使用する複数コンポーネントのアップグレード(未サポート)

Oracle Service Bus 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.2.1.1)にアップグレードできません

特定のFusion Middlewareコンポーネント(Oracle SOA、Oracle Service Bus (OSB)、Business Activity Monitoring (BAM)など)は、12cでは、ユーザー・メッセージング・サービス(UMS)に対する依存関係があります。単一の12c (12.2.1.1)ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。

このようなコンポーネントをアップグレードするには、ドメインの再構成時に、各コンポーネントに個別のクラスタを作成する必要があります(クラスタに関する項を参照)。

このようなコンポーネントに対してサポートされるアップグレード・トポロジについては、「クラスタ化トポロジのアップグレード」を参照してください。

7.3 Oracle Service Bus (OSB)のアップグレード前タスクの実行

Oracle Service Busをアップグレードする場合は、アップグレードを開始する前に、次の各タスクを実行する必要があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

1. 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

2. Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

3. すべてのサービス、プロジェクトおよびリソースの削除

4. 以前のリリースからのOracle Service Busリソースの移行

7.3.1 11g環境へのOracle Web Services Managerポリシー・マネージャのデプロイ

Oracle Web Services Manager (OWSM)ポリシー・マネージャがOracle Service Bus 11g環境にデプロイされていない場合は、12cにアップグレードする前に、それを手動でデプロイする必要があります。

11gでは、WebLogicのセキュリティ・ポリシーとOWSMのポリシーは、どちらもOracle Service Busでサポートされていました。11g (11.1.1.7)の時点で、WebLogicセキュリティ・ポリシーは非推奨になり、12c (12.1.3)ではサポートされなくなりました。11gではWebLogicセキュリティ・ポリシーが使用可能であったため、OWSMマネージャのデプロイメントとOWSMポリシーの使用はオプションでした。12cではOWSMポリシーのみがサポートされているため、OWSMポリシー・マネージャのデプロイメントが必須になります。

OWSMポリシー・マネージャを手動で11g環境にデプロイする方法の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebLogic ServerでのOWSMのインストールに関する項を参照してください。

7.3.2 Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート

Oracle Service Bus 12.2.1にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。

リソースとサービスは、サポート対象の旧リリースから手動でエクスポートできます。「以前のリリースからのOracle Service Busリソースの移行」を参照してください。

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

7.3.3 すべてのサービス、プロジェクトおよびリソースの削除

エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。

Oracle Service Bus Consoleの使用方法の詳細は、プロジェクト、フォルダおよびリソースの削除方法に関する項を参照してください。

JDeveloperを使用したリソースの削除の詳細は、「プロジェクトまたはリソースの削除方法」を参照してください。

7.3.4 以前のリリースからのOracle Service Busリソースの移行

リソースとサービスは、次の各リリースから手動でエクスポートして、Oracle Service Bus 12c (12.2.1.1)で使用できます。

- Oracle Service Bus 12cリリース12.1.3および12.2.1.0

- Oracle Service Bus 11gリリース: 11.1.1.7.0

- Oracle Service Bus 10.3リリース: 10.3.1および10.3.0

- AquaLogic® Service Busリリース3.0以降

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

7.4 WebLogic ServerおよびJRF Infrastructureのインストール

アップグレードする前に、まず12c (12.2.1.1) Infrastructureディストリビューションを使用してOracle WebLogic ServerおよびJRFをインストールしておく必要があります。

SOA Suiteでは、12c (12.2.1.1) Infrastructureディストリビューションを使用してOracle WebLogic ServerおよびJRFをインストールする必要があります。

詳細な手順は、『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。

注意:

Infrastructureディストリビューションをインストールするときには、ドメインの構成に構成ウィザードを使用しないでください。11gドメインは、新しい再構成ウィザードを使用して、アップグレード・プロセスで構成します。

注意:

Infrastructureディストリビューションのインストールを完了してから、SOA 12c (12.2.1.1)にアップグレードする必要があります。Oracle Fusion Middleware 12c (12.2.1.1)でサポートしているアプリケーション・サーバーは、Oracle WebLogic Serverのみです。

以前の12cリリースを使用してInfrastructureコンポーネントをインストールおよび構成した場合は、まず、Infrastructure 12c (12.2.1.1)にアップグレードする必要があります。

詳細は、以前のInfrastructure 12cリリースからのアップグレードに関する項を参照してください。

7.5 Oracle Service Busのインストール

Oracle Service Busをインスト－するには、『Oracle Service Busのインストールと構成』を参照してください。

Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 12c (12.2.1)をインストールする必要があります。詳細はOracle Fusion Middleware Infrastructureのインストールと構成を参照してください。

注意:

Oracle Service BusでOracle Web Services Managerポリシーを使用する場合、Oracle WebLogicドメインの構成時にいずれかのOracle Service Busドメインを選択した後、Oracle Web Services Manager拡張テンプレートを選択する必要があります。

7.6 Oracle Service Busのスキーマの作成

Oracle Service Bus 12cには、 <prefix>_SOAINFRA、<prefix>_UMSおよび<prefix>_STBスキーマが必要です。Upgrade Assistantを起動する前に、これらのスキーマを作成する必要があります。

Oracle Service Busのすべてのデータベース・スキーマのデータはSOAINFRAスキーマに組み込まれているので、Oracle Service Busには独自のスキーマがありません。したがって、Oracle SOAを実行せずにOracle Service Busを実行できますが、アップグレードを開始する前に、_SOAINFRA、_UMSおよび_STBスキーマを作成する必要があります。

注意:
Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.1)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。

新しい12c Oracleホーム・ディレクトリからRCUを実行します。

1. JAVA_HOME変数を設定し、JAVA_HOME/binを$PATHに追加します(まだそうしていない場合)。

2. ご使用のシステムの12c_ORACLE_HOME/oracle_common/binディレクトリに移動します。

3. RCUを起動します。
UNIXシステムの場合は、次のように入力します。
./rcu

Windowsシステムの場合は、次のように入力します。
.\rcu.bat

4. RCU画面をナビゲートして、スキーマ作成を完了します。詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください

- 11gからアップグレードする前の必須SOAスキーマの作成
サポートされている11gリリースからアップグレードする場合、アップグレードする前に、サポートされているデータベースで新しい12c必須スキーマを作成することが必要になる場合があります。

7.6.1 11gからアップグレードする前の必須SOAスキーマの作成

サポートされている11gリリースからアップグレードする場合、アップグレードする前に、サポートされているデータベースで新しい12c必須スキーマを作成することが必要になる場合があります。

注意:

OIDベースのセキュリティ・ストア・ユーザーのみ: 11gでOIDベースのセキュリティ・ストアを使用している場合、リポジトリ作成ユーティリティ(RCU)を使用して、新しい12cスキーマ_STBおよび_OPSSスキーマを作成する必要があります。

アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。Upgrade Assistantでスキーマをアップグレードする場合、新しいOPSSスキーマを選択します(Upgrade AssistantによってOIDベースのセキュリティ・ストアが自動的にアップグレードされます)。

12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

表7-1 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)

RCUを使用してスキーマを作成する手順は次のとおりです。

1. JAVA_HOME環境変数を設定し、$JAVA_HOME/binを$PATHに追加します(まだそうしていない場合)。現在サポートされているJDKバージョンは、jdk1.8.0_77です

2. ご使用のシステムの12c ORACLE_HOME/oracle_common/binディレクトリに移動します。

3. RCUを起動します。
UNIXオペレーティング・システムでは、次のようにします。
./rcu

Windowsオペレーティング・システムの場合:
rcu.bat

4. RCU画面をナビゲートして、スキーマ作成を完了します。アップグレード用に新しいスキーマを作成する際は、「既存の接頭辞の選択」を選択して、既存のスキーマの作成に使用した接頭辞を見つけます。
注意: デフォルトで、Common Infrastructure Services (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

。

詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください

7.7 OSBドメインのアップグレード(SOAを含まない場合)

Oracle Service Busアップグレードするには、表7-2で説明する基本手順に従います。

表7-2 Upgrade Assistant画面: スキーマのアップグレード

画面

説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「個別に選択されたスキーマ」を選択します。

注意: OSBスキーマはありません。Oracle Service Busのすべてのデータベース・スキーマのデータは、SOAINFRAスキーマに組み込まれています。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

OSBのアップグレード時には、Metadata Services、Audit ServicesおよびOracle Platform Security Servicesを選択します。

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてアップグレードする11gドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

注意: この画面のプログレス・バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

7.8 OSBドメインの再構成

スキーマのアップグレード後に、Oracle再構成ウィザードを使用して、11g OSBドメインを再構成する必要があります。このプロセスは、「再構成ウィザードを使用したドメインの再構成」で説明しているSOAドメインの再構成手順と同じです。

7.9 WebLogicコンポーネント構成のアップグレード

ドメインの再構成後に、アップグレード・アシスタントをもう一度実行して、11g OSBドメインのコンポーネント構成をアップグレードします。

このプロセスについては、「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」で説明しています。

7.10 Oracle Service Busのアップグレード後タスクの実行

アップグレードが正常に完了したら、次のタスクを1つ以上実行する必要がある場合があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

注意:

Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busのトラブルシューティング」で、一般的な解決策の一覧を参照してください。

- ドメイン構成データのインポート

- セキュリティ構成のインポート

- XQueryリソースのアップグレード

- 12cの分割-結合の理解

7.10.1 ドメイン構成データのインポート

アップグレード後に、「Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート」でエクスポートしたドメイン構成データをインポートする必要があります。

詳細は、「コンソールで構成JARファイルからリソースをインポートする方法」および構成ファイルの実行に関する項を参照してください。

7.10.2 セキュリティ構成のインポート

Oracle WebLogic Server管理コンソールを使用して、アップグレード前にエクスポートしたセキュリティ・データを新しいOracle Service Busドメインにインポートします。

詳細は、Oracle WebLogic Server管理コンソールのオンライン・ヘルプでセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。

注意:

セキュリティ情報は、セキュリティ・プロバイダごとに個別にインポートする必要があります。

7.10.3 XQueryリソースのアップグレード

Oracle Service Busでは、XQuery 1.0をサポートしています。旧XQuery 2004もサポートされます。Service Busで作成された新しいXQueryリソースは、デフォルトでXQuery 1.0を使用します。

12cより前のService Busプロジェクトからアップグレードすると、そのプロジェクト内のすべてのXQueryリソースが、XQuery 2004バージョンを使用するように構成されます。

XQuery Resourcesのアップグレードの詳細は、「XQuery 1.0を使用したXQueryリソースのアップグレード方法」を参照してください。

7.10.4 12cの分割-結合の理解

12cには、パイプライン・サービスまたはプロキシ・サービスから直接分割-結合コンポーネントを呼び出す方法があるため、11gの分割-結合ビジネス・サービスがなくなりました。アップグレード・プロセスでは、次のようにして、静的に構成されたすべての呼び出しの参照を自動的に分割-結合ビジネス・サービスに変更します。

- フロー・ビジネス・サービスは削除されます。つまり、フロー・ビジネス・サービス用に構成されたTimeoutプロパティも削除されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが同じプロジェクトに配置されている場合は、そのプロキシ・サービスに関連付けられたパイプラインにより分割-結合が直接呼び出されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが異なるプロジェクトに配置されている場合は、分割-結合を呼び出すためのローカル プロキシ・サービスが作成されます。このローカル・プロキシ・サービスは、元のプロキシ・サービスから呼び出されます。

7.11 Oracle Service Busアップグレードのトラブルシューティング

Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。

- クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラーの解決

- OSBコンソールへのアクセス時のHTTP 404エラーの解決

7.11.1 クラスタのフロントエンド・ホストとしてOHSを使用するOSBのアップグレード後のHTTP 404エラーの解決

クラスタ・ドメインのフロントエンド・ホストとしてOracle HTTP Server (OHS)を構成する場合は、OHS構成ファイル(ohs.confg)に次のコードを追加する必要があります。

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster [ADMIN_SERVER_HOST]:[ADMIN.SERVER:PORT]
</Location>

ADMIN.SERVER:PORTは、OHSに使用するマシン名、サーバー名およびポート番号です。

次のサンプル・コード内のmymachine.us.mycompany.com:7001がその例です。

<Location /sbconsole>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>
<Location /servicebus>
SetHandler weblogic-handler
WebLogicCluster mymachine.us.mycompany.com:7001
</Location>

7.11.2 OSBコンソールへのアクセス時のHTTP 404エラーの解決

12cより前のOSBコンソールには、URL: http://[HOST]:[PORT]/sbconsoleを使用してアクセスしていました。

12cでは、OSBコンソールのURLがhttp://[HOST]:[PORT]/servicebusに変更されています。

アップグレード後に、http://[HOST]:[PORT]/sbconsoleと入力すると、http://[HOST]:[PORT]/servicebusにリダイレクトされます。

リダイレクトに失敗して、HTTP 404エラーが返された場合は、12cのURL http://[HOST]:[PORT]/servicebusを直接入力してみてください。

8 アップグレード後タスクの実行

Oracle SOA Suite 12cへのアップグレード後に実行する必要のある可能性があるタスクについて概要を説明します。

注意:

次のものについては、コンポーネント固有の追加のアップグレード後タスクがあります。

Business Activity Monitoring (BAM)については、「Oracle Business Activity Monitoring 11gを含むOracle SOA Suiteから12cへのアップグレード」を参照してください

Oracle Service Bus (OSB)については、「Oracle Service Busのアップグレード後タスクの実行」を参照してください

ユーザー・メッセージング・サービス(UMS)については、「ユーザー・メッセージング・サービスのアップグレード」を参照してください。

- アップグレード後タスクの実行

- アップグレードしたコンポーネントが期待どおりに動作していることの確認

8.1 アップグレード後タスクの実行

次の各タスクは、アップグレード後に実行する必要があります。

- JVMの開始スクリプトのプロパティの再適用

- setDomainEnvへのカスタマイズの再適用

- XEngine構成ファイルへのカスタマイズの再適用

- カスタムのXPathクラスのコピー

- アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

- サーバーの起動と停止

- Business Process Management (BPM)メタデータのアップグレード

- Oracle Fusion Middleware 12c監査データ・ストアの構成

- リモート・クライアントによるServerSocketのアップグレード

- SOA 12cのスレッドの再構成

8.1.1 JVMの開始スクリプトのプロパティの再適用

11g環境で必須の起動プロパティを指定するため、または起動時に必要になるその他の操作を実行するために開始スクリプトを使用していた場合は、アップグレード後にプロパティを再適用する必要があります。

つまり、11g環境でJRockit JVMの引数を構成している場合は、アップグレード後にこれらの構成の再適用が必要になります。JVMの起動パラメータを構成する場合は、startup-plan.xmlまたはstartscript.xmlを使用することをお薦めします。

注意:

開始スクリプトの引数を更新していないと、アップグレード後にSOAサーバーとOSBサーバーが起動できなくなることがあります。

スクリプトを有効にするには:

1. nodemanager.propertiesファイルで、StartScriptEnabledプロパティをtrueに設定します。(デフォルトはfalseです。)起動スクリプトの名前がstartWebLogic.shまたはstartWebLogic.cmdの場合は、ノード・マネージャはそれらのスクリプトのいずれかをデフォルトとして使用します。

2. カスタム起動スクリプトを指定する場合は、nodemanager.propertiesファイルで、StartScriptNameプロパティを、使用するスクリプトの名前に設定します。

ノード・マネージャは、JAVA_VENDOR、JAVA_HOME、JAVA_OPTIONS、SECURITY_POLICY、CLASSPATH、およびADMIN_URLを設定します。管理コンソールを使用してサーバーを起動するか、または管理サーバーに接続されたWLSTを使用するとき、ノード・マネージャはこれらの値をServerMBean、ServerStartMBean、およびSSLMBeanから取得します。ノード・マネージャに直接接続されたWLSTを使用する場合は、値を指定できますが、使用しない場合は空白にします。

ノード・マネージャは、ServerStartMBean Arguments属性で指定されるすべてのコマンド行起動オプション(-Dフラグ)とSSLArgumentsを組み合わせ、JAVA_OPTIONSという1つの環境変数にします。SSLArgumentsは、SSLMBeanの値から取得されます。SSLMBeanは、ignoreHostnameVerification、HostnameVerifier、およびReverseDNSAllowedの各値があるか検査し、それらの値は-Dフラグに付加されます。すべてのフラグは、SSLArgumentsパラメータから構成されます。ServerStartMBean内のSSLArgumentsおよびArgumentsのすべての値は、起動スクリプトに定義されるJAVA_OPTIONS環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

8.1.2 setDomainEnvへのカスタマイズの再適用

SOA SuiteおよびBPM環境の12.2.1へのアップグレードを完了するには、開始スクリプト(setDomainEnvなど)のカスタマイズの再適用が必要になることがあります。

サーバーが起動しない場合やAdminModeで起動する場合、最も可能性の高い原因は、setDomainEnv.shの11gからの変更内容が12cドメインに再適用されていないことです。11gと12cのsetDomainEnvを比較して、カスタムの変更をアップグレード後に追加してください。

詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。

注意:

今後のアップグレードでカスタマイズの内容が失われないようにするには、『Oracle Fusion Middlewareのアップグレードのプランニング』の、「カスタムのsetDomainEnv設定の保持」を参照してください。

8.1.3 XEngine構成ファイルへのカスタマイズの再適用

アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。

たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。

8.1.4 カスタムのXPathクラスのコピー

アップグレード後には、次の例で示すように、カスタマイズしたXPathクラスを新しい12c Oracleホームの/classesディレクトリにコピーする必要があります。

カスタムのXPathクラスのコピー元:

<11g Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes

コピー先:

<12c Oracle Home>/soa/modules/oracle.soa.ext_11.1.1/classes folder

8.1.5 アプリケーションのロールとポリシーに対するパーティション固有のロールの再作成

アップグレード後には、11g環境で使用していたパーティション固有のロールを再作成する必要があります。

既存のアプリケーションに対するパーティションのアプリケーション・ロールは、12cのアップグレード・プロセスでは再作成されません。そのかわりに、次のWLSTスクリプトを使用して、これらのロールを手動で作成する必要があります。

sca_createDefaultPartitionAppRoles partition

8.1.6 サーバーの起動と停止

統合コンポーネントを含むSOA SuiteおよびBPMのアップグレード後には、環境のすべての管理サーバーと管理対象サーバーを起動して、それらが期待どおりに機能していることを確認する必要があります。

ドメインのアップグレードが適切に実行されているときには、引き続きアップグレードされた11gのドメイン・ホームからサーバーを起動します。

サーバーを起動する順序と停止する順序が重要であり、正しい順序で起動または停止していないと、デプロイメントで問題が発生することがあります。

注意:

管理サーバー、管理対象サーバーおよびコンポーネントを含めたOracle Fusion Middlewareの開始および停止の手順については、「Oracle Fusion Middlewareの開始と停止」を参照してください

サーバーの起動順序:

1. Web層(Oracle HTTP Serverを含む)

2. ノード・マネージャ

3. 管理サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. サービス指向アーキテクチャ(SOA)管理対象サーバー

6. Oracle Service Bus (OSB)管理対象サーバー

7. Business Activity Monitoring (BAM)管理対象サーバー

サーバーの停止順序:

1. Business Activity Monitoring (BAM)管理対象サーバー

2. Oracle Service Bus (OSB)管理対象サーバー

3. サービス指向アーキテクチャ(SOA)管理対象サーバー

4. Oracle Web Services Manager (OWSM)管理対象サーバー

5. 管理サーバー

6. ノード・マネージャ

7. Web層(Oracle HTTP Serverを含む)

8.1.7 Business Process Management (BPM)メタデータのアップグレード

BPMメタデータのアップグレードは、Business Process Composer 12c (12.2.1)に最初にログインすると(アップグレード完了後)開始されます。

Business Process Composerの使用の詳細は、Oracle Business Process Composerを使用したビジネス・プロセスの開発を参照してください。

8.1.8 Oracle Fusion Middleware 12c監査データ・ストアの構成

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、「監査データ・ストアの管理」を参照してください。

8.1.9 リモート・クライアントによるServerSocketのアップグレード

Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。

8.1.10 SOA 12cのスレッドの再構成

Oracle SOA Suite 12c (12.2.1)から、ワーク・マネージャはほとんどのSOA関連ワーク・スレッドを処理するようになりました。SOA 11gに指定したスレッドの構成は、アップグレードしたSOA 12c環境には適用されません。SOA 12cへのアップグレード後に、スレッドを再構成する必要があります。

新しいスレッド・モデルの使用方法の詳細は、『パフォーマンス・チューニング』のSOAインフラストラクチャのチューニングに関する項を参照してください。

8.2 アップグレードしたコンポーネントが期待どおりに動作していることの確認

アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。

- ドメイン・コンポーネント構成のアップグレードの確認

- データベース・スキーマのアップグレード成功の確認

- フロー・トレースの12cでの変更内容の理解

8.2.1 ドメイン・コンポーネント構成のアップグレードの確認

ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次のURLを使用して管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントでアップグレードされたバージョン番号を確認します。

管理コンソールのURL: http://administration_server_host:administration_server_port/console

Fusion Middleware ControlのURL: http://administration_server_host:administration_server_port/em

注意:

アップグレード後には、11g Oracleホームではなく、新しい12.2.1Oracleホームからすべての管理ツールを実行する必要があります。

8.2.2 データベース・スキーマのアップグレード成功の確認

データベース・スキーマのアップグレードとインスタンスのアップグレードが成功したかどうかは、アップグレード・アシスタントの各アップグレード・ステータス画面に加え、SQLコマンドを使用して手動で確認することもできます。

詳細は、「SQL問合せによるアップグレード・ステータスの監視」を参照してください。

8.2.3 フロー・トレースの12cでの変更内容の理解

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で作成した新しいインスタンスのリカバリ・ステータスは、図8-1に示すようにrecoveredと表示されます。

図8-1 新しい12cインスタンスのフロー・トレース

ただし、BPELで捕捉されたフォルトについて、アップグレードした11gインスタンスのリカバリ・ステータスは、図8-2に示すようにNonrecoverableと表示されます。

注意:
11gのフォルトから渡された情報は、フォルトの状態を正しく識別するのに十分ではありません。これに対処するために、11gから取得された実際のフォルトはすべて、最初はリカバリ不能として識別されます。その後、ダミーのフォルトが作成されて、適切な状態(BPEL_invoke_recovery、Bpel_activity_recovery)に設定されます。

したがって、11gのフォルトがリカバリ不能であるという警告が表示された場合や、そのことに気づいた場合、警告を無視してかまいません。

図8-2 アップグレードした11gインスタンスのフロー・トレース

9 SOAインスタンスのアップグレードの管理と監視

この章では、オープンおよびクローズされたSOAインスタンスを12c (12.2.1)にアップグレードする方法と、アップグレード・プロセスの管理と監視のためのオプションについて説明します。

SOA SuiteおよびBPM 12cの標準アップグレード・プロセスでは、オープンおよびクローズされたSOAインスタンスの自動アップグレード・ソリューションを提供します。閉じているインスタンスのアップグレードは、次の各項で説明する管理スクリプトで監視および管理できます。

- インスタンス・アップグレードのプロセスの理解

- インスタンス・アップグレードのバックグラウンド・ジョブの理解

- アップグレード前のパージ・スクリプトの使用

- アップグレード管理スクリプトの使用

- 管理スクリプトの構成

- アップグレードのセッションとジョブの停止

- 不完全なアップグレードの再開

- SQL問合せによるアップグレード・ステータスの監視

- Fusion Middleware Controlによるアップグレード・ステータスの監視

- インスタンス・アップグレードのエラーの解決

- 失敗したアップグレードの再試行

9.1 インスタンス・アップグレードのプロセスの理解

アップグレード・アシスタントのフレームワークでは、スキーマのアップグレードは各コンポーネントのインストール(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つの異なる段階で行われます。

1. アップグレード・アシスタントにより、11gスキーマの定義がアップグレードされます。

2. その後、アップグレード・アシスタントにより、11gメタデータがアップグレードされ、オープン・インスタンスをアップグレードするためのバックグラウンド制御ジョブが作成されます。
注意: このプロセスには時間がかかることがあります。これは、最後のデータベース・ジョブがオープン・インスタンスのアップグレードを完了するまで、各ジョブがUAで実行され続けるためです。最後のジョブが完了するまで、アップグレード・アシスタントを終了しないことが重要になります。

たとえば、インスタンスのアップグレードに必要な時間は、次の項目に応じて異なります。

- 接頭辞_SOAINFRAスキーマのサイズ(オープンおよびクローズされたインスタンス数)

- システム構成(CPIの数(コア数)、メモリーの使用状況、ディスクI/O構成)。

- システムの速度とドライバ表のサイズ

3. すべてのオープン・インスタンスのアップグレードが完了すると、クローズされたインスタンスをアップグレードするバックグラウンド・ジョブが開始されます。クローズされたインスタンスのアップグレードは、アップグレード・アシスタントのクローズ後も、バックグラウンドで継続される点に注意してください。ただし、バックグラウンド・ジョブが停止されたときに、アップグレード対象のクローズされたインスタンスが残っている場合は、管理スクリプトを使用してこれらを再開する必要があります。

4. 最終的に、最後のジョブがオープン・インスタンスのアップグレードを完了すると、アップグレード・アシスタントによりアップグレード・ステータスが示され、アップグレード・プロセスの後続の手順がリストされます。
アップグレード・アシスタントの「アップグレード成功」画面に示された情報を基にして、次に実行する手順を判断してください。注意: -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管理対象サーバーなど)が開始されるまで継続されます。

すべてのクローズされたインスタンスのアップグレードが完了する前に中間層が開始されると、アップグレード・ジョブは停止します。管理スクリプトを使用して、手動でアップグレードを再開する必要があります。

9.2 インスタンス・アップグレードのバックグラウンド・ジョブの理解

バックグラウンド・ジョブは、_SOAINFRAスキーマのアップグレード時に、アップグレード・アシスタントによって作成されます。このようなジョブは、バックグラウンドで実行され、オープンおよびクローズされたインスタンス・データを自動的にアップグレードします。このようなジョブがアップグレード・プロセスで動作する方法と、そのジョブを管理する方法について理解することが重要になります。次のリストでは、このようなジョブに関する重要な情報について説明します。

- ジョブの作成はアップグレード・アシスタント(UA)で行いますが、ジョブの管理は管理スクリプトで行います。管理スクリプトを使用することで、たとえば、このようなジョブを実行する方法や時期を構成できます。

- ジョブは、スキーマのアップグレード・プロセス後に、自動的に開始されます。

- UAから開始されたジョブは、次のいずれかの状況が発生すると自動的に停止します。

- ジョブが完了して、クローズされたすべてのインスタンスが12cに移行された

- 中間層アプリケーションが開始された(管理対象サーバーなど)

- ジョブ停止スクリプト(オプション8)が開始された

- クローズされたインスタンスのアップグレードが完了していない場合は、アップグレード・アシスタントの終了後も、バックグラウンド・ジョブがバックグラウンドで続行されます。

- ジョブが停止されたときに、アップグレード対象のインスタンスが残っている場合は、管理スクリプトを使用することで、別のときにジョブを実行することも、ジョブを実行するようにスケジュールすることもできます。
バックグラウンド・ジョブの構成の詳細は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」、「アップグレードのセッションとジョブの停止」および「不完全なアップグレードの再開」を参照してください。

9.3 アップグレード前のパージ・スクリプトの使用

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。12cパージ・スクリプトには、移行対象外のクローズされたインスタンスが含まれています。つまり、アップグレード後、12cパージ・スクリプトの実行をスケジュールすると、移行対象外のクローズされたインスタンスがスクリプトでパージされます。パージ・スクリプトを使用してクローズされたインスタンスを削除すると、アップグレードの全体的なパフォーマンスを向上できます。

注意:

オープン・インスタンスのみをアップグレードすると、中断されたステータス・フローが表示されることがあります。子フローが11gで中断されていると、フローは中断状態になります。

このECIDに関連付けられたすべてのコンポジット・インスタンスは、終了状態を維持します。

自動パージまたはパージ・スクリプトの使用の詳細は、「データベース増分の管理」を参照してください。

注意:

アップグレード・アシスタントのバックグラウンド・ジョブの実行中に、パージ・ジョブを実行するようにスケジュールしないでください。アップグレード・アシスタントの実行中にスクリプトを実行すると、パージまたはアップグレードが失敗することがあります。

Upgrade Assistantの実行中にパージ・スクリプトを実行するように構成すると、ORA-20099: ERROR 11gから12cへのアップグレードが進行中ですというメッセージが表示されます。

パージ・スクリプトの実行中にUAを実行すると、SQLException: ORA-00054: リソース・ビジー。NOWAITが指定されているか、タイムアウトしましたというメッセージが表示されます。

9.4 アップグレード管理スクリプトの使用

アップグレード管理スクリプトは、SOA Suite 12c (12.2.1)のインストールに付属するアップグレード・アシスタント機能の一部として含まれています。このようなPL/SQLスクリプトは、インスタンスのアップグレード全体に追加的な管理制御を提供します。アップグレードが完了すると、Oracle Enterprise Manager Consoleでインスタンスを表示できるようになります。さらに詳しいアップグレード・プロセスの情報が必要な場合は、追加のレポートおよび構成オプションに対応した管理スクリプトを使用してください。

注意:

管理アップグレード・スクリプトにより、アップグレードに関する詳細情報が示されます。このようなスクリプトにより、インスタンス・アップグレードに対する追加の構成、管理および監視機能が得られます。このようなスクリプトは、独自の要件に基づいて実行するように(または実行しないように)構成できます。

Fusion Middleware Control Consoleを使用してアップグレード・プロセスを管理および監視することもできますが、管理スクリプトを使用するほうが管理オプションが多くなります。

クローズされたインスタンスのアップグレードを監視するためにアップグレード・アシスタントを使用した後には、Report Upgrade Summary(オプション1)スクリプトを実行することをお薦めします。

アップグレードの進行状況の監視にFusion Middleware Control Consoleを使用する方法の詳細は、「Fusion Middleware Controlによるアップグレード・ステータスの監視」を参照してください。

- アップグレード・スクリプト・メニューへのアクセス

- 管理スクリプトの実行

9.4.1 アップグレード・スクリプト・メニューへのアクセス

インスタンス・アップグレードを構成、管理および監視するために使用できるスクリプトは複数あります。これらのスクリプトへのアクセスには、soa_upgrade_menu PL/SQLスクリプトを使用できます。

アップグレード・スクリプト・メニューにアクセスするには:

1. 12.2.1 SOAホームの/adminディレクトリに移動します。
次に例を示します。

cd  <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/121300/upgrade/admin

2. 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

3. 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では、各スクリプトの機能について説明しています。

9.4.2 管理スクリプトの実行

管理スクリプトのメイン・メニューには、バックグラウンド制御ジョブとその他の管理タスク(トラブルシューティングなど)の監視と管理に必要になるすべてのオプションが表示されます。

注意:

拡張オプションは、アップグレードのトラブルシューティングを行う場合や、特定のアップグレード要件に基づいてアップグレード・プロセスに変更を加える場合にのみ使用します。多くの場合、このようなスクリプトは、指名されたシステム管理者またはOracleサポートのみが実行します。

管理スクリプトのいずれかを実行するには、プロンプトが表示されているときにオプション番号を入力します。表9-1では、各スクリプトの機能について説明しています。

表9-1 アップグレード管理スクリプトのメニュー・オプション

オプション番号

スクリプト名

このオプションの用途

説明

1

Report Upgrade Summary

アップグレードの全体的なステータスを表示します。

このレポートは、サブセクションに分割されていて、アップグレード全体の概要と現在の実行が示されます。

Report Upgrade Summaryには、METADATA、OPEN ECIDS (オープン・インスタンス)およびALL ECIDS (クローズされたインスタンス)のアップグレード・サマリーが示されます。アップグレード・ステータスはCOMPLETEまたはOUTSTANDING (実行中)のどちらかになります。

さらに、次の事項についての説明されています。

- クローズされた11gインスタンスの最終アップグレード日
Maximum Upgrade Date for Closed 11g Instancesセクションには、最後にアップグレードされたフローのクローズ日が表示されます。アップグレードは、最も最近クローズされたインスタンスから開始され、最も以前に完了したインスタンスがアップグレードされるまで継続します。2014年1月1日にクローズしたインスタンス・フローは、2013年12月1日にクローズしたフローより先にアップグレードされます。Maximum Upgrade Date が2013年6月1日の場合は、2013年6月1日までにクローズされたすべてのインスタンスのアップグレードが完了していて、2013年6月1日よりも前にクローズされていたインスタンスはまだアップグレード処理中であることを示しています。

- アップグレードのエラー数
UPGRADE ERROR COUNTには、アップグレード中に発生したエラーの数が表示されます。upgrade_error_logファイルを使用すると、エラーの原因がわかります。

アップグレード・エラーの処理方法の詳細は、「インスタンス・アップグレードのエラーの解決」を参照してください。

- アップグレード開始以降のインスタンス数
Overview Since Start of Upgrade には、アップグレードの開始日時、アップグレード対象インスタンスの合計数および残りのインスタンス数が示されます。

- 現在の実行統計
現在のアップグレードの実行からのアップグレード・データです。各実行には、番号が付けられます。後述するサンプル・レポートの場合、データは最初の実行(run:1)から得られたものになります。(run:2)の指定では、アップグレードは2番目に実行されたものであることが示され、2番目の実行についての統計が表示されます。

- START COUNT: 実行の開始時点で未処理のインスタンス数が表示されます。後続のアップグレード実行(run2、run3など)については、START COUNTの合計に、前回の実行が完了した時点で残されているものの詳細が示されます。

- REMAINING COUNT: アップグレードの実行中に、未処理の現行インスタンス数の合計が5分ごとに収集されます。未処理の現行インスタンス数を、START COUNTから差し引くと、REMAINING COUNT となります。つまり、REMAINING COUNT= START COUNT - 未処理の現行インスタンス数になります

- PROCESSED COUNT:
PROCESSED COUNT= START COUNT - REMAINING COUNT

レポート・データは、次のように示されます。

=============================================
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)を使用して、JOB_MAX_RUNTIMEに変更を加えます。

6

Enable/Disable background control job

バックグラウンド・ジョブを有効または無効にします。

デフォルトでは、Enable/Disable background control jobは無効にされています(ENABLE: FALSE)。現在の設定を変更するには、Y (Yes)を入力します。制御ジョブを無効化すると、指定した繰り返し間隔でバックグラウンド制御ジョブが実行できなくなる点に注意してください。

この設定は、サマリー・レポートではENABLE: TRUE またはFALSEとして表示されます。

現在の設定を維持するには、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

スクリプト管理メニューを閉じます。

このオプションで、メニューが閉じられます。

9.5 管理スクリプトの構成

この項では、アップグレード管理スクリプトの構成に必要な手順について説明します。

- バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

- バックグラウンド制御ジョブの有効化と無効化(オプション6)

- 制御ジョブ・パラメータの設定(オプション7)

- エラーが発生した11gインスタンスのリセット(オプション9)

9.5.1 バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)

バックグラウンド制御ジョブの実行スケジュールを変更するには、オプション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

9.5.2 バックグラウンド制御ジョブの有効化と無効化(オプション6)

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:

9.5.3 制御ジョブ・パラメータの設定(オプション7)

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

注意: をTRUEに設定したSQL_TRACEは、デバッグやトラブルシューティングに使用できますが、DBAは次に示すようにsoainfraユーザーにalter sessionを付与することが必要になる場合があります。

$ sqlplus / as sysdba
SQL> grant alter session to <soainfra>;

ジョブ制御パラメータを変更するには:

1. 「アップグレード・スクリプト・メニューへのアクセス」の手順を使用してSOAアップグレード・メニューを起動する。

「オプションの入力」フィールドに7を入力して、Change Background Control Job Parametersスクリプトを実行します。

SOAアップグレード・メニューが次のように示されます。

==================================================
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 :

***********************************************************************************************

2. 変更するパラメータの番号を「オプションの入力」フィールドに入力します。

たとえば、BATCH_SIZEを変更する場合は1を入力します。

制御ジョブ・パラメータの完全なリストが、次のように示されます。

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 :

3. 新しい値を入力して、パラメータの値を変更します。[Enter]キーを押して、変更をコミットします。変更するパラメータごとに、この手順を繰り返します。

Before ChangeフィールドとAfter Changeフィールドの値を調べることで、変更が受け入れられたことを確認できます。

4. 「オプションの入力」フィールドに15を入力してメイン・メニューに戻ります。

メインの管理スクリプト・メニューに戻ります。

==================================================
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 :

***********************************************************************************************

5. Report Background Control Job Parametersスクリプト(オプション4)を使用して、変更内容を確認します。

======================================================
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

9.5.4 エラーが発生した11gインスタンスのリセット(オプション9)

実行中にアップグレードのエラーが発生した場合は、問題を解決してから、エラーの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:

9.6 アップグレードのセッションとジョブの停止

管理スクリプトを使用すると、実行中のセッションまたはジョブを停止できます。

注意:

実行中のアップグレードジョブを完了前に停止すると、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管理対象サーバーなど)を起動します。
中間層アプリケーション(管理対象サーバーなど)が起動されると、クローズされたインスタンスのアップグレードが自動的に停止されます。管理スクリプトを使用すると、アップグレード・ジョブを別のときに実行するようにスケジュールできます。

9.7 不完全なアップグレードの再開

インスタンスのアップグレードが停止されている場合は、次に説明するように管理スクリプトを使用して、手動で再開する必要があります。

1. 管理スクリプト・オプション6のEnable/Disable background control jobを使用して、バックグラウンド制御ジョブを有効にします。

「バックグラウンド制御ジョブの有効化と無効化(オプション6)」を参照してください。

2. 管理スクリプト・オプション5のChange background control job execution scheduleを使用して、指定した時間間隔でバックグラウンド制御ジョブが実行されるようにスケジュールします。

「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照してください。

3. 手順2で指定した時間間隔に達すると、バックグラウンド制御ジョブが開始されます。管理スクリプトのオプション1のReport Upgrade Summaryを使用して、アップグレード・ステータスを監視します。

表9-1のオプション1を参照してください。

4. アップグレードが完了したら、Oracle Enterprise Manager Fusion Middleware Controlにログインし、「SOA」を開いて「soa-infra」(soa_server1)をクリックし、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。

「データ移行の完了の確認」を参照してください。

9.8 SQL問合せによるアップグレード・ステータスの監視

この項では、管理スクリプトとともに、アップグレードの監視と検証に使用できる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表では、次に示す各タイプのエラーが報告されます。

- 0: このエラーは、前回のアップグレード実行で報告されています。Typeは、アップグレード管理スクリプトのResetting Errored 11g instances(オプション9)を実行したときに、0に設定されます。

- 1: インスタンスのアップグレード中にエラーが発生しました。

- 2: EDNエラー・イベント・ストアまたはアダプタ拒否メッセージのアップグレード中にエラーが発生しました。

- 9: メタデータのアップグレード中にエラーが発生しました。

- 12: データのアップグレード・プロセス中に一般エラーが発生しました。

これらの表にエラーが発生したレコードが存在していないことを確認することが重要です。

詳細は、「エラーが発生した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行が返されます。

9.9 Fusion Middleware Controlによるアップグレード・ステータスの監視

管理スクリプトに加えて、アップグレードの一般的なステータスを表示するには、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用することもできます。管理スクリプトでは、アップグレード・ジョブを詳細に管理制御できますが、次に示す事項はFusion Middleware Controlコンソールで監視できます。

注意:

アップグレードの際に高度な管理タスク(アップグレードのスケジュールや時間間隔の変更など)を実行する必要がある場合は、「アップグレード管理スクリプトの使用」に記載されている管理スクリプトを使用する必要があります。

- データ移行の完了の確認

- 不完全な(停止された)アップグレードの管理

- Enterprise Managerでのインスタンスの表示最適化

- アップグレード時に失敗したインスタンスの表示

- コンポジットの再デプロイ前に作成されたインスタンスの表示

9.9.1 データ移行の完了の確認

Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックし、次に示すように、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。

図9-1 SOAランタイム・ヘルス: データ移行の完了

「データ移行の完了」をクリックして、次のメッセージが表示されることを確認します。

図9-2 移行完了

「OK」をクリックして、「移行完了」ダイアログ・ボックスを閉じます。「SOAランタイム・ヘルス」の移行ステータス・メッセージが表示されます(図9-3)。

図9-3 SOAランタイム・ヘルス: 移行ステータス・メッセージ

「このメッセージを閉じる」をクリックします。次の確認ダイアログが表示されます。

図9-4 データ非表示の確認

「はい」をクリックして、データ移行完了アラートを非表示にします。「SOAランタイム・ヘルス」セクションから、「このメッセージを閉じる」ボタンの表示がなくなります。

「いいえ」をクリックすると、「SOAランタイム・ヘルス」セクションにアラートが表示されたままになります。

9.9.2 不完全な(停止された)アップグレードの管理

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分ごとにリフレッシュできます。

図9-5 SOAランタイム・ヘルス: データの移行が完了していません

「データの移行が完了していません」をクリックすると、次のメッセージが表示されます。

図9-6 SOAランタイム・ヘルス: 移行が完了していない場合のステータス・メッセージ

データ移行のステータス:

- アクティブ・インスタンス: アップグレードされたオープン・インスタンスのステータスが示されます。前掲の例では、オープン・インスタンスはアップグレードが完了しています(ステータスは、「完了」になります)。

- 非アクティブ・インスタンス: アップグレードされたクローズ済インスタンスのステータスが示されます。前掲の例では、2013年7月9日より古いクローズ済インスタンスは、まだアップグレードされていません。アップグレードは最新のものから古いものへの順で実行されます。アップグレードが済んでいないインスタンスは、Fusion Middleware Controlのレポートやビューに表示されません。レポートは、5分ごとにリフレッシュできます。

注意:

実行中のアップグレードの詳細なレポートは、Report Upgrade Summaryスクリプト(オプション1)を実行します(「管理スクリプトの実行」を参照)。

すべてのクローズ済インスタンスがアップグレードされると、リンクは「データ移行の完了」に変化します(図9-2を参照)。

9.9.3 Enterprise Managerでのインスタンスの表示最適化

アップグレードに多数のインスタンス(クローズおよびオープン)の移行が含まれる場合は、Enterprise Managerフロー・トレースのロード時にパフォーマンスの問題が発生することがあります。パフォーマンスの低下を防ぐには、次の手順で説明するように索引を作成します。

1. 管理サーバーと、実行中のすべての管理対象サーバーを停止します。

2. SQLPLUSからSOAINFRAスキーマに接続し、次のコマンドを実行します。

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

3. 管理サーバーおよび管理対象サーバーを再起動します。

9.9.4 アップグレード時に失敗したインスタンスの表示

アップグレード中に失敗した11gインスタンスは、コンポジット・レベルでのみアップグレード後に表示できます。このようなインスタンスは、パーティション・レベルでは表示されません。

このようなインスタンスを表示するには、デプロイ済コンポジットの「フロー・インスタンス」タブに移動します(図9-7を参照)。

図9-7 アップグレード時に失敗したインスタンスのコンポジット・レベルを使用した表示

注意: 「検索オプション」を使用すると、特定のインスタンス作成時間または作成日の範囲を指定できます。

9.9.5 コンポジットの再デプロイ前に作成されたインスタンスの表示

コンポジットが同一のアップグレード前リビジョンで再デプロイされている場合、該当するインスタンスを表示するには、パーティション・レベル(コンポジット・レベルではありません)に移動する必要があります(図9-8を参照)。

ただし、アップグレード後に作成されたインスタンスは、12cのコンポジット・レベルで表示できます。

図9-8 アップグレード前に作成したインスタンスのパーティション・レベルを使用した表示

9.10 インスタンス・アップグレードのエラーの解決

アップグレードが失敗した場合や、Report Upgrade Summaryレポート(オプション1)のUPGRADE ERROR COUNTセクションに、現在の実行でのエラー発生が示されている場合は、アップグレードに向けてインスタンスを再発行する前に、エラーを解決する必要があります。

upgrade_error_logは、エラーの状況を診断するために使用でき、問題を解決する手がかりを示すこともあります。一般的なアップグレード・エラーの解決方法の詳細は、「失敗したアップグレードからのリカバリ」を参照してください。

次の表では、各エラーと考えられる解決方法について説明します。

エラー・タイプ

説明

エラー・メッセージ

解決方法

0

これらのエラーは、前回のアップグレード実行で報告されています。

タイプは、エラーが発生したインスタンスをリセットすると0に設定されます(「エラーが発生した11gインスタンスのリセット(オプション9)」を参照)。

エラー・メッセージには、前回のエラー・タイプに基づいて、発生したエラーに関する詳細が示されます。

前回の実行からのエラーを修正し、管理スクリプトを使用してリセットします。

1

インスタンスのアップグレード中にエラーが発生しました。

エラー・メッセージには、アップグレード・スクリプトからスローされた実際のエラーが含まれています。また、エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースも示されます。

根本原因のデバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。

Info列に移入されたECIDは、失敗したインスタンスのデータを取得する場合に役立ちます。

2

EDNエラー・イベント・ストアまたはアダプタ拒否メッセージのアップグレード中にエラーが発生しました。

エラー・メッセージには、失敗したコンポーネントを特定するための文字列upgrade_rejected_message/upgrade_edn_messageが含まれています。

これには、失敗したメッセージのIDとともに、失敗の理由が含まれています。

デバッグは、エラーの実際の理由を分析することで実行できます。失敗したアダプタ/EDNメッセージの詳細を取得するために、ERROR_MSGの一部としてログ出力されたIDを使用できます。

9

メタデータのアップグレード中にエラーが発生しました。

メタデータのアップグレードに失敗したcomposite_dnの詳細が含まれています。

エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。

デバッグは、トレースとともに実際のエラーを調べて、エラーの場所を見つけることで実行できます。Info列では、メタデータのアップグレードに失敗したcomposite_dnの全体が得られます。

12

データのアップグレード・プロセス中に一般エラーが発生しました。これは、単一のインスタンスに関するものではありません。

Infoには、文字列migrate_soaのみが含まれます。

エラーが発生したアップグレードPL/SQLスクリプトの行を指すスタック・トレースとともに、アップグレード・スクリプトからスローされた実際のエラーも含まれます。

このエラー・タイプは、アップグレードの実行中に、データのアップグレードが全体として失敗したときに、失敗が必ずしも特定のインスタンスに関連しない場合に報告されます。

このタイプのエラーの一例として、TEMP表領域の問題が考えられます。

9.11 失敗したアップグレードの再試行

エラーを解決したら、次の手順を実行してアップグレードを再開します。

1. upgrade_error_logに表示されたエラー条件を修正します。

2. 「エラーが発生した11gインスタンスのリセット(オプション9)」の説明に従って、upgrade_error_logからエラー・フラグを削除します。これにより、エラーが発生したインスタンスを後続の実行で再発行できるようになります。

3. 「バックグラウンド制御ジョブの有効化と無効化(オプション6)」の説明に従って、バックグラウンド制御ジョブを有効にします。別個のアップグレード実行をトリガーする必要があります。

4. バックグラウンド制御ジョブの繰り返し間隔と継続時間を必要に応じて変更します(「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照)。

5. Report Summary Upgradeスクリプト(オプション1)を使用して、アップグレード・ステータスを監視します。レポートのUPGRADE ERROR COUNTセクションに、エラーが0個と示される必要があります。エラーが残っている場合は、問題を解決してから、ここに示した手順を繰り返します。

A アップグレードのトラブルシューティング

この付録では、失敗したアップグレード、ドメインの再構成やサーバー起動の問題をトラブルシューティングする場合に、共通するいくつかの手順について説明します。

- リリース・ノートの確認

- サーバー起動エラーの解決

- 失敗したアップグレードからのリカバリ

- アップグレード時のOWSMデータ・ソース接続障害 (12.1.3から12.2.1へ)
Upgrade Assistant実行時に「ドメインによって使用されるすべての構成」を選択すると、アップグレードは調査フェーズで失敗します(WSMERROR-00015エラー)。

- 失敗したBAMアップグレードのトラブルシューティング

- アップブレード後のSOA JMSモジュールへのEDNTopicの再適用
SOA Serverアップグレード後タスクの開始時にEDN Topicが見つかりません。これは既知の問題であり、回避策は手動でEDN Topicを再作成することです。

- Oracle Service Busのトラブルシューティング

- Oracle Managed File Transfer (MFT)アップグレードの問題点のトラブルシューティング
Oracle Managed File Transferのアップグレード時にアップグレード・エラーが発生する場合、次のトラブルシューティング・タスクを参照して問題を修正します。

- 12cへのアップグレード後のOWSM起動エラー

- アップグレード時の暗号化の問題

- アップグレード・アシスタントによるサポート対象外ドメインのアップグレード

- インスタンスのアップグレード後に表示されなくなるビジネス・ルールの監査証跡

- Coherenceキャッシュ例外の解決

- WSDLで生じるカスタム例外の欠落要素

- リモート・クライアントを介したServerSocketへの接続

A.1 リリース・ノートの確認

リリース・ノートは、既知の問題がアップグレードに影響する可能性があるかどうかを判断するために必ず確認してください。リリース・ノートは、Oracle Fusion Middleware 12c (12.2.1)ライブラリ内にあります。

A.2 サーバー起動エラーの解決

サーバーが起動しない場合やサーバーがAdminModeで起動する場合、最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が12cドメインに再適用されていないことです。11gのsetDomainEnvファイルと新しい12cのsetDomainEnvファイルを比較して、カスタムの変更をアップグレード後に追加してください。

詳細は、起動スクリプトへのカスタマイズの再適用に関する説明を参照してください。

A.3 失敗したアップグレードからのリカバリ

失敗したアップグレードからのリカバリ方法は、どの時点でエラーが発生したかによって異なります。次の事項を確認して、リカバリの方法を判断してください。

- アップグレード・アシスタントを実行して、_SOAINFRAスキーマをアップグレードしているときにエラーが発生した場合は、スキーマのエラーを修正してから、バッチ・ジョブを再実行する必要があります。
このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。

- 再構成ウィザードの実行中にエラーが発生した場合は、ソース環境からリストアして、アップグレードを最初からやり直す必要があります。

- アップグレード・アシスタントを実行して、WebLogicコンポーネント構成オプションをアップグレードしているときにエラーが発生した場合は、エラーを修正してからアップグレード・アシスタントを再実行します。アップグレード・アシスタントの2回目の実行時には、バックアップからリストアして、アップグレード・プロセスを最初からやり直す必要ありません。このプロセスは、再入可能です。

- アップグレード・アシスタントを実行してスキーマをアップグレードしているときにエラーが発生した場合、そのエラーがアップグレード・フェーズで発生したときには、バックアップからリストアして、問題を修正した後に最初からアップグレードをやり直す必要があります。ただし、調査フェーズでエラーが発生した場合は、問題を修正してアップグレード・アシスタントを再開できます。アップグレード・フェーズ前に発生したエラーは、再入可能です。

アップグレードのトラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。

注意:

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

BAM固有の問題点の解決に関する詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

A.4 アップグレード時のOWSMデータ・ソース接続障害 (12.1.3から12.2.1へ)

Upgrade Assistant実行時に「ドメインによって使用されるすべての構成」を選択すると、アップグレードは調査フェーズで失敗します(WSMERROR-00015エラー)。

エラー・メッセージ:

[2015-09-22T10:46:54.552-07:00] [WSM] [INCIDENT_ERROR] [upgrade.WSM.WSMPLUGIN]oracle.ias.update.exception.UpgradeException: WSMERROR-00015: Failed to read the Oracle WSM datasource connection details.at oracle.wsm.lifecycle.upgrade.impl.WSMUpgradePlugin.initializePluginData(WSMUpgradePlugin.java:396)

このエラーは、12.1.3ドメインがマルチ・データソース接続で作成されているために発生します。12.2.1にアップグレードする場合、Upgrade Assistantは汎用データソース接続を必要とします。

アップグレードを実行するには、次の手順を実行します。

1. "mds-owsm"データ・ソースを汎用データ・ソースに変更します。

2. Upgrade Assistantを再起動し、要求されたら「ドメインによって使用されるすべての構成」を選択します。

3. アップグレードに成功したら、"mds-owsm"データ・ソースをマルチDSに戻すことができます。

A.5 失敗したBAMアップグレードのトラブルシューティング

Oracle Business Activity Monitoring (BAM)を含むドメインをアップグレードする場合、追加のBAM固有のトラブルシューティング手順があります。

詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

A.6 アップブレード後のSOA JMSモジュールへのEDNTopicの再適用

SOA Serverアップグレード後タスクの開始時にEDN Topicが見つかりません。これは既知の問題であり、回避策は手動でEDN Topicを再作成することです。

SOA 12.2.1にアップグレードすると、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

これは既知の問題であり、クラスタ環境でも非クラスタ環境でも発生します。

管理コンソールのオンライン・ヘルプでEDNTopicの再適用の詳細を参照するか、Oracleサポートに問い合せてください。

A.7 Oracle Service Busのトラブルシューティング

Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busアップグレードのトラブルシューティング」で説明されているトラブルシューティング手順を確認してください。

A.8 Oracle Managed File Transfer (MFT)アップグレードの問題点のトラブルシューティング

Oracle Managed File Transferのアップグレード時にアップグレード・エラーが発生する場合、次のトラブルシューティング・タスクを参照して問題を修正します。

いくつかの一般的なManaged File Transferのアップグレード・エラー・メッセージを次に示します。

SQLException: ORA-04020: オブジェクトをロックしようとしてデッドロックを検出しました。

解決方法: Upgrade Assistantの「使用可能なコンポーネント」画面で「Managed File Transfer」を選択していることを確認します。Oracle Managed File Transferを選択しない場合、アップグレードにMFTスキーマは含まれません。

A.9 12cへのアップグレード後のOWSM起動エラー

アップグレード前にEnterprise Manager 11gに構成されたカスタムのトラスト・キーストアがあった場合、OWSMの起動で問題が発生する場合があります。

具体的には、OWSMを実行している11gドメインを12cにアップグレードした後に、OWSMサーバー・ログ(2回目の起動後)に次のエラーが発生した場合、この問題を手動で修正する必要があります。

####<Dec 18, 2014 12:07:01 PM MST> <Error> <HTTP> <srvgdysoap01.nov.com> <wls_wsm1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <26c804bb-15a7-46de-a81e-82565fcd2f28-00000004> <1418929621034> <BEA-101216> <Servlet: "PolicyManagerValidator" failed to preload on startup in Web application: "/wsm-pm".

Stack:
java.lang.NullPointerException
at oracle.wsm.config.ConfigurationProcessor.isContextValid(ConfigurationProcessor.java:297)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)

wsm-pmアプリケーションが起動しない場合、次の手順を実行する必要があります。

1. アップグレードを11gまでロールバックします

2. Upgrade Assistantを使用してアップグレード手順をもう一度実行します。

3. OWSMサーバーを起動します

注意:

OWSMサーバーは、一度のみ起動し、そのまま実行させておくことが非常に重要です。それを停止して再起動すると、NPEが現れ、再びロールバックする必要が生じます

4. <domain_home>/oracle_common/common/bin場所から実行中のOWSMサーバーに対して、次のWLSTコマンドを実行します。

exportMetadata('wsm-pm','<wsm server>','location to write the zip')

where <wsm_server> is the name of the WLS server running OWSM ('wsm_server1' for example)

5. MDSアーカイブを抽出し、/configuration/WLS/に移動して、そこでファイルを開きます。ファイル名はドメインの名前です。

6. 文字列「keystore.inst.0」を含んでいるプロパティ・エントリを検索します。おそらく、次のようなものがいくつか続けて見つかります

<orares:property ........</orares:property>

7. これらのプロパティをファイルから削除します。

8. アーカイブを再構築して、次のコマンドを使用して、実行中のサーバーにそれをインポートして戻します。

importMetadata('wsm-pm','<wsm server>','location of zip')

9. サーバーを再起動します。

A.10 アップグレード時の暗号化の問題

再構成時に次のエラー・メッセージが返された場合は、JDKに追加のポリシー・ファイルを適用して、バックアップからアップグレードを再開する必要がある可能性があります。

JPS-06513: Failed to save keystore. Reason oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to perform cryptographic operation

このエラーの再発を防止するには、その後のアップグレードを実行する前に、強化された暗号化(AES 256)の使用の情報を使用してポリシー・ファイルを適用します。

A.11 アップグレード・アシスタントによるサポート対象外ドメインのアップグレード

アップグレード・アシスタントから、指定されたドメインをアップグレードできないというエラーが返されたときには、詳細についてOracleサポートに問い合せてください。サポート対象のドメイン構成は、「SOAドメイン・アップグレードの制限の理解」で説明しています。

サポート対象外のドメインのスキーマやドメイン構成は、アップグレードしないでください。

A.12 インスタンスのアップグレード後に表示されなくなるビジネス・ルールの監査証跡

デシジョン・サービス・コンポーネントのアップグレードした11gインスタンスについての監査証跡は、アップグレード後に使用できなくなります。新しい12cインスタンスの監査証跡は、これまでどおりに表示されます。

A.13 Coherenceキャッシュ例外の解決

次に示すWebLogic Cache Provider Coherence例外が示された場合は、エンタープライズ・デプロイメント・トポロジの推奨事項に従って、特定のListenAddressを指定していない可能性があります。

この例外が示されたときには、次のように管理対象サーバーのListenAddressを設定する必要があります。

例外:

weblogic.cacheprovider.coherence.CoherenceException:
at weblogic.cacheprovider.coherence.CoherenceClusterManager.ensureWKAAddresses(CoherenceClusterManager.java:510)
at weblogic.cacheprovider.coherence.CoherenceClusterManager.configureClusterService(CoherenceClusterManager.java:236)
at weblogic.cacheprovider.CacheProviderServerService.bootCoherenceFromWLSCluster(CacheProviderServerService.java:225)
at weblogic.cacheprovider.CacheProviderServerService.initCoherence(CacheProviderServerService.java:94)

解決方法:

1. WebLogic Serverコンソールにログインします。

2. 「サーバー」に移動します。

3. 管理対象サーバー(SOAやOSBなど)を検索します。

4. 「リスニング・アドレス」をlocalhostから127.0.0.1に変更するか、実際のマシン名を指定します。

A.14 WSDLで生じるカスタム例外の欠落要素

EJBにカスタム例外が含まれているときに、EJBビジネス・サービスからWeb Service Description Language (WSDL)ファイルをエクスポートすると、生成されたWSDLファイルにはカスタム例外のプロパティが含まれなくなります。アップグレード後に、WSDLファイルを手動で編集して、該当するカスタム例外のプロパティを含める必要があります。

これは、ファイルのWSDL生成部分に限定された問題です。実行時に、EJBからスローされたカスタム例外は、SOAPフォルトのそれぞれの要素にマップされます。レスポンス・ペイロードには、カスタム例外のプロパティに対応する要素が移入されます。

A.15 リモート・クライアントを介したServerSocketへの接続

Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。

詳細は、テクノロジ・アダプタの理解のOracleソケット・アダプタに関する項を参照してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。