Oracle® Fusion Middleware

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

12c (12.2.1.2)

E82837-02(原本部品番号:E77900-03)

2016年12月

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

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

E82837-02

Copyright © 2013, 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.2)

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

- 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 アップグレード可能な既存のスキーマの識別

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

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

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

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

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

- 2.10.4 以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除

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

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

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

3 SOA SuiteおよびBusiness Process Managementの11gからのアップグレード

- 3.1 SOA SuiteおよびBPMのアップグレード・プロセス・フローについて

- 3.2 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

- 3.3 RCUを使用した必要な12cスキーマの作成

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

- 3.4.1 アップグレード前の準備状況チェックの実行について

- 3.4.2 準備状況モードでのUpgrade Assistantの起動

- 3.4.2.1 アップグレード・アシスタントのパラメータ

- 3.4.3 Upgrade Assistantでの準備状況チェックの実行

- 3.4.4 準備状況レポートの理解

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

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

- 3.6.1 製品スキーマのアップグレード

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

- 3.6.1.1.1 アップグレード・アシスタントのパラメータ

- 3.6.1.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

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

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

- 3.7 ドメインの再構成

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

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

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

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

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

- 3.8.1.1 アップグレード・アシスタントのパラメータ

- 3.8.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

4 Oracle Service Bus (Oracle SOA Suiteなし)の11gからのアップグレード

- 4.1 Oracle Service Busの12cへのスタンドアロン・アップグレードの理解

- 4.2 Oracle Service Bus 12c (12.2.1.2)のアップグレードに関する制限事項

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

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

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

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

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

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

- 4.5 RCUを使用した必要な12cスキーマの作成

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

- 4.7 Oracle Service Busドメイン(SOAなし)のアップグレード

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

- 4.7.1.1 アップグレード・アシスタントのパラメータ

- 4.8 ドメインの再構成

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

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

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

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

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

- 4.9.1.1 アップグレード・アシスタントのパラメータ

- 4.9.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

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

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

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

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

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

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

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

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

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

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

- 5.1 Business Activity Monitoring 12c (12.2.1.2)へのアップグレードの理解

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

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

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

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

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

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

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

- 5.4.1 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

- 5.4.2 RCUを使用した必要な12cスキーマの作成

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

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

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

- 5.4.5.1 製品スキーマのアップグレード

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

- 5.4.5.1.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

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

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

- 5.4.6.1 ドメインの再構成

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

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

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

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

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

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

- 5.4.7.1.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 5.7.1 CFGFWK-60950エラーの解決

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

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

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

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

- 6.1 以前の12cリリースからのアップグレードの理解

- 6.2 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

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

- 6.3.1 アップグレード前の準備状況チェックの実行について

- 6.3.2 準備状況モードでのUpgrade Assistantの起動

- 6.3.2.1 アップグレード・アシスタントのパラメータ

- 6.3.3 Upgrade Assistantでの準備状況チェックの実行

- 6.3.4 準備状況レポートの理解

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

- 6.5 製品スキーマのアップグレード

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

- 6.5.1.1 アップグレード・アシスタントのパラメータ

- 6.5.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

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

- 6.6 ドメインの再構成

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

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

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

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

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

- 6.7.1.1 アップグレード・アシスタントのパラメータ

- 6.7.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

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

- 7.1 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

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

- 7.2.1 アップグレード前の準備状況チェックの実行について

- 7.2.2 準備状況モードでのUpgrade Assistantの起動

- 7.2.2.1 アップグレード・アシスタントのパラメータ

- 7.2.3 Upgrade Assistantでの準備状況チェックの実行

- 7.2.4 準備状況レポートの理解

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

- 7.4 製品スキーマのアップグレード

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

- 7.4.1.1 アップグレード・アシスタントのパラメータ

- 7.4.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

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

- 7.5 ドメインの再構成

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

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

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

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

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

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

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

- 8.4 別のホストへのドメイン構成の伝播

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

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

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

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

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

- 8.5.1 管理サーバーおよびSOA管理対象サーバーの起動

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 10.1.1 SOAインフラストラクチャの共通プロパティの更新

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

- 10.1.3 setDomainEnv.shへのカスタマイズの再適用

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

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

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

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

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

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

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

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

- 10.2.1 サーバーおよびプロセスの起動

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

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

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

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

- A.2.1 setDomainEnv.shへのカスタマイズの再適用

- A.2.2 JVMの開始スクリプト・プロパティの再適用

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

- A.2.4 カスタムのXPathクラスのコピー

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

- A.4 12c (12.1.3または12.2.1.0)から12c (12.2.1.2)へのアップグレード中のOWSMデータ・ソース接続の失敗

- 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.10.1 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

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

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

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

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

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

- A.16 スキーマ・レジストリ内の無効なオブジェクトのトラブルシューティング

はじめに

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

- 対象読者

- 表記規則

- 関連ドキュメント
12cドキュメント・ライブラリでは、アップグレード・ドキュメントは作業別に編成されています。タスク固有のページには、一般的なアップグレード手順および関連ドキュメントへのダイレクト・リンクが用意されています。

対象読者

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

関連ドキュメント

12cドキュメント・ライブラリにおいて、アップグレード・ドキュメントはタスクに基づいて編成されています。タスク固有のページには、一般的なアップグレード手順および関連ドキュメントへのダイレクト・リンクが用意されています。

詳細はOracle Fusion Middlewareライブラリを参照してください。

- インストールの情報は、Fusion Middlewareインストール・ドキュメントを参照してください。

- アップグレードの情報は、Fusion Middleware 12cアップグレード・ドキュメントを参照してください。

- 管理関連の情報は、Fusion Middleware 12c管理ドキュメントを参照してください。

- リリース関連の情報は、Fusion Middleware 12cリリース・ノートを参照してください。

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.2)へのアップグレードの理解
アップグレード前の環境がアップグレードによってどのように影響を受けるかを理解します。

- SOA Suite 12c (12.2.1.2)のアップグレードの開始点の理解
アップグレード前に、アップグレード前の環境がサポート対象のバージョンであることを確認します。

- アップグレード前の相互運用性および互換性に関する制限事項の理解
アップグレード前のドメイン内のすべてのコンポーネントがアップグレード後の12c (12.2.1.2)コンポーネントとどのように相互作用するかを読んで理解してください。

- SOAドメインのアップグレードに関する制限事項の理解
アップグレードを開始する前に、ドメイン・アップグレードに関する制限事項を確認します。

- 標準SOAアップグレード・トポロジの理解
実際のトポロジは異なる場合がありますが、このガイドで示すトポロジは、同様のSOA Suiteコンポーネント・トポロジをアップグレードするために使用できます。

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

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

アップグレード前の環境がアップグレードによってどのように影響を受けるかを理解します。

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

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

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

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

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

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

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

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

注意:

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

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

アップグレード前に、アップグレード前の環境がサポート対象のバージョンであることを確認します。

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

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

- 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 アップグレード前の相互運用性および互換性の制約の理解

アップグレード前のドメイン内のすべてのコンポーネントがアップグレード後の12c (12.2.1.2)コンポーネントとどのように相互作用するかを読んで理解してください。

SOA SuiteおよびBPM 11gから12c (12.2.1.2)へのアップグレード・プロセスを開始する前に、アップグレードが11gドメイン内のすべてのコンポーネントにどのような影響を与えるかを理解する必要があります。相互運用性および互換性の理解には、同時にアップグレードできるコンポーネントと、アップグレードできないコンポーネントについての詳細なマトリックスが掲載されています。

通常、Oracle Fusion Middleware12c (12.2.1.2)でまだ使用できないコンポーネントを含むドメインは、アップグレードできません。12c (12.2.1.2)にアップグレードできるコンポーネントには、その他の制限事項があります。これについての情報は、アップグレードを実行する前に注意深く確認する必要があります。

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

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

アップグレードを開始する前に、ドメインのアップグレードに関する制限事項を確認してください。

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

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

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

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

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

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

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

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

実際のトポロジは異なる場合がありますが、このガイドで示すトポロジは、同様のSOA Suiteコンポーネント・トポロジをアップグレードするために使用できます。

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

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

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

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

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

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

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

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

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

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を含むOracle SOA Suiteの11gからのアップグレード

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

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

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

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

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

SOA Suiteを含まないOracle Service Bus (OSB)
注意: SOA Suiteを含むOracle Service Bus (OSB) 11gは、標準のアップグレード手順に従います。

Oracle Service Busドメイン(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スキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。

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

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

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

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

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

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

- アップグレード可能な既存のスキーマの識別
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。

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

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

アップグレードを成功させて停止時間を少なくするために、アップグレードを開始する前に、このチェックリスト内の作業を実行します。

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

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

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

タスク

説明

必須

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

アップグレードしようとしているスキーマを含めて、システムに重要なファイルとデータベースをすべてバックアップします。アップグレードに失敗した場合、アップグレード前の環境をリストアして、アップグレードを再度開始する必要があります。

「完全なバックアップの作成」を参照してください。

- 必ずバックアップにスキーマ・バージョン・レジストリ表が含まれるようにしてください。スキーマ・バージョン・レジストリ表のバックアップを参照してください。

- 既存のドメイン内の起動スクリプトのいずれかを変更した場合、アップグレード中にそれらを(既存ドメインの外部にある)一時ディレクトリの場所にコピーし、アップグレード後に再デプロイする必要があります。カスタム・ドメイン環境設定の保持を参照してください。

オプション

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

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

「本番環境のテスト用クローニング」を参照してください。

必須

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

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

(オペレーティング・システムを含む)ハードウェアとソフトウェアの構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。また、12c製品のディストリビューションをインストールする前に、サポート対象バージョンのJDKを使用していることを確認してください。

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

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

動作保証とシステム要件の確認に関する項を参照してください。

32ビット・オペレーティング・システムのみで必要

アップグレードの前に、64ビット・オペレーティング・システムに移行します。

これは、現在サポート対象外の32ビット・オペレーティング・システムを実行している場合にのみ必要になります。
「32ビットから64ビット・オペレーティング・システムへの移行」を参照してください。

オプション

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

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

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

「強化された暗号化(AES 256)を使用する際のポリシー・ファイルの更新」を参照してください。

オプション

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

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

「未使用データのパージ」を参照してください。

Oracle Databaseユーザーのみ必要

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

エディション・ベースの再定義(EBR)データベースを使用している場合、アップグレードの開始前にエディションを作成する必要があります。
「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。

オプション

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

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

「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

オプション

開始する前に、現在ドメイン内にあるスキーマを識別します。

アップグレードの開始前に、アップグレード前のドメインに存在するスキーマを把握することが重要です。スキーマの所有者名とパスワード、および各スキーマのバージョンを知る必要があります。

「アップグレードに対応可能な既存のスキーマの特定」を参照してください。

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

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

アップグレードが失敗した場合にコンテンツをそのアップグレード前の状態にリストアできるよう、バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

実際のアップグレードに進む前に、Upgrade Assistantの「前提条件」画面に、バックアップを実行してあることの確認を求めるメッセージが表示されます。ただし、Upgrade Assistantではバックアップが作成されていることは確認しないため注意してください。

バックアップの作成の詳細は、次を参照してください。

- Oracle Fusion Middlewareの管理の環境のバックアップ

- Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードおよび準備

システムの完全なバックアップの作成に加え、スキーマ・バージョン・レジストリのバックアップ、およびアップグレード後の環境で使用するカスタム設定も作成する必要があります。次の資料も参照してください。

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

- カスタム・ドメイン環境設定の保持
アップグレード前の環境で、生成されたドメイン、またはサーバー起動スクリプトを変更した場合は、これらの変更がインストール、ドメイン・アップグレードおよび再構成操作の間に上書きされることに注意することが重要です。

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

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

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

注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。アップグレード中に、バックアップを実行してあることの確認を求められます。

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

アップグレード前の環境で、生成されたドメイン、またはサーバー起動スクリプトを変更した場合は、これらの変更がインストール、ドメイン・アップグレードおよび再構成操作の間に上書きされることに注意することが重要です。

すべてのドメイン・インストールには、動的に生成されたドメイン、およびsetDomainEnvなどのサーバー起動スクリプトが含まれています。これらのファイルは、インストールおよびアップグレード・プロセスの間に新しいバージョンに置き換えられます。カスタムのドメインレベルの環境設定を保持するには、スクリプトを直接変更するのではなく、アップグレードする前に別のファイルを作成してカスタムのドメイン情報を格納することをお薦めします。

たとえば、ドメイン内のすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のコマンドライン・オプションを指定する、または追加の環境変数を指定するなどの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、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スクリプトを作成できない場合は、Oracle WebLogic Serverのアップグレードの起動スクリプトへのカスタマイズの再適用の説明に従って、設定を再適用する必要があります。

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

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

テスト用に本番環境をクローニングすることをお薦めしますが、必須ではありません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認

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

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

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

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

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

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

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

32ビット環境を実行している場合は、さらに一連の手順を実行する必要があります。

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

2.4.2.1 32ビットから64ビット・オペレーティング・システムへの移行

32ビットのオペレーティング・システムを使用している場合は、アップグレード前に、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 すべてのプロセスを停止する

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

管理対象サーバーを停止します

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

管理サーバーを停止します

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。

ノード・マネージャを停止します

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

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ホームでインストールする必要があります。

インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

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

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

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

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

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

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

アップグレードを開始する前にFusion Middlewareデータベース要件を確認し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードを実行するための十分なスペースがあることを確認します。詳細は、12c (12.2.1.2)の動作保証マトリックスに関する説明を参照してください。

注意:
ご使用のデータベース・バージョンがサポート対象外だった場合は、アップグレードを開始する前に、サポート対象のバージョンにアップグレードする必要があります。Oracle Fusion Middlewareのアップグレードのプランニングの12cのためのOracleデータベースのアップグレードと準備を参照してください。

2.4.4 このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認

Oracle Technology Network (OTN)で、Oracle Fusion Middlewareのサポート対象システム構成に関する情報を参照して、現在使用しているJDKがサポートされていることを確認します。

このマニュアルの発行時点で、12c (12.2.1.2)の動作保証済JDKは、1.8.0_101です。

ご使用のJDKがサポートされていないか、JDKをインストールしていない場合は、次のWebサイトから、必要な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 未使用データのパージ

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

注意:大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の次の情報を参照してください。

- パージおよびパーティション化の方法の開発

- データベース増分管理戦略の策定

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

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

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

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

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

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

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

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

create edition Oracle_FMW_12_2_1_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_1;

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

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

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

注意
前のリリースで非SYSDBAユーザーFMWを作成した場合は、アップグレードを開始する前に、このユーザーを削除して再作成する必要があります。古いFMWユーザーでUpgrade Assistantを実行すると、新しい権限が追加されているためにアップグレードが失敗する可能性があります。既存のFMWユーザーを変更するのではなく、ユーザーを削除して再作成することをお薦めします。

デフォルトでは、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;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;

注意:

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

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

2.9 アップグレード可能な既存のスキーマの識別

このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。

Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることや、個々のスキーマを選択してアップグレードすることができます。決定に役立つよう、次の手順に従って、アップグレード可能なすべてのスキーマのリストを表示します。

1. Oracleデータベースを使用している場合は、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 ;

2. 生成されたレポートを確認します。VERSION列内の値が11.1.1.7.0以上で、STATUS列の値がVALIDの場合、スキーマは、アップグレードのサポート対象となります。
あるスキーマでアップグレードの必要がない場合、schema_version_registry表には、アップグレード前のバージョンでそのスキーマが保持されます。

3. 既存スキーマに使用されていたスキーマ接頭辞名をメモします。新しい12cスキーマを作成するときに、これと同じ接頭辞を使用することになります。

注意

- 既存のスキーマがサポート対象バージョンでない場合は、12c (12.2.1.2)のアップグレード手順を使用する前に、それらをサポート対象バージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。

- Oracle Enterprise Data Quality、Oracle GoldenGate MonitorおよびOracle GoldenGate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。

- 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しいOPSSスキーマを必ず作成してください。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。

- Oracle Fusion Middleware 12c (12.2.1.2)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.2)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

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

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

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

