Oracle Identity Manager単一ノード環境のアップグレード

Oracle Identity Managerのアップグレード前のタスクの完了

Oracle Identity Managerをアップグレードする前に、この項で説明しているアップグレード前のタスクを完了します。

SOAコンポジットのアップグレード
開始ポイントがOracle Identity Manager 11.1.1.x.xの場合は、作成したカスタム・コンポジットを手動でアップグレードする必要があります。
MD5アルゴリズムを削除するためのサーバー・ウォレットの更新
OIM 12c (12.2.1.3.0)では、MD5署名アルゴリズムをサポートしないJDK 8を使用します。既存のキーストアに12c (12.2.1.3.0)バイナリをインストールするために使用するJDK8には無効な証明書が含まれている(つまり、無効なアルゴリズムを使用している)場合、キーストアを生成し、DOMAIN_HOME/config/fmwconfigディレクトリに配置する必要があります。
MD5アルゴリズムを削除するためのDBウォレットの更新(SSL有効設定の場合)
12c (12.2.1.3.0)ではMD5アルゴリズムをサポートしないJDK 8が使用されるため、SSL有効設定がある場合は、すべてのDBウォレットを更新し、MD5アルゴリズムをすべて削除します。
メモリー設定の確認
Oracle Identity Managerに関するメモリーの問題を回避するため、要件に従ってメモリー設定が更新されていることを確認します。
SSL有効設定のための非SSLポートのオープン
SSL有効設定と非SSL無効設定がある場合、Oracle Identity Managerのアップグレードを続行する前に、サーバーとデータベースのための非SSLポートをオープンする必要があります。
metadata.marファイルの手動バックアップ

SOAコンポジットのアップグレード

開始ポイントがOracle Identity Manager 11.1.1.x.xの場合は、作成したカスタム・コンポジットを手動でアップグレードする必要があります。

次のステップを実行して、SOAコンポジットをアップグレードします。

JDeveloperでSOAコンポジット・プロジェクトを開きます(Jdeveloper 11.1.1.9.0を使用)。
ApprovalTask.taskファイルをデザイナ・モードで開きます。
「一般」を選択します。
「所有者」をGroup, SYSTEM ADMINISTRATORS, STATICに変更します。
結果の参照を選択します。
「結果ダイアログ」が開きます。
「コメントが必要な結果」を選択します。
「却下」を選択して「OK」をクリックします。
「OK」を再度クリックします。
「通知」を選択します。

「通知」の下の更新アイコンをクリックします。

通知内のすべての古いURLを、11.1.2.3.0の対応する新しいURLに更新します。

次に、通知内容の例を示します:

A <%/task:task/task:payload/task:RequestModel%> request has been assigned to you for approval. <BR><BR>
Request ID: <%/task:task/task:payload/task:RequestID%> <BR>
Request type: <%/task:task/task:payload/task:RequestModel%> <BR>
<BR>
Access this task in the 
<A 
style="text-decoration: none;" href=<%substring-before(/task:task/task:payload/task:url, "/workflowservice/CallbackService")%>/identity/faces/home?tf=approval_details
>
Identity Self Service
</A>
 application or take direct action using the links below. Approvers are required to provide a justification when rejecting the request

「詳細」をクリックします。
「ワークリスト/ワークスペースURLを通知に表示」チェック・ボックスの選択を解除します。
ステップ10の例に示すように、アイデンティティ・アプリケーション内の保留中の承認へのURLを指定します。
コンポジット内にその他のヒューマン・タスクがあれば、それらについてステップ1からステップ12を繰り返し、作業を保存します。
「プロジェクト」を右クリックし、「デプロイ」→「アプリケーション・サーバーにデプロイ」の順に選択します。
リビジョンIDを指定します。
「リビジョンをデフォルトとしてマーク」および「同じリビジョンIDで既存のコンポジットを上書きします。」を選択します。

ノート:
コンポジットは、異なるリビジョンIDでもデプロイできます。この場合、このコンポジットを使用しているすべての承認ポリシーを変更する必要があります。
アプリケーション・サーバー接続がすでに存在している場合はこれを選択して、「次」をクリックします。
アプリケーション・サーバー接続が存在しない場合は、これを作成します。
「次」をクリックします。
「終了」をクリックします。
残りのカスタム・コンポジットで、手順を繰り返します。

MD5アルゴリズムを削除するためのサーバー・ウォレットの更新

OIM 12c (12.2.1.3.0)では、MD5署名アルゴリズムをサポートしないJDK 8を使用します。既存のキーストアに12c (12.2.1.3.0)バイナリをインストールするために使用するJDK8には無効な証明書が含まれている(つまり、無効なアルゴリズムを使用している)場合、キーストアを生成し、DOMAIN_HOME/config/fmwconfigディレクトリに配置する必要があります。

デフォルトのキーストアにMD5アルゴリズムが含まれている場合は、アップグレード準備状況チェックおよびOIM構成アップグレードの調査フェーズが失敗します。

証明書を確認するには、次のようにします。

JAVA_HOME/jre/lib/security/java.securityファイルでjdk.certpath.disabledAlgorithmsプロパティを確認します。
たとえば:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
次のようにして、既存のキーストア内の証明書アルゴリズムを確認します。
1. デフォルトのキーストアDOMAIN_HOME/config/fmwconfig/default-keystore.jksの場合は、JAVA_HOME/jre/binディレクトリから次のコマンドを実行します:
```
./keytool -list -v -keystore DOMAIN_HOME/config/fmwconfig/default-keystore.jks
```
  カスタム・キーストア、つまりDOMAIN_HOME/config/fmwconfig/name_of_custom_storeを使用している場合はJAVA_HOME/jre/binディレクトリから次のコマンドを実行します:
```
./keytool -list -v -keystore DOMAIN_HOME/config/fmwconfig/custom_keystore.jks
```
  このコマンドによって、キーストア・データが表示されます。キーストア・パスワードを、求められたら入力します。
2. 前述のコマンドの出力で、Signature algorithm nameフィールド値を確認します。Signature algorithm nameフィールドの値と、jdk.certpath.disabledAlgorithmsプロパティにMD5アルゴリズムが含まれている場合、アップグレード後、指定されているキーストアは有効ではなくなります。
  アップグレード後、キーストアが有効でなくなると、リクエストのユース・ケース実行中にサーバー・ログに次のエラーが表示され、いずれのリクエストのユース・ケースも成功しません。
```
Caused by: java.security.cert.CertPathValidatorException: Algorithm 
constraints check failed: MD5withRSA 
```

必要に応じて、次のステップで、キーストア内の証明書を有効な署名アルゴリズムを使用する新しい証明書に置き換えます。説明に従ってプレースホルダ値を置き換えます。

表3-2 プレースホルダ値と説明のリスト

プレースホルダ値	説明
temporary_directory	一時キーストアおよびcsrファイルを格納するための書込みアクセス権を持つディレクトリ。たとえば: `/tmp`
cert_req_file_name	証明書署名リクエスト(CSR)のわかりやすいファイル名。たとえば: `xell.csr`
certificate_name	証明書のわかりやすいファイル名。たとえば: `xell.cert`。
key_password	一意の資格証明文字列。(既存のOracleデフォルトと一致する必要があるかどうかは不明。)
keystore_password	更新される既存の11gキーストアの資格証明と一致する資格証明。
key_size	-genkeypairを使用する場合の値は2048で、-keyalgは`RSA`です。
supported_algorithm_name	`jdk.certpath.disabledAlgorithms`リストにない有効な署名アルゴリズム。たとえば: `SHA256withRSA`。
validity_period	組織のセキュリティ要件に応じた有効期間(日数)
valid_name	引用符付き文字列。指定すると、生成される証明書のサブジェクトとして使用されます。そうでない場合は、証明書要求の名前が使われます。たとえば: "CN=IADGovernanceDomain, OU=CustomerOrg, O=Customer, L=City, ST=NY, C=US")

SHA256withRSA署名アルゴリズムを使用してキー・ペアを生成します。

./keytool -genkeypair -alias xell \
              -keypass key_password \
              -keystore /temporary_dir/temp_keystore_name.jks \
              -storepass keystore_password \
              -keyalg supported_algorithm_name \
              -keysize key_size \
              -sigalg supported_algorithm_name \
              -validity validity_period \
              -dname vaild_name

たとえば:

./keytool -genkeypair -alias xell \
              -keypass yourkeypassword \
              -keystore /tmp/default-keystore.jks \
              -storepass yourkeystorepassword \
              -keyalg RSA \
              -keysize 2048 \
              -sigalg SHA256withRSA \
              -validity 3600 \
              -dname "CN=IADGovernanceDomain, OU=CustomerOrg, O=Customer, L=City, ST=NY, C=US"

更新されたキーストアでxellとxeltrustedの両方の別名に使用される証明書を置き換えるために使用されるCSRを生成します。

/keytool -certreq -alias xell \
              -keypass key_password \
              -keyalg RSA \
              -file /tmp/cert_req_file_name.csr \
              -keystore /temporary_dir/temp_keystore_name.jks \
              -storepass keystore_password \
              -storetype jks

たとえば:

./keytool -certreq -alias xell \
              -keypass yourkeypassword \
              -keyalg RSA \
              -file /tmp/xell.csr \
              -keystore /tmp/default-keystore.jks \
              -storepass yourkeystorepassword \
              -storetype jks

xell別名の証明書をエクスポートします。

./keytool -exportcert -alias xell \
              -file /temporary_dir/certificate_name.cer \
              -keystore new_keystore_location/temp_keystore_name.jks \
              -storepass keystore_password \
              -rfc

たとえば:

./keytool -exportcert -alias xell \
              -file /tmp/xell.cer \
              -keystore /tmp/default-keystore.jks \
              -storepass yourkeystorepassword \
              -rfc

xeltrustedとして2番目の別名で同じ証明書をインポートします。新しい別名による同じ証明書の追加を確認するプロンプトが表示されたら、「yes」と回答します。

./keytool -importcert -alias xeltrusted \
              -file /temporary_dir/certificate_name.cer \
              -keystore /temporary_dir/temp_keystore_name.jks \
              -storepass keystore_password

たとえば:

./keytool -importcert -alias xeltrusted \
              -file /tmp/xell.cer \
              -keystore /tmp/default-keystore.jks \
              -storepass yourkeystorepassword

Certificate already exists in keystore under alias <xell>
Do you still want to add it? [no]: yes
Certificate was added to keystore

次のコマンドを実行して、新しく生成されたキーストアを既存のキーストアDOMAIN_HOME/config/fmwconfig/default-keystore.jksにインポートします。

