| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード 12c (12.1.3) E56224-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード 12c (12.1.3) E56224-02 |
|
前 |
次 |
この章では、Oracle Fusion Middleware 11g Application DeveloperインストールをOracle Fusion Middleware 12c (12.1.3) Infrastructureにアップグレードする詳しい手順について説明します。
この章の内容は次のとおりです。
Oracle Fusion Middleware 11g Application DeveloperインストールをOracle Fusion Middleware 12.1.3 Infrastructureにアップグレードする前に、既存の11g環境をバックアップする必要があります。なんらかの理由でアップグレードに失敗した場合、ソース・バックアップからアップグレード・プロセスをやりなおす必要があります。
詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ戦略に関する項を参照してください。
|
注意: アップグレード後、 アップグレード後の設定の保持に関する詳細は、カスタムsetDomainEnv設定のメンテナンス(オプション)を参照してください。 |
新しい12c環境をホストするために使用するデータベースは、サポートされている必要があります。Oracle Fusion Middleware 12c (12.1.3) InfrastructureのOracle Database要件を理解することが重要であり、必要に応じて、Fusion Middlewareのアップグレードを行う前にOracle Fusion Middleware Databaseをアップグレードします。
12c向けのOracle Databaseのアップグレードおよび準備の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』の12c (12.1.3)でのOracle Databaseのアップグレードおよび準備に関する項を参照してください。
各ドメインには、動的に生成されるドメインおよびサーバーの起動スクリプト(setDomainEnv)が含まれます。これらの起動スクリプトは後続のドメイン・アップグレード操作によって上書きされるため、変更しないことをお薦めします。
|
注意: アップグレード前に |
ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加したカスタマイズは、ドメインのアップグレード操作中保持され、PackおよびUnpackコマンドの使用時に、リモート・サーバーに継承されます。
サーバーの起動時に(このファイルが存在する場合)起動シーケンスに組み込まれ、そこに定義されているオーバーライドが有効化されます。このファイルは、domain_home/binディレクトリに格納する必要があります。
ドメイン全体に適用されるカスタマイズされたパラメータをアップグレード後に保持するための、setUserOverridesファイルの作成に関する詳細は、「ドメイン全体に適用されるサーバー・パラメータのカスタマイズ」を参照してください。
|
注意: アップグレード前に |
既存の11g環境でファイルベースのセキュリティ・ストアを使用している場合、アップグレード処理を開始する前に、次のタスクを実行する必要があります。
詳細は、次のタスクを参照してください。
11gのリポジトリ作成ユーティリティを使用して、サポートされているデータベースで新しい11g Oracle Platform Security Services (OPSS)スキーマを作成します。アップグレード時にOPSSを使用して、データベース・ベースのストアへのOPSSの再関連付けが正常に完了した場合、12.1.3 RCUを使用して12.1.3監査(IAU)スキーマを作成できます。
11gスキーマ作成の詳細は、11gリリース1 (11.1.1.7.0)の『Oracle Fusion Middlewareリポジトリ作成ユーティリティ・ユーザーズ・ガイド』のリポジトリ作成ユーティリティの入手と実行に関する項を参照してください。
11gで監査データ・ストアを使用しているかどうかおよび使用している監査データ・ストアのタイプに応じて、IAU 12c (12.1.3)スキーマの作成が必要な場合があります。詳細は、第1.1.2.2項「Infrastructure 12cは特定のデータベース・スキーマを必要とする」を参照してください。
11g環境でファイルベースのセキュリティ・ストアを使用している場合、ファイルベースのストアをデータベースベースのリポジトリおよびOPSSスキーマに再関連付けします。
「新規ドメインの作成」ボックスが選択されていない場合、再関連付け後にWebLogic Serverが起動しません。
アップグレード前に、11g OPSSとIAU (監査)スキーマがデータベース・ベースになるように再関連付けするには、次の操作を行います。
コンソールでJDBCデータ・ソースを構成します:
コンソールにログインし、「サービス」→「データソース」に移動します。
「新規」を選択し、ドロップダウン・メニューから「汎用データ・ソース」を選択します。
新しいデータ・ソースに名前を付けます。
「JNDI名」に入力します。
注意: この名前は、jps-config.xmlファイルでのDBベース・ストアの構成に使用します。また、この値は再関連付けコマンドで使用します。値の例は、OPSSではjdbc/opssDataSource、IAUではjdbc/AuditDBです。
「データベース・タイプ」ドロップダウン・メニューから適切なDBタイプを選択します。
「データベース・ドライバ」プルダウンで、「Oracleのインスタンス接続用ドライバ(Thin)、バージョン: 9.0.1以降」を選択します(これは非XA JDBCドライバです)。
「グローバル・トランザクションのサポート」の選択が解除されていることを確認してください。
「接続プロパティ」領域で、データベース名、ホスト名、ポート、データベース・ユーザー名およびパスワードのデータを入力します。それらの設定を確認して、テストします。
「ターゲット」セクションでは、このデータ・ソースのターゲットとしてドメイン内のすべてのサーバーを指定する必要があります。「終了」をクリックします。
データ・ファイルを再度関連付けます:
データ・ファイルをOPSSスキーマのOPSSと再度関連付けます:
$cd $11g_MW_Home/oracle_common/common/bin $./wlst.sh connect() wls:/jrf_domain/serverConfig> reassociateSecurityStore(domain="jpsconfig", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opssDataSource")
データ・ファイルをIAUスキーマのIAUと再度関連付けます:
$cd $11g_MW_Home/oracle_common/common/bin $./wlst.sh connect() wls:/base_domain/serverConfig> setAuditRepository(switchToDB="true",dataSourceName="jdbc/AuditDB")
すべてのサーバーを再起動します。
Enterprise Manager Fusion Middleware Controlを使用して再関連付けを検証します。
Enterprise Manager Fusion Middleware Controlを使用したOPSS再関連付けの検証:
- Enterprise Manager Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
- その構成の「プロバイダ・タイプ」の表示が「ファイル」ではなくなったことを確認します。
- 表の前述の「プロバイダ・タイプ」フィールドには、エントリ「Oracle Database」が表示されます。
Enterprise Manager Fusion Middleware Controlを使用した監査DB構成の検証:
- Enterprise Manager Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。
- 画面の「監査サービス」セクションの「構成」をクリックし、「OHS11GPS61STdomain」画面にアクセスします。
- JNDIデータ・ソース名が正しいこと、また以前に指定したとおりであることを検証し、データベース接続が「URL」フィールドで指定されていることを確認します。
- DBベースの監査データ・ソースが指定されていない場合は、「データソースJNDI名」の隣にある虫眼鏡のアイコンをクリックして、以前に作成した監査データ・ソースを選択します。
- 前述の各手順で指定した内容とこの画面の詳細が一致していることを確認し、「適用」をクリックします。
|
注意: データ・ソースおよびデータ・ソース・ストア構成にアクセスするデータベース・ユーザーは、OPSSスキーマの所有者と同じである必要があります。 IAUスキーマのアップグレードは、オプションとして指定する必要があります。11gのデフォルトでは、「監査ストア」が構成されていません。「監査ストア」を構成しない場合は、監査ストアの関連付けはスキップできます。 |
12cにアップグレードして、WLSでセキュリティ・ポリシー・ストア用のOIDを使用する場合、デフォルトのSSLモードの変更が必要な場合があります。Oracle Internet Directory 11gでは、SSL相互運用性モードはデフォルトで有効です。ただし、Oracle Internet Directoryは、SSL相互運用性モードが無効であることを前提として、JDKのSSLに完全に準拠しています。
Oracle Internet Directory (OID)における認証なしSSLモードのデフォルト使用は、介在者(MITM)攻撃を受けやすくなるため、本番環境ではお薦めできません。
ただし、認証なしSSLが必要で、WebLogic Serverがクライアントの場合は、アップグレード前に次のシステム・プロパティをweblogic.propertiesファイルに適用する必要があります。
-Dweblogic.security.SSL.AllowAnonymousCipher=true
-Dweblogic.security.SSL.ignoreHostnameVerification=true
|
注意: これらのプロパティを設定することにより、匿名暗号スイートが有効化され、ホスト名の検証チェックなしでクライアント接続が確立されるため、結果的にWLSは介在者攻撃を受けやすくなります。 WLS 12cでOIDを使用する場合は、サーバー認証またはクライアント/サーバーSSL認証の使用を強くお薦めします。 |
ポリシー・セットのサーバー・インスタンス・スコープは、11g (11.1.1.7.0)では非推奨で、12cではサポートされていません。ただし、サーバー・スコープを使用するポリシー・セットがある場合、それらのポリシー・セットは12cへのアップグレード時に無効化されます。したがって、12cへのアップグレード前に、すべての11gポリシー・セットからサーバー・インスタンス・スコープを削除する必要があります。
詳細は、Oracle Fusion Middleware 11gリリース1 (11.1.1.7.0)のドキュメント・ライブラリのWebサービスのためのセキュリティおよび管理者ガイドのポリシー・セットの編集に関する項を参照してください。
アップグレードの際、ご使用の環境向けにカスタマイズされていない事前定義ドキュメントは読取り専用バージョンで置き換えられ、新しい読取り専用の事前定義ドキュメントが追加される点に注意してください。ただし、カスタマイズされた既存の事前定義ドキュメント、およびリポジトリのユーザー作成のカスタム・ポリシーは上書きされません。
最新のポリシーを常にすべて取得できるように、変更した事前定義ドキュメントはクローニングし、ポリシー・アタッチメントは移行することをお薦めします。詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOWSMリポジトリのアップグレードに関する項を参照してください。
12.1.3 Infrastructureを、11gと同じホスト上の新しいOracleホームにインストールします。
|
注意: Oracle Fusion Middleware Infrastructure 12.1.3の構成に、構成ウィザードを使用しないでください。 |
表2-1に示す指示に従い、Oracle Fusion Middleware Infrastructure 12.1.3をインストールします。
表2-1 Oracle Fusion Middleware Infrastructureインストール・ロードマップ
| タスク | 説明 | 詳細 |
|---|---|---|
|
12.1.3のインストール用にシステムを準備します。 |
Infrastructure 12.1.3をインストールする前に、システムおよびネットワークの最小要件が満たされていることを確認します。 |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のシステム環境の確認ロードマップに関する項。 |
|
Infrastructureディストリビューションを入手します。 |
Oracle Fusion Middleware Infrastructureディストリビューション( |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middleware Infrastructureディストリビューションの理解と入手に関する項。 |
|
Infrastructure 12.1.3インストーラを起動します。 |
ダウンロードした場所からInfrastructureインストーラを起動します。 |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のインストール・プログラムの起動に関する項。 |
|
インストーラ画面に従います。 |
インストーラを使用してInfrastructure 12.1.3をインストールします。 |
『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のインストール画面のナビゲートに関する項。 |
11gドメインに、そのドメインに関連付けられたOracle HTTP Serverインスタンスが含まれる場合、次のマシンにOracle HTTP Server 12.1.3をインストールする必要があります。
11g Oracle HTTP Serverインスタンスが実行されているマシン
管理サーバーが実行されているマシン
Oracle HTTP Server 12.1.3のインストールの詳細は、Oracle Fusion Middleware Oracle Fusion Middleware Oracle HTTP Serverのインストールと構成に関するマニュアルのOracle HTTP Serverソフトウェアのインストールに関する項を参照してください。
|
注意: Oracle HTTP Server 12.1.3を構成しないでください。 |
アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。これを行わないと、アップグレードが不完全になったり失敗する場合があります。
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。
Oracle Fusion Middleware環境を停止する手順は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のOracle Fusion Middleware環境の停止に関する項に記載されています。
Upgrade Assistantは、アップグレードできるスキーマを識別します。シングル・セッションのUpgrade Assistantの実行で、複数のスキーマをアップグレードできます。
データベースにスキーマが作成されると、RCUは、schema_version_registryという表を作成して維持します。この表には、バージョン番号、コンポーネント名とID、作成日と変更日およびカスタム接頭辞などのスキーマ情報が含まれています。
どの11gまたは12.1.2スキーマが12.1.3.0.0にアップグレードできるかを判断するには、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレード・アシスタントを使用してアップグレードできるスキーマの識別に関する項を参照してください。
アップグレードする前に、サポートされているデータベースに1つ以上のスキーマをインストールする必要があります。
次のシナリオを検討してください。
11gでデータベースを使用していなかった場合、サポートされているデータベースをインストールして構成し、第1.1.2.2項「Infrastructure 12cは特定のデータベース・スキーマを必要とする」の説明に従って、1つ以上のデータベース・スキーマを作成する必要があります。
Application Developer 11gドメインのスキーマをホストするためにデータベースをすでに使用していた場合は、第2.11項の説明に従い、スキーマ・バージョン・レジストリを使用して、データベースですでに利用可能なOracle Fusion Middleware 11gスキーマのリストを表示します。
スキーマ・バージョン・レジストリに表示されるどのスキーマも作成しないでください(かわりに、後でOracle Fusion Middleware Upgrade Assistantをアップグレード処理で使用して、11gスキーマを12.1.3にアップグレードできます)。
ただし、その場合も、第1.1.2.2項「Infrastructure 12cは特定のデータベース・スキーマを必要とする」の説明に従って必要なスキーマを作成する必要があることに注意してください。
|
注意: リリース12c (12.1.2.0)より、サービス表(_STB)スキーマは、すべてのInfrastructureインストールに必要です。サービス表は、インフラストラクチャをアップグレードするたびに、アップグレードする必要があります。新しいInfrastructureのインストールで、古いバージョンのスキーマは使用できません。 |
次の手順を実行して、必要なスキーマを作成します。
|
注意: 新しい12.1.3スキーマを作成する場合、一意のスキーマ接頭辞を使用するようにしてください。この接頭辞によって、データベースにインストール済またはアップグレード済のスキーマと、Oracle Fusion Middleware 12.1.3専用に作成したものとを区別できます。 |
次の方法によるリポジトリ作成ユーティリティ(RCU)の起動
まだ設定していない場合は、JAVA_HOME変数を設定し、JAVA_HOME/binを$PATHに追加します。
システムのORACLE_HOME/oracle_common/binディレクトリに移動します。
RCUを起動します。
(UNIX) ./rcu
(Windows) .\rcu.bat
RCU画面に従ってInfrastructureアップグレードに必要なスキーマを作成します。
詳細は、『Oracle Fusion Middleware Oracle Fusion Middleware Infrastructureのインストールと構成』のRCU画面でのスキーマの作成に関する項を参照してください。
|
注意: エディションベースの再定義(EBR)を使用すると、1つのデータベース・スキーマの複数のバージョンを同一のデータベースで、同時にサポートできます。再定義のためのサーバーでのエディション作成の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のエディションベースの再定義のためのサーバーでのエディション作成に関する項を参照してください。 |
アップグレード・アシスタントを使用してInfrastructureスキーマをアップグレードするには、この項の手順に従います。
Oracle Fusion Middleware Upgrade Assistantを起動する前に、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のUpgrade Assistantを使用してアップグレードできるスキーマの識別に関する項の手順を使用して、スキーマ・バージョン・レジストリで、既存の11gスキーマのリストを表示します。
『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』に記載されているスキーマは、12.1.3コンポーネントをサポートするために使用できるコンポーネント・スキーマです。このリストから、アップグレードするドメインで使用されるスキーマを特定します。
|
注意: ドメインで、このアップグレードでサポートされていないスキーマが使用されている場合は、ドメインをアップグレードしないでください。サポートされているドメイン構成の詳細は、『Oracle Fusion Middleware相互運用性および互換性の理解』を参照してください。 |
次の手順を実行して、アップグレード・アシスタントを起動します。
ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。
次のコマンドを入力してアップグレード・アシスタントを起動します。
(UNIX) ./ua
(Windows) ua.bat
スキーマのアップグレード時、アップグレード・アシスタントでは表2-2に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。
表2-2 アップグレード・アシスタント画面: スキーマのアップグレード
| 画面 | 説明および必要なアクション |
|---|---|
|
ようこそ |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 |
|
スキーマ |
「スキーマ」を選択します。 |
|
使用可能なコンポーネント |
この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。 |
|
ドメイン・ディレクトリ |
この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。 既存の11g WebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてアップグレードする11gドメイン・ディレクトリを選択します。 |
|
前提条件 |
スキーマ・アップグレードの前提条件が満たされているかどうかを確認します。 |
|
スキーマの選択 |
この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。
アップグレードが必要なスキーマの詳細は、第1.1.2.2項「Infrastructure 12cは特定のデータベース・スキーマを必要とする」を参照してください。 注意:
|
|
調査 |
各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。 |
|
アップグレード・サマリー |
スキーマ・アップグレードのために選択したオプションのサマリーを確認します。 「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。 |
|
アップグレードの進行状況 |
アップグレード処理のステータスを確認します。 「アップグレードの進行状況」ステータス・バーには、完了したアップグレード・プロセスの数が表示されます。残りの時間を特定するわけではありません。 アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。 アップグレードが完了したら「次へ」をクリックします。 |
|
アップグレード成功 |
アップグレードが成功していれば「閉じる」をクリックします。 アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。 |
次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しく更新されていることを検証します。
SELECT comp_id, owner, version, status, upgraded FROM schema_version_registry where version like '12.1.3.%';
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。『Upgrade Assistantによるアップグレード』の表1-1「アップグレードが必要なスキーマ」を参照して、スキーマの更新されたバージョン番号が正しいことを確認します。
問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。
次の問合せを発行して、無効なデータベース・オブジェクトが残っていないことを確認します。
SELECT owner, object_name FROM all_objects WHERE status='INVALID';
この時点で、アップグレードしたスキーマに無効なデータベース・オブジェクトがあってはなりません。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が解決しない場合は、次のスクリプトを実行してサービス・リクエストを提出します。
SQL>@?/rdbms/admin/utlrp.sql
これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。
再構成ウィザードを使用して既存の11gドメインを再構成するには、この項の手順に従います。
次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。
ドメインが存在するシステムにログインします。
コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
次のSQLコマンドを実行して、デフォルト・エディションを設定します。
ALTER DATABASE DEFAULT EDITION = edition_name;
ここで、edition_nameは、デフォルトのデータベース・エディション名の名前です。
次のディレクトリに移動します。
(UNIX) ORACLE_HOME/oracle_common/common/bin
(Windows) ORACLE_HOME\oracle_common\common\bin
ORACLE_HOMEはOracleホーム・ディレクトリです。
次のコマンドを実行します。
(UNIX) ./reconfig.sh -log=log_file (Windows) reconfig.cmd -log=log_file
log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスに置き換えます。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。
|
注意:
*sys-package-mgr*: can't create package cache dir 環境変数
|
再構成ウィザードには、表2-3に示すような一連の画面が表示されます。
選択するオプションによっては、表2-3に示されているすべての画面が表示されない場合もあります。一部の拡張構成では、追加の画面が表示されます。拡張構成の詳細は、オンライン・ヘルプを参照してください。
Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成に記載されている、完全な再構成プロセスを確認します。
表2-3 再構成ウィザードの画面
| 画面 | 説明および必要なアクション |
|---|---|
|
ドメインの選択 |
既存の11gドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。 |
|
再構成セットアップの進行状況 |
再構成テンプレートの適用の進行状況が表示されます。 |
|
ドメイン・モードとJDK |
ドメイン・モードは変更できません。 ドメイン内の使用するJDKを選択するか、「参照」をクリックして、使用するJDKに移動します。 Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。 |
|
JDBCデータ・ソース |
この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。 この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを確認します。 このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。 |
|
JDBCデータ・ソース・テスト |
「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。 このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースのテストに関する項を参照してください。 |
|
データベース構成タイプ |
前の画面でデータ・ソース接続の詳細を指定した場合は、データベース接続の詳細が自動的に入力されます。 この画面で情報が入力されない場合は、「RCUデータ」を選択してデータベース資格証明を指定して、ドメインに含まれているすべての12.1.2スキーマのスキーマ情報を取得します。このオプションを選択した場合、この画面のフィールドはアクティブ化されます。リポジトリ作成ユーティリティ(RCU)のSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。 接続情報を入力した後、「RCU構成の取得」をクリックしてスキーマ情報を取得します。 詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。 |
|
JDBCコンポーネント・スキーマ |
デフォルトでは、前の画面で「RCUデータの取得」を選択し、すべてのスキーマの所有者が同じ場合、スキーマ情報が表示されます。 画面に表示されたスキーマのデータ・ソース設定を変更する場合は、各スキーマ名の横のチェック・ボックスを選択します。画面の上部のフィールドで変更を行うと、下部で選択しているスキーマが更新されます。変更するスキーマのみを選択してください。 注意:
|
|
JDBCコンポーネント・スキーマ・テスト |
前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。 テストの結果は「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。 |
|
ノード・マネージャ |
この画面は、再構成するドメインで、ドメインごとのデフォルトの場所のノード・マネージャが使用されている場合にのみ表示されます。 「既存の構成を移行」を選択して、ドメインごとのデフォルトの場所の場所を指定します。 「Oracle推奨デフォルトの適用」を有効にします。 「ノード・マネージャ資格証明」を指定します。これは、ノード・マネージャを管理するために作成される、新しい「ユーザー」です。ノード・マネージャにより処理されるコンポーネントには、起動時にパスワードが要求されます(OHSを含む)。 注意: WebLogic Server環境の起動および停止にカスタム・スクリプトを使用している場合は、ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。 ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のデフォルトのノード・マネージャの構成に関する項を参照してください。 |
|
拡張構成 |
詳細な構成を実行するすべてのカテゴリ(存在する場合)を選択します。選択した各カテゴリの適切な構成画面が表示され、詳細な構成を実行できます。この画面で項目を選択しない場合は、「構成のサマリ」画面が次に表示されます。 次に表示される画面は、選択するカテゴリに応じて異なります。各画面の詳細は、オンライン・ヘルプを参照してください。 注意: ノード・マネージャが使用可能な場合に選択しないときは、Oracle WebLogic Serverのアップグレードのノード・マネージャ構成の実行に関する項の説明に従って、ノード・マネージャを手動で構成する必要があります。 ノード・マネージャの詳細オプションは、ホストごとのノード・マネージャ構成を使用中のドメインを再構成する場合にのみ使用できます。ドメインごとのノード・マネージャ構成に切り替えることも、すでに存在する既存のノード・マネージャの使用を続行することも可能です。 |
|
構成のサマリー |
続行する前に、ドメイン構成の設定の詳細を確認します。「表示」ドロップダウン・リストからフィルタ・オプションを選択することで、右端のパネルに表示されるアイテムを限定できます。 構成を変更する必要がある場合は、「戻る」をクリックして適切な画面に戻ります。 「再構成」をクリックしてドメインを再構成するか、構成を変更する場合は「戻る」をクリックします。 |
|
再構成の進行状況 |
再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。 |
|
再構成に成功しました |
再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。 |
アップグレード・アシスタントを使用して追加のドメイン・コンポーネント構成(OWSMポリシー・メタデータ構造およびアダプタ構成など)をアップグレードするには、この項の手順に従います。
次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。
ディレクトリをORACLE_HOME/oracle_common/upgrade/bin (UNIXオペレーティング・システムの場合)またはORACLE_HOME\oracle_common\upgrade\bin (Windowsオペレーティング・システムの場合)に変更します。
次のコマンドを入力してアップグレード・アシスタントを起動します。
(UNIX) ./ua
(Windows) .\ua.bat
WebLogicコンポーネント構成のアップグレード時、アップグレード・アシスタントでは表2-4に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。
表2-4 アップグレード・アシスタント画面: WebLogicコンポーネント構成のアップグレード
| 画面 | 説明および必要なアクション |
|---|---|
|
ようこそ |
この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。 「次へ」をクリックして続行します。 |
|
WebLogicコンポーネント |
「WebLogicコンポーネント構成」を選択します。 管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。 「次へ」をクリックします。 |
|
コンポーネント・リスト |
この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。 |
|
前提条件 |
コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。 |
|
UMS構成 |
この画面を使用して、UMS 11g構成ファイルをホストするリモート管理対象サーバーのログイン資格証明を指定します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、アップグレード・アシスタントにより、リモート構成ファイルが自動的にコピーされます。 注意: UAにより管理対象サーバーまたは構成ファイルを特定できない場合は、手動でファイルをコピーしてからアップグレード・アシスタントを再起動する必要があります。詳細は、第2.16.3項「アップグレード・アシスタント: UMS構成ファイルのコピーを参照してください。 |
|
調査 |
各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。 |
|
アップグレード・サマリー |
スキーマ・アップグレードのために選択したオプションのサマリーを確認します。 「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。 |
|
アップグレードの進行状況 |
アップグレード処理のステータスを確認します。 アップグレードが完了したら「次へ」をクリックします。 |
|
アップグレード成功 |
アップグレードが成功していれば「閉じる」をクリックします。 アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。 |
Infrastructureアップグレード時にエラーが発生した場合は、次の項目を参照してください。
|
注意: 大半のFusion Middlewareエラーと同様、調査フェーズで検出されたエラーは修正可能であり、アップグレード・アシスタントの実行を継続できます。しかし、アップグレード・フェーズで発生したエラーは、リストア済のバックアップ・ファイルを使用して修正する必要があり、アップグレード・プロセスは最初からやりなおす必要があります。アップグレード・フェーズでエラーの発生したアップグレードを、再実行しないでください。その環境は不安定だとみなして、アップグレード前の状態にリストアする必要があります。 詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』の一般的なトラブルシューティングのガイドラインに関する項を参照してください。 |
ドメインの再構成時にエラーが発生した場合は、『Oracle WebLogic Serverのアップグレード』のドメインのアップグレード・プロセスに関する重要な注意事項に関する項を参照してください。
アップグレード・アシスタントを実行してWeblogicコンポーネント構成をアップグレードする際に、UMSサーバーに不適切なログイン資格証明を指定した場合、UAのログ・ファイルに次のような例外が記載されます。
[upgrade.UCSUMS.UCSUMS_CONFIGURATION_PLUGIN] [tid: 110] [ecid: 88ab893d-a523-4a83-b5a6-f7b1cf8cb029-00000001,0] [[ com.jcraft.jsch.JSchException: Auth fail
このエラーの解決方法は、エラーが発生した時点に応じて異なります。
調査フェーズ (アップグレード・フェーズの前)でこのエラーが発生した場合: すべての管理対象サーバーおよびディレクトリに対して入力したユーザー名およびパスワードが有効であること、および指定したユーザー名にssh権限があることを確認します。エラーを修正した後、接続を再試行します。
アップグレード・フェーズでエラーが発生した場合、アップグレード操作は正常に行われておらず、バックアップからファイルをリストアして、アップグレードをやりなおす必要があります。要求に従って、適切なログイン資格証明を入力していることを確認してください。
|
注意: アップグレード・フェーズで発生したエラーは非リエントラントであり、エラーを修正してアップグレードを続行することはできません。「アップグレード」をクリックした後でエラーが発生した場合は、アップグレード・プロセスをやりなおす前に、バックアップから環境をリストアする必要があります。 |
アップグレード・アシスタントでUMS構成ファイルの自動コピーに失敗した場合は、UMSをアップグレードする前に、アップグレードを停止して構成ファイルを手動でコピーする必要があります。
|
注意: この手順は、アップグレード・アシスタントで構成ファイルの自動コピーが失敗した場合、または構成ファイルを手動でコピーした場合のみ必要です。 |
この項では、User Messaging Service (UMS)を11gから12cにアップグレードする際にリモートの管理対象サーバー・ノードから管理サーバーにコピーされる、UMS構成ファイルの場所について説明します。必要な前提条件をすべて満たし、必要なログイン情報を指定した場合、リモート構成ファイルは、アップグレード・アシスタントにより自動的にコピーされます。アップグレード・アシスタントによる構成ファイルのコピーに関する詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。
ただし、アップグレード・アシスタントでファイルの場所を特定できない場合は、リモートの管理対象サーバーからアップグレードを実行している管理サーバー上の同じ場所に、構成ファイルをコピーする必要があります。コピーする必要がある構成ファイルには、UMSサーバー構成ファイル(appconfig.xml)、ドライバの構成ファイル(driverconfig.xml)およびユーザー・プリファレンス・ファイル(businessterms.xml)などがあります。これらのファイルは、表2-5に示されているように、各管理対象サーバーの/applicationsフォルダに置かれています。
管理対象サーバーから管理サーバーに構成ファイルを手動でコピーした後、第2.15項「アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード」に記載されている手順に従って、アップグレード・アシスタントを起動しなおす必要があります。
表2-5 構成ファイルの場所
| 構成ファイル | 場所 |
|---|---|
|
UMSサーバー |
<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingserver/configuration/appconfig.xml |
|
ドライバの構成( |
<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingdriver-<DRIVER_NAME>/configuration/driverconfig.xml |
|
ユーザー・プリファレンス( |
<DOMAIN_HOME>/config/fmwconfig/servers/<MANAGED_SERVER_NAME>/applications/usermessagingserver/configuration/businessterms.xml |
|
注意: ドメイン内に複数のドライバがデプロイされている場合は、すべてのドライバの構成ファイルをコピーしていることを確認してください。<DRIVER_NAME>を、ドメインにデプロイされているすべてのドライバ名で置き換えて確認します。 |
Oracle Fusion Middleware 11g Application DeveloperをOracle Fusion Middleware 12.1.3 Infrastructureにアップグレードした後に、第4章「アップグレード後に実行するタスク」の説明に従ってアップグレード後のタスクを完了する必要があります。