注意:

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

アップグレード前タスク

詳細

必須

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

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

必須

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

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

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

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

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

以前の12cリリースからのアップグレード時の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.2)を実行する前に、サポートされるデータベースを必須のスキーマで構成しておく必要があります。

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

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

- 以前の12cリリースからのアップグレード時の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.10.1 SOA SuiteアップグレードのためのFusion Middleware Databaseのアップグレードと準備

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

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

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.10.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.10.2 アップグレード前のSOA Composerの変更のコミット

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

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

2.10.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.10.4 以前の12cリリースからのアップグレード時のcloudsdkアプリケーションの削除

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.10.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の11gからのアップグレード

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

注意:

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

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

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

- Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

- RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

- アップグレード前の準備状況チェックの実行
アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- サーバーおよびプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンする必要があります。

- Upgrade Assistantを使用したスキーマのアップグレード
パーティション化されていないスキーマをアップグレードする場合は、「Upgrade Assistantを使用したスキーマのアップグレード」で説明されている手順に従ってください。パーティション化されているスキーマをアップグレードする場合は、「パーティション化されているスキーマのアップグレード」で説明されている手順に従ってください。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

3.1 SOA SuiteおよびBPMのアップグレード・プロセス・フローについて

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

既存のドメインをアップグレードするために実行する手順は、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当する手順にのみ従ってください。

図3-1 SOA SuiteおよびBPMのアップグレード・プロセス・フローチャート

表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.2)をインストールする必要があります。

12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。

インストールしますが、新しくインストールしたドメインを構成するために構成ウィザードを使用しないでください。アップグレード中、再構成ウィザードを使用して既存の11gドメインを構成します。

必須

SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)と、統合されたSOA統合ディストリビューション(Oracle HTTP Server、Oracle Service Busなど)を、新しく作成したOracleホームにインストールします。

Fusion Middleware 12c (12.2.1.2)ディストリビューションは、アップグレードするSOA統合製品ごとにインストールする必要があります。たとえば、Oracle Service Busを含むSOA 11g環境をアップグレードする場合は、Oracle SOA SuiteおよびBPM 12c (12.2.1.2)ディストリビューションの他に、Oracle Service Bus Vディストリビューションも入手する必要があります。

オプション
Upgrade Assistantでアップグレード前の準備状況チェックを実行します

アップグレードを開始する前にUpgrade Assistantを—readinessモードで実行し、アップグレードを失敗させる可能性がある、アップグレード前環境での潜在的な問題を識別します。必要な場合は、問題を修正し、準備状況チェックを再度実行します。

必須

11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。

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

必須

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

作成するスキーマは、既存のスキーマ構成によって異なります。

必須

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

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

オプション

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

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

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

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

「Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード」を参照

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

必須

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

アップグレード中に、構成ウィザードを再構成モードで実行し、新しくインストールしたソフトウェアを使用するよう既存のドメインをアップグレードします。

必須

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

Upgrade Assistantは、再構成したドメインのコンポーネント構成を更新するために使用します。

必須

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

コンポーネントには、その他のアップグレード後手順は必要ない場合があります。

必須

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

バックアップを削除する前に、アップグレードしたすべてのコンポーネントが予想どおりに動作することを確認することをお薦めします。

クラスタ・アップグレードに必要
アップグレードが正常に終了したことを確認したら、環境を他のホストに伝播する必要があります。

「別のホストへのドメイン構成の伝播」

3.2 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

開始する前に、次の点に注意してください。

- 以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、12c (12.2.1.2)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。

- Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、SOAディストリビューションsoa_generic.jarの一部です。

Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには、次の手順を実行します。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。

- Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.2.0_soa_generic.jar)

- Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.2.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)およびOracle B2B (fmw_12.2.1.2_b2b_generic.jar)をダウンロードします。

3. 12c (12.2.1.2)製品ディストリビューションをダウンロードしたディレクトリに移動します。

4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。

9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

14. Infrastructureをインストールしたら、手順3から13までを繰り返してその他の製品ディストリビューションをインストールします。

3.3 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメイン内の既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

- 次の表では、存在する必要があるその他のスキーマを示します。

表3-2 SOAおよびSOA統合製品に必要なスキーマ

アップグレードする内容

存在する必要がある12cスキーマ

SOA Suite (SOA)

Service Table (_STB)

Audit Services (_IAU): 11gから12cへのアップグレードでは、11gソース・ドメインにOracle Platform Services (_OPSS)スキーマがある場合は、このスキーマを作成する必要があります。

注意: Oracle Platform Security Services (_OPSS)が選択されている場合は、必要なAudit Services (_IAU)スキーマ(_IAU_APPENDおよび_IAU_VIEWER)が自動的に選択されます。

既存の11gドメイン内の_OPSSスキーマ(データベースベースのOPSS)、およびファイルベースのAudit Services (_IAU)スキーマがすでに存在する場合は、12cドメインのために新しいAudit Servicesスキーマを作成する必要があります。

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.2)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。

SOAインフラストラクチャ(_SOAINFRA)

Service Table (_STB)

ユーザー・メッセージング(_UMS)

注意: Oracle SOAを実行しなくてもOracle Service Busはインストールできますが、_SOAINFRAスキーマと_STBスキーマを作成する必要があります。

ユーザー・メッセージング・サービス(UMS)

Service Table (_STB)

Audit Services (_IAU)

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、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 ;

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以降です。
JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

3. oracle_common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、選択したコンポーネントに対してRCUでアクションが実行された場合にコールされるのと同じSQL文およびブロックをすべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

表3-3 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

オプション

説明と例

ホスト名

データベースが実行されるサーバーの名前を、次の書式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「標準」またはSYSDBA

表3-4 MySQLデータベースに対する接続資格証明

オプション

説明と例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表3-5 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明と例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL名前付きインスタンス: コンピュータのネットワーク名、およびインストール中に指定したインスタンス名によって特定される、名前付きインスタンス。クライアントは、接続時に、サーバー名とインスタンス名を両方とも指定する必要があります。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表3-6 IBM DB2データベースに対する接続資格証明

オプション

説明と例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

注意: デフォルトでは、Common Infrastructure Services Service Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックし、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

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

アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

- 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

- Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

3.4.1 アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

Upgrade Assistantの準備状況チェックでは、サポート対象となる開始点にある、Fusion MiddlewareスキーマおよびWebLogicドメイン構成について、読取り専用でアップグレード前の確認が実行されます。確認は読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

実際のアップグレードを実行する前に、何回でも準備状況チェックを実行できます。ただし、アップグレードの実行後は、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックの結果と異なる可能性があるためです。

注意:

パフォーマンスに影響を及ぼさないよう、オフピーク時に準備状況チェックを実行することをお薦めします。

3.4.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

Upgrade Assistantで、アップグレード前の環境で準備状況チェックを実行するには、次の手順を実行します。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードが使用可能になるようDISPLAY環境変数が正しく設定されていない場合は、次のエラーが発生する可能性があります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

DISPLAYを設定してもこれらのエラーが発生し続ける場合は、vncconfigなど、他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

3.4.2.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表3-7 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

3.4.3 Upgrade Assistantでの準備状況チェックの実行

Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポート対象となるアップグレード開始点にある、スキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには、次の手順を実行します。

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個々のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードのサポート対象かどうか、またはアップグレードが必要な場所がレポートされます。
このオプションを選択すると、画面名が「選択したスキーマ」に変わります。

- 「ドメイン・ベース」を使用すると、Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレードに適格なすべてのスキーマまたはコンポーネント構成を検出および選択できます。
このオプションを選択すると、画面名が「スキーマおよび構成」に変わります。

Upgrade Assistantですべてのスキーマおよびコンポーネント構成を同時にチェックする場合はデフォルトの選択内容のままにします。そうでない場合は、次の特定のオプションを選択します。

- アップグレード可能なスキーマがあるすべてのコンポーネントを検出および確認するには、「すべてのスキーマのチェックを含める」。

- 管理対象WebLogic Serverドメインのコンポーネント構成を確認するには、「すべての構成のチェックを含める」。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマがあるコンポーネントを選択します。

従属コンポーネントがあるコンポーネントを選択した場合、それらの従属コンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesが自動的に選択されます。

選択したコンポーネントによっては、その他の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します(「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」)。次に、「接続」をクリックします。

警告
Oracleデータベースは、デフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択するようにしてください。正しくないデータベース・タイプを選択したことがわかった場合は、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、Upgrade Assistantを閉じ、正しいデータベース・タイプがすべてのスキーマに確実に適用されるよう、正しいデータベース・タイプを選択した状態で準備状況チェックを再度開始します。

- 「スキーマ・ユーザー名」を選択し、「スキーマ・パスワード」を指定します。

「次」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択内容に基づいて実行された準備状況チェックのサマリーを確認します。
選択内容をレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

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

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには数分かかる可能性があります。
複数のコンポーネントをチェックしている場合は、各コンポーネントの進行状況が、固有の進行状況バーに同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが正常に終了した場合は、「準備状況レポートの表示」をクリックして完了レポートを確認します。準備状況チェックが正常に終了した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認することをお薦めします。レポート内の特定の単語または語句を検索するには、「検索」オプションを使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再度開始します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

3.4.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

準備状況レポート・ファイルのフォーマットは、次のとおりです。

readiness_timestamp.txt

ここでのtimestampは、準備状況チェックが実行された日付と時刻を示します。

準備状況レポートには、次の情報が含まれています。

表3-8 準備状況レポートの要素

レポートの情報

説明

必要な処置

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

処置は必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

処置は必要ありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

処置は必要ありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個々のオブジェクトのテスト・ステータス: FAIL

準備状況チェック・テストで、特定のオブジェクト内に問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個々のオブジェクトのテスト・ステータス: PASS

準備状況チェック・テストで、特定のオブジェクトに問題は検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェック完了ステータス: FAILURE

準備状況チェックで、スキーマ、索引またはデータタイプなどの特定のオブジェクトに、解決が必要な1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の準備状況チェック完了ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

処置は必要ありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAUスキーマの12.1.3.0バージョンを実行しており、それらのスキーマが11gリリース(11.1.1.7以降)または12c (12.1.2.0)からアップグレードされていた場合、準備状況チェックは、次のエラーで失敗する可能性があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポート内の、索引が見つからないというエラーは無視してかまいません。これは既知の問題です。その見つからない索引は、スキーマのアップグレード操作の間に追加されます。このエラーは、アップグレードするスキーマが、12cでRCUを使用して作成されている場合は発生しません。

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

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

手順3: Oracle Identity Managementコンポーネントの停止環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

手順4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

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

パーティション化されていないスキーマをアップグレードする場合は、「Upgrade Assistantを使用したスキーマのアップグレード」で説明されている手順に従ってください。パーティション化されているスキーマをアップグレードする場合は、「パーティション化されているスキーマのアップグレード」で説明されている手順に従ってください。

注意:
必ずスキーマ構成のための手順を選択するようにしてください。パーティション化されたスキーマは、Upgrade Assistantを使用してアップグレードできません。

- 製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

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

3.6.1 製品スキーマのアップグレード

サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

3.6.1.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

3.6.1.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表3-9 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

3.6.1.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

Upgrade Assistantで製品スキーマをアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- アップグレードのために個々のスキーマを選択する必要があり、ドメインで使用されるすべてのスキーマをアップグレードする必要がない場合は、「個別に選択されたスキーマ」。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

- Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレード可能なスキーマがあるすべてのコンポーネントを検出および選択できるようにするには、「ドメインで使用されるすべてのスキーマ」。これは、ドメイン支援スキーマ・アップグレードとも呼ばれます。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、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)がアップグレードに含まれます。

4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. スキーマ資格証明画面で、アップグレードしている各スキーマのデータベース接続詳細を指定します(選択したスキーマに基づいて画面名が変わります)。

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

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

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