./keytool —importkeystore —srckeystore new_keystore_location/new_keystore_name.jks -destkeystore DOMAIN_HOME/config/fmwconfig/default-keystore.jks -srcstorepass source_keystore_password -deststorepass destination_keystore_password -noprompt

たとえば:

./keytool -importkeystore -srckeystore /tmp/default-keystore.jks -destkeystore DOMAIN_HOME/config/fmwconfig/default-keystore.jks -srcstorepass password -deststorepass password -noprompt

Enterprise Managerコンソールにログインし、oimマップの下のxellという名前のCSFキーを、前述でキーストア内の新しいキーを生成するために使用したパスワードで更新します。前述の例では、使用されたパスワードはpasswordです。
<export file>.certおよび<cert_req>.csrをDOMAIN_HOME/config/fmwconfig/の場所に移動します。
cp /tm/xell.csr DOMAIN_HOME/config/fmwconfig/

cp /tmp/xell.cert DOMAIN_HOME/config/fmwconfig/
複数のDOMAIN_HOMEを持つHA/エンタープライズ・デプロイメント・ガイド・リファレンス・アーキテクチャ・トポロジでは、更新されたファイルを各ホスト上の管理対象サーバーのDOMAIN_HOMEにコピーします。
たとえば:
```
cd ASERVER_DOMAIN_HOME/config/fmwconfig/

scp ./default-keystore.jks ./xell.csr .xlserver.cert OIMHOST1:MSERVER_DOMAIN_HOME/config/fmwconfig/.

scp ./default-keystore.jks ./xell.csr .xlserver.cert OIMHOST2:MSERVER_DOMAIN_HOME/config/fmwconfig/.
```

ノート:

キーツール・コマンドの使用の詳細は、Java Platform、Standard Editionツール・リファレンスのキーツールに関する項を参照してください。
default-keystore.jksまたはカスタム・キーストアに関するこの項で説明している手順には、自己署名証明書が含まれています。CA署名証明書が必要な場合は、同様、つまりCSRを生成し、キーストアに署名証明書をインポートするという標準の手順に従ってください。

OIMでのブートストラップ・プロセス中、default-keystore.jksキーストアは、キーストア・サービス(KSS)のデフォルトで構成されます。カスタム・キーストアの場合は、アップグレードの完了後に指定のカスタム・キーストアをKSSにアップロードします。指定のカスタム・キーストアをKSSにアップグレードした後、サーバーを再起動します。

キーストア・サービス・コマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のOPSSキーストア・サービス・コマンドに関する項を参照してください。

MD5アルゴリズムを削除するためのDBウォレットの更新(SSL有効設定の場合)

12c (12.2.1.3.0)ではMD5アルゴリズムをサポートしないJDK 8が使用されるため、SSL有効設定がある場合は、すべてのDBウォレットを更新し、MD5アルゴリズムをすべて削除します。

ノート:

この手順のこれらすべてのステップは、データベース・サーバーで実行する必要があります。つまり、OIMデータベースがインストールされているサーバー上です。

DBウォレットを更新するには、次のようにします。

次のコマンドを使用して、Oracleウォレットをデフォルトの信頼できる証明書使用して作成します。
./orapki wallet create -wallet <trust_wallet_name> -pwd password

たとえば:
./orapki wallet create -wallet trust_wallet.p12 -pwd password
次のコマンドを使用して、CN=root_test,C=USの識別名(DN)でウォレット内に自己署名証明書を追加します。
./orapki wallet add -wallet trust_wallet_name -dn 'dn_name'-keysize 2048 -sign_alg sha256 -self_signed -validity 3650 -pwd password_of_wallet

たとえば:
./orapki wallet add -wallet trust_wallet.p12 -dn 'CN=root_test,C=US' -keysize 2048 -sign_alg sha256 -self_signed -validity 3650 -pwd password
次のコマンドを使用して、Oracleウォレットから自己署名された信頼できる証明書をエクスポートし、それを使用して他の証明書に署名します。
./orapki wallet export -wallet trust_wallet_name -dn 'dn_name' -cert trust_cert_file_name -pwd password_of_wallet

たとえば:
./orapki wallet export -wallet trust_wallet.p12 -dn 'CN=root_test,C=US' -cert wallet_trusted.cert -pwd password
ユーザー証明書が含まれたOracleウォレットはすでに識別済です。ユーザーのウォレットは、DB_HOME/bin/user_wallet.p12です。このユーザー証明書のDNは、CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=USです。次のコマンドを使用して、既存のユーザー証明書をこのウォレットから削除します。
ここで、DB_HOMEはOIMデータベースがインストールされているサーバーです。

./orapki wallet remove -wallet user_wallet_name -pwd password_of_existing_wallet -dn 'DN_name' -user_cert

たとえば:
./orapki wallet remove -wallet user_wallet.p12 -pwd password -dn ' CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US ' -user_cert
リクエストされた証明書が含まれたOracleウォレットはすでに識別済です。ユーザーのウォレットは、DB_HOME/bin/user_wallet.p12です。このリクエストされた証明書のDNは、CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=USです。次のコマンドを使用して、既存のリクエストされた証明書をこのウォレットから削除します。
./orapki wallet remove -wallet user_wallet_name -dn 'DN_name' —cert_req -pwd password_of_existing_wallet

たとえば:
./orapki wallet remove -wallet user_wallet.p12 -dn 'CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US' -cert_req -pwd password
信頼できる証明書が含まれたOracleウォレットはすでに識別済です。ユーザーのウォレットは、DB_HOME/bin/user_wallet.p12です。この信頼できる証明書のDNは、CN=root_test,C=USです。次のコマンドを使用して、既存の信頼できる証明書をこのウォレットから削除します。
./orapki wallet remove -wallet user_wallet_name -pwd password-of-existing_wallet -dn 'DN_name' -trusted_cert

たとえば:
./orapki wallet remove ¿wallet user_wallet.p12 -pwd password -dn ' CN=root_test,C=US' -trusted_cert
次のコマンドを使用して、CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=USという識別名で、既存のユーザー・ウォレットにユーザー証明書を追加します。
./orapki wallet add -wallet user_wallet_name -dn 'dn_name' -keysize 2048 -sign_alg sha256 -pwd password_of_existing_wallet

たとえば:
./orapki wallet add —wallet user_wallet.p12 -dn 'CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US' -keysize 2048 -sign_alg sha256 -pwd password
次のコマンドを使用して、ユーザー証明書リクエストをファイルにエクスポートします。
./orapki wallet export -wallet user_wallet_name -dn 'dn_name' —request CSR_file_name -pwd password_of_existing_wallet

たとえば:
./orapki wallet export -wallet user_wallet.p12 -dn 'CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US' -request server_creq.csr -pwd password
次のコマンドを使用して、前述で作成した信頼できるウォレットを使用してユーザー証明書リクエストに署名します。
./orapki cert create -wallet trusted_wallet_name-request CSR_file_name -cert user_cert_file_name sign_alg sha256 -pwd password_of_exiting_user_wallet

たとえば:
./orapki cert create -wallet trust_wallet.p12 -request server_creq.csr -cert wallet_user.cert -sign_alg sha256 - validity 3650 -pwd password
次のコマンドを実行して、前述の手順を使用して作成した信頼できる証明書wallet_trusted.certをウォレットに追加します。
./orapki wallet add -wallet user_wallet_name -trusted_cert -cert trust_cert_file_name -pwd password_of_exiting_user_wallet

たとえば:
./orapki wallet add -wallet user_wallet.p12 -trusted_cert -cert wallet_trusted.cert -pwd password
次のコマンドを使用して、署名されたユーザー証明書をOracleウォレットに追加します。
./orapki wallet add -wallet user_wallet -user_cert -cert user_cert_file_name -pwd password_of_exiting_user_wallet

./orapki wallet add ¿wallet user_wallet.p12 -user_cert -cert wallet_user.cert -pwd password
DBの信頼できる証明書をサーバーのキーストアから削除します。次のコマンドを使用して、デモ・アイデンティティおよびデモ信頼の場合はdefault-keystore.jksから削除し、カスタム・アイデンティティおよびカスタム信頼の場合はカスタム信頼キーストアから削除します。
./keytool -delete -alias alias_of_db_cert -keystore custom_trust_store -storepass password-of-existing-trust-keystore

たとえば:
./keytool -delete -alias dbtrusted -keystore DOMAIN_HOME/config/fmwconfig/custom_trust_store.jks -storepass password
次のコマンドを使用して、信頼ウォレットに自己署名されたDB証明書をインポートします。
keytool -import -trustcacerts -alias <alias_of_db_cert> -noprompt -keystore custom_trust_store -file DB_Trust_cert_file —storepass password_of_existing_trust_keystore

たとえば:
keytool -import -trustcacerts -alias dbtrusted -noprompt -keystore DOMAIN_HOME/config/fmwconfig/custom_trust_store.jks -file /DB_HOME/bin/wallet_trusted.cert -storepass password

メモリー設定の確認

Oracle Identity Managerに関するメモリーの問題を回避するため、要件に従ってメモリー設定が更新されていることを確認します。

Linuxで、rootユーザーとして次を実行します:

/etc/security/limits.confまたは/etc/security/limits.dファイルの次のパラメータに対して、指定した値が設定されていることを確認します:
```
FUSION_USER_ACCOUNT soft nofile 32767
FUSION_USER_ACCOUNT hard nofile 327679
```
/etc/ssh/sshd_configファイルで、UsePAMがYesに設定されていることを確認します。
sshdを再起動します。
maxprocの制限を確認し、必要に応じて16384以上に増やします。制限を増やすと、メモリーの問題が発生しなくなります。
次のコマンドを使用して、制限をチェックします:

ulimit -u

16384未満の場合は、次のコマンドを使用して、開いているファイルの制限を増やします:

ulimit -u 16384

ノート:
コマンドulimit -uを再発行すると、制限が正しく設定されたことを確認できます。
再起動時に設定が保持されるようにするには、/etc/security/limits.confファイルまたは /etc/security/limits.dファイルに次の行を追加します:
```
oracle hard nproc 16384
```
ここで、oracleはインストール・ユーザーです。
システムをログアウト(または再起動)し、再度ログインします。

SSL有効設定のための非SSLポートのオープン

SSL有効設定と非SSL無効設定がある場合、Oracle Identity Managerのアップグレードを続行する前に、サーバーとデータベースのための非SSLポートをオープンする必要があります。

サーバーの非SSLポートを有効にするには、次のステップを実行します:

WebLogic Server管理コンソールにログインします。
「環境」 > 「サーバー」をクリックし、必要な管理サーバーを選択します。
「サーバーの設定」ページで、「構成」タブをクリックし、「全般」をクリックします。
「ロックして編集」をクリックします。
「リスニング・ポートの有効化」を選択します。デフォルト・ポートは14000です。
ドメイン内の必要なサーバーごとに、ステップ1からステップ5までを繰り返します。

ノート:

アップグレードの完了後は、必要に応じてこれらの変更を元に戻すことができます。

データベースの場合: データベース・リスナーが、Upgrade Assistantにパラメータとして指定したデータベース・サーバーのTCPポートと同じTCPポートでリスニングしていることを確認します。詳細は、「Oracle Identity Governance DBのSSLの有効化」を参照してください。

`metadata.mar`ファイルの手動バックアップ

新しいOracleホームに12c (12.2.1.3.0)バイナリをインストールしたら、アップグレードの前に12c (12.2.1.3.0)_ORACLE_HOME>/idm/server/apps/oim.ear/metadata.marファイルのバックアップを取得します。

製品ディストリビューションのインストール

アップグレードの開始前に、Oracle Fusion Middleware Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

ノート:

12cバイナリは、以前の11gバイナリとは異なる場所にインストールされます。12cバイナリは、アップグレードの計画停止時間の前にインストールできます。

前述の製品のインストールでは、クイック・インストーラ(fmw_12.2.1.3.0_idmquickstart_generic.jar)を使用する簡易インストール・プロセスを使用することをお薦めします。クイック・インストーラでは、Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.3.0)が一度にインストールされます。

ノート:

冗長なバイナリの場所を使用している場合は、必ず冗長な場所それぞれにソフトウェアをインストールしてください。

『Oracle Identity and Access Managementのインストールおよび構成』のクイック・インストーラを使用したOracle Identity Governanceのインストールに関する項を参照してください。

もう1つのオプションとして、必要な製品ディストリビューション(Infrastructure、Oracle SOA SuiteおよびOracle Identity Manager 12c (12.2.1.3.0))を個別にインストールすることもできます。これを行うには、次のステップを実行します:

ターゲット・システムにサインインします。
Oracle Technical ResourcesまたはOracle Software Delivery Cloudから次のものをターゲット・システムにダウンロードします:
- Oracle Fusion Middlewareインフラストラクチャ (fmw_12.2.1.3.0_infrastructure_generic.jar)
- Oracle SOA Suite (fmw_12.2.1.3.0_soa_generic.jar)
- Oracle Identity Manager (fmw_12.2.1.3.0_idm_generic.jar)
12c (12.2.1.3.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
Oracle Fusion Middleware Infrastructureのインストール・プログラムを開始します。
- (UNIX) JAVA_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
- (Windows) JAVA_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次」をクリックします。

ノート:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次」をクリックします。
「自動更新」画面で、オプションを選択します。
- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。
- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。
- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。
「次」をクリックします。
「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリに関する項を参照してください。
「インストール・タイプ」画面で、次に示す項目を選択します。
- インフラストラクチャの場合は、「Fusion Middlewareインフラストラクチャ」を選択します。
- Oracle SOA Suiteの場合は、「Oracle SOA Suite」を選択します
- Oracle Identity Managerの場合は、「Oracle Identity and Access Management」を選択します
「次」をクリックします。
「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。
「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
Oracle Fusion Middleware Infrastructureのインストール後に、次のコマンドを入力して、製品ディストリビューションのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
Oracle SOA Suite 12c (12.2.1.3.0)をインストールする場合は、次のインストーラを実行します。
- (UNIX) JAVA_HOME/bin/java -jar fmw_12.2.1.3.0_soa_generic.jar
- (Windows) JAVA_HOME\bin\java -jar fmw_12.2.1.3.0_soa_generic.jar
Oracle Identity Manager 12c (12.2.1.3.0)をインストールする場合は、次のインストーラを実行します:
- (UNIX) JAVA_HOME/bin/java -jar fmw_12.2.1.3.0_idm_generic.jar
- (Windows) JAVA_HOME\bin\java -jar fmw_12.2.1.3.0_idm_generic.jar

Oracle Identity Manager 12c (12.2.1.3.0)のインストールの詳細は、『Oracle Identity and Access Managementのインストールおよび構成』のOracle Identity and Access Managementソフトウェアのインストールに関する項を参照してください。

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

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

アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。
準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。
Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

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

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

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

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

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

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

ノート:

パフォーマンスへの影響を避けるため、準備状況チェックはピーク時以外に実行するようにしてください。

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

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

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
ORACLE_HOMEは、12c Oracleホームです。
Upgrade Assistantを起動します。
- (UNIX) ./ua -readiness
- (Windows) ua.bat -readiness
ノート:
DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
```
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified 
```
この問題を解決するには、DISPLAY変数を、有効なX環境が動作しているホストおよびデスクトップに設定する必要があります。

たとえば、デスクトップ6のローカル・ホストでVNC内部のX環境を実行している場合は、DISPLAY=:6を設定します。デスクトップ1のリモート・ホストでXを実行している場合は、これをDISPLAY=remoteHost:1に設定します。
その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

Upgrade Assistantのパラメータ

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

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

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ログイン・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。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`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: 準備状況モードでのUpgrade Assistantの起動

Upgrade Assistantを使用した準備状況チェックの実行

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

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

準備状況チェックを完了するには:

「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次」をクリックします。
「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
  このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。
- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
  このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。
  Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。
  - 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。
  - 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。
「次」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインに存在するコンポーネントのリストを確認してください。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。
選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。
- 管理サーバーのドメイン・ディレクトリを指定します。
  
  必ず、11.1.2.3.0管理者サーバー・ドメイン・ディレクトリを指定します。
- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。アップグレード前の要件の一部として、必要なユーザーをすでに作成しました。「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。
  
  次に、「接続」をクリックします。
  
  ノート:
  Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。
- 「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。
「次」をクリックして、準備状況チェックを開始します。
「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

ノート:
アップグレード・アドバイザのコマンドラインでレスポンス・ファイルを指定してサイレント実行を実行する場合、アップグレード・アドバイザの一部のテストでは、レスポンス・ファイルに格納されている値にかかわらず、ソース・ドメインから直接JDBC URL接続文字列が動的に検索される可能性があります。レスポンス・ファイルのDB接続文字列をなんらかの方法でカスタマイズする必要がある場合でも、レスポンス・ファイルの変更は実行に影響しない可能性があります。これが発生した場合、状況によってはソース・ドメインのデータソースJDBC URLを直接編集する必要があります。

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

「次」をクリックします。
「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。
「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。
- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。
- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックして、ログ・ファイルを確認して問題を特定し、問題を修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

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

readiness_timestamp.txt

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

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

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

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE	レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。	1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。
タイムスタンプ	レポートが生成された日付と時刻です。	必要なアクションはありません。
ログ・ファイルの場所 `ORACLE_HOME/oracle_common/upgrade/logs`	生成されたログ・ファイルのディレクトリの場所です。	必要なアクションはありません。
準備状況レポートの場所 `ORACLE_HOME/oracle_common/upgrade/logs`	生成された準備状況レポートのディレクトリの場所です。	必要なアクションはありません。
チェックされたコンポーネントの名前	チェックに含まれるコンポーネントの名前およびバージョンとステータス。	ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。
チェックされたスキーマの名前	チェックに含まれるスキーマの名前および現在のバージョンとステータス。	スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。
個別のオブジェクトのテスト・ステータス: FAIL	準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。	失敗した問題がすべて解決されるまではアップグレードしないでください。
個別のオブジェクトのテスト・ステータス: PASS	準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。	準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。
<オブジェクト>の準備状況チェックの完了ステータス: FAILURE	準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。	失敗した問題がすべて解決されるまではアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS	準備状況チェック・テストによって問題が検出されませんでした。	必要なアクションはありません。

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

ノート:

次の警告が発生した場合は、パッチ27830741をインストールし、準備状況チェックを再実行して、続行する前にこの警告がなくなったことを確認してください。

[oracle] [WARNING] [] [com.oracle.cie.domain.template.catalog.impl.LocalTemplateCat] [tid: 13] [ecid: 7b6f129a-3761-461b-a64a-fb41fa79c822-00000002,0] Couldn't load [/u01/oracle/products/12c/identity/soa/common/templates/wls/oracle.bpm.jms.reconfig_template_12.2.1.3.0.jar].[[
java.util.MissingResourceException: Not managing namespace: (config).
      at com.oracle.cie.common.util.ResourceBundleManager.getPublishedMessage(ResourceBundleManager.java:249

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.

一部のエラーは、Identity and Access Management製品コンポーネントではなく、Oracle Fusion Middleware Infrastructure製品コンポーネントに関連している場合があります。エラーが発生した場合は、使用可能な回避策について『Oracle Fusion Middleware Infrastructureへのアップグレード』の「Infrastructureアップグレードのトラブルシューティング」を参照してください。

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

ノート:

これは、Oracle Identity Managerには適用されません。

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

ノート:

準備状況レポートの欠落している索引に関するエラーは無視してもかまいません。これは既知の問題です。欠落している索引に対応するものが、スキーマのアップグレード操作時に追加されます。このエラーは、アップグレードするスキーマがRCUを使用して12cで作成されていた場合は発生しません。

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

11gからアップグレードする場合は、必要な12cスキーマを作成する必要があります。SSLが有効な設定ではない場合、Upgrade Assistantを使用して、デフォルトのスキーマ設定を利用してスキーマを作成できます。SSLが有効な設定の場合、リポジトリ作成ユーティリティ(RCU)を使用して、カスタマイズされたスキーマを作成できます。この手順では、RCUを使用したスキーマの作成方法を説明します。Upgrade Assistantを使用したスキーマの作成に関する情報は、アップグレード手順で説明されています。

ノート:

SSL以外の設定の場合は、アップグレード中にUpgrade Assistantによって必要な12cスキーマが作成されるためこのステップは必要ありません。

SSL有効設定の場合は、RCUを実行して必要な12cスキーマを作成する必要があります。

ノート:

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

12cにアップグレードする前に、次のスキーマが存在している必要があります。11gからアップグレードする際、現在どのスキーマが存在しているか不明な場合は、次のステップを参照してドメイン内の既存のスキーマを識別します。これらのスキーマがすでに存在している場合、再作成する必要はありません。

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

ノート:

サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。
Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。Upgrade Assistantの実行中に、OPSSスキーマを選択できます。Upgrade Assistantは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。

ノート:

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

RCUを使用して12cスキーマを作成するには:

(オプション) 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 ;

コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.3.0)では、動作保証されたJDKは1.8.0_131以上です。
JAVA_HOME環境変数が、動作保証されたJDKの場所に設定されていることを確認します。たとえば:
- (UNIX) setenv JAVA_HOME=/home/Oracle/Java/jdk1.8.0_131
- (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_131
Add $JAVA_HOME/bin to $PATH.
oracle_common/binディレクトリに移動します。
- (UNIX) NEW_ORACLE_HOME/oracle_common/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\bin
RCUを起動します。
- (UNIX) ./rcu
- (Windows) rcu.bat
「ようこそ」画面で「次へ」をクリックします。
「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これにより、SQLスクリプトが生成されます。このスクリプトには、RCUが選択されたコンポーネントに対してアクションを実行するときにコールするものと同じSQL文とブロックがすべて含まれています。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。
「次」をクリックします。

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

ノート:

最新のデータベース・バージョンを使用しており、推奨どおりにデータベース・バージョンを検証した場合は、次のポップアップ警告を無視してRCUの実行を続行できます。

選択したデータベースはOracle Fusion Middlewareのこのバージョンで動作保証されているデータベースのサポートされているリストより最近です。動作保証されているデータベースの最新のリストは、Oracle Technology Networkのサポートされているシステム構成を参照してください。

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

オプション	説明および例
ホスト名	データベースが実行されるサーバーの名前を、次の書式で指定します。 `examplehost.exampledomain.com` Oracle RACデータベースの場合は、このフィールドにSCAN名またはいずれかのノード名を指定します。
ポート	データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、`1521`です。
サービス名	データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。 Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。たとえば: `examplehost.exampledomain.com`
ユーザー名	アップグレード・プロセス用に作成されたFMWユーザーを指定するか、データベース用の別のSYSDBAユーザー・アカウントを指定します。Oracle DatabaseのデフォルトのSYSDBAアカウントは`SYS`です。
パスワード	データベース・ユーザーのパスワードを入力します。
ロール	ドロップダウン・リストからデータベース・ユーザーのロールを選択します。「標準」または「SYSDBA」

「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。次のスキーマを選択します。
- SSL有効設定をアップグレードする場合は、次のスキーマを選択します。
  - ユーザー・メッセージング・サービス(prefix_UMS)
  - WebLogicサービス(prefix_WLS)
  - 監査サービス(prefix_IAU_APPENDおよびprefix_IAU_VIEWER)
  ノート:
  共通インフラストラクチャ・サービス(prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマがデフォルトで選択されています。11gが監査データ・ストアに対して構成されている場合、IAUはグレー表示されます。
- 非SSL有効設定をアップグレードする場合は、次のスキーマを選択します。
  - WebLogicサービス(prefix_WLS)
  - 監査サービス(prefix_IAU_APPENDおよびprefix_IAU_VIEWER)
  ノート:
  非SSL設定をアップグレードしている場合は、ユーザー・メッセージング・サービス(prefix_UMS)の選択を解除する必要があります。既存の11g prefix_ORASDPMスキーマがインプレースでアップグレードされます。prefix_UMSスキーマは、アップグレード・プロセスによって孤立することになるため不要です。
ノート:
このステップでRCUを使用してスキーマが作成されなくても、必要なすべてのスキーマは、スキーマのアップグレード時にUpgrade Assistant (UA)によって作成されます。
インストールするコンポーネントの接頭辞とスキーマ名をノートにとります。インストールの構成時にこの情報が必要になります。「次」をクリックします。
「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。
「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードをノートにとってください。製品インストールの構成中に必要となります。
「表領域のマップ」画面で、作成するスキーマに必要な表領域マッピングを構成します。また、表示された場合は「表領域の暗号化」チェック・ボックスを選択し、「次」をクリックします。確認ダイアログが表示されたら、「OK」をクリックします。最後に、進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。

ノート:
「表領域の暗号化」チェック・ボックスは、RCUの起動時にOracleまたはOracle EBRデータベースで透過的データ暗号化(TDE)が有効になっている場合に表示されます。
「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示します。
「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

Oracle Identity Managerに対するデータベース・パラメータのチューニング

スキーマのアップグレード前に、Oracle Identity Managerに対してデータベース・パラメータをチューニングする必要があります。

Oracle Identity Manager (OIM)パフォーマンス・チューニング・ガイドラインおよび診断取集(ドキュメントID 1539554.1)を参照してください。

また、OPSSスキーマに接続し、次の問合せを実行してパフォーマンスを向上させます:

create index  IDX_ATTR_DNID1 on  JPS_ATTRS( JPS_DN_ENTRYID,  ATTRNAME, ATTRVAL);
alter index  IDX_ATTR_DNID1 noparallel;
drop index IDX_ATTR_DNID;
alter index   IDX_ATTR_DNID1 rename to IDX_ATTR_DNID;
drop index IDX_ATTR_NAME;
create index IDX_ATTR_NAME on JPS_ATTRS(ATTRNAME,JPS_DN_ENTRYID,ATTRVAL);

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

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

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

ノート:

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

ノート:

データベース以外、デプロイメントにあるすべてのサーバーを停止します。アップグレード・プロセス中、データベースが稼働している必要があります。

アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動して次のステップを実行します。

ステップ1: システム・コンポーネントを停止する

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

ノート:

Oracle HTTP Serverが他のサービスと共有されている場合は、Oracle HTTP Serverを停止しないように選択できます。

(UNIX) OHS_INSTANCE_HOME/bin/opmnctl stopall
(Windows) OHS_INSTANCE_HOME\bin\opmnctl stopall

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

管理対象サーバーの起動方法に応じて、次のいずれかの方法に従ってWebLogic管理対象サーバーを停止します:

方法1: ノード・マネージャによって管理されていないWebLogic Server管理対象サーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

方法2: Weblogicコンソールを使用してWebLogic Server管理対象サーバーを停止するには:

weblogic管理者としてWeblogicコンソールにログインします。
「サーバー」 > 「制御」タブに移動します。
必要な管理対象サーバーを選択します。
「停止」をクリックします。

方法3: ノード・マネージャを使用してWebLogic Server管理対象サーバーを停止するには、次のコマンドを実行します:

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'AdminServerHostName','5556','domain_name',
            'DOMAIN_HOME')

wls:/offline>nmKill('ManagedServerName')

ステップ3: 管理サーバーを停止する

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

次のいずれかの方法に従って、管理サーバーを停止します:

方法1: ノード・マネージャによって管理されていない管理サーバーを停止するには:

(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

方法2: Weblogicコンソールを使用して管理サーバーを停止するには:

weblogic管理者としてWeblogicコンソールにログインします。
「サーバー」 > 「制御」タブに移動します。
必要な管理サーバーを選択します。
「停止」をクリックします。

方法3: ノード・マネージャを使用してWebLogic Server管理対象サーバーを停止するには、次のコマンドを実行します:

wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'AdminServerHostName','5556','domain_name',
            'DOMAIN_HOME')

wls:/offline>nmKill('AdminServer')

ステップ4: ノード・マネージャを停止する

ノード・マネージャを停止するには、次のコマンドを実行します:

kill $(ps -ef | grep nodemanager | | awk '{print $2}')

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

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

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

ノート:

12.2 RAC環境でデータポンプ・ワーカー(DW)プロセスの'ライブラリ・キャッシュ・ロック' (サイクル)<='ライブラリ・キャッシュ・ロック'が原因で、長い待機時間およびパフォーマンスの低下が見られる場合があります。この問題を解決するには、次のコマンドを使用してS最適化を無効にする必要があります:

ALTER SYSTEM SET "_lm_share_lock_opt"=FALSE SCOPE=SPFILE SID='*';

前述のコマンドの実行後、すべてのRACインスタンスを再起動します。アップグレードの完了後、次のコマンドを使用してパラメータをリセットできます:

alter system reset "_lm_share_lock_opt" scope=spfile sid='*';

アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。レジストリには、バージョン番号、コンポーネント名およびID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれます。
Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、Upgrade Assistantを非SYSDBAユーザーとして実行することをお薦めします。
Upgrade Assistantを使用したOracle Identity Managerスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

アップグレードに対応可能な既存のスキーマの特定

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

Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個別に選択することもできます。この判断には、次に示すステップを実行して、アップグレードに対応可能なすべてのスキーマのリストを表示することが役立ちます。

Oracleデータベースを使用している場合は、Oracle DBA権限が付与されたアカウントを使用してデータベースに接続し、SQL*Plusから次を実行します。

SET LINE 120
SET PAGESIZE 20
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 VERSION, MRC_NAME, COMP_ID;

生成されたレポートを調査します。

アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンがschema_version_registry表に維持されます。
既存のスキーマに使用されているスキーマ接頭辞名を確認します。RCUを使用して新しい12cスキーマを作成する場合は、同じ接頭辞を使用します。

ノート:

11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレードを実行する前に新しいOPSSスキーマを必ず作成してください。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

親トピック: 製品スキーマのアップグレード

Upgrade Assistantの起動

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

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

ノート:

Upgrade Assistantを起動する前に、JVMの文字エンコーディングが、Upgrade Assistantが実行されるプラットフォームでUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていないと、名前にUnicode文字を含むファイルをダウンロードできません。これにより、アップグレードに失敗する可能性があります。

UTF-8がJVMによって使用されていることを確認するには、JVMオプション-Dfile.encoding=UTF-8を使用します。

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX) export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows) set UA_PROPERTIES="-Dfile.encoding=UTF-8"
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ノート:

前述のコマンドで、ORACLE_HOMEは12c (12.2.1.3.0) Oracleホームを示しています。

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

親トピック: 製品スキーマのアップグレード

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

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

ノート:

アップグレード前の環境に11g監査スキーマ(IAU)が存在する場合、「選択したスキーマ」画面の「個別に選択されたスキーマ」オプションを使用し、Oracle Audit Servicesスキーマを選択して、最初に監査スキーマのみをアップグレードする必要があります。使用可能なIAUスキーマのリストから適切なIAUスキーマを選択していることを確認します。Upgrade Assistantでは、指定されたドメインのディレクトリ内で対応するIAUスキーマは自動的に検出されません。このため、手動で選択する必要があります。IAUスキーマがアップグレードされたら、Upgrade Assistantを再度実行し、「選択したスキーマ」画面の「ドメインで使用されるすべてのスキーマ」オプションを使用して残りのスキーマをアップグレードします。
アップグレード前の環境にいずれの監査スキーマ(IAU)も存在しない場合は、「選択したスキーマ」画面の「ドメインで使用されるすべてのスキーマ」オプションを使用して続行します。
アップグレード前の環境にIAUスキーマとそのバージョンが存在するかどうか確認するには、sysdba権限を持つユーザーを使用して次のSQLコマンドを実行します:
```
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 WHERE COMP_ID LIKE '%IAU%' ORDER BY VERSION, MRC_NAME, COMP_ID ;
```
このコマンドでは、構成したデータベースで使用可能なIAUスキーマとそのバージョンがリストされます。

ノート:

SSL有効設定の場合は、リポジトリ作成ユーティリティ(RCU)を実行して既存のスキーマをアップグレードする必要があります。詳細は、「RCUを使用した必要な12cスキーマの作成(オプション)」を参照してください。非SSL有効設定の場合は、RCUの実行によるスキーマのアップグレードはオプションです。

Upgrade Assistantを使用して、製品スキーマをアップグレードするには:

「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
- 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。
  
  注意:
  12c (12.2.1.3.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.3.0)に含まれていないコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。
- 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。
  
  ノート:
  ほとんどのアップグレードでは、「ドメインで使用されるすべてのスキーマ」を選択して、必要なすべてのスキーマがアップグレードに含まれるようにすることをお薦めします。
ノート:

OIMデータベースでSSLポートのみが開いている場合は、「個別に選択されたスキーマ」オプションを選択し、Oracle Identity Managerスキーマのみを選択します。これにより、依存スキーマが自動的に選択されます。SSL有効設定をアップグレードする場合は、「スキーマ資格証明」画面で非SSLデータベース接続の詳細を入力する必要があります。

「次」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

ノート:

個別のスキーマ・オプションの場合、ドメイン構成はアクセスされないため、パスワード値は前の画面からのものがそのまま使用されます。接続に失敗する場合は、原因を調べ、修正してください。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

ノート:
Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
スキーマ資格証明の画面で、アップグレードするスキーマごとにデータベース接続の詳細を指定します(この画面名は、選択したスキーマに応じて変化します)。
- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。
- データベース接続の詳細を入力して、「接続」をクリックします。
- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。
  
  ノート:
  リリース12.1.2のUCSUMSスキーマでは、コンポーネントIDまたはスキーマ名が変わるため、Upgrade Assistantは、使用可能なスキーマを自動的に認識し、それらをドロップダウン・リストに表示することはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前はアップグレードの開始ポイントに応じて、prefix_ORASDPMまたはprefix_UMSのいずれかになります。
  11gから12cへのアップグレードのみ: UCSUMSスキーマは自動的には移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名に_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。
「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。
「アップグレード・サマリー」画面で、スキーマのアップグレードに選択したオプションのサマリーを確認します。
アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。

これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

「次」をクリックします。
アップグレードが正常に完了すると、Upgrade Assistantによりアップグレード・ステータスが示され、アップグレード・プロセスの後続のステップがリストされます。Upgrade Assistantの「アップグレード成功」画面に示された情報を基にして、次に実行するステップを判断してください。ウィザードには次の情報が表示されます:
```
Upgrade Succeeded.

Log File: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/ua2020-09-15-18-27-29PM.txt
Post Upgrade Text file: /u01/oracle/products/12c/identity/oracle_common/upgrade/logs/postupgrade2020-09-15-18-27-29PM.txt
Next Steps

Oracle SOA
1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
   Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management.
```
「閉じる」をクリックすると、アップグレードが完了しウィザードが終了します。
アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、ORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

親トピック: 製品スキーマのアップグレード

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

すべてのアップグレード・ステップを完了したら、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.3.0であることを確認します。

次に、サンプル出力を示します:

MRC_NAME    COMP_ID            OWNER              VERSION     STATUS   UPGRADED
--------  -----------     ------------------    -----------  --------  --–------
 PREFIX    BIPLATFORM     PREFIX_BIPLATFORM     11.1.1.9.0     VALID       N
 PREFIX    OPSS           PREFIX_OPSS           12.2.1.0.0     VALID       Y  
 PREFIX    UCSUMS         PREFIX_ORASDPM        12.2.1.0.0     VALID       Y
 PREFIX    WLS            PREFIX_WLS            12.2.1.0.0     VALID       N
 PREFIX    IAU            PREFIX_IAU            12.2.1.2.0     VALID       N  
 PREFIX    IAU_APPEND     PREFIX_IAU_APPEND     12.2.1.2.0     VALID       N
 PREFIX    IAU_VIEWER     PREFIX_IAU_VIEWER     12.2.1.2.0     VALID       N  
 PREFIX    MDS            PREFIX_MDS            12.2.1.3.0     VALID       Y
 PREFIX    OIM            PREFIX_OIM            12.2.1.3.0     VALID       Y      
 PREFIX    SOAINFRA       PREFIX_SOAINFRA       12.2.1.3.0     VALID       Y
 PREFIX    STB            PREFIX_STB            12.2.1.3.0     VALID       N

11 rows selected.

ノート:

一部のスキーマ・バージョンはアップグレード前のバージョン番号のままであり、その他のスキーマ・バージョンには様々な12.2.1.x.yバージョン番号がリストされる場合があります。

BIPLATFORM - is not upgraded and remains 11.1.1.9.0
Audit schemas (IAU*) may not upgrade if pre-exist in 11g, otherwise will be created at version 12.2.1.2.0.
WLS schema will be created new at version 12.2.1.0.0
STB schema will be created new at 12.2.1.3.0

STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示される場合がありますが、失敗を意味するものではありません。IAUスキーマがアップグレードではなく作成された場合、それらはVALIDとして表示されます。

これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当するINVALIDオブジェクトは、無視しても問題ありません。

親トピック: 製品スキーマのアップグレード

ドメインの再構成について

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

ノート:

OIM 11gでカスタム・アプリケーションをデプロイすると、再構成ウィザードに、カスタム・アプリケーションおよびライブラリのリスト(存在する場合)とともに警告メッセージが表示されます。これらのアプリケーション/ライブラリは、OIM 12c (12.2.1.3)にアップグレードした後も11gの場所を指し続けます。アップグレード後にそれらを手動で更新する必要があります。
再構成後も、ドメインは同じ場所(11g DOMAIN_HOME)に残ります。それは、12c $ORACLE_HOME/user_projects/domains/に移動またはコピーされません。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン

ノート:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。

動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

アップグレードするインストールでOracle Access Manager (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。

次の例のように、$DOMAIN_HOME/init-info/domain-info.xmlの行をコメント・アウトします:

ここで、DOMAIN_HOMEは管理者サーバーのドメイン・ホームです。

<!--extention-template-ref name="Oracle Identity Navigator" 
  version="11.1.1.3.0" 
  location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/oracle.oinav_11.1.1.3.0_template.jar"
symbol=""/-->
<!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" 
  symbol="oracle.idm.oinav_11.1.1.3.0_iam111130_ORACLE_HOME" 
  product_home="/u01/app/oracle/product/fmw/iam111130"/-->

また、次の例のように、$DOMAIN_NAME/config/config.xmlの行を同様にコメント・アウトします:

<!--app-deployment> 
  <name>oinav#11.1.1.3.0</name>
  <target>AdminServer</target>
  <module-type>ear</module-type>

  <source-path>/u01/app/oracle/product/fmw/iam111130/oinav/modules/oinav.ear_11.1.1.3.0/oinav.ear</source-path>
  <deployment-order>500</deployment-order>
  <security-dd-model>DDOnly</security-dd-model>
  <staging-mode>nostage</staging-mode>
</app-deployment-->

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

ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。

変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

ノート:

ドメイン再構成プロセスが開始されると、そこで行われた変更は元に戻せません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前の元の状態にドメインを復元するための唯一の方法です。

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

ドメインのバックアップ
再構成ウィザードの起動
Oracle Identity Managerドメインの再構成
再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

ドメインのバックアップ

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

管理サーバーのドメイン・ディレクトリのバックアップを作成するには:

コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
(Windows) copy /Oracle/Middleware/user_projects/domains to /Oracle/Middleware/user_projects/domains_backup。

(UNIX) cp -rf mydomain mydomain_backup
各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメインのバックアップしたバージョンが完全であることを確認します。

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

親トピック: ドメインの再構成について

再構成ウィザードの起動

ノート:

再構成プロセスを開始する前に管理サーバーおよびすべての管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します(ここで、プライマリ・ノードは管理サーバーです)。Pack/Unpackユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードをグラフィカル・モードで起動するには:

コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
次の環境変数を設定します。
- WLS_ALTERNATIVE_TYPES_DIR - 次のコマンドを使用します:
  (Bash以外): setenv WLS_ALTERNATIVE_TYPES_DIR ORACLE_HOME/idm/server/loginmodule/wls
  
  (Bash):export WLS_ALTERNATIVE_TYPES_DIR=ORACLE_HOME/idm/server/loginmodule/wls
  
  ORACLE_HOMEは、12c Oracleホームです。
- CONFIG_JVM_ARGS - ./reconfig.shコマンドによって、デフォルトのキャッシュ・ディレクトリが有効でないことを示す次のエラーが表示される場合があります:
```
*sys-package-mgr*: can't create package cache dir
```
  エラーを回避するには、CONFIG_JVM_ARGSを設定してキャッシュ・ディレクトリを変更します。
  
  たとえば: CONFIG_JVM_ARGS=-Dpython.cachedir=any_writable_directory。
oracle_common/common/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/common/bin
- (Windows) ORACLE_HOME\oracle_common\commom\bin
ORACLE_HOMEは、12c Oracleホームです。
次に示すロギングオプションを指定して、再構成ウィザードを開始します。
- (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL
- (Windows) reconfig.cmd -log=log_file -log_priority=ALL
ここで、log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

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

親トピック: ドメインの再構成について

Oracle Identity Managerドメインの再構成

再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

再構成ウィザードを使用してドメインを再構成するには:

「ドメインの選択」画面で、OIGドメインの管理サーバーで使用されるDOMAIN_HOMEディレクトリの場所を指定するか、「参照」をクリックし、正しいOIGドメイン・ディレクトリに移動して選択します。「次」をクリックします。
「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。
- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。
- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。
- ドメイン・アップグレードが検証されます。
- 「セットアップの進行状況」が完了したら、ビューの下部パネルで警告メッセージを確認します。
  - 特定のエラー・コードが表示された場合は、ログ・ファイルでそのエラー・コードを検索し、Oracleサポートに確認します。ログの一部のエラーには、推奨される解決策が直接含まれます。
  - より一般的な「元のMWホームにカスタム・アプリケーションが残っており、これを手動で修正する必要があります:...」という警告メッセージが表示された場合は、ログでCFGFWK-40951メッセージを確認します。
    たとえば:
```
2020-09-16 18:54:22,249 WARNING [42] com.oracle.cie.domain.progress.domain.reconfig.wlscore.ValidateDomainPhase - CFGFWK-40951: An application or library was not relocated to the new MW home.
CFGFWK-40951: Custom Applications were left in the original MW home and must be fixed manually:
spml-dsml

CFGFWK-40951: Correct source path of the applications to refer to the new installation.
```
「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.3.0)に対してサポートされているJDKバージョンは1.8.0_131以上です。「次」をクリックします。

ノート:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

ノート:
デフォルトでは、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意のドライバが選択されています。接続の詳細で、サービス名ではなくインスタンス名を指定した場合は、Oracleのプール済インスタンス接続用ドライバ(Thin)、バージョン: 任意を選択する必要があります。ドライバ・タイプを変更しないと、接続に失敗します。

ノート:
既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。RCUで12c用にスキーマが作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

ノート:
11gからアップグレードし、データベースに_OPSSまたは_IAU 11gデータベース・スキーマがある場合は、それらのスキーマに対してデータベース接続の詳細を手動で入力する必要があります。これらのスキーマは、11gでは必要なかったため、手動で作成する必要がありました。これらのスキーマに任意の名前が割り当てられている可能性があるため、再構成ウィザードではそれらを認識しません。_IAUに対する接続情報を指定する場合は、IAU_APPENDユーザー情報を使用します。
「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。
ノート:
- OPSS以外のすべてのスキーマについて、ホスト、ポートおよびサービスの詳細が自動移入されます。OPSSスキーマ資格証明は手動で入力する必要があります。
- RACデータベースを使用している場合は、「JDBCコンポーネント・スキーマ」画面で、すべてのデータソースを選択し、グリッド・リンクに変換を選択します。
グリッド・リンク画面で、サービス名、スキーマ・パスワード、ONSホストおよびポート、SCANホスト名およびポートを指定し、「FAN」および「SCAN」チェック・ボックスを適切に選択します。また、各スキーマ所有者の接頭辞が環境を反映していることを確認します。RACコンポーネント・スキーマごとにこのステップを実行します。

完了したら、「次へ」をクリックします。

ノート:
グリッド・リンク画面は、ステップ6でグリッド・リンクに変換を選択した場合にのみ表示されます。
「JDBCコンポーネント・スキーマ・テスト」画面では、コンポーネント・スキーマの接続がテストされます。テストの結果は、「ステータス」列に表示されます。

チェックが完了したら、「次へ」をクリックします。
「ノード・マネージャ」画面で、要件に応じてノード・マネージャの構成でデフォルトのオプションを使用するか、または「新規構成の作成」を選択します。いずれの場合でも、ノード・マネージャの詳細に対してWebLogic管理ユーザー資格証明を指定します。
「資格証明」画面の「weblogicAdminnKey」に、11gで使用されているWeblogic管理ユーザー名およびパスワードを移入し、「次」をクリックします。
デフォルトの選択を変更せずに「次」をクリックします。
「拡張構成」画面で、アップグレード中に、すべてのオプションを選択解除したまま「次」をクリックすることをお薦めします。拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

ノート:
必要に応じて、オプションを選択し、構成の詳細を確認できます。ただし、現時点では、すべての設定がドメイン構成の最終状態を表すとはかぎりません。追加のコンポーネント構成は、後のステップでUpgrade Assistantによって完了されます。現時点ではこれらの詳細を確認せず、アップグレード・プロセス中に「拡張構成」ビューを変更しないことをお薦めします。
「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

ノート:
ドメインを再構成しても、その場所は変更されません。
「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。
- ドメイン情報が抽出、保存および更新されます。
- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。
進捗バーが100%になったら、「次へ」をクリックします。
「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが表示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをノートにとります。

親トピック: ドメインの再構成について

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

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

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

Upgrade Assistantの起動

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

ノート:

UTF-8がJVMによって使用されていることを確認するには、JVMオプション-Dfile.encoding=UTF-8を使用します。

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
JVMエンコーディング要件を含むようにUpgrade Assistantのパラメータを設定します:
- (UNIX) export UA_PROPERTIES="-Dfile.encoding=UTF-8"
- (Windows) set UA_PROPERTIES="-Dfile.encoding=UTF-8"
Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat

ノート:

前述のコマンドで、ORACLE_HOMEは12c (12.2.1.3.0) Oracleホームを示しています。

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

Upgrade Assistantのパラメータ

親トピック: ドメイン・コンポーネント構成のアップグレード

Upgrade Assistantのパラメータ

コマンドラインからUpgrade Assistantを起動するときに、追加のパラメータを指定できます。

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

パラメータ	必須またはオプション	説明
`-readiness`	準備状況チェックの場合は必須ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。スキーマと構成がチェックされます。 `-examine`パラメータを指定した場合は、このパラメータを指定しないでください。
`-threads`	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。値は、1 - 8の正の整数である必要があります。デフォルトは4です。
`-response`	サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須	Upgrade AssistantがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantはサイレント・モード(Upgrade Assistantの画面表示なし)で実行されます。
`-examine`	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 `-readiness`パラメータを指定した場合、このパラメータを指定しないでください。
`-logLevel attribute`	オプション	次のいずれかの属性を指定して、ログイン・レベルを設定します。 `TRACE` `NOTIFICATION` `WARNING` `ERROR` `INCIDENT_ERROR` デフォルトのロギング・レベルは`NOTIFICATION`です。 `-logLevel TRACE`属性を設定して、より多くのログが記録されるようにすることを検討してください。これは、アップグレードの失敗をトラブルシューティングする際に役立ちます。`-logLevel TRACE`が使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
`-logDir location`	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。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`	オプション	すべてのコマンドライン・オプションを表示します。

親トピック: Upgrade Assistantの起動

Oracle Identity Managerドメイン・コンポーネント構成のアップグレード

Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後、Upgrade Assistantを実行して、ドメイン・コンポーネント構成を更新済ドメイン構成に一致するようにアップグレードする必要があります。

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:

「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が表示されます。「次」をクリックします。

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
次の画面で、次を実行します。
- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変更されます。
- 「ドメイン・ディレクトリ」フィールドに、WebLogicドメイン・ディレクトリのパスを入力します。
  
  「ドメイン・ディレクトリ」は、管理サーバー・ドメイン・ディレクトリです。
「次」をクリックします。
「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定します。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

ノート:
Upgrade Assistantでは前提条件が満たされているかどうかを確認できません。
ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

ノート:
Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。
古い(つまり11g) OIMホームの場所画面で、「11gソース」を選択し、11.1.2.3.0 OIM Oracleホーム(ORACLE_HOME/Oracle_IDM)への絶対パスを指定します。
「次」をクリックします。
「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。
「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

注意:
Upgrade Assistantにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

「次」をクリックします。
アップグレードが成功した場合: 「アップグレード成功」画面で、「閉じる」をクリックし、アップグレードを完了してウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のあるタスクが、アップグレード後のアクションのウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合にのみ表示されます。

アップグレードが失敗した場合: 「アップグレード失敗」画面で「ログの表示」をクリックして、エラーを確認し、トラブルシューティングします。ログは、NEW_ORACLE_HOME/oracle_common/upgrade/logsにあります。

ノート:
アップグレードが失敗した場合は、アップグレード前の環境をバックアップからリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。

親トピック: ドメイン・コンポーネント構成のアップグレード

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

11gから12cへのアップグレード後、11g Middlewareホームにあるカスタム構成を12c Oracleホームにコピーし、SOAコンポジットをアップグレードするなど、アップグレード後のタスクを完了する必要があります。

カスタム構成のコピー

カスタム構成をコピーする場合は、次の点を考慮してください:

11g Middlewareホームを参照するパラメータでジョブをスケジュールした場合は、対応する12c Oracleホームに更新する必要があります。
カスタマイズした構成データ(存在する場合)を保持するには、11g MiddlewareホームのXLIntegrationsやconnectorResourcesなどの標準ディレクトリから、12c Oracleホームの対応するディレクトリにコンテンツをコピーします。

親トピック: アップグレード後のタスクの実行

WebLogic Serverセッション・レプリケーションの最大メッセージ・サイズの増加

最大メッセージ・サイズをデフォルト値の10MBから100MBに変更することをお薦めします。この値は、ノード間でセッション・データをレプリケートするために使用されます。すべての管理対象サーバーおよび管理サーバーに対してこのステップを実行する必要があります。

WebLogic Server管理コンソールにログインします。
「サーバー」に移動し、「プロトコル」を選択して、「一般」をクリックします。
「最大メッセージ・サイズ」の値を100MBに設定します。

親トピック: アップグレード後のタスクの実行

アップグレード後のJMSおよびTLOG永続ストアの変更

JMSおよびTLOG永続ストアは、Oracle Identity Manager 12c (12.2.1.3.0)へのアップグレード後も同じままです。つまり、永続ストアがアップグレード前にファイルベースである場合は、アップグレード後もファイルベースになります。

永続ストアをファイルベースのシステムからデータベースベースのシステムに変更する場合は、ステップを手動で実行する必要があります。「エンタープライズ・デプロイメントでのTLOGおよびJMSに対する永続ストアの使用」を参照してください。

親トピック: アップグレード後のタスクの実行

12c Oracleホームへのフォルダのコピー

12cにアップグレードする際に、一部のフォルダにファイル・システム依存データがある場合は、それらのフォルダを12c Oracleホームに手動でコピーする必要があります。

たとえば、plugins、ScheduleTask、XLIntegrations、JavaTasks、connectorResourcesなどです。

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

cp -r 11g_MW_HOME/<product_idm>/server/plugins/* ORACLE_HOME/<product_idm>/server/plugins/

ORACLE_HOMEは、12c Oracleホームです。

サーバーの起動

Oracle Identity Managerのアップグレード後、サーバーを起動します。

サーバーは次の順序で起動してください。

管理サーバーを起動します。
ノード・マネージャが構成されている場合は、ノード・マネージャを起動しないでください。
ノート:

通常、管理サーバーの名前は常に'AdminServer'です。管理サーバーの名前がデフォルト名の'AdminServer'と異なる場合は、サーバーを起動する前に、<domainname>/config/config.xmlファイル内の名前を適切に変更する必要があります。
名前を変更するには:
1. <domainname>/config/config.xmlファイルを開き、次のライブラリ・エントリを見つけます:
  <library> <name>oracle.idm.ipf</name> <target>AdminServer</target> <module-type>jar</module-type> ..... ..... </library>
2. 管理サーバーの名前に注意します。名前が'AdminServer'以外の場合は、次のエントリを適切に変更します:
  <target><name_of_your_admin_server></target>
ターミナルで、管理サーバーURLを使用し、BPMプロパティをTRUEに設定してOracle SOA Suite管理対象サーバーを起動します。
たとえば:
./startManagedWebLogic.sh <SOA_Managed_server> t3://weblogic_admin_host:weblogic_admin_port —Dbpm.enabled=true
ノート:
- 初回起動の場合、前述の例のコマンドを使用して、Oracle SOA Suite管理対象サーバーを手動で起動する必要があります。
- SSL環境では、管理対象サーバーをブートストラップのために初めて起動するときに、管理サーバーの非SSLポート番号を指定します。
- SOAが実行状態になった後、OIMサーバーを起動する前に、Oracle Enterprise Managerコンソールを使用してすべてのコンポジットが正常にデプロイされたことを確認します。タイミングの問題はSOAコンポジットのデプロイメントで発生する可能性があり、正常にデプロイされていない場合、OIMブートストラップはコンポジット・デプロイメント・フェーズで失敗します。コンポジットを確認し、デプロイに失敗した可能性のあるコンポジットを修正する手順は、ドキュメントID 2417785.1を参照してください。
SOAサーバーが実行状態になったら、ターミナルで管理サーバーURLを使用してOracle Identity Manager管理対象サーバーを起動します。
これにより、OIMブートストラップ・プロセスが実行され、ブートストラップに成功した後、OIM管理対象サーバーは自動的に停止されます。
たとえば:
./startManagedWebLogic.sh <OIM_Managed_server> t3://weblogic_admin_host:weblogic_admin_port

ノート:
前のステップで行ったように、管理サーバーの非SSLポート番号を指定します。
SOA管理対象サーバーおよび管理サーバーを停止します。サーバーとプロセスの停止の詳細は、「サーバーとプロセスの停止」を参照してください。

サーバーとプロセスの起動
アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。

サーバーとプロセスの起動

アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

ノート:

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

Fusion Middleware環境を起動するには、次に示すステップを実行します。

ステップ1: ノード・マネージャを起動する

管理サーバー<DOMAIN_HOME>/binの場所からノード・マネージャを起動します:

(UNIX) nohup ./startNodeManager.sh > <DOMAIN_HOME>/nodemanager/nodemanager.out 2>&1 &
(Windows) nohup .\startNodeManager.sh > <DOMAIN_HOME>\nodemanager\nodemanager.out 2>&1 &

ここで、<DOMAIN_HOME>は管理サーバーのドメイン・ホームです。

ステップ2: 管理サーバーの起動

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

管理サーバーを起動するためにnodemanagerを使用しない場合は、startWebLogicスクリプトを使用します:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ3: 管理対象サーバーを起動する

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

プロンプトが表示されたらユーザー名とパスワードを入力します。

ノート:

通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。
12cでは、モバイル・セキュリティ・マネージャ(MSM)サーバーはサポートされていません。サーバーの再起動後に、MSMサーバーの11g構成(omsm_server1やWLS_MSM1など)が残る場合があります。これらの構成は無視してください。MSMサーバーを再起動しないでください。

ステップ4: システム・コンポーネントを起動する

必要な場合、startComponentスクリプトを使用して、Oracle HTTP Serverなどのシステム・コンポーネントを起動します:

(UNIX) OHS_INSTANCE_HOME/bin/startComponent.sh ohs1
(Windows) OHS_INSTANCE_HOME\bin\startComponent.sh ohs1

システム・コンポーネントは任意の順序で起動できます。

親トピック: サーバーの起動

OIMおよびSOA管理対象サーバーのフロントエンドに使用できるようにするためのOracle HTTP Serverの構成

Oracle Identity Governanceドメインにリクエストをルーティングするように環境のOracle HTTP Serverを構成している場合は、次のOHSディレクティブが存在するように構成を更新する必要があります。追加のディレクティブは削除できます。

次のステップを実行します。

Webサーバーで、OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/instances/OHS_INSTANCE_NAME/moduleconfにあるOIGのOracle HTTP Server構成ファイルを見つけます。

ノート:

OHS_DOMAIN_HOME/config/fmwconfig/components/OHS/instances/OHS_INSTANCE_NAMEディレクトリのmod_wls_ohs.confファイルをコールしている可能性があります。

次のOHSディレクティブを構成していることを確認します:

# oim admin console(idmshell based)
   # oim admin console(idmshell based)
   <Location /admin>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
   </Location>
 
# oim self and advanced admin webapp consoles(canonic webapp)
 
  <Location /oim>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /identity>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid 
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /sysadmin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /admin>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log" 
  </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /sodcheck>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com  
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# OIM, role-sod profile
  <Location /role-sod>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the OIM Managed Server Port
  <Location /workflowservice>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com  
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# xlWebApp - Legacy 9.x webapp (struts based)
   <Location /xlWebApp>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com 
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# Nexaweb WebApp - used for workflow designer and DM
  <Location /Nexaweb>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# used for FA Callback service.
  <Location /callbackResponseService>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# spml xsd profile
  <Location /spml-xsd>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /HTTPClnt>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>
 
  <Location /reqsvc>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com  
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# SOA Infra
  <Location /soa-infra>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/component/oim_component.log"  
  </Location>
 
  <Location /integration>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
  </Location>

  <Location /sdpmessaging/userprefs-ui>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/soa_component.log"
  </Location>

  <Location /ws_utc>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /provisioning-callback>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>
 
  <Location /CertificationCallbackService>
    SetHandler weblogic-handler
    WLCookieName JSESSIONID
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /IdentityAuditCallbackService>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /soa/composer>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com  
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/soa_component.log"
  </Location>

  # UMS Email Support
  <Location /ucs>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/OHS/component/oim_component.log"
  </Location>

  <Location /FacadeWebApp>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

# Scheduler webservice URL
  <Location /SchedulerService-web>
    WLSRequest ON
    WLCookieName oimjsessionid
    WebLogicHost oimserver.example.com
    WebLogicPort 14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
  </Location>

  <Location /iam/governance/configmgmt>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /iam/governance/scim/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /iam/governance/token/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /OIGUI>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com  
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /iam/governance/applicationmanagement>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /iam/governance/adminservice/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

  <Location /iam/governance/selfservice/api/v1>
   SetHandler weblogic-handler
   WLCookieName oimjsessionid
   WebLogicHost oimserver.example.com
   WebLogicPort 14000
   WLLogFile /tmp/web_log.log
  </Location>

WEBHOST1とWEBHOST2の両方でファイルを保存します。
WEBHOST1およびWEBHOST2の両方で、Oracle HTTP Serverインスタンスを停止および起動します。
startComponentスクリプトを使用して、Oracle HTTP Serverなどのシステム・コンポーネントを起動します:
- (UNIX) OHS_INSTANCE_HOME/bin/startComponent.sh ohs1
- (Windows) OHS_INSTANCE_HOME\bin\startComponent.sh ohs1
システム・コンポーネントは任意の順序で起動できます。

Oracle Identity Manager Design Consoleのアップグレード

Oracle Identity Manager (OIM)ドメイン・コンポーネント構成をアップグレードした後、Oracle Identity Manager Design Consoleをアップグレードします。

Oracle Identity Manager Design Consoleをアップグレードするには、12c (12.2.1.3.0) ORACLE_HOME/idm/designconsole/config/xlconfig.xmlファイルを11.1.2.3.0 ORACLE_HOME/Oracle_IDM1/designconsole/config/xlconfig.xmlファイルに置き換えます。

SSL有効設定のためのアップグレード後のタスクの完了

Oracle Identity Manager SSL有効設定をアップグレードする場合は、アップグレード・プロセスを完了するために必要なアップグレード後のタスクを実行する必要があります。

SSL有効設定をアップグレードした場合は、次のタスクを完了します。

setDomainEnv.sh、startWeblogic.sh、startManagedWeblogic.shおよびデータソースのSSL設定に対して行われた変更は、アップグレード後に失われます。変更をすべてやりなおしてください。
WebLogic管理サーバーを起動します。管理サーバーを起動するには、startWebLogicスクリプトを使用します。
- (UNIX) DOMAIN_HOME/bin/startWebLogic.sh
- (Windows) DOMAIN_HOME\bin\startWebLogic.cmd
ここで、DOMAIN_HOMEは管理ドメインです。

プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
SSL設定について、新しく作成された次のデータソースに対して必要な変更を行います。
- LocalSvcTblDataSource
- opss-audit-DBDS
- opss-audit-viewDS
- opss-data-source
- WLSSchemaDataSource
新しく作成されたデータソースの更新の詳細は、『Oracle Identity Governanceの管理』のデータソースoimOperationsDBの構成の更新に関する項を参照してください
カスタム・アイデンティティとJava標準信頼の場合は、新しいJDKホームにアイデンティティ信頼証明書をインポートします。12c (12.2.1.3.0)ではjdk1.8.0_131が使用されます。新しいJDKホームにアイデンティティ信頼証明書をインポートするには、次のコマンドを使用します。
./keytool -importcert -alias startssl -keystore JAVA_HOME/jre/lib/security/cacerts -storepass <password> -file supportcert.pem
11g (アップグレード前)に行われた変更に関連するSSLポートを含め、すべてのSSL構成の変更がアップグレード後も存在することを確認します。変更が失われた場合は、アップグレード後にそれらをやりなおす必要があります。SSL構成の変更の一部には次が含まれます。
- OimFrontEndURL
- backOfficeURL
- SOA Server URL
- ForeignJNDIProvider-SOA
Oracle Identity Goverenanceに対するSSLの構成の詳細は、『Oracle Identity Governanceの管理』のOracle Identity Governanceの更新に関する項を参照してください。

スタンドアロンのOracle BI Publisherのインストール

Oracle Identity Manager 11.1.2.3.0をOracle Identity Governance 12c (12.2.1.3.0)にアップグレードすると、11.1.2.3.0デプロイメントに存在する組込みOracle BI Publisherが削除されます。したがって、アップグレード後に新しいスタンドアロンのOracle BI Publisher 12c (12.2.1.3.0)を、Oracle Identity Governanceレポートを構成するためにインストールする必要があります。

Oracle BI Publisher 12c (12.2.1.3.0)のインストールおよび構成の詳細は、『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のOracle BI Publisherのインストールおよび構成を参照してください。

スタンドアロンのOracle BI PublisherとOracle Identity Governance 12c (12.2.1.3.0)の統合の詳細は、『Oracle Identity Governanceのためのアプリケーションの開発とカスタマイズ』のスタンドアロンのBI PublisherとOracle Identity Governanceの統合を参照してください。

ユーザー・インタフェースに対するアプリケーション・モジュールのチューニング

Oracle Identity Manager中間層のアップグレードに成功したら、アプリケーション・モジュール(AM)をチューニングします。

Oracle Fusion Middlewareパフォーマンスのチューニングのユーザー・インタフェースに対するアプリケーション・モジュール(AM)のチューニングに関する項を参照してください。

パッチ後のインストール・ステップの実行

アップグレードが完了した後、パッチ後のインストール・ステップを実行する必要があります。

パッチ後のインストール・ステップは次で構成されます:

poststartコマンドの実行によるバイナリ・パッチ適用の成功の確認

次に示すように、変数およびスタック・バッチ・バンドルのREADME.txtファイルの手順を使用して、製品のpoststartコマンドを実行します:

$ ./spbat.sh -type oig -phase poststart -mw_home /<INSTALLATION_DIRECTORY>/IAM12c -spb_download_dir /<DOWNLOAD_LOCATION>/IDM_SPB_12.2.1.4.200714 -log_dir /<DOWNLOAD_LOCATION>/OIGlogs

詳細は、ドキュメントID 2657920.1を参照してください。

patch_oim_wls.profileファイルへの入力

テキスト・エディタを使用して、ORACLE_HOME/idm/server/bin/ディレクトリにあるファイルpatch_oim_wls.profileを編集し、環境に一致するようファイル内の値を変更します。patch_oim_wls.profileファイルには、サンプル値が含まれます。

表4-7に、patch_oim_wls.profileファイルに入力する情報を示します。このファイルは、バンドル・パッチ・プロセスの次のステージで使用されます。

表3-7 patch_oim_wls.profileファイルのパラメータ

パラメータ	説明	サンプル値
`ant_home`	ANTインストールの場所。通常は、MW_HOMEの下になります。	Linuxの場合: `$MW_HOME/oracle_common/modules/thirdparty/org.apache.ant/1.10.5.0.0/apache-ant-1.10.5/` Windowsの場合: `%MW_HOME%/oracle_common/modules/thirdparty/org.apache.ant/1.10.5.0.0/apache-ant-1.10.5/`
`java_home`	Oracle Identity Governanceドメインの実行に使用されるJDK/JREインストールの場所。	Linuxの場合: $MW_HOMEで使用される<JAVA_HOME_PATH> Windowsの場合: %MW_HOME%で使用される<JAVA_HOME_PATH>
`mw_home`	Oracle Identity Governanceがインストールされているミドルウェア・ホームの場所。	Linuxの場合: `/u01/Oracle/Middleware` Windowsの場合: `C:\Oracle\MW_HOME\`
`oim_oracle_home`	Oracle Identity Governanceインストールの場所。	Linuxの場合: `$MW_HOME/idm` Windowsの場合: `%MW_HOME%\idm`
`soa_home`	SOAインストールの場所。	Linuxの場合: `$MW_HOME/soa` Windowsの場合: `%MW_HOME%\soa`
`weblogic.server.dir`	WebLogicサーバーがインストールされているディレクトリ。	Linuxの場合: `$MW_HOME/wlserver` Windowsの場合: `%MW_HOME%\wlserver`
`domain_home`	Oracle Identity Governanceがインストールされているドメイン・ホームの場所。	`$MW_HOME/user_projects/domains/base_domain`
`weblogic_user`	ドメイン管理者のユーザー名。通常は、`weblogic`ですが、異なる値も指定できます。	`weblogic`
`weblogic_password`	ドメイン管理者ユーザーのパスワード。この行がコメント・アウトされている場合、パスワードの入力を求められます。	NA
`soa_host`	SOA管理対象サーバーのリスニング・アドレスまたはSOA管理対象サーバーがリスニングしているホスト名。ノート: SOA管理対象サーバーが仮想IPアドレスを使用するように構成されている場合、仮想ホスト名を指定する必要があります。	`oimhost.example.com`
`soa_port`	SOA管理対象サーバーのリスニング・ポートまたはSOA管理対象サーバーのポート番号。	8001 非SSLリスニング・ポートのみを指定する必要があります。
`operationsDB.user`	Oracle Identity Governanceデータベース・スキーマ・ユーザー。	`DEV_OIM`
`OIM.DBPassword`	Oracle Identity Governanceデータベース・スキーマ・パスワード。この行がコメント・アウトされている場合、スクリプトの実行時にパスワードの入力を求められます。	NA
`operationsDB.host`	Oracle Identity Governanceデータベースのホスト名。	`oimdbhost.example.com`
`operationsDB.serviceName`	Oracle Identity Governanceスキーマ/データベースのデータベース・サービス名。これはホスト名ではなく、異なる値を指定することもできます。	`oimdb.example.com`
`operationsDB.port`	Oracle Identity Governanceデータベースのデータベース・リスナー・ポート番号。	1521
`mdsDB.user`	MDSスキーマ・ユーザー	DEV_MDS
`mdsDB.password`	MDSスキーマ・パスワード。この行がコメント・アウトされている場合、パスワードの入力を求められます。	NA
`mdsDB.host`	MDSデータベースのホスト名	`oimdbhost.example.com`
`mdsDB.port`	MDSデータベース/リスニング・ポート	1521
`mdsDB.serviceName`	MDSデータベースのサービス名	`oimdb.example.com`
`oim_username`	Oracle Identity Governanceのユーザー名。	システム管理者のユーザー名
`oim_password`	Oracle Identity Governanceのパスワード。これはオプションです。これがコメント・アウトされている場合、スクリプトの実行時にパスワードの入力を求められます。	NA
`oim_serverurl`	Oracle Identity GovernanceへのURL。	`t3://oimhost.example.com:14000`
`wls_serverurl`	WLSコンソールへのURL	`t3://wlshost.example.com:7001`
`opss_customizations_present=false`	認可に関連するカスタマイズまたはカスタム・タスク・フローの有効化。カスタマイズを有効にするには、この値をtrueに設定します。	true

ノート:

使用される設定に応じてパラメータ値を更新してから、patch_oim_wls.shファイルを実行します。

Oracle Identity Governance管理対象サーバーへのパッチ適用(patch_oim_wlsステージ)

Oracle Identity Governance管理対象サーバーへのパッチ適用は、ステージング済ファイルを正しい場所にコピーし、SQLスクリプトを実行して、イベント・ハンドラをインポートし、SOAコンポジットをデプロイするプロセスです。MBeanコールを行う場合、スクリプトはpatch_oim_wls.profileファイルで指定されたOracle Identity Governance管理対象サーバーおよびSOA管理対象サーバーを自動的に起動します。

このステップは、patch_oim_wls.profileファイルで指定された入力を使用して、patch_oim_wls.sh (UNIXの場合)およびpatch_oim_wls.bat (Microsoft Windowsの場合)スクリプトを実行することで行います。前提条件として、WebLogic管理サーバー、SOA管理対象サーバーおよびOracle Identity Governance管理対象サーバーが稼働中である必要があります。

WebLogic上のOracle Identity Governance管理対象サーバーにパッチを適用するには:

WebLogic管理サーバー、SOA管理対象サーバーおよびOracle Identity Governance管理対象サーバーが稼働中であることを確認します。
次の環境変数を設定します。
LINUXまたはSolarisの場合、JAVA_HOME環境変数を設定します:
```
export JAVA_HOME=<JAVA_HOME_PATH>
export PATH=$JAVA_HOME/bin:$PATH
```
Microsoft Windowsの場合:
```
set JAVA_HOME=<JAVA_HOME_PATH>
set ANT_HOME=\PATH_TO_ANT_DIRECTORY\ant
set ORACLE_HOME=%MW_HOME%\idm
```
ノート:
patch_oim_wls.sh (UNIXの場合)またはpatch_oim_wls.bat (Microsoft Windowsの場合)スクリプトを実行する前に、現在のPATHにJDKバイナリに対する参照を設定していることを確認してください。このJAVA_HOMEのバージョンは、WebLogic Serverの実行に使用されているバージョンと同じである必要があります。/usr/bin/のJAVA_HOMEバージョンまたはデフォルトは、通常古いため使用しないでください。次のコマンドを実行してバージョンを確認することができます。
```
java -version
```
patch_oim_wls.sh (UNIXの場合)またはpatch_oim_wls.bat (Microsoft Windowsの場合)を実行して、構成変更をOracle Identity Governanceサーバーに適用します。Linuxシステムでは、次のコマンドを使用して、シェル環境でスクリプトを実行する必要があります。
```
sh patch_oim_wls.sh
```
ノート:
EDG実装の場合、このスクリプトをサーバー・ドメイン・ディレクトリではなく、mserverドメイン・ディレクトリに対して実行する必要があります。
OIGドメイン・ホームから次のディレクトリを削除します:

$DOMAIN_HOME/servers/oim_server1/tmp/_WL_user/oracle.iam.console.identity.self-service.ear_V2.0

ここで、oim_server1は、OIGに使用されるWebLogic管理対象サーバーです。
patch_oim_wlsスクリプトが正常に完了したことを確認するには、ORACLE_HOME/idm/server/bin/patch_oim_wls.logログ・ファイルをチェックします。

ノート:

patch_oim_wlsスクリプトの実行時に、$DOMAIN_HOME/servers/MANAGED_SERVER/security/boot.propertiesファイルが削除される場合があります。スクリプトを使用して管理対象サーバーを起動し、boot.propertiesファイルを使用して、スクリプト内のパスワードを入力する必要性を不要にした場合、新しいboot.propertiesファイルを作成します。

EDG環境では、boot.propertiesファイルは、MSERVER_HOME/servers/MANAGED_SERVER/security内にあります。
WebLogic管理サーバー、SOAサーバーおよびOracle Identity Governanceサーバーを停止し、起動します。
- Oracle Identity Governanceサーバーの停止をforce=falseオプションを使用して行っている場合、時間がかかる可能性があります。Oracle Identity Governanceサーバーを強制的に停止することをお薦めします。
- patch_oim_wlsスクリプトはリエントラントであり、障害が発生した場合再度実行できます。

サーバーのクリーン再起動の実行

すべてのサーバー(管理サーバーおよび管理対象サーバーを含む)を再起動します。「サーバーとプロセスの起動」を参照してください。

WebLogic Serverセッション・レプリケーションの最大メッセージ・サイズの増加

WebLogic Server管理コンソールにログインします。
「サーバー」に移動し、「プロトコル」を選択して、「一般」をクリックします。
「最大メッセージ・サイズ」の値を100MBに設定します。