注意:
リリース12.1.2.0以降、UCSUMSスキーマについては、コンポーネントIDまたはスキーマ名が変わります。つまり、Upgrade Assistantでは、使用可能なスキーマが自動的に認識されることやドロップダウン・リストに表示されることはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。
11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名として_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

7. Upgrade Assistantで各スキーマを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、スキーマのアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

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

これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合、詳細は、Upgrade Assistantのログ・ファイルを参照してください。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

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 ;

問合せ結果について:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

- STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

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

- IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。

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

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

注意:
この手順は、アップグレード済の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.2の検証スクリプトはアップグレードに対応しており、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 (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

- ドメイン・バージョン

注意:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

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

- アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

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

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

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

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

再構成ウィザードを使用して既存のドメインを変更するには、次の説明に従ってください。ドメインがどのように再構成されるかの一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

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. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションを指定して起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには、次の手順を実行します。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)でサポートされているJDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

「管理対象サーバー」>サーバー・グループのターゲット指定

注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

a. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

b. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー

サーバー・グループ

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

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

- SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

- OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します

- WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

- 12.1.3.0を12.2.1.2にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

3.8 ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

3.8.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

3.8.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表3-10 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

3.8.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 次の画面で、次のことを実行します。

- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。

- 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。

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

3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。

4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

注意:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。

7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

8. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合のみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

4 Oracle Service Bus (Oracle SOA Suiteなし)の11gからのアップグレード

Oracle SOA SuiteおよびBusiness Process Managementを含まないOracle Service Bus 11gをアップグレードする際の、アップグレード固有の作業について説明します。

注意:
Oracle Service BusがSOA 11gまたは以前の12cドメインの一部であり、Oracle Service BusをOracle SOA Suiteの12c (12.2.1.2)へのアップグレードの一環としてアップグレードする場合は、SOA SuiteおよびBusiness Process Managementの11gからのアップグレードまたはOracle SOA SuiteおよびBusiness Process Managementの以前の12cリリースからのアップグレードで説明されている標準アップグレード手順に従ってください。

- Oracle Service Busの12cへのスタンドアロン・アップグレードの理解
Oracle SOA Suiteを含まないOracle Service Bus 11gデプロイメントをアップグレードするには、このプロセス・フローに従います。

- Oracle Service Bus 12c (12.2.1.2)のアップグレードに関する制限事項
Oracle Service Bus 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.2.1.2)にアップグレードできません

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

- Oracle Service Busのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用して、必要な製品ディストリビューションをターゲット・システムにインストールします。Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 12c (12.2.1.2)をインストールする必要があります。

- RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

- サーバーおよびプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンする必要があります。

- Oracle Service Busドメイン(SOAなし)のアップグレード

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

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

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

4.1 Oracle Service Busの12cへのスタンドアロン・アップグレードの理解

Oracle SOA Suiteを含まないOracle Service Bus 11gデプロイメントをアップグレードするには、このプロセス・フローに従います。

Oracle Service Bus (OSB)は、Oracle SOA SuiteおよびBusiness Process Managementの有無にかかわらず12c (12.2.1.2)にアップグレードできます。このトピック内のアップグレード手順では、SOAを含まないOracle Service Busのアップグレード方法について説明します。

Oracle Service BusがSOA 11gまたは以前の12cドメインに含まれており、Oracle SOA Suiteの12c (12.2.1.2)へのアップグレードの一部としてOracle Service Busをアップグレードする場合は、「SOA SuiteおよびBusiness Process Managementの11gからのアップグレード」で説明している標準アップグレード・プロセスに従います。

注意:
ドメインにSOAが含まれていない場合でも、Oracle Service Busメタデータをアップグレードするために、_SOAINFRAスキーマをアップグレードする必要があります。Oracle Service Busには別個のスキーマはありません。

タスク

説明

Oracle Web Services Managerがまだデプロイされていない場合は必要となります。
既存の11g環境にOracle Web Services Managerポリシー・マネージャをデプロイします。

Oracle Web Services Manager (OWSM)ポリシー・マネージャがOracle Service Bus 11g環境にデプロイされていない場合は、12cにアップグレードする前に、それを手動でデプロイする必要があります。

必須

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

Oracle Service Bus 12c (12.2.1.2)にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。

必須

既存の環境からすべてのサービス、プロジェクトおよびリソースを削除します。

エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。

必須

12c Oracle Fusion Middleware Infrastructureディストリビューションを新しいOracleホームにインストールします。

12c Infrastructure (Oracle WebLogic ServerおよびJRFコンポーネントを含む)をインストールする必要があります。

必須

Oracle Service Busを新しいOracleホームにインストールします。

Oracle Service Busディストリビューションを入手して、そのコンテンツを新しいOracleホームにインストールします。

必須
リポジトリ作成ユーティリティ(RCU)を実行して、必要な新しいスキーマを作成します。

Service Tableスキーマ(_STB)は、すべてのドメインのための新しい必須スキーマです。11gからアップグレードする場合は、12cにアップグレードする前にこのスキーマを作成する必要があります。
SOAがドメインの一部でない場合でも、Oracle Service Busには、SOAスキーマ(_SOAINFRA)も必要となります。

以前の12cリリースからアップグレードする場合、別のService Tableスキーマは作成しないでください。

必須
すべてのサーバーおよびプロセスを停止します。

アップグレードを開始する前に、すべてのサーバーおよびプロセスを停止する必要があります。

必須

Upgrade Assistantを実行して、必要なスキーマをアップグレードします。

以前の12cリリースからアップグレードする場合は、_SOAINFRAスキーマを12c (12.2.1.2)にアップグレードする必要があります。

必須
再構成ウィザードを実行して、既存のドメインを再構成します。

アップグレード後も既存のドメインを引き続き使用するため、新しいコンポーネントと機能するよう、それを再構成する必要があります。

必須
Upgrade Assistantを実行して、コンポーネント構成を構成します。

Upgrade Assistantをもう一度実行して、新しいドメインで機能するようコンポーネント構成を更新します。

必須

アップグレード後タスクをすべて実行します。

標準の12cアップグレード後タスクと、各自のデプロイメントに該当するOSB固有のアップグレード後タスクをすべて実行します。

4.2 Oracle Service Bus 12c (12.2.1.2)のアップグレードに関する制限事項

Oracle Service Bus 11gのトポロジが単一のドメイン内の複数のコンポーネントで構成されている場合は、12c (12.2.1.2)にアップグレードできません

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

特定のFusion Middlewareコンポーネント(Oracle SOA、Oracle Service Bus (OSB)、Business Activity Monitoring (BAM)など)は、12cでは、ユーザー・メッセージング・サービス(UMS)に対する依存関係があります。単一の12c (12.2.1.2)ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります。

このようなコンポーネントをアップグレードするには、ドメインの再構成時に、各コンポーネントに個別のクラスタを作成する必要があります(クラスタに関する項を参照)。

このようなコンポーネントに対してサポートされるアップグレード・トポロジについては、「クラスタ化トポロジのアップグレード」を参照してください。

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

Oracle Service Busをアップグレードする場合は、アップグレードを開始する前に、次の各タスクを実行する必要があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

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

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

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

4. 以前のリリースからのOracle Service Busリソースの移行

4.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.2.1.2)ではサポートされなくなりました。11gではWebLogicセキュリティ・ポリシーが使用可能であったため、OWSMポリシー・マネージャのデプロイメントとOWSMポリシーの使用はオプションでした。12cではOWSMポリシーのみがサポートされているため、OWSMポリシー・マネージャのデプロイメントが必須になります。

OWSMポリシー・マネージャを手動で11g環境にデプロイする方法の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のWebLogic ServerでのOWSMのインストールに関する項を参照してください。

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

Oracle Service Bus 12c (12.2.1.2)にアップグレードする前に、サービス、プロジェクトおよびリソースを構成JARファイルにエクスポートする必要があります。アップグレード後に、このJARファイルを新しい12c環境にインポートします。

リソースとサービスは、サポート対象の旧リリースから手動でエクスポートできます。「以前のリリースからのOracle Service Busリソースの移行」を参照してください。

詳細は、『Oracle Service Busでのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

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

エクスポートの後、ユーザーが作成したすべてのサービス、プロジェクトおよびリソースを、アップグレード前に削除する必要があります。

Oracle Service Bus Consoleの使用方法の詳細は、プロジェクト、フォルダおよびリソースの削除方法に関する項を参照してください。

JDeveloperを使用したリソースの削除の詳細は、「プロジェクトまたはリソースの削除方法」を参照してください。

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

リソースとサービスは、次の各リリースから手動でエクスポートして、Oracle Service Bus 12c (12.2.1.2)で使用できます。

- Oracle Service Bus 12cリリース12.1.3.0、12.2.1.0および12.2.1.1

- 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でのサービスの開発』のリソースと構成のインポートおよびエクスポートに関する項を参照してください。

4.4 Oracle Service Busのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、必要な製品ディストリビューションをターゲット・システムにインストールします。Oracle Service Busは、Oracle SOA SuiteおよびBusiness Process Managementなしでインストールおよびアップグレードできますが、Oracle Service Busをアップグレードする前には、Oracle Fusion Middleware Infrastructure 12c (12.2.1.2)をインストールする必要があります。

注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

開始する前に、次の点に注意してください。

- Oracle Service Busには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。

- Oracle Service BusでOracle Web Services Managerポリシーを使用する場合、Oracle WebLogicドメインの構成時にいずれかのOracle Service Busドメイン・テンプレートを選択した後、Oracle Web Services Manager拡張テンプレートを選択する必要があります。

Oracle Service Busの必須ディストリビューションをインストールするには、次の手順を実行します。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。

- Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.2.0_infrastructure_generic.jar)

- Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)

3. 12c (12.2.1.2)製品ディストリビューションをダウンロードしたディレクトリに移動します。

4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。

9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

14. Infrastructureをインストールしたら、手順3から11までを繰り返してOracle Service Busディストリビューションをインストールします。

4.5 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでOracle Service Bus (OSB)を実行することもできました。ただし、12cでは、Oracle Service Bus 12c (12.2.1.2)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメイン内の既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- SOA Infrastructureスキーマ(prefix_SOAINFRA)。

- Oracle User Messaging Serviceスキーマ(prefix_UMS)。

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、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 ;

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以降です。
JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

3. oracle_common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、選択したコンポーネントに対してRCUでアクションが実行された場合にコールされるのと同じSQL文およびブロックをすべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

表4-1 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

オプション

説明と例

ホスト名

データベースが実行されるサーバーの名前を、次の書式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「標準」またはSYSDBA

表4-2 MySQLデータベースに対する接続資格証明

オプション

説明と例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表4-3 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明と例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL名前付きインスタンス: コンピュータのネットワーク名、およびインストール中に指定したインスタンス名によって特定される、名前付きインスタンス。クライアントは、接続時に、サーバー名とインスタンス名を両方とも指定する必要があります。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表4-4 IBM DB2データベースに対する接続資格証明

オプション

説明と例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

Oracle Service Busに必要なスキーマを選択します。

注意: デフォルトでは、Common Infrastructure Services Service Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックし、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

4.6 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

手順3: Oracle Identity Managementコンポーネントの停止環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

手順4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

4.7 Oracle Service Busドメイン(SOAなし)のアップグレード

Oracle Service Busスキーマはありませんが、Oracle Service Busのデータベース・スキーマのデータは、SOAINFRAスキーマに組み込まれています。そのため、Oracle Service Busをアップグレードするには、SOAINFRAスキーマをアップグレードする必要があります。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

4.7.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

4.7.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表4-5 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

4.8 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

- ドメイン・バージョン

注意:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

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

- アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

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

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

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインがどのように再構成されるかの一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

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

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

ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。

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

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

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

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

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

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

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

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

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションを指定して起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには、次の手順を実行します。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)でサポートされているJDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

「管理対象サーバー」>サーバー・グループのターゲット指定

注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

a. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

b. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー

サーバー・グループ

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

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

- SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

- OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します

- WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

- 12.1.3.0を12.2.1.2にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

4.9 ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

4.9.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

4.9.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表4-6 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

4.9.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 次の画面で、次のことを実行します。

- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。

- 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。

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

3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。

4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

注意:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。

7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

8. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合のみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

アップグレードが正常に完了したら、次のタスクを1つ以上実行する必要がある場合があります。独自のユース・ケースのシナリオと既存のデプロイメントを調べて、次のタスクが各自の環境に当てはまるかどうかを判断してください。

注意:

Oracle Service Busでアップグレード後の問題が発生した場合は、「Oracle Service Busのトラブルシューティング」で、一般的な解決策の一覧を参照してください。

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

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

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

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

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

4.10.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の構成に関する項を参照してください。

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

アップグレード後に、「Oracle Service Busのアップグレード時のサービス、プロジェクトおよびリソースのエクスポート」でエクスポートしたドメイン構成データをインポートする必要があります。

詳細は、「コンソールで構成JARファイルからリソースをインポートする方法」および構成ファイルの実行に関する項を参照してください。

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

Oracle WebLogic Server管理コンソールを使用して、アップグレード前にエクスポートしたセキュリティ・データを新しいOracle Service Busドメインにインポートします。

詳細は、Oracle WebLogic Server管理コンソールのオンライン・ヘルプでセキュリティ・プロバイダへのデータのインポートに関する項を参照してください。

注意:

セキュリティ情報は、セキュリティ・プロバイダごとに個別にインポートする必要があります。

4.10.4 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リソースのアップグレード方法」を参照してください。

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

12cにはパイプラインまたはプロキシ・サービスから分割-結合コンポーネントを直接呼び出す方法があるため、12cではFusion Middleware 11gの分割-結合ビジネス・サービスはなくなりました。アップグレード・プロセスでは、次のようにして、静的に構成されたすべての呼び出しの参照を自動的に分割-結合ビジネス・サービスに変更します。

- フロー・ビジネス・サービスは削除されます。つまり、フロー・ビジネス・サービス用に構成されたTimeoutプロパティも削除されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが同じプロジェクトに配置されている場合は、そのプロキシ・サービスに関連付けられたパイプラインにより分割-結合が直接呼び出されます。

- ビジネス・サービスと、それを呼び出すプロキシ・サービスが異なるプロジェクトに配置されている場合は、分割-結合を呼び出すためのローカル プロキシ・サービスが作成されます。このローカル・プロキシ・サービスは、元のプロキシ・サービスから呼び出されます。

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

Oracle Service Busでアップグレード後の問題が発生した場合は、次の内容を確認して、関連する解決方法を適用してください。

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

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

4.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>

4.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を直接入力してみてください。

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

Business Activity Monitoring (BAM)を含むサポートされているOracle SOA Suite 11g環境から、新しく再設計されたOracle BAM 12cを含むSOA 12c (12.2.1.2)環境にアップグレードできます。

注意:
BAM 12cリリースを含む、以前のOracle SOA Suiteからアップグレードする場合、「Business Activity Monitoringを含むOracle SOA Suiteの以前の12cリリースからのアップグレード」を参照してください

- Business Activity Monitoring 12c (12.2.1.2)へのアップグレードの理解
Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

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

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

- Oracle BAMドメインを含むSOAの12cへのアップグレード
Oracle BAMを含むSOA 11gドメインをOracle BAMを含むSOA 12c (12.2.1.2)ドメインにアップグレードするには、この手順を使用します。

- Oracle BAM 12cを含むOracle SOAでのアップグレード後構成タスクの実行
最終的にOracle BAM 12cを含むSOA 12cドメインを実行するには、アップグレード後に追加の構成タスクを実行する必要があります。

- Oracle BAM 12cを含むSOAドメインの拡張
アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。

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

5.1 Business Activity Monitoring 12c (12.2.1.2)へのアップグレードの理解

Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。

注意:

次の各項で説明している手順は、11gからのアップグレードにのみ適用されます。すでにアップグレード済の12cドメインをこの12cリリースにアップグレードする場合、「Oracle SOA SuiteおよびBusiness Process Managementの以前の12cリリースからのアップグレード」で説明されている標準アップグレード手順に従います。

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ドメインを作成し、データ・オブジェクトをインポートしてから、すべてのダッシュボードとアラートを再作成する必要があります。

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

次のフローチャートは、Oracle BAMを含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。

5.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ドメインの完全なバックアップの作成

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

既存のOracle Business Activity Monitoring (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ドメインの拡張」を参照してください。

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

新しいOracle BAM 11gドメインを新しい場所にインストールして構成したら、アップグレード前に、11g Oracle BAM ICommandユーティリティを使用して既存の(旧) Oracle BAM 11gドメインからデータをエクスポートし、そのデータを新しいOracle BAM 11gドメインにインポートする必要があります。

11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。

5.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によるビジネス・アクティビティの監視のインポートに関する項を参照してください。

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

アップグレードが失敗した場合は、バックアップ・バージョンを使用して、アップグレード前の環境全体をリストアする必要があります。アップグレード・プロセスを続行する前に、Oracle BAM 11g環境全体のバックアップ・バージョンを必ず作成してください。バックアップのドメインは、「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成した新しいOracle BAM 11gドメインとは異なります。

詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。

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

Oracle BAMを含むSOA 11gドメインを、Oracle BAMを含むSOA 12c (12.2.1.2)ドメインにアップグレードするには、この手順を使用します。

これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。

1. Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

2. RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

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

4. サーバーおよびプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンする必要があります。

5. Upgrade Assistantの実行によるスキーマのアップグレード

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

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

5.4.1 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

開始する前に、次の点に注意してください。

- 以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、12c (12.2.1.2)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。

- Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、SOAディストリビューションsoa_generic.jarの一部です。

Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには、次の手順を実行します。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。

- Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.2.0_soa_generic.jar)

- Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.2.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)およびOracle B2B (fmw_12.2.1.2_b2b_generic.jar)をダウンロードします。

3. 12c (12.2.1.2)製品ディストリビューションをダウンロードしたディレクトリに移動します。

4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。

9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

14. Infrastructureをインストールしたら、手順3から13までを繰り返してその他の製品ディストリビューションをインストールします。

5.4.2 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでBusiness Activity Monitoring (BAM)を実行することもできました。ただし、12cでは、Business Activity Monitoring 12c (12.2.1.2)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。

注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメイン内の既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

- サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

- Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

- Audit Services(prefix_IAU)

- WebLogic Services (prefix_WLS)。このスキーマは、12cのBAMに必要となります。11gでは、BAMには固有の別個のスキーマはありません。

- Managed File Transfer (prefix_MFT)。このスキーマはリリース12c (12.1.3)で導入されたものであり、MFTがドメインの一部になっている場合にのみ必要です。

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

1. (オプション) 11gからアップグレードし、既存のドメインにどのスキーマが存在しているかを確認するには、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 ;

2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.2)では、動作保証されたJDKは1.8.0_101以降です。
JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。次に例を示します。

- (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101

- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101

$JAVA_HOME/binを$PATHに追加します。

3. oracle_common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/bin

- (Windows) ORACLE_HOME\oracle_common\bin

4. RCUを起動します。

- (UNIX) ./rcu

- (Windows) rcu.bat

5. 「ようこそ」画面で「次へ」をクリックします。

6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、選択したコンポーネントに対してRCUでアクションが実行された場合にコールされるのと同じSQL文およびブロックをすべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次へ」をクリックします。

7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

表5-1 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

オプション

説明と例

ホスト名

データベースが実行されるサーバーの名前を、次の書式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「標準」またはSYSDBA

表5-2 MySQLデータベースに対する接続資格証明

オプション

説明と例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表5-3 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明と例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
MSSQL名前付きインスタンス: コンピュータのネットワーク名、およびインストール中に指定したインスタンス名によって特定される、名前付きインスタンス。クライアントは、接続時に、サーバー名とインスタンス名を両方とも指定する必要があります。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表5-4 IBM DB2データベースに対する接続資格証明

オプション

説明と例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックに成功したら、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

Oracle BAMに必要なスキーマを選択します。

注意: デフォルトでは、Common Infrastructure Services Service Table (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

インストールするコンポーネントの接頭辞とスキーマ名を書き留めます。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。

9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。

10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードを書き留めてください。製品インストールの構成中に必要となります。

11. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックし、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

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

アップグレード・アシスタントで11gスキーマをアップグレードする前に、次のOracle BAM再構成テンプレートの名前を変更する必要があります。そうしないと、アップグレードは失敗します。

この手順を完了する前に、11g Oracle Business Activity Monitoring (BAM)データがエクスポート済になっていることを確認してください。よくわからない場合は、既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポートを参照してください。

テンプレートは、12cのディレクトリ$ORACLE_HOME/soa/common/templates/wlsにあります。

テンプレート名

変更後の名前

oracle.bam.reconfig_template_12.2.1.2.0.jar

oracle.bam.reconfig_template_12.2.1.2.0.jar.old

oracle.bam.reconfig.template_12.2.1.2.0.jar.rename

oracle.bam.reconfig_template_12.2.1.2.0.jar

5.4.4 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

手順3: Oracle Identity Managementコンポーネントの停止環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

手順4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

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

アップグレード・アシスタントを使用したスキーマのアップグレードの、標準の手順に従います。

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のままになります。

- 製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

5.4.5.1 製品スキーマのアップグレード

サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

5.4.5.1.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

5.4.5.1.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表5-5 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

5.4.5.1.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

Upgrade Assistantで製品スキーマをアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- アップグレードのために個々のスキーマを選択する必要があり、ドメインで使用されるすべてのスキーマをアップグレードする必要がない場合は、「個別に選択されたスキーマ」。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

- Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレード可能なスキーマがあるすべてのコンポーネントを検出および選択できるようにするには、「ドメインで使用されるすべてのスキーマ」。これは、ドメイン支援スキーマ・アップグレードとも呼ばれます。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、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)がアップグレードに含まれます。

4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. スキーマ資格証明画面で、アップグレードしている各スキーマのデータベース接続詳細を指定します(選択したスキーマに基づいて画面名が変わります)。

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

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

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

注意:
リリース12.1.2.0以降、UCSUMSスキーマについては、コンポーネントIDまたはスキーマ名が変わります。つまり、Upgrade Assistantでは、使用可能なスキーマが自動的に認識されることやドロップダウン・リストに表示されることはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。
11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名として_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

7. Upgrade Assistantで各スキーマを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、スキーマのアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

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

これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合、詳細は、Upgrade Assistantのログ・ファイルを参照してください。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

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 ;

問合せ結果について:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

- STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

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

- IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。

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

Oracle BAMの再構成テンプレートの名前を変更した後、再構成ウィザードを起動し、説明されている手順に従います。

再構成ウィザードにより、Oracle BAM 11gアプリケーション、ライブラリ、BAMDataSource、BAMJMSSserverおよびBAMJmsSystemResourceがドメインから削除されます。

注意: アップグレード後に、Oracle BAMサーバーおよびクラスタを手動で削除する必要があります(構成後作業「ドメインからのOracle BAMサーバーおよびクラスタの削除」を参照)。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

5.4.6.1 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

- ドメイン・バージョン

注意:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

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

- アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

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

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

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインがどのように再構成されるかの一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

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

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

ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。

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

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

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

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

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

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

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

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

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションを指定して起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには、次の手順を実行します。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)でサポートされているJDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

「管理対象サーバー」>サーバー・グループのターゲット指定

注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

a. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

b. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー

サーバー・グループ

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

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

- SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

- OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します

- WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

- 12.1.3.0を12.2.1.2にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

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

ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。

- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

5.4.7.1 ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

5.4.7.1.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

5.4.7.1.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表5-6 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

5.4.7.1.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 次の画面で、次のことを実行します。

- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。

- 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。

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

3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。

4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

注意:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。

7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

8. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合のみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

最終的に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ドライバを削除する必要があります。

5.5.1 管理(Admin)サーバーの起動

Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

管理コンソールを表示する手順は次のとおりです。

1. ブラウザに次のURLを入力します。

http://hostname:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

ログイン・ページが表示されます。

2. インストール時に指定したユーザー名とパスワード、作成した別の管理ユーザーのユーザー名とパスワードを使用してログインします。

あるいは、管理サーバーや管理対象サーバーなどのターゲットのホームページから、Fusion Middleware Controlの管理コンソールにアクセスすることもできます。

5.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. 「削除」をクリックします。

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

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

1. UMS JMSサーバーから、サブデプロイメントのリソースを削除します。

「UMSJMSSystemResourceの設定」画面で、「サブデプロイメント」タブをクリックします。

2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバーを選択します(次の例では、UMSJMSServer_auto_3)。

3. 「削除」をクリックします。

5.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. 「削除」をクリックします。

5.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

5.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

管理対象サーバーは、次に示す順序で停止する必要があります。

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

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

管理対象サーバーを停止する

ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。
次のスクリプトを使用して、SOA管理対象サーバーを停止します。

- (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)管理対象サーバー

管理サーバーを停止します。

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/stopWebLogic.sh

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

5.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コマンドの概要に関する項を参照してください。

5.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は、ドメイン・テンプレート・ファイルに割り当てられる名前です。

5.5.10 管理サーバーの再起動

残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。

管理サーバーを起動するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。

管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

5.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アダプタの構成に関する項を参照してください。

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

構成後の作業を完了するには、SOA管理対象サーバーを再起動する必要があります。

次のスクリプトでWebLogic Server管理対象サーバーを起動します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

SOAサーバーおよびプロセスを次の順番で起動します。

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

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

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

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

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

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

メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。

新しいドライバは、SOA 12cドメインをOracle BAM 12cテンプレートで拡張した後に作成します。

1. 管理サーバーと、すべての管理対象サーバーがSOAドメインで実行しているときに、「ユーザー・メッセージング・サービス」に移動し、soa_serverに向けてターゲット設定されたusermessagingdriver-mailサービスを選択します。

「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで、「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「ターゲット・ナビゲーション」ペインで、「ユーザー・メッセージング・サービス」の電子メール・ドライバ名を選択します。

3. 「削除」をクリックします。

4. ドメイン内にある別のクラスタにも、このプロセスを繰り返します。

5.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互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)

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

管理対象サーバーを停止する

ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。
次のスクリプトを使用して、SOA管理対象サーバーを停止します。

- (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)管理対象サーバー

管理サーバーを停止します。

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/stopWebLogic.sh

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

5.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環境のアップグレード」の図8-1を参照してください。

構成ウィザードの「拡張構成」画面に進んだら、「管理対象サーバー、クラスタおよびCoherence」を選択して、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項の説明に従い、BAMクラスタを作成します。

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

Oracle BAMサーバーがクラスタで実行されているときに、Fusion Middleware Controlコンソールを使用して、次のタスクを完了します。

1. 「電子メール・ドライバ・プロパティ」 画面に移動します。

「ターゲット・ナビゲーション」ペインで「ユーザー・メッセージング・サービス」を選択し、「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

2. 「作成」をクリックして、新しいUMS電子メール・ドライバを追加します。

3. 次に示すように、「名前」フィールドで新しい電子メール・ドライバの一意の名前を指定します。UMSは、12cドメイン内の各クラスタに対して構成する必要があります。そのため、イメージに示すように「クラスタ」として「構成レベル」のデフォルト選択を維持します。

4. デフォルトの送信者アドレスの使用を選択して、EMAIL:emailid@company.comと入力します。このフィールドには、EMAIL:という接頭辞が必須になります。

5. 「OK」をクリックして、指定したプロパティで新しいドライバを作成します。

5.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に移行すると、一部の情報が変更されます。

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

BAM 11gドメインで使用したダッシュボード、アラート、ビューなどは、BAM 12cドメインで再作成する必要があります。

BAMユーザー・ガイド、Oracle BAMによるビジネス・アクティビティの監視の、次に関する項を参照してください。

- ダッシュボードの作成

- アラートの作成

- パラメータの作成

- ビジネス・ビューの作成と使用

5.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サーバー実行中のプロセス・メトリックを有効化します。

5.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. 「適用」をクリックします。

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

exportTypeは、移行前に決定しておく必要があります。アクティブ・インスタンスの移行が完了して、プロセス分析が有効化されると、後戻りして完了インスタンス・データを移行できなくなってしまいます。

有効なexportTypeの値は、次のとおりです。

- INFLIGHT_WITH_DIMENSION_AND_DEFINITION (デフォルト): アクティブ・インスタンスのファクト・データ・アーカイブのみを移行します

- ALL: すべてのアクティブ・インスタンスと完了インスタンスのファクト・データ・アーカイブを移行します

5.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スター・スキーマへの移行」を参照してください。

5.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スター・スキーマへの移行」を参照してください。

5.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スター・スキーマへの移行」を参照してください。

5.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

5.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スター・スキーマへの移行」を参照してください。

5.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

プロンプトが表示されたらユーザー名とパスワードを入力します。

5.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. 「適用」をクリックします。

5.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へのパブリッシュを有効化します。

5.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. 「適用」をクリックします。

5.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_>>
#************************************

5.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

5.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スター・スキーマへの移行」を参照してください。

5.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 プロセス固有のビューを再作成する

5.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

5.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など)。

5.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(オプション)は、ビューを作成する単一のコンポジットの名前です。

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

この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。

- CFGFWK-60950エラーの解決

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

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

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

5.7.1 CFGFWK-60950エラーの解決

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

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

一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。

すべてのデータ変更内容のロールバック:

1. SOAデータベースでSQLセッションを開きます。

2. SOAINFRAスキーマ・ユーザーとしてログインし、次のスクリプトを実行して、すべてのデータ変更内容をロールバックします。

"<exportDir>/rollBackBPMProcessCubesMigration.sql"

使用しているオペレーティング・システムの推奨事項を確認してください。

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

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

5.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.*にある移行のログを調べます。

5.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プロセス・スター・スキーマへの移行(オプション)」の残りの移行手順を繰り返します。

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

以前の12cリリースからアップグレードする場合、次の手順を使用してこのリリースにアップグレードします。

これらの手順を使用して、既存のSOA SuiteおよびBusiness Process Management 12c (12.1.3、12.2.1または12.2.1.1)ドメインを12c (12.2.1.2)にアップグレードします。

注意:
以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合、12c (12.2.1.2)にアップグレードするには、これらすべての作業を完了する必要があります。12.2.1.2ディストリビューションを同じOracleホームにインストールすることで既存のドメインをアップデートしようとしないでください。12.2.1.2へのドメインのアップグレードは、パッチ・セット・インストールではありません。

- 以前の12cリリースからのアップグレードの理解
以前の12c リリースからのアップグレードには、11gからのアップグレード時に使用される一連の様々なアップグレード手順が含まれますが、まだフル・アップグレードが必要になります。

- Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- サーバーおよびプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンする必要があります。

- 製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

6.1 以前の12cリリースからのアップグレードの理解

以前の12c リリースからのアップグレードには、11gからのアップグレード時に使用される一連の様々なアップグレード手順が含まれますが、まだフル・アップグレードが必要になります。

12.1.2、12.1.3、12.2.1.0または12.2.1.1など、以前の12cリリースからのアップグレード時は、12c (12.2.1.2)に到達するようフル・アップグレードを実行します。

6.2 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

開始する前に、次の点に注意してください。

- 以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、12c (12.2.1.2)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。

- Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、SOAディストリビューションsoa_generic.jarの一部です。

Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには、次の手順を実行します。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。

- Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.2.0_soa_generic.jar)

- Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.2.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)およびOracle B2B (fmw_12.2.1.2_b2b_generic.jar)をダウンロードします。

3. 12c (12.2.1.2)製品ディストリビューションをダウンロードしたディレクトリに移動します。

4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。

9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

14. Infrastructureをインストールしたら、手順3から13までを繰り返してその他の製品ディストリビューションをインストールします。

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

アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

- 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

- Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

6.3.1 アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

Upgrade Assistantの準備状況チェックでは、サポート対象となる開始点にある、Fusion MiddlewareスキーマおよびWebLogicドメイン構成について、読取り専用でアップグレード前の確認が実行されます。確認は読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

実際のアップグレードを実行する前に、何回でも準備状況チェックを実行できます。ただし、アップグレードの実行後は、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックの結果と異なる可能性があるためです。

注意:

パフォーマンスに影響を及ぼさないよう、オフピーク時に準備状況チェックを実行することをお薦めします。

6.3.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

Upgrade Assistantで、アップグレード前の環境で準備状況チェックを実行するには、次の手順を実行します。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードが使用可能になるようDISPLAY環境変数が正しく設定されていない場合は、次のエラーが発生する可能性があります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

DISPLAYを設定してもこれらのエラーが発生し続ける場合は、vncconfigなど、他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

6.3.2.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表6-1 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

6.3.3 Upgrade Assistantでの準備状況チェックの実行

Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポート対象となるアップグレード開始点にある、スキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには、次の手順を実行します。

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個々のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードのサポート対象かどうか、またはアップグレードが必要な場所がレポートされます。
このオプションを選択すると、画面名が「選択したスキーマ」に変わります。

- 「ドメイン・ベース」を使用すると、Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレードに適格なすべてのスキーマまたはコンポーネント構成を検出および選択できます。
このオプションを選択すると、画面名が「スキーマおよび構成」に変わります。

Upgrade Assistantですべてのスキーマおよびコンポーネント構成を同時にチェックする場合はデフォルトの選択内容のままにします。そうでない場合は、次の特定のオプションを選択します。

- アップグレード可能なスキーマがあるすべてのコンポーネントを検出および確認するには、「すべてのスキーマのチェックを含める」。

- 管理対象WebLogic Serverドメインのコンポーネント構成を確認するには、「すべての構成のチェックを含める」。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマがあるコンポーネントを選択します。

従属コンポーネントがあるコンポーネントを選択した場合、それらの従属コンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesが自動的に選択されます。

選択したコンポーネントによっては、その他の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します(「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」)。次に、「接続」をクリックします。

警告
Oracleデータベースは、デフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択するようにしてください。正しくないデータベース・タイプを選択したことがわかった場合は、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、Upgrade Assistantを閉じ、正しいデータベース・タイプがすべてのスキーマに確実に適用されるよう、正しいデータベース・タイプを選択した状態で準備状況チェックを再度開始します。

- 「スキーマ・ユーザー名」を選択し、「スキーマ・パスワード」を指定します。

「次」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択内容に基づいて実行された準備状況チェックのサマリーを確認します。
選択内容をレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

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

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには数分かかる可能性があります。
複数のコンポーネントをチェックしている場合は、各コンポーネントの進行状況が、固有の進行状況バーに同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが正常に終了した場合は、「準備状況レポートの表示」をクリックして完了レポートを確認します。準備状況チェックが正常に終了した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認することをお薦めします。レポート内の特定の単語または語句を検索するには、「検索」オプションを使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再度開始します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

6.3.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

準備状況レポート・ファイルのフォーマットは、次のとおりです。

readiness_timestamp.txt

ここでのtimestampは、準備状況チェックが実行された日付と時刻を示します。

準備状況レポートには、次の情報が含まれています。

表6-2 準備状況レポートの要素

レポートの情報

説明

必要な処置

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

処置は必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

処置は必要ありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

処置は必要ありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個々のオブジェクトのテスト・ステータス: FAIL

準備状況チェック・テストで、特定のオブジェクト内に問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個々のオブジェクトのテスト・ステータス: PASS

準備状況チェック・テストで、特定のオブジェクトに問題は検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェック完了ステータス: FAILURE

準備状況チェックで、スキーマ、索引またはデータタイプなどの特定のオブジェクトに、解決が必要な1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の準備状況チェック完了ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

処置は必要ありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAUスキーマの12.1.3.0バージョンを実行しており、それらのスキーマが11gリリース(11.1.1.7以降)または12c (12.1.2.0)からアップグレードされていた場合、準備状況チェックは、次のエラーで失敗する可能性があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポート内の、索引が見つからないというエラーは無視してかまいません。これは既知の問題です。その見つからない索引は、スキーマのアップグレード操作の間に追加されます。このエラーは、アップグレードするスキーマが、12cでRCUを使用して作成されている場合は発生しません。

6.4 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

手順3: Oracle Identity Managementコンポーネントの停止環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

手順4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

6.5 製品スキーマのアップグレード

サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

6.5.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

6.5.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表6-3 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

6.5.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

Upgrade Assistantで製品スキーマをアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- アップグレードのために個々のスキーマを選択する必要があり、ドメインで使用されるすべてのスキーマをアップグレードする必要がない場合は、「個別に選択されたスキーマ」。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

- Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレード可能なスキーマがあるすべてのコンポーネントを検出および選択できるようにするには、「ドメインで使用されるすべてのスキーマ」。これは、ドメイン支援スキーマ・アップグレードとも呼ばれます。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、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)がアップグレードに含まれます。

4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. スキーマ資格証明画面で、アップグレードしている各スキーマのデータベース接続詳細を指定します(選択したスキーマに基づいて画面名が変わります)。

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

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

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

注意:
リリース12.1.2.0以降、UCSUMSスキーマについては、コンポーネントIDまたはスキーマ名が変わります。つまり、Upgrade Assistantでは、使用可能なスキーマが自動的に認識されることやドロップダウン・リストに表示されることはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。
11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名として_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

7. Upgrade Assistantで各スキーマを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、スキーマのアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

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

これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合、詳細は、Upgrade Assistantのログ・ファイルを参照してください。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

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 ;

問合せ結果について:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

- STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

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

- IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。

6.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

- ドメイン・バージョン

注意:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

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

- アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

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

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

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインがどのように再構成されるかの一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

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

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

ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。

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

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

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

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

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

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

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

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

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションを指定して起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには、次の手順を実行します。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)でサポートされているJDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

「管理対象サーバー」>サーバー・グループのターゲット指定

注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

a. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

b. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー

サーバー・グループ

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

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

- SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

- OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します

- WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

- 12.1.3.0を12.2.1.2にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

6.7 ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

6.7.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

6.7.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表6-4 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

6.7.2 Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.2)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 次の画面で、次のことを実行します。

- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。

- 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。

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

3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。

4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

注意:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。

7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

8. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後の手順がある場合のみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

既存の12cデプロイメントに、Business Activity Monitoring (BAM)を含むSOA Suiteが含まれる場合、12c (12.2.1.2)リリースにアップグレードするには、次の作業を完了する必要があります。

注意:
以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合、12c (12.2.1.2)にアップグレードするには、これらすべての作業を完了する必要があります。12.2.1.2ディストリビューションを同じOracleホームにインストールすることで既存のドメインをアップデートしようとしないでください。12.2.1.2へのドメインの移行は、パッチ・セット・インストールではありません。

- Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

- アップグレード前の準備状況チェックの実行
アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- サーバーおよびプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンする必要があります。

- 製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

- ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

7.1 Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.2)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。

開始する前に、次の点に注意してください。

- 以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、12c (12.2.1.2)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。

- Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、SOAディストリビューションsoa_generic.jarの一部です。

Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには、次の手順を実行します。

1. 12c (12.2.1.2)製品ディストリビューションをインストールするターゲット・システムにサインインします。

2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。

- Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.2.0_infrastructure_generic.jar)

- Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.2.0_soa_generic.jar)

- Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.2.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.2_osb_generic.jar)およびOracle B2B (fmw_12.2.1.2_b2b_generic.jar)をダウンロードします。

3. 12c (12.2.1.2)製品ディストリビューションをダウンロードしたディレクトリに移動します。

4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。

- (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

- (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.0_infrastructure_generic.jar

5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択します。オプションは次のとおりです。

- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。

9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。

12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

14. Infrastructureをインストールしたら、手順3から13までを繰り返してその他の製品ディストリビューションをインストールします。

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

アップグレードに関する潜在的な問題を識別するために、アップグレード・プロセスの開始前に準備状況チェックを実行することをお薦めします。準備状況チェックではアップグレードに関する潜在的なすべての問題を検出できるわけではない可能性があることに注意してください。準備状況チェックで成功とレポートされた場合でも、アップグレードが失敗する可能性があります。

- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

- 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

- Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

- 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

7.2.1 アップグレード前の準備状況チェックの実行について

Upgrade Assistantを-readinessモードで実行することにより、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用してGUIモードで、またはレスポンス・ファイルを使用してサイレント・モードで準備状況チェックを実行できます。

Upgrade Assistantの準備状況チェックでは、サポート対象となる開始点にある、Fusion MiddlewareスキーマおよびWebLogicドメイン構成について、読取り専用でアップグレード前の確認が実行されます。確認は読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。

実際のアップグレードを実行する前に、何回でも準備状況チェックを実行できます。ただし、アップグレードの実行後は、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックの結果と異なる可能性があるためです。

注意:

パフォーマンスに影響を及ぼさないよう、オフピーク時に準備状況チェックを実行することをお薦めします。

7.2.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

Upgrade Assistantで、アップグレード前の環境で準備状況チェックを実行するには、次の手順を実行します。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua -readiness

- (Windows) ua.bat -readiness

注意:
GUIモードが使用可能になるようDISPLAY環境変数が正しく設定されていない場合は、次のエラーが発生する可能性があります。

Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

DISPLAYを設定してもこれらのエラーが発生し続ける場合は、vncconfigなど、他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数がまだ正しく設定されていない可能性があります。

コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

7.2.2.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表7-1 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

7.2.3 Upgrade Assistantでの準備状況チェックの実行

Upgrade Assistantで複数の画面をナビゲートし、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポート対象となるアップグレード開始点にある、スキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには、次の手順を実行します。

1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。

2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。

- 「個別に選択されたスキーマ」を使用すると、アップグレード前の確認のために個々のスキーマを選択できます。準備状況チェックにより、スキーマがアップグレードのサポート対象かどうか、またはアップグレードが必要な場所がレポートされます。
このオプションを選択すると、画面名が「選択したスキーマ」に変わります。

- 「ドメイン・ベース」を使用すると、Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレードに適格なすべてのスキーマまたはコンポーネント構成を検出および選択できます。
このオプションを選択すると、画面名が「スキーマおよび構成」に変わります。

Upgrade Assistantですべてのスキーマおよびコンポーネント構成を同時にチェックする場合はデフォルトの選択内容のままにします。そうでない場合は、次の特定のオプションを選択します。

- アップグレード可能なスキーマがあるすべてのコンポーネントを検出および確認するには、「すべてのスキーマのチェックを含める」。

- 管理対象WebLogic Serverドメインのコンポーネント構成を確認するには、「すべての構成のチェックを含める」。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、準備状況チェックを実行する、アップグレード可能なスキーマがあるコンポーネントを選択します。

従属コンポーネントがあるコンポーネントを選択した場合、それらの従属コンポーネントは自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択した場合、Oracle Audit Servicesが自動的に選択されます。

選択したコンポーネントによっては、その他の画面が表示される場合があります。たとえば、次のような作業が必要になることがあります。

- ドメイン・ディレクトリを指定します。

- スキーマ資格証明を指定して、選択したスキーマに接続します(「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」)。次に、「接続」をクリックします。

警告
Oracleデータベースは、デフォルトのデータベース・タイプです。続行する前に、正しいデータベース・タイプを選択するようにしてください。正しくないデータベース・タイプを選択したことがわかった場合は、正しいタイプに変更するためにこの画面に戻らないでください。かわりに、Upgrade Assistantを閉じ、正しいデータベース・タイプがすべてのスキーマに確実に適用されるよう、正しいデータベース・タイプを選択した状態で準備状況チェックを再度開始します。

- 「スキーマ・ユーザー名」を選択し、「スキーマ・パスワード」を指定します。

「次」をクリックして準備状況チェックを開始します。

4. 「準備状況サマリー」画面で、選択内容に基づいて実行された準備状況チェックのサマリーを確認します。
選択内容をレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

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

5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには数分かかる可能性があります。
複数のコンポーネントをチェックしている場合は、各コンポーネントの進行状況が、固有の進行状況バーに同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。

6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

- 準備状況チェックが正常に終了した場合は、「準備状況レポートの表示」をクリックして完了レポートを確認します。準備状況チェックが正常に終了した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認することをお薦めします。レポート内の特定の単語または語句を検索するには、「検索」オプションを使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

- 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定および修正してから、準備状況チェックを再度開始します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

7.2.4 準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認して、アップグレードの正常実行のために処置が必要かどうかを判断します。

準備状況レポート・ファイルのフォーマットは、次のとおりです。

readiness_timestamp.txt

ここでのtimestampは、準備状況チェックが実行された日付と時刻を示します。

準備状況レポートには、次の情報が含まれています。

表7-2 準備状況レポートの要素

レポートの情報

説明

必要な処置

全体的な準備状況ステータス: SUCCESSまたはFAILURE

レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。

1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

処置は必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

処置は必要ありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

処置は必要ありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個々のオブジェクトのテスト・ステータス: FAIL

準備状況チェック・テストで、特定のオブジェクト内に問題が検出されました。

失敗した問題がすべて解決されるまではアップグレードしないでください。

個々のオブジェクトのテスト・ステータス: PASS

準備状況チェック・テストで、特定のオブジェクトに問題は検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェック完了ステータス: FAILURE

準備状況チェックで、スキーマ、索引またはデータタイプなどの特定のオブジェクトに、解決が必要な1つ以上のエラーが検出されました。

FAILED問題がすべて解決されるまではアップグレードしないでください。

<オブジェクト>の準備状況チェック完了ステータス: SUCCESS

準備状況チェック・テストによって問題が検出されませんでした。

処置は必要ありません。

準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。

Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
Starting readiness check of Oracle Metadata Services.
Schema User Name: DEV11_MDS
Database Type: Oracle Database
Database Connect String: machinename@yourcompany.com
VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAUスキーマの12.1.3.0バージョンを実行しており、それらのスキーマが11gリリース(11.1.1.7以降)または12c (12.1.2.0)からアップグレードされていた場合、準備状況チェックは、次のエラーで失敗する可能性があります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAIL

注意:
準備状況レポート内の、索引が見つからないというエラーは無視してかまいません。これは既知の問題です。その見つからない索引は、スキーマのアップグレード操作の間に追加されます。このエラーは、アップグレードするスキーマが、12cでRCUを使用して作成されている場合は発生しません。

7.3 サーバーとプロセスの停止

Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。

Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。

注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を停止するには、次の手順に従います。

手順1: システム・コンポーネントの停止

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

どの順序でもシステム・コンポーネントを停止できます。

手順2: 管理対象サーバーの停止

WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。

- (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)管理対象サーバー

手順3: Oracle Identity Managementコンポーネントの停止環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。

- (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

手順4: 管理サーバーの停止

管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

- (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

手順5: ノード・マネージャの停止

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。

7.4 製品スキーマのアップグレード

サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

- Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

- スキーマ・アップグレードの確認
すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

7.4.1 Upgrade Assistantの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

1. oracle_common/upgrade/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin

- (Windows) ORACLE_HOME\oracle_common\upgrade\bin

2. Upgrade Assistantを起動します。

- (UNIX) ./ua

- (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

- アップグレード・アシスタントのパラメータ

7.4.1.1 アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表7-3 Upgrade Assistantコマンド・ライン・パラメータ

パラメータ

必須/オプション

説明

-readiness

準備状況チェックに必要
注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel 属性

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

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

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir 場所

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

UNIXの場合:

ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

Windowsの場合:

ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

オプション

すべてのコマンド・ライン・オプションを表示します。

7.4.2 アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

Upgrade Assistantで製品スキーマをアップグレードするには、次の手順を実行します。

1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

注意:
Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。

2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。

- アップグレードのために個々のスキーマを選択する必要があり、ドメインで使用されるすべてのスキーマをアップグレードする必要がない場合は、「個別に選択されたスキーマ」。

注意:
12c (12.2.1.2)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.2)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

- Upgrade Assistantで、「ドメイン・ディレクトリ」フィールドで指定したドメイン内の、アップグレード可能なスキーマがあるすべてのコンポーネントを検出および選択できるようにするには、「ドメインで使用されるすべてのスキーマ」。これは、ドメイン支援スキーマ・アップグレードとも呼ばれます。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

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

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、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)がアップグレードに含まれます。

4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します

5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. スキーマ資格証明画面で、アップグレードしている各スキーマのデータベース接続詳細を指定します(選択したスキーマに基づいて画面名が変わります)。

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

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

- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

注意:
リリース12.1.2.0以降、UCSUMSスキーマについては、コンポーネントIDまたはスキーマ名が変わります。つまり、Upgrade Assistantでは、使用可能なスキーマが自動的に認識されることやドロップダウン・リストに表示されることはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。
11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名として_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

7. Upgrade Assistantで各スキーマを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、スキーマのアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

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

これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合、詳細は、Upgrade Assistantのログ・ファイルを参照してください。

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

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

10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。

注意:
アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

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

すべてのアップグレード手順が完了したら、schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。

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 ;

問合せ結果について:

- VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。

- STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。

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

- IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。

7.5 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

- ドメイン・バージョン

注意:

ドメイン再構成を開始する前に、次の制限事項に注意してください。

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

- アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。

具体的には、ドメインを再構成すると、次のようになります。

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

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

- 起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインがどのように再構成されるかの一般情報は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

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

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

ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。

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

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

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

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

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

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

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

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

4. oracle_common/common/binディレクトリに移動します。

- (UNIX) ORACLE_HOME/oracle_common/common/bin

- (Windows) ORACLE_HOME\oracle_common\commom\bin

5. 再構成ウィザードを次のロギング・オプションを指定して起動します。

- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL

- (Windows) reconfig.cmd -log=log_file -log_priority=ALL

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

パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

注意:

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

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

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

CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

ドメインを再構成するには、次の手順を実行します。

1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.2)でサポートされているJDKバージョンは、1.8.0_101以降です。「次へ」をクリックします。

注意:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。
注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。

7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。

「拡張構成」>「管理対象サーバー」:
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

「管理対象サーバー」>サーバー・グループのターゲット指定

注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

a. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。

b. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。

コンポーネントとサーバー

サーバー・グループ

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

「拡張構成」>「サーバーのマシンへの割当」

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

「拡張構成」>「サーバーのクラスタへの割当」

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:

- SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します

- OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します

- WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します

- 12.1.3.0を12.2.1.2にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。

8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

注意:
ドメインを再構成しても、その場所は変更されません。

9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをメモします。

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

クラスタ化されたSOA環境へのアップグレード・プロセスと、アップグレード後の構成タスクを実行するプロセスについて説明します。

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

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

- クラスタ化トポロジでの保護されたタスク・フォームの使用
タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。

- 別のホストへのドメイン構成の伝播
アップグレードの成功を確認したら、ここに示す手順を実行して、新しくアップグレードしたファイルをもう一方のホストに伝播します。

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

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

表8-1は、クラスタ化された複数ホストのOracle SOA Suiteサンプル・トポロジ(図8-1)をアップグレードするために必要な手順を示しています。

表8-1 Oracle SOA SuiteおよびBPMクラスタのアップグレード・ロードマップ

タスク

参照先

アップグレード・トポロジを確認して、設定でSOAHOST1およびSOAHOST2を特定します。

「SOAクラスタ・アップグレード・トポロジの理解」を参照

SOAHOST1またはSOAHOST2で実行中の管理サーバー、すべての管理対象サーバーおよびノード・マネージャを停止します。

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

SOAHOST1で、11gデプロイメントの完全アップグレードを実行します。環境に適用するアップグレード後の構成を実行します。

「SOA SuiteおよびBusiness Process Managementの11gからのアップグレード」を参照

関連項目:

Business Activity Monitoring (BAM)がドメインの一部である場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照

Oracle Service Bus (OSB)がドメインの一部である場合は、「Oracle Service Bus (Oracle SOA Suiteなし)の11gからのアップグレード」を参照

アップグレードが成功したら、SOAHOST1のドメイン構成をSOAHOST2に伝播します。

これを行うには、SOAHOST1上のドメインを圧縮し、それをSOAHOST2上の新しいドメイン内で解凍する必要があります。

「別のホストへのドメイン構成の伝播」を参照

SOAHOST1とSOAHOST2で、管理サーバーと管理対象サーバーを再起動します。

「管理サーバーおよびSOA管理対象サーバーの起動」

ご使用の環境のためのその他のアップグレード後構成作業を実行します。

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

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

図8-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環境に適用できます。

このサンプル・トポロジのアップグレードに必要な手順は、次の項の表8-1で説明しています。

注意:

SOAを含むOracle BAMをアップグレードする場合は、「Oracle BAMドメインを含むSOAの12cへのアップグレード」を参照してください。

図8-1 クラスタ化されたSOAのトポロジ

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

タスク・フォームは、Java Server Page XML (.jspx)ファイルです。このファイルは、ヒューマン・タスクが含まれるSOAコンポジットを作成したOracle JDeveloper Designerで作成します。

SOAコンポジットにヒューマン・タスク・フォームが含まれている場合や、タスク・フォームが非SOAサーバーにデプロイされている場合は、アップグレード後にタスク・フォームを保護する必要があります。

8.4 別のホストへのドメイン構成の伝播

アップグレードの成功を確認したら、ここに示す手順を実行して、新しくアップグレードしたファイルをもう一方のホストに伝播します。

SOAHOST1で単一ノードのアップグレードを完了したら、ここに示す手順を実行して、新しくアップグレードしたファイルをもう一方のノード(この例では、セカンダリ・ホストをSOAHOST2と呼びます)に伝播します。

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

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

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

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

次のコマンドを使用して、domainupgradetemplate.jarファイルをSOAHOST2にコピーします。

scp soadomaintemplate.jar company@SOAHOST2:12c_ORACLE_HOME/oracle_common/common/bin

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

8.4.1.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.2)ビットのインストール・ディレクトリ)への実際のパスを表します。

- 11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

- デフォルトでは、domainupgradetemplateは、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template引数の一部としてテンプレートJARファイルのフルパスを指定できます。

ORACLE_COMMON_HOME/common/bin/

packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。

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

管理サーバーと管理対象サーバーが停止していることを確認してから、unpackコマンドを実行して、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用する完全ドメイン(またはドメインのサブセット)を作成します。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。

注意:
既存のドメインの上にドメインを解凍しないようにしてください。ドメイン・アップグレード・テンプレートのjarファイルのコンテンツは、新しいドメイン・ロケーションに解凍することをお薦めします。
ドメインの解凍時に -overwrite_domain=true引数を使用する場合でも、既存ドメインのコンテンツは所定の場所に残り、サーバー起動時に問題が発生します。このため、ドメイン・テンプレートのjarファイルを新しい場所に解凍するか、解凍前に既存の場所のコンテンツを手動で削除することをお薦めします。

サンプルのunpackコマンドのコード・スニペットを次に示します。

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=NEW_DOMAIN_LOCATION

この例では、次のようになります。

- 12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12c (12.2.1.2)のインストール・ディレクトリ)への実際のパスを表します。

- NEW_DOMAIN_LOCATIONを、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。

- domainupgradetemplate.jarは、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。

- domainupgradetemplateは、ドメイン・テンプレート・ファイルに割り当てられる名前です。

8.4.3 unpack後の次の確認手順の完了

1. 11gドメインからのsetDomainEnv.shスクリプトのWL_HOME、SOA_ORACLE_HOME、UMS_ORACLE_HOMEが、12cを指していることを確認します。
「setDomainEnv.shへのカスタマイズの再適用」を参照してください。

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ドメイン・ディレクトリから起動する必要があります。

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

クラスタのアップグレードが正常に完了した後で、追加のアップグレード後構成タスクを実行する必要があります。目的のクラスタ化環境に当てはまるタスクのみを実行してください。

- 管理サーバーおよびSOA管理対象サーバーの起動
Oracle WebLogic管理サーバーおよびその他のSOA管理対象サーバーを再起動します。

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

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

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

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

8.5.1 管理サーバーおよびSOA管理対象サーバーの起動

Oracle WebLogic管理サーバーおよびその他のSOA管理対象サーバーを再起動します。

管理サーバーの起動

管理サーバーを起動するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。

管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

管理対象サーバーを起動します

次のスクリプトでWebLogic Server管理対象サーバーを起動します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

SOAサーバーおよびプロセスを次の順番で起動します。

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

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

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

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

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

8.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クロス・コンポーネント・ワイヤリングの更新」の説明に従ってコンポーネントを再接続する必要があります。

8.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を選択します。

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

SOAクラスタ・ドメインを12.2.1にアップグレードすると、アップグレードしたSOA JMSモジュールにEDNTopicがない場合があります。JMSモジュールにEDNTopicがない場合は、管理コンソールまたはWLSTを使用して、このトピックにトピックまたはUDDを手動で追加する必要があります。

EDNTopicの再適用の詳細は、管理コンソールのオンライン・ヘルプを参照してください。

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

12cクラスタ・ドメインのjmsServerは、移行可能なターゲットに向けてターゲット設定されています。これは、jmsServerが個別のサーバーに向けてターゲット設定されていた、11gのデフォルト動作とは異なります。

JMSトランスポートに基づいて12cプロキシ・サービスを構成するときには、トピック分散モードをOne-Copy-Per-ApplicationまたはOne-Copy-Per-Serverに設定します。重複メッセージを防止するために、クラスタ化環境では互換性モードを使用しないでください。

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

この章では、オープンおよびクローズされたSOAインスタンスを12c (12.2.1)にアップグレードする方法と、アップグレード・プロセスの管理と監視のためのオプションについて説明します。

SOA SuiteおよびBPM 12cの標準アップグレード・プロセスでは、オープンおよびクローズされたSOAインスタンスの自動アップグレード・ソリューションを提供します。閉じているインスタンスのアップグレードは、次の各項で説明する管理スクリプトで監視および管理できます。

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

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

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

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

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

- 管理スクリプトの構成

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

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

- 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での変更内容の理解

12c SOAでは、インスタンスがECIDではなくflowIDを使用して制御されます。アップグレード・アシスタントでインスタンスを11g SOAから12c SOAにアップグレードすると、アップグレードした11gのフロー・インスタンスと新しく作成した12cインスタンスには、いくつかの相違点があります。このような相違点がフロー・トレースの機能性に影響を与えることはありませんが、その相違点に注意することは重要です。

後述するフロー・トレースXMLの例には、次のような相違点が示されています。

- ActionType属性とActionName属性は、新しく12cに導入されたもので、アップグレードした11gインスタンスでは使用できません。

- アップグレードした11gインスタンスの場合、DateとlastUpdatedDateは同じです。

- アップグレードした11gインスタンスの場合、Entry Instance IdのElapsedTimeは0になります。

11gから12cにアップグレードしたインスタンスのフロー・トレースXML:

================================
<audit_trail
ecid="9dd01e5816e19dbc:-33f3b618:140c1ee8b0f:-8000-000000000000317e"
flowId="96102"  flowCorrelationId="null"  activeInstances="0"
date="2013-09-02 00:09:52.133 PDT"  lastUpdatedDate="2013-09-02 00:09:52.156
PDT"  elapsedTime="23">
<entry instanceId="10093" parentInstanceId="-110092" date="2013-09-02
00:09:52.156 PDT" lastUpdatedDate="2013-09-02 00:09:52.156 PDT"
elapsedTime="0" timestamp="1378105792156" state="18" subType="bpel"
type="component">
...
</entry>
</audit_trail>

新しく作成した12cインスタンスのフロー・トレースXML:

====================================
<audit_trail ecid="dfcc3828-d7de-4af8-b94e-474ff830c961-0000069a"  flowId="6"
flowCorrelationId="0000K7z3tBPFCCGpIwt1if1IRXgh00000M"  activeInstances="0"
date="2013-10-28 05:35:12.738 PDT"  lastUpdatedDate="2013-10-28 05:35:12.825
PDT"  elapsedTime="87">
<entry instanceId="13" parentInstanceId="12" date="2013-10-28
05:35:12.749 PDT" lastUpdatedDate="2013-10-28 05:35:12.786 PDT"
elapsedTime="37" timestamp="1382963712749" state="18" actionType="operation"
actionName="process" subType="bpel" type="component">
...
</entry>
</audit_trail>

さらに、BPELで捕捉されたフォルトについて、12cで作成した新しいインスタンスのリカバリ・ステータスは、図9-1に示すようにrecoveredと表示されます。

図9-1 新しい12cインスタンスのフロー・トレース

ただし、BPELで捕捉されたフォルトについて、アップグレードした11gインスタンスのリカバリ・ステータスは、図9-2に示すようにNonrecoverableと表示されます。

注意:
11gのフォルトから渡された情報は、フォルトの状態を正しく識別するのに十分ではありません。これに対処するために、11gから取得された実際のフォルトはすべて、最初はリカバリ不能として識別されます。その後、ダミーのフォルトが作成されて、適切な状態(BPEL_invoke_recovery、Bpel_activity_recovery)に設定されます。

したがって、11gのフォルトがリカバリ不能であるという警告が表示された場合や、そのことに気づいた場合、警告を無視してかまいません。

図9-2 アップグレードした11gインスタンスのフロー・トレース

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

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。12cパージ・スクリプトには、移行対象外のクローズされたインスタンスが含まれています。つまり、アップグレード後、12cパージ・スクリプトの実行をスケジュールすると、移行対象外のクローズされたインスタンスがスクリプトでパージされます。パージ・スクリプトを使用してクローズされたインスタンスを削除すると、アップグレードの全体的なパフォーマンスを向上できます。

注意:

オープン・インスタンスのみをアップグレードすると、中断されたステータス・フローが表示されることがあります。子フローが11gで中断されていると、フローは中断状態になります。

このECIDに関連付けられたすべてのコンポジット・インスタンスは、終了状態を維持します。

自動パージまたはパージ・スクリプトの使用の詳細は、「データベース増分の管理」を参照してください。

注意:

アップグレード・アシスタントのバックグラウンド・ジョブの実行中に、パージ・ジョブを実行するようにスケジュールしないでください。アップグレード・アシスタントの実行中にスクリプトを実行すると、パージまたはアップグレードが失敗することがあります。

Upgrade Assistantの実行中にパージ・スクリプトを実行するように構成すると、ORA-20099: ERROR 11gから12cへのアップグレードが進行中ですというメッセージが表示されます。

パージ・スクリプトの実行中にUAを実行すると、SQLException: ORA-00054: リソース・ビジー。NOWAITが指定されているか、タイムアウトしましたというメッセージが表示されます。

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

アップグレード管理スクリプトは、SOA Suiteのインストールに付属するUpgrade Assistant機能の一部として含まれています。このようなPL/SQLスクリプトは、インスタンスのアップグレード全体に追加的な管理制御を提供します。アップグレードが完了すると、Oracle Enterprise Manager Consoleでインスタンスを表示できるようになります。さらに詳しいアップグレード・プロセスの情報が必要な場合は、追加のレポートおよび構成オプションに対応した管理スクリプトを使用してください。

注意:

管理アップグレード・スクリプトにより、アップグレードに関する詳細情報が示されます。このようなスクリプトにより、インスタンス・アップグレードに対する追加の構成、管理および監視機能が得られます。このようなスクリプトは、独自の要件に基づいて実行するように(または実行しないように)構成できます。

Fusion Middleware Control Consoleを使用してアップグレード・プロセスを管理および監視することもできますが、管理スクリプトを使用するほうが管理オプションが多くなります。

クローズされたインスタンスのアップグレードを監視するためにアップグレード・アシスタントを使用した後には、Report Upgrade Summary(オプション1)スクリプトを実行することをお薦めします。

アップグレードの進行状況の監視にFusion Middleware Controlコンソールを使用する方法の詳細は、「Fusion Middleware Controlによるアップグレード・ステータスの監視」を参照してください。

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

- 管理スクリプトの実行

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

インスタンス・アップグレードを構成、管理および監視するために使用できるスクリプトは複数あります。これらのスクリプトへのアクセスには、soa_upgrade_menu PL/SQLスクリプトを使用できます。

アップグレード・スクリプト・メニューにアクセスするには:

1. SOAホームの/adminディレクトリに移動します。
次に例を示します。

cd  <ORACLE_HOME>/soa/common/sql/soainfra/sql/oracle/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.5.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.6 管理スクリプトの構成

この項では、アップグレード管理スクリプトの構成に必要な手順について説明します。

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

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

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

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

9.6.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.6.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.6.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.6.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.7 アップグレードのセッションとジョブの停止

管理スクリプトを使用すると、実行中のセッションまたはジョブを停止できます。

注意:

実行中のアップグレードジョブを完了前に停止すると、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.8 不完全なアップグレードの再開

インスタンスのアップグレードが停止されている場合は、次に説明するように管理スクリプトを使用して、手動で再開する必要があります。

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.9 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.10 Fusion Middleware Controlによるアップグレード・ステータスの監視

管理スクリプトに加えて、アップグレードの一般的なステータスを表示するには、Oracle Enterprise Manager Fusion Middleware Controlコンソールを使用することもできます。管理スクリプトでは、アップグレード・ジョブを詳細に管理制御できますが、次に示す事項はFusion Middleware Controlコンソールで監視できます。

注意:

アップグレードの際に高度な管理タスク(アップグレードのスケジュールや時間間隔の変更など)を実行する必要がある場合は、「アップグレード管理スクリプトの使用」に記載されている管理スクリプトを使用する必要があります。

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

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

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

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

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

9.10.1 データ移行の完了の確認

Oracle Enterprise Manager Fusion Middleware Controlの「ターゲット・ナビゲーション」ペインで、「SOA」を開いて「soa-infra (soa_server1)」をクリックし、次に示すように、「SOAランタイム・ヘルス」セクションに「データ移行の完了」リンクが表示されていることを確認します。

図9-3 SOAランタイム・ヘルス: データ移行の完了

「データ移行の完了」をクリックして、次のメッセージが表示されることを確認します。

図9-4 移行完了

「OK」をクリックして、「移行完了」ダイアログ・ボックスを閉じます。「SOAランタイム・ヘルス」の移行ステータス・メッセージが表示されます(図9-5)。

図9-5 SOAランタイム・ヘルス: 移行ステータス・メッセージ

「このメッセージを閉じる」をクリックします。次の確認ダイアログが表示されます。

図9-6 データ非表示の確認

「はい」をクリックして、データ移行完了アラートを非表示にします。「SOAランタイム・ヘルス」セクションから、「このメッセージを閉じる」ボタンの表示がなくなります。

「いいえ」をクリックすると、「SOAランタイム・ヘルス」セクションにアラートが表示されたままになります。

9.10.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-7 SOAランタイム・ヘルス: データの移行が完了していません

「データの移行が完了していません」をクリックすると、次のメッセージが表示されます。

図9-8 SOAランタイム・ヘルス: 移行が完了していない場合のステータス・メッセージ

データ移行のステータス:

- アクティブ・インスタンス: アップグレードされたオープン・インスタンスのステータスが示されます。前掲の例では、オープン・インスタンスはアップグレードが完了しています(ステータスは、「完了」になります)。

- 非アクティブ・インスタンス: アップグレードされたクローズ済インスタンスのステータスが示されます。前掲の例では、2013年7月9日より古いクローズ済インスタンスは、まだアップグレードされていません。アップグレードは最新のものから古いものへの順で実行されます。アップグレードが済んでいないインスタンスは、Fusion Middleware Controlのレポートやビューに表示されません。レポートは、5分ごとにリフレッシュできます。

注意:

実行中のアップグレードの詳細なレポートは、Report Upgrade Summaryスクリプト(オプション1)を実行します(「管理スクリプトの実行」を参照)。

すべてのクローズ済インスタンスがアップグレードされると、リンクは「データ移行の完了」に変化します(図9-4を参照)。

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

アップグレードに多数のインスタンス(クローズおよびオープン)の移行が含まれる場合は、Enterprise Managerフロー・トレースのロード時にパフォーマンスの問題が発生することがあります。パフォーマンスの低下を防ぐには、次の手順で説明するように索引を作成します。

1. 管理サーバーと、実行中のすべての管理対象サーバーを停止します。

2. SQLPLUSからSOAINFRAスキーマに接続し、次のコマンドを実行します。

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

3. 管理サーバーおよび管理対象サーバーを再起動します。

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

アップグレード中に失敗した11gインスタンスは、コンポジット・レベルでのみアップグレード後に表示できます。このようなインスタンスは、パーティション・レベルでは表示されません。

このようなインスタンスを表示するには、デプロイ済コンポジットの「フロー・インスタンス」タブに移動します(図9-9を参照)。

図9-9 コンポジット・レベルを使用した、アップグレード時に失敗したインスタンスの表示

注意: 「検索オプション」を使用すると、特定のインスタンス作成時間または作成日の範囲を指定できます。

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

コンポジットが同一のアップグレード前リビジョンで再デプロイされている場合、該当するインスタンスを表示するには、パーティション・レベル(コンポジット・レベルではありません)に移動する必要があります(図9-10を参照)。

ただし、アップグレード後に作成されたインスタンスは、12cのコンポジット・レベルで表示できます。

図9-10 アップグレード前に作成したインスタンスのパーティション・レベルを使用した表示

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

アップグレードが失敗した場合や、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.12 失敗したアップグレードの再試行

エラーを解決したら、次の手順を実行してアップグレードを再開します。

1. upgrade_error_logに表示されたエラー条件を修正します。

2. 「エラーが発生した11gインスタンスのリセット(オプション9)」の説明に従って、upgrade_error_logからエラー・フラグを削除します。これにより、エラーが発生したインスタンスを後続の実行で再発行できるようになります。

3. 「バックグラウンド制御ジョブの有効化と無効化(オプション6)」の説明に従って、バックグラウンド制御ジョブを有効にします。別個のアップグレード実行をトリガーする必要があります。

4. バックグラウンド制御ジョブの繰り返し間隔と継続時間を必要に応じて変更します(「バックグラウンド制御ジョブの実行スケジュールの変更(オプション5)」を参照)。

5. Report Summary Upgradeスクリプト(オプション1)を使用して、アップグレード・ステータスを監視します。レポートのUPGRADE ERROR COUNTセクションに、エラーが0個と示される必要があります。エラーが残っている場合は、問題を解決してから、ここに示した手順を繰り返します。

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

Oracle SOA Suite 12cへのアップグレード後に実行する必要のある可能性があるタスクについて概要を説明します。

注意:

次のものについては、コンポーネント固有の追加のアップグレード後タスクがあります。

Business Activity Monitoring (BAM)については、「Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード」を参照してください

Oracle Service Bus (OSB)については、「Oracle Service Busのアップグレード後タスクの実行」を参照してください

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

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

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

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

次の各タスクは、アップグレード後に実行する必要があります。

- SOAインフラストラクチャの共通プロパティの更新
アップグレードした環境でデータ表示オプションを更新するには、Oracle Enterprise Manager Fusion Middleware Control 12cを使用します。

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

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

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

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

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

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

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

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

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

10.1.1 SOAインフラストラクチャの共通プロパティの更新

アップグレードした環境でデータ表示オプションを更新するには、Oracle Enterprise Manager Fusion Middleware Control 12cを使用します。

Oracle Fusion Middleware 11gからアップグレードしており、インスタンスおよびフォルトの表示を特定の日数までに制限した場合は、アップグレード後にこの設定を更新する必要があります。12cでは、デフォルトの問合せ期間設定は、日単位ではなく時間単位で取得されます。

アップグレード後に問合せ期間設定を更新するには、次の手順を実行します。

1. Fusion Middleware Control 12c管理コンソールにログインします。

http://machinename.mycompany.com:7001/console

2. ナビゲーション・パネルからSOA管理対象サーバー(例: soa_server1)を選択することで、「SOAインフラストラクチャの共通プロパティ」画面に移動します。

3. 次の図に示すように、デフォルト問合せ期間を更新します。

10.1.2 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環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

10.1.3 setDomainEnv.shへのカスタマイズの再適用

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が、新しく構成した12cドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前のsetDomainEnvファイルのバックアップを新しい12cのsetDomainEnvファイルと比較します。相違点がある場合は、新しいsetDomainEnvファイルに同様の変更を加えます。

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

アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。

たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。

10.1.5 カスタムのXPathクラスのコピー

アップグレード前の環境でデフォルトのXPathクラスを変更した場合は、アップグレード後に、次の例で示すように、カスタマイズしたXPathクラスを新しい12c Oracleホームにコピーする必要があります。

アップグレード前のバックアップからカスタムXPathクラスをコピーします。クラスは、次のディレクトリにあります。

/11g_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

コピー先は次の12cディレクトリです。

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

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

アップグレード後には、11g環境で使用していたパーティション固有のロールを再作成する必要があります。

既存のアプリケーションに対するパーティションのアプリケーション・ロールは、12cのアップグレード・プロセスでは再作成されません。そのかわりに、次のWLSTスクリプトを使用して、これらのロールを手動で作成する必要があります。

sca_createDefaultPartitionAppRoles partition

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

Business Process Managementメタデータのアップグレードは、Business Process Composer 12c (12.2.1.2)に初めて(アップグレード成功後)ログインすると開始されます。

Business Process Composerの使用の詳細は、Oracle Business Process Composerを使用したビジネス・プロセスの開発を参照してください。

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

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。

監査ストア、監査ポリシーおよびバスストップ・ファイルの管理に使用する主な管理タスクおよびツールの詳細は、Oracle Platform Security Servicesによるアプリケーションの保護の監査データ・ストアの管理を参照してください。

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

Oracleリリース11gからリリース12gにアップグレードすると、ServerSocketを作成する際の動作が変更されます。このため、hostnameがlocalhostとして構成されていると、リモート・クライアントはServerSocketに接続できなくなる可能性があります。回避策として、localhostをhostnameに変更してください。

10.1.10 SOA 12cのスレッドの再構成

Oracle SOA Suite 12c (12.2.1.2)以降は、ワーク・マネージャで、ほとんどのSOA関連ワーク・スレッドが処理されるようになりました。SOA 11gに指定したスレッドの構成は、アップグレードしたSOA 12c環境には適用されません。SOA 12cへのアップグレード後に、スレッドを再構成する必要があります。

新しいスレッド・モデルの使用方法の詳細は、『パフォーマンス・チューニング』のSOAインフラストラクチャのチューニングに関する項を参照してください。

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

アップグレードが正常に終了したら、次のタスクを実行して、コンポーネントが引き続き期待どおりに機能していることと、新しいデプロイメントに問題がないことを確認する必要があります。

- サーバーおよびプロセスの起動
アップグレードが正常に終了したら、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

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

10.2.1 サーバーおよびプロセスの起動

アップグレードが正常に終了したら、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

それらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:
この項内の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーおよびプロセスを起動する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。

Fusion Middleware環境を起動するには、次の手順に従います。

ステップ1: 管理サーバーの起動

管理サーバーを起動するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。

管理サーバーを起動するには、startWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

ステップ2: ノード・マネージャの起動

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

- (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementコンポーネントの起動環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを起動します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーの起動

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

- (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

SOAサーバーおよびプロセスを次の順番で起動します。

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

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

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

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

注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

ステップ5: システム・コンポーネントの起動

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

- (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

- (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

どの順序でもシステム・コンポーネントを起動できます。

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

ドメイン・コンポーネント構成のアップグレードが成功したことを確認するには、次の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ホームではなく、新しい12c (12.2.1.2)Oracleホームからすべての管理ツールを実行する必要があります。

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

この付録では、失敗したアップグレード、ドメインの再構成やサーバー起動の問題をトラブルシューティングする場合に、共通するいくつかの手順について説明します。

- リリース・ノートの確認

- サーバー起動エラーの解決
アップグレード後に管理サーバーまたは管理対象サーバーが起動しない場合は、起動スクリプト、ファイルおよびクラスに追加したカスタマイズを再適用する必要がある可能性があります。

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

- 12c (12.1.3または12.2.1.0)から12c (12.2.1.2)へのアップグレード中のOWSMデータ・ソース接続の失敗

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

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

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

- Oracle Managed File Transfer (MFT)アップグレードの問題点のトラブルシューティング
Oracle Managed File Transferのアップグレード時にアップグレード・エラーが発生する場合、次のトラブルシューティング・タスクを参照して問題を修正します。

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

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

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

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

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

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

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

- スキーマ・レジストリ内の無効なオブジェクトのトラブルシューティング
アップグレード後のステータスがINVALIDであるスキーマは、状況によりますが、アップグレードの失敗を示している場合があります。

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

リリース・ノートは、既知の問題がアップグレードに影響する可能性があるかどうかを判断するために必ず確認してください。リリース・ノートは、Oracle Fusion Middleware 12c (12.2.1.2)ライブラリ内にあります。

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

アップグレード後に管理サーバーまたは管理対象サーバーが起動しない場合は、起動スクリプト、ファイルおよびクラスに追加したカスタマイズを再適用する必要がある可能性があります。

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からの起動スクリプトまたはドメイン変数の変更内容が、新しく構成された12cドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前の起動スクリプトまたはファイルのバックアップを新しい12cスクリプトおよびファイルと比較します。相違点がある場合は、次の手順で示すように、ファイルを更新します。

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

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

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

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

A.2.1 setDomainEnv.shへのカスタマイズの再適用

サーバーが起動しない場合やAdminModeで起動される場合、その最も可能性の高い原因は、以前の環境からのsetDomainEnv.shの変更内容が、新しく構成した12cドメインに再適用されていないことです。アップグレード・プロセスの間に、起動スクリプトは、最新バージョンに置き換えられます。これらのファイルに変更を加えた場合、新しい起動スクリプトを同じ情報で編集する必要があります。

これが原因かどうかを判断するには、アップグレード前のsetDomainEnvファイルのバックアップを新しい12cのsetDomainEnvファイルと比較します。相違点がある場合は、新しいsetDomainEnvファイルに同様の変更を加えます。

A.2.2 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環境変数から構成されます。さらに、このスクリプトは、独自定義された値をこの環境変数に追加します。

A.2.3 XEngine構成ファイルへのカスタマイズの再適用

アップグレード前に、XEngineの構成ファイル(SeverityConfig.xmlなど)に加えた変更は、ドメインの再構成プロセスで再生成される新しい構成ファイルにより上書きされます。そのため、アップグレード前の構成ファイルで使用していたカスタマイズしたすべての設定を、アップグレード後に再適用する必要があります。

たとえば、アップグレード前のXEngine構成ファイルSeverityConfig.xmlに、SNIPについてのセクションを追加している場合は、それと同じセクションをアップグレード後の新しいSeverityConfig.xmlファイルに追加する必要があります。

A.2.4 カスタムのXPathクラスのコピー

アップグレード前の環境でデフォルトのXPathクラスを変更した場合は、アップグレード後に、次の例で示すように、カスタマイズしたXPathクラスを新しい12c Oracleホームにコピーする必要があります。

アップグレード前のバックアップからカスタムXPathクラスをコピーします。クラスは、次のディレクトリにあります。

/11g_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

コピー先は次の12cディレクトリです。

/12c_ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1/classes

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

失敗したアップグレードからのリカバリ方法は、どの時点でエラーが発生したかによって異なります。次の事項を確認して、リカバリの方法を判断してください。

- アップグレード・アシスタントを実行して、_SOAINFRAスキーマをアップグレードしているときにエラーが発生した場合は、スキーマのエラーを修正してから、バッチ・ジョブを再実行する必要があります。
このリカバリ方法は、アップグレード・アシスタントの初回実行時に、スキーマ・オプションを選択した場合にのみ適用します。

- 再構成ウィザードの実行中にエラーが発生した場合は、ソース環境からリストアして、アップグレードを最初からやり直す必要があります。

- アップグレード・アシスタントを実行して、WebLogicコンポーネント構成オプションをアップグレードしているときにエラーが発生した場合は、エラーを修正してからアップグレード・アシスタントを再実行します。アップグレード・アシスタントの2回目の実行時には、バックアップからリストアして、アップグレード・プロセスを最初からやり直す必要ありません。このプロセスは、再入可能です。

- アップグレード・アシスタントを実行してスキーマをアップグレードしているときにエラーが発生した場合、そのエラーがアップグレード・フェーズで発生したときには、バックアップからリストアして、問題を修正した後に最初からアップグレードをやり直す必要があります。ただし、調査フェーズでエラーが発生した場合は、問題を修正してアップグレード・アシスタントを再開できます。アップグレード・フェーズ前に発生したエラーは、再入可能です。

アップグレードのトラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。

注意:

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

BAM固有の問題点の解決に関する詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

A.4 12c (12.1.3または12.2.1.0)から12c (12.2.1.2)へのアップグレード中のOWSMデータ・ソース接続の失敗

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)

12c (12.2.1.2)にアップグレードする場合、Upgrade Assistantは汎用データソース接続を必要とします。調査フェーズの間にこのエラーが検出された場合は、前に戻って問題を修正し、バックアップからリストアすることなく、アップグレードを続行できます。

アップグレードを完了するには、次の手順を実行します。

1. Upgrade Assistantでデータソース画面に戻ります。

2. "mds-owsm"データ・ソースを汎用データ・ソースに変更します。

3. Upgrade Assistantを再起動し、要求されたら「ドメインによって使用されるすべての構成」を選択します。

4. アップグレードに成功したら、"mds-owsm"データ・ソースをマルチDSに戻すことができます。

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

Oracle Business Activity Monitoring (BAM)を含むドメインをアップグレードする場合、追加のBAM固有のトラブルシューティング手順があります。

詳細は、「失敗したOracle BAMアップグレードからのリカバリ」を参照してください。

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

12c (12.2.1.2)にアップグレードした後、アップグレードした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スキーマは含まれません。

SOAPサービスの下位互換性の作成

12.1.3.0から12.2.1.2リリースにアップグレードしており、JDevを使用して古いバージョンでManaged File Transfer固有プロジェクトを作成してある場合は、既存のSOA/SOAPプロジェクトのWSDL定義を、JDevで開いてコンポジットを再デプロイすることで修正する必要があります。

これは、MFTがSOAコンポジットのターゲットである場合に必要になります(SOAのソースである場合ではない)。

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

アップグレード前にEnterprise Manager 11gに構成されたカスタムのトラスト・キーストアがあった場合、OWSMの起動で問題が発生する場合があります。

具体的には、OWSMを実行している11gドメインを12cにアップグレードした後に、OWSMサーバー・ログ(2回目の起動後)に次のエラーが発生した場合、この問題を手動で修正する必要があります。

<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".

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)を使用する際のポリシー・ファイルの更新
Advanced Encryption Standard (AES) 256などの強化された暗号化をアップグレード済環境で使用する予定の場合に行います。アップグレードする前に、最新の必要なポリシー・ファイルをJDKに適用することをお薦めします。

A.10.1 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

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

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

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

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

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

指定されたドメインをアップグレードできないというエラーがUpgrade Assistantから示された場合、このリリースでは、ご使用のドメイン構成がサポートされていません。サポートされている構成およびドメインに関する制限事項の詳細は、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ソケット・アダプタに関する項を参照してください。

A.16 スキーマ・レジストリ内の無効なオブジェクトのトラブルシューティング

アップグレード後のステータスがINVALIDであるスキーマは、状況によりますが、アップグレードの失敗を示している場合があります。

アップグレード後のステータスが「INVALID」と表示されている場合は、スキーマ更新が失敗したことを示している可能性があります。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

例外: IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、スキーマ・バージョン・レジストリ表でINVALIDと表示されますが、失敗を示しているわけではありません。シノニム・オブジェクトは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, 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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network 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)を参照してください。