6 Oracle Identity Managerのアウトオブプレース・クローン・アップグレードの実行

このガイドに示すアウトオブプレース・アップグレード手順では、Oracle Identity Manager 12c (12.2.1.3.0)からOracle Identity Manager 12c (12.2.1.4.0)へのクローン・アップグレードを実行する方法について説明します。

この章の内容は次のとおりです。

アップグレード前のアセスメント

アップグレード前チェックでは、OIM 12c (12.2.1.4.0)へのクローン・アップグレードを開始する前に、現在のOIM 12c (12.2.1.3.0)環境を確認します。

詳細は、以下のトピックを参照してください。

サポートされているバージョンの確認

Oracle Identity Manager 12c (12.2.1.3.0)を12c (12.2.1.4.0)にアップグレードできます。OIMに最新のバンドルおよび必要なパッチが完全に適用されていることを確認する必要があります。

古いバージョンのOIMを実行している場合は、まず12c (12.2.1.3.0)にアップグレードしてから、12c (12.2.1.4.0)にアップグレードする必要があります。

OAMまたはOAAM (あるいはその両方)との潜在的な統合の確認

Oracle 12cでは、OIMが個別の分離ドメインに存在する必要があります。AccessとGovernanceのスキーマ・セットは異なるため、同じデータベース接頭辞を共有することはできません。そのため、スキーマを共有できません。現在のデプロイメントでOIMがOracle Access Manager (OAM)やOracle Adaptive Access Manager (OAAM)などの他のOracle Identity and Access Management製品と共存している場合は、まずドメインを分離する必要があります。

OIMとOAMを分離する方法の詳細は、「Oracle Identity Managementアプリケーションの複数のドメインへの分離」を参照してください。

ホスト名を使用するためのソース環境の検証

この章で説明するクローニング・ソリューションでは、すべての構成プロパティでIPアドレスを使用するのではなく、ホスト名を使用しています。ソース環境の様々なドメインおよびアプリケーション構成パラメータを検証して、IPアドレスが直接構成されていないことを確認します。IPアドレスが使用中であることが判明した場合、クローニング・プロセスを開始する前にソース環境を更新することをお薦めします。

この項には次のトピックが含まれます:

WebLogic Serverドメイン構成の監査

様々なリスナー、nodemanager、データソース・ホスト/SCAN/ONSパラメータなどのIPアドレスでドメインが構成されていないことを確認します。顧客の構成は範囲が異なり、パラメータの数が多すぎて具体的に列挙できないため、ここでは基本的な監査プロセスのみを示します。既知のホスト名ごと、またはドメイン名、IPアドレス・リスト、ネットワーク範囲でドメイン構成ファイルを単純に検索すると、クイック・レポートが表示されます。

ソース環境には、次のようなホスト・レコードが含まれる場合があります:

# On-Prem Host Entries
10.99.5.42   srchost27.example.com srcHost27   webhost1
10.99.5.43   srchost28.example.com srcHost28   webhost2
10.99.5.44   srchost20.example.com srcHost20  ldaphost1
10.99.5.45   srchost21.example.com srcHost21  ldaphost2
10.99.5.46   srchost23.example.com srcHost23   oamhost1
10.99.5.47   srchost24.example.com srcHost24   oamhost2
10.99.5.48   srchost25.example.com srcHost25   oimhost1
10.99.5.49   srchost26.example.com srcHost26   oimhost2
# Compute VNIC Secondary IP for AdminServer floating VIPs
10.99.5.61 srcVIPiad.example.com srcVIPiad
10.99.5.62 srcVIPigd.example.com srcVIPigd
# Database Systems with on-prem override aliases
10.99.5.20 src-DB-SCAN.example.com src-DB-SCAN
# Load Balancer IP
10.99.5.6  prov.example.com  login.example.com  idstore.example.com  iadadmin.example.com  igdadmin.example.com  iadinternal.example.com  igdinternal.example.com

チェックする値は、コマンドラインで簡単に使用できるようにファイルに書き込むことができます。企業ネットワーク範囲、部分的なドメイン名および関連する可能性のある企業ホストの命名規則からの部分的な文字列を含め、DOMAIN_HOME/configフォルダからすべてのXML構成ファイルの検索を実行します。

cat << EOF > /tmp/domainHostNameSearchList.txt
10.99.
.example.com
srcHost
webhohst
ldaphost
oamhost
oimhost
EOF

cd DOMAIN_HOME/config
find .-name "*.xml" -exec grep -H -f /tmp/domainHostNameSearchList.txt {} \;

これにより、構成のファイル・パス/名前と、テキストが検出された行のリストが生成されます。結果のリストには、マシンおよびリスニング・アドレスのエントリ、JDBC URL、ONSノード・リストのエントリ(Gridlink JDBCドライバを使用している場合)などが含まれます。

./config.xml:    <machine>OIMHOST1</machine>
./config.xml:    <listen-address>OIMHOST1</listen-address>
./config.xml:      <arguments>-Dtangosol.coherence.wka1=OIMHOST1 -Dtangosol.coherence.wka2=OIMHOST2 -Dtangosol.coherence.localhost=OIMHOST1 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089 -Dtangosol.coherence.localport=8089</arguments>
./config.xml:    <machine>OIMHOST1</machine>
./config.xml:    <listen-address>10.99.5.48</listen-address>
./config.xml:    <machine>OIMHOST1</machine>
./config.xml:    <listen-address>OIMHOST1</listen-address>
./config.xml:    <name>OIMHOST2</name>
./config.xml:      <name>OIMHOST2</name>
./config.xml:      <listen-address>srcHost26</listen-address>
./jdbc/mds-soa-jdbc.xml:    <url>jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=src-DB-SCAN.example.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=igdupgdb.example)))</url>
./jdbc/mds-soa-jdbc.xml:    <ons-node-list>src-DB-SCAN.example.com:6200</ons-node-list>
すべてのエントリでホスト名(短縮名または完全修飾名)が使用されていることを確認します。これらは、ターゲット・ホスト・ファイルで確認する必要がある値です。

ノート:

IPアドレスを指定する構成は、クローニングの前にソース・システムで修正する必要があります。
メタデータ・サービス(MDS)に格納されたアプリケーション構成データの監査

Oracle Identity Governanceは、Fusion Middlewareメタデータ・ストア(MDS)データベース・スキーマに構成の詳細を格納します。これらの構成の詳細には、環境をクローニングする前に確認および検証する必要があるエンドポイントURIおよびJDBC接続文字列が含まれます。これらのURIおよび接続文字列で参照されるホストは、IPアドレスではなく、ホスト名または完全修飾ドメイン名(FQDN)として構成する必要があります。IPアドレスが使用されている場合、それらはターゲット環境でオーバーライドできず、クローニング・プロセス中に変更する必要があります。

クローニングのメンテナンスを行う前に、ソース環境を修正し、ハードコードされたIPアドレスを適切なホスト名に置き換えることをお薦めします。

WLSTを使用してOIMの格納済メタデータ構成を監査するには:

  1. ORACLE_HOMEディレクトリに対する権限を持つOSユーザーとして、ソース環境のOIMホストにログインします。
  2. 一時作業ディレクトリを作成します。
    mkdir -p /tmp/mds/oim/
  3. WLSTを介してAdminServerに接続します。
    $ ORACLE_HOME/common/bin/wlst.sh
    wls:/offline> connect()
    Please enter your username :weblogic
    Please enter your password :
    Please enter your server URL [t3://localhost:7001] :t3://ADMINHOST:7001
    Connecting to t3://ADMINHOST:7001 with userid weblogic ...
    Successfully connected to Admin Server 'AdminServer' that belongs to domain 'IAMGovernanceDomain'.
    wls:/IAMGovernanceDomain/serverConfig>
  4. FMWメタデータ・ストアからOIM構成XMLデータをエクスポートし、WLSTを終了します。
    • Application=OIMMetadata
    • server=WLS_OIM1 (実際のサーバー名は異なる場合があります)
    • toLocation=/tmp/mds/oim
    • docs= /db/oim-config.xml

    たとえば:

    wls:/IAMGovernanceDomain/serverConfig> exportMetadata(application='OIMMetadata', server='WLS_OIM1', toLocation='/tmp/mds/oim', docs='/db/oim-config.xml')
    
    Executing operation: exportMetadata.
    
    Operation "exportMetadata" completed. Summary of "exportMetadata" operation is:
    1 documents successfully transferred. 
    List of documents successfully transferred:
    
    /db/oim-config.xml
    
    wls:/IAMGovernanceDomain/serverConfig> exit()
  5. OIM構成から関連データをフィルタするために使用する検索条件のファイルを作成します。エクスポートされたXMLファイルには、多くの構成要素があります。フィルタリングに使用する短いリストを作成します。

    たとえば:

    $ cat << EOF > /tmp/mds/oim/grepHostValidationTerms.txt
    <directDBConfigParams
    bIPublisherURL
    oimFrontEndURL
    oimExternalFrontEndURL
    oimJNDIURL
    backOfficeURL
    accessServerHost
    tapEndpointUrl
    soapurl
    rmiurl
    host
    serviceURL
    EOF
  6. 検索条件を使用してOIM構成データを検索します。

    たとえば:

    $ grep -f /tmp/mds_oim/grepHostValidationTerms.txt /tmp/mds/oim/db/oim-config.xml
    
    <directDBConfigParams checkoutTimeout="1200" connectionFactoryClassName="oracle.jdbc.pool.OracleDataSource" connectionPoolName="OIM_JDBC_UCP" driver="oracle.jdbc.OracleDriver" idleTimeout="360" maxCheckout="1000" maxConnections="5" minConnections="2" passwordKey="OIMSchemaPassword" sslEnabled="false" url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=src-DB-SCAN.example.com )(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=igdupgdb.example)))" username="IGDUPG_OIM" validateConnectionOnBorrow="true">
    <bIPublisherURL>http://OIMHOST2:9704,OIMHOST1:9704</bIPublisherURL>
    <oimFrontEndURL>http://igdinternal.example.com</oimFrontEndURL>
    <oimExternalFrontEndURL>https://prov.example.com:443</oimExternalFrontEndURL>
    <oimJNDIURL>@oimJNDIURL</oimJNDIURL>
    <backOfficeURL/>
    <accessServerHost>srcHost23</accessServerHost>
    <tapEndpointUrl>https://login.example.com:443/oam/server/dap/cred_submit</tapEndpointUrl>
    <soapurl>http://OIMHOST2:8001</soapurl>
    <rmiurl>cluster:t3://cluster_soa</rmiurl>
    <host>@oaacghost</host>
    <serviceURL>@oaacgserviceurl</serviceURL>
  7. 検索結果を確認し、すべての構成プロパティを検証して、適切なホスト名または完全修飾ドメイン名を使用します。

    ノート:

    • 一部のプロパティにはプレースホルダ値がある場合があります(たとえば: @oaacghostまたは@oaacgserviceurl)。これらは使用できます。
    • 指定する<rmiurl> URIは、通常、WLSサーバー名またはクラスタ名を指定するWLS t3プロトコルURIであり、ホスト名は使用しません。これも使用できます。

未使用データのパージ

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

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

データベース内に失効データが多すぎると、アップグレード・スキーマの更新の実行時に問題が発生する可能性があります。アップグレード・プロセスを最適化するために、失効したデータや不要なデータをアップグレード前にパージすることをお薦めします。

たとえば、アーカイブおよびパージ・ユーティリティを使用したデータ増加の制御に関する項の説明に従ってOIMに付属のデータ・パージ・スクリプトを使用すると、サイトで、どのデータを別の場所にアーカイブする必要があり、どのデータをパージできるかを決定でき、これらの操作を管理するためのオプションを選択できます。

ノート:

データ量が多い大規模システムでは、アーカイブ/パージに時間がかかる場合があります。パフォーマンスを向上させるために、アーカイブ/パージ・スクリプトを並行して実行しないことを強くお薦めします。

アウトオブプレース・クローン・アップグレードの実行

Oracle Identity Manager 11.1.2.3から12c (12.2.1.4.0)へのアウトオブプレース・アップグレードには、ホスト・ファイルの準備、データベース、バイナリおよび構成のクローニング、ターゲット・システムのアップグレードが含まれます。

ホスト・ファイルの準備

クローン環境では、ターゲット環境で参照されるホスト名は、ソース・システムのホスト名と同じです。エンタープライズ・デプロイメント・ガイドの推奨事項に従って、すべての構成に仮想ホスト名を使用した場合、これらのエントリを実際のターゲット・ホスト名に別名指定するだけです。たとえば:
10.0.2.17   oimhost1.idm.tenant.oraclevcn.com   oimhost1
ソースWebLogic構成で物理ホスト名を使用している場合、これらの名前を実際のターゲット・ホスト名に別名指定する必要があります。たとえば:
10.0.2.17   oimhost1.idm.tenant.oraclevcn.com   oimhost1   srchost25.example.com srcHost25
また、ソース環境にAdminServerのマシン・リスニング・アドレスおよびノード・マネージャ・ホスト宣言用の追加のフローティングVIPおよびFQDNがある場合、ターゲット・セカンダリIPアドレスを適切なターゲット・コンピュート・インスタンスのVNICで構成し、ホスト・ファイルに追加する必要があります。これらのセカンダリIPアドレス・エントリには、AdminServerへの接続時にDNSをオーバーライドするためのソース環境FQDNおよびホスト名も含める必要があります。
10.0.2.21 igdadminvhn.idm.tenant.oraclevcn.com igdadminvhn srcVIPigd.example.com srcVIPigd
/etc/hostsファイルの例:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

# Compute with on-prem override aliases
10.0.2.11   webhost1.idm.tenant.oraclevcn.com   webhost1   srchost27.example.com srcHost27
10.0.2.12   webhost2.idm.tenant.oraclevcn.com   webhost2   srchost28.example.com srcHost28
10.0.2.13  ldaphost1.idm.tenant.oraclevcn.com  ldaphost1   srchost20.example.com srcHost20
10.0.2.14  ldaphost2.idm.tenant.oraclevcn.com  ldaphost2   srchost21.example.com srcHost21
10.0.2.15   oamhost1.idm.tenant.oraclevcn.com   oamhost1   srchost23.example.com srcHost23
10.0.2.16   oamhost2.idm.tenant.oraclevcn.com   oamhost2   srchost24.example.com srcHost24
10.0.2.17   oimhost1.idm.tenant.oraclevcn.com   oimhost1   srchost25.example.com srcHost25
10.0.2.18   oimhost2.idm.tenant.oraclevcn.com   oimhost2   srchost26.example.com srcHost26

# Compute VNIC Secondary IP for AdminServer floating VIPs
10.0.2.20 iadadminvhn.idm.tenant.oraclevcn.com iadadminvhn srcVIPiad.example.com srcVIPiad
10.0.2.21 igdadminvhn.idm.tenant.oraclevcn.com igdadminvhn srcVIPigd.example.com srcVIPigd

# Database Systems with on-prem override aliases
10.0.2.19  iamdbhost.idm.tenancy.oraclevcn.com  iamdbhost   src-DB-SCAN.example.com src-DB-SCAN

# Load Balancer IP
10.0.1.10  prov.example.com  login.example.com  idstore.example.com  iadadmin.example.com  igdadmin.example.com  iadinternal.example.com  igdinternal.example.com

ノート:

各ターゲット・コンピュート・インスタンスおよびDBホスト/SCANアドレスのエントリが、トポロジ内のすべてのホストのホスト・ファイルに存在することを確認します。

データベースのクローニング

既存の環境のコピーを作成し、そのコピーをアップグレードできます。アップグレード中に問題が発生した場合は、既存の環境がフォールバックとして使用されます。

詳細は、クローン環境を介したアップグレードの実行に関する項を参照してください。

データベースのクローニング方法

データベースのクローニングには様々な方法があり、各方法には独自のメリットがあります。

ノート:

Oracle Identity and Access Management 12cでは、同じデータベース・スキーマ接頭辞を使用するように構成されたOracle Access ManagerおよびOracle Identity Managerはサポートされません。アップグレードする前に、両方の製品が共存し、同じデータベース・スキーマを共有している場合は、まずデータベースを2つの異なる接頭辞とスキーマ・セットに分割する必要があります。

次のオプションを使用して、データベースをクローニングできます:

オプション1 – データベースのエクスポートとインポート

  • 小規模なデータベースに適しています。

  • バージョン間の移動を許可します。たとえば、12.1.0.3から19cです。

  • コンテナ・データベース/プライベート・データベースへの移動を許可します。

  • 完全なコピーです。実行をやり直すには、毎回ターゲットからデータを削除する必要があります。

  • 進行中の同期はありません。

  • カットオーバー中は、ソース・システムを更新のために凍結する必要があります。

オプション2 – RMANを使用したデータベースの複製

  • あらゆるサイズのデータベースに適しています。

  • データベース全体をバックアップします。

  • データベース・バージョンおよびパッチ・レベルは、ソースと宛先の両方で同じである必要があります。

  • データベースのアップグレードは、別のタスクとして実行する必要があります。

  • CDP/PDBの移行は、別の実行として行う必要があります。

  • 進行中の同期はありません。

  • カットオーバー中は、ソース・システムを更新のために凍結する必要があります。

オプション3 – Data Guardデータベース

  • あらゆるサイズのデータベースに適しています。

  • データベース全体をバックアップします。

  • データベースのアップグレードは、別のタスクとして実行する必要があります。

  • CDP/PDBの移行は、別の実行として行う必要があります。

  • 進行中の同期。データベースを開いてアップグレードをテストし、再度閉じてデータとソース・システムの同期を保つことができます。

ノート:

要件に基づいてソリューションを選択する必要があります。

エクスポート/インポート方法を使用したデータベースのクローニング

12c (12.2.1.3)環境で、データベースからエクスポート・ファイルにデータをエクスポートします。

ソース環境の場合:

  1. ソースDBホストでエクスポート・プロセスのディレクトリ詳細を作成および設定します。
    1. 十分な領域がある場所で、ソースDBホストにディレクトリを作成します。
      mkdir -p /u01/installers/database
    2. ソース・データベースで、次の場所を指すデータベース・ディレクトリ・オブジェクトを作成します:
      SQL> CREATE DIRECTORY orcl_full AS '/u01/installers/database';
  2. OIM、SOAおよびBIPのWebLogic Server管理対象サーバーまたはクラスタを停止します。

    ノート:

    ドメイン・バックアップと並行して実行する場合は、AdminServerおよびNodeManagersを含むドメイン全体の停止を調整します。
  3. ソース・データベースのSOA DBMSキューを停止します。
    1. SOAINFRAスキーマ・ユーザーとして接続し、ユーザー・キューを問い合せます。
      $ sqlplus <PREFIX>_SOAINFRA@<sourceDB>
      SQL> COLUMN name FORMAT A32
      SQL> SELECT name,enqueue_enabled,dequeue_enabled  
      FROM USER_QUEUES where queue_type = 'NORMAL_QUEUE' order by name;
      NAME                             ENQUEUE DEQUEUE
      -------------------------------- ------- -------
      B2B_BAM_QUEUE                     YES        YES
      EDN_EVENT_QUEUE                   YES        YES
      EDN_OAOO_QUEUE                    YES        YES
      IP_IN_QUEUE                       YES        YES
      IP_OUT_QUEUE                      YES        YES
      TASK_NOTIFICATION_Q               YES        YES
      
      6 rows selected.
    2. 各キューを停止します。
      SQL> BEGIN
      
      DBMS_AQADM.STOP_QUEUE ('B2B_BAM_QUEUE');
      
      DBMS_AQADM.STOP_QUEUE ('EDN_OAOO_QUEUE');
      
      DBMS_AQADM.STOP_QUEUE ('EDN_EVENT_QUEUE');
      
      DBMS_AQADM.STOP_QUEUE ('IP_IN_QUEUE');
      
      DBMS_AQADM.STOP_QUEUE ('IP_OUT_QUEUE');
      
      DBMS_AQADM.STOP_QUEUE ('TASK_NOTIFICATION_Q');
      
      END;
      
      /
      exit
  4. OIMスキーマ・ユーザーとして、ソース・データベースで実行中のDBMS_SCHEDULERジョブを問い合せて停止します。
    $ sqlplus <PREFIX>_OIM@<sourceDB>
    
    SQL> SELECT job_name,session_id,running_instance,elapsed_time 
    FROM user_scheduler_running_jobs ORDER BY job_name;
    
    no rows selected

    ノート:

    実行中のジョブがある場合は、ジョブが完了するまで待機するか、次を使用してジョブを正常に停止します:

    SQL> BEGIN
    
    DBMS_SCHEDULER.stop_job('REBUILD_OPTIMIZE_CAT_TAGS');
    
    END;
    
    /
    SQL> exit
  5. データポンプのエクスポート・ジョブ中のエラーを回避するために、システム・ポリシーを付与します。
    $ sqlplus SYS as SYSDBA
    SQL> GRANT EXEMPT ACCESS POLICY TO SYSTEM;
    SQL> exit
  6. ソース・データベースからシステム・スキーマおよびアプリケーション・スキーマをエクスポートし、ディレクトリ・プロパティを適切に設定します。
    1. system.schema_version_registry表およびビューをエクスポートします:
      $ expdp \"sys/<password>@<sourcedb> as sysdba \" \
           DIRECTORY=orcl_full \
           DUMPFILE=oim_system.dmp \
           LOGFILE=oim_system_exp.log \
           SCHEMAS=SYSTEM \
           INCLUDE= VIEW:"IN('SCHEMA_VERSION_REGISTRY')" TABLE:"IN('SCHEMA_VERSION_REGISTRY$')"\
           JOB_NAME=MigrationExportSys
    2. ソースWebLogicServerドメインのデータソースで使用されるすべてのスキーマをエクスポートします。
      $ expdp \"sys/<password>@<sourcedb> as sysdba \" \
           DIRECTORY=orcl_full \
           DUMPFILE=oim.dmp \
           LOGFILE=oim_exp.log \
           SCHEMAS=<PREFIX>_OIM,<PREFIX>_SOAINFRA,<PREFIX>_BIPLATFORM,<PREFIX>_MDS,<PREFIX>_ORASDPM,<PREFIX>_OPSS,IGDJMS,IGDTLOGS \
           JOB_NAME=MigrationExport \
           EXCLUDE=STATISTICS
  7. 表領域、スキーマ・ユーザーおよび権限付与のソース・データベースDDLを抽出します。

    このステップでは、ターゲット・データベースに正しい表領域を効率的に作成し、スキーマ・ユーザーのパスワードを保持できます。したがって、ドメインの再構成は必要ありません。エクスポートされたスキーマ外のオブジェクトに対するシステム権限およびオブジェクト権限は、無効なオブジェクトや再コンパイルの問題のリスクを軽減するためにも考慮されます。

    完全なSQL DDL出力を一度に作成するサンプル・スクリプトが用意されています。CDB/PDBを使用しない場合は、この例を変更する必要があります。

    1. SQLPLUSで、SQLスクリプトの例を実行して、データポンプ・エクスポート・ダンプと同じディレクトリにあるddl.sqlファイルにDDLを抽出します。ソース環境およびターゲットPDBを入力します。出力は、画面とddl.sqlという名前のファイルの両方にコピーされます。.
      $ cd /u01/installers/database
      $ sqlplus SYS as SYSDBA
      SQL> @extract_ddl.sql
      Enter RCU Prefix: <PREFIX>
      Enter PDB: targetPDB

      SQLスクリプトの例:

      ノート:

      太字の行は、ターゲット・データベースがPDBの場合にのみ適用されます。このSQLでは、すべてのオブジェクトがRCU接頭辞を使用して作成されていることを前提としています。接頭辞なしでオブジェクトを作成した場合(JMSまたはTLogsの表領域/ユーザーなど)、これらを手動で追加します。
      $ cat << EOF > extract_ddl.sql
      set pages 0
      set feedback off
      set heading off
      set long 5000
      set longchunksize 5000
      set lines 200
      set verify off
      exec dbms_metadata.set_transform_param (dbms_metadata.session_transform, 'SQLTERMINATOR', true);
      exec dbms_metadata.set_transform_param (dbms_metadata.session_transform, 'PRETTY', true);
      accept PREFIX char prompt 'Enter RCU Prefix:'
      accept PDBNAME char prompt 'Enter PDB:'
      
      spool ddl.sql
      
      select 'alter session set container=&&PDBNAME;'
      from dual
      /
      SELECT DBMS_METADATA.GET_DDL('TABLESPACE',Tablespace_name)
      from  dba_tablespaces
      where tablespace_name like '&&PREFIX%'
      /
      set lines 600
      SELECT DBMS_METADATA.GET_DDL('USER',USERNAME)
      from DBA_USERS
      where USERNAME like '&&PREFIX%'
      /
      set lines 200
      SELECT DBMS_METADATA.GET_GRANTED_DDL ('SYSTEM_GRANT',USERNAME)
      from DBA_USERS
      where USERNAME like '&&PREFIX%'
      and USERNAME NOT LIKE '%_IAU_APPEND'
      and USERNAME NOT LIKE '%_IAU_VIEWER'
      /
      
      SELECT DBMS_METADATA.GET_GRANTED_DDL ('OBJECT_GRANT',USERNAME)
      from DBA_USERS
      where USERNAME like '&&PREFIX%'
      and USERNAME NOT LIKE '%TLOGS'
      and USERNAME NOT LIKE '%JMS'
      /
      
      spool off
      EOF
    2. 出力ddl.sql内のシステムQT*_BUFFERビューに対するオブジェクト権限を削除します。バッファ・ビューはターゲット・データベースに存在しないため、エラーが発生します。
      $ sed -i.bak -e '/QT.*_BUFFER/d' /u01/installers/database/ddl.sql
  8. SOA DBMSキューを再起動します。SOAINFRAスキーマ・ユーザーとして接続し、以前に停止した各キューを再起動します。
    $ sqlplus <PREFIX>_SOAINFRA@sourceDB
    SQL> BEGIN
    
    DBMS_AQADM.START_QUEUE ('B2B_BAM_QUEUE');
    
    DBMS_AQADM.START_QUEUE ('EDN_OAOO_QUEUE');
    
    DBMS_AQADM.START_QUEUE ('EDN_EVENT_QUEUE');
    
    DBMS_AQADM.START_QUEUE ('IP_IN_QUEUE');
    
    DBMS_AQADM.START_QUEUE ('IP_OUT_QUEUE');
    
    DBMS_AQADM.START_QUEUE ('TASK_NOTIFICATION_Q');
    
    END;
    
    /
    SQL> COLUMN name FORMAT A32
    SQL> SELECT name,enqueue_enabled,dequeue_enabled  
    FROM USER_QUEUES where queue_type = 'NORMAL_QUEUE' order by name;
    
    NAME                             ENQUEUE DEQUEUE
    -------------------------------- ------- -------
    B2B_BAM_QUEUE                     YES        YES
    EDN_EVENT_QUEUE                   YES        YES
    EDN_OAOO_QUEUE                    YES        YES
    IP_IN_QUEUE                       YES        YES
    IP_OUT_QUEUE                      YES        YES
    TASK_NOTIFICATION_Q               YES        YES
    
    6 rows selected.
    SQL> exit
  9. OIM、SOAおよびBIPのWebLogic Server管理対象サーバーまたはクラスタを再起動します。
  10. DDL SQLおよびデータポンプ・ダンプ・ファイルをターゲット・データベース・ホストにレプリケートします。
    • oim.dmp
    • oim_system.dmp
    • ddl.sql

ターゲット環境の場合:

  1. FMW要件に従って、ターゲット・データベースを十分にインストール/構成します。使用するOracleデータベースのバージョンをターゲット環境にインストールします。このデータベースは、単一インスタンス・データベース、Real Application Cluster (RAC)データベース、標準データベース、または別のプラガブル・データベース(PDB)にOIGを含むコンテナ・データベースのいずれかです。
  2. 『Oracle Identity and Access Managementのインストールおよび構成』Oracle Identity Governanceソフトウェアのインストールおよび構成に関する項で定義されているように、ターゲット・データベースがOracle Identity Managerのすべての基準を満たすように構成されていることを確認します。
  3. 必要に応じて、ターゲット・システムにプラガブル・データベースのTNSエントリを作成します。たとえば:
    IGDPDB =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)
                     (HOST = iamdbhost.idm.tenancy.oraclevcn.com)
                     (PORT = 1521)
          )
          (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = igdpdb.idm.tenancy.oraclevcn.com)
          )
         )
  4. ソースDBホストでエクスポート・プロセスのディレクトリ詳細を作成および設定します。
    1. 十分な領域がある場所で、ターゲットDBホストにディレクトリを作成します。
      $ mkdir -p /u01/installers/database
    2. ソース・データベースと宛先データベースのこの場所を指すデータベース・ディレクトリ・オブジェクトを作成します。
      SQL> CREATE DIRECTORY orcl_full AS '/u01/installers/database';
  5. トランザクションをロールバックする必要がある場合に備えて、データベース・リストア・ポイントを作成します。
  6. ソース環境と同じサービス名で、新しいデータベースのデータベース・サービスを作成して起動します。

    たとえば:

    $ srvctl add service -db iamcdb -pdb igdpdb -service onpremservice -rlbgoal SERVICE_TIME -clbgoal SHORT 
    $ srvctl start service -db iamcdb -service onpremservice 
    $ srvctl status service -db iamcdb -service onpremservice
  7. エクスポートされたデータポンプ・ダンプ・ファイルとSQLファイルが、ターゲット・データベース・ホストの正しいディレクトリで使用可能であり、データベースのDBAディレクトリ名とパスが一致していることを確認します。
    $ ls -al /u01/installers/database
    $ sqlplus / as sysdba
    SQL> ALTER SESSION SET CONTAINER = igdpdb;
    SQL> CREATE DIRECTORY orcl_full AS '/u01/installers/database';

    検証するには:

    $ sqlplus / as sysdba
    SQL> ALTER SESSION SET CONTAINER = igdpdb;
    
    SQL> COLUMN directory_name FORMAT A32
    SQL> COLUMN directory_path FORMAT A64
    SQL> set linesize  128
    SQL> SELECT directory_name,directory_path FROM dba_directories ORDER BY directory_name;
  8. 必要なDBMS_SHARED_POOLおよびXATRANSデータベース・オブジェクトが存在することを確認し、存在しない場合は作成します。OIMスキーマ・エクスポート・ダンプをリストアするターゲット・データベースで、次の各SQLのカウントが2であることを確認します。
    SQL> SELECT COUNT(*) FROM dba_objects 
    WHERE owner = 'SYS' AND object_name = 'DBMS_SHARED_POOL' 
    AND object_type IN ('PACKAGE','PACKAGE BODY');
    
      COUNT(*)
    ----------
             2
    
    SQL> SELECT COUNT(*) FROM dba_objects 
    WHERE owner = 'SYS' AND object_name like '%XATRANS%';
    
      COUNT(*)
    ----------
             0
    1. DBMS_SHARED_POOLカウントが2未満の場合は、適切なSQLを実行して再構成します。
      SQL> @/u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/admin/dbmspool.sql
      SQL> @/u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/admin/prvtpool.plb
    2. XATRANSカウントが2未満の場合は、適切なSQLを実行して再構成します:
      SQL> @/u01/app/oracle/product/19.0.0.0/dbhome_1/rdbms/admin/xaview.sql
  9. ソース・データベースのシステム・ダンプを正しいフォルダからインポートしてschema_version_registry表およびビューを作成し、SQLを使用して必要なパブリック・シノニムを手動で作成します。
    $ cd /u01/installers/database
    $ impdp \"SYS/<password>@<targetdb> AS SYSDBA\" \
        PARALLEL=4 
        DIRECTORY=orcl_full \
        DUMPFILE=oim_system.dmp \
        LOGFILE=oim_system_imp.log \
        FULL=YES;
    
    $ sqlplus / as sysdba
    
    SQL> alter session set container=igdpdb;
    SQL> CREATE PUBLIC SYNONYM schema_version_registry FOR system.schema_version_registry;
    SQL> exit
  10. schema_version_registry表のデータがソース環境と一致することを確認します。デプロイメントと一致する行が次の問合せによって返されることを確認することが重要です。この表は、前述のステップの一部としてインポートされている必要があります。失敗した場合は、ソース・システムの値を表に移入する必要があります。
    $ sqlplus / as sysdba
    SQL> alter session set container=igdpdb;SQL> set linesize 100
    SQL> col comp_id for a10
    SQL> col comp_name for a50
    SQL> col version for a10
    SQL> select comp_id, comp_name, version, status, upgraded 
    from system.schema_version_registry;
    
    Output will look something like: 
    
    COMP_ID    COMP_NAME                                          VERSION    STATUS      U
    ---------- -------------------------------------------------- ---------- ----------- -
    BIPLATFORM OracleBI and EPM                                   11.1.1.9.0 VALID       N
    MDS        Metadata Services                                  11.1.1.9.0 VALID       N
    OIM        Oracle Identity Manager                            11.1.2.3.0 VALID       N
    OPSS       Oracle Platform Security Services                  11.1.1.9.0 VALID       N
    ORASDPM    SDP Messaging                                      11.1.1.9.0 VALID       N
    SOAINFRA   SOA Infrastructure Services                        11.1.1.9.0 VALID       N
  11. ソース・データベースからDDL SQLを実行して、必要な表領域、同じパスワードを持つスキーマ・ユーザー、システム権限およびオブジェクト権限を作成します。PDBを使用している場合、コンテナが正しく設定されていることを確認します。
    $ sqlplus / as sysdba
    SQL> alter session set container=igdpdb;
    SQL> @'/u01/installers/database/ddl.sql'
    SQL> exit
  12. アプリケーション・スキーマをインポートします。

    ノート:

    事前作成されたユーザーが原因でORA-31684エラーが発生します。次のタイプのエラーは無視してください:

    • プロシージャ/パッケージ/ファンクション/トリガーのコンパイル警告
    • DBMS_AQエラー
    • ORA-31684: オブジェクト・タイプUSER:""はすでに存在します

    たとえば:

    $ cd /u01/installers/database
    $ impdp \"SYS/<password>@<targetdb> AS SYSDBA\" \
        PARALLEL=4 \
        DIRECTORY=orcl_full \
        DUMPFILE=oim.dmp \
        LOGFILE=oim_imp.log 
        FULL=YES;
  13. インポートされたスキーマの無効なオブジェクトを問い合せ、無効なオブジェクトを含むスキーマごとに再コンパイルを実行します。

    たとえば:

    $ sqlplus / as sysdba
    SQL> alter session set container=igdpdb;
    SQL> COLUMN owner       FORMAT A24
    SQL> COLUMN object_type FORMAT A12
    SQL> COLUMN object_name FORMAT A32
    SQL> SET LINESIZE 128
    SQL> SET PAGESIZE 50
    
    SQL> SELECT owner,object_type,object_name, status
    FROM   dba_objects
    WHERE  status = 'INVALID'
    AND owner like '<PREFIX>'
    ORDER BY owner, object_type, object_name;
    
    OWNER                    OBJECT_TYPE  OBJECT_NAME                      STATUS
    ------------------------ ------------ -------------------------------- -------
    IGDUPG_OIM               SYNONYM      ALTERNATE_ADF_LOOKUPS            INVALID
    IGDUPG_OIM               SYNONYM      ALTERNATE_ADF_LOOKUP_TYPES       INVALID
    IGDUPG_OIM               SYNONYM      FND_LOOKUPS                      INVALID
    IGDUPG_OIM               SYNONYM      FND_STANDARD_LOOKUP_TYPES        INVALID
    
    SQL> EXECUTE UTL_RECOMP.RECOMP_SERIAL('IGDUPG_OIM');
    
    SQL> SELECT owner,object_type,object_name, status
    FROM   dba_objects
    WHERE  status = 'INVALID'
    AND owner like '<PREFIX>'
    ORDER BY owner, object_type, object_name;
    
    no rows selected
  14. SOA DBMSキューを開始します。
    1. SOAINFRAスキーマ・ユーザーとして接続し、ユーザー・キューを問い合せます。
      $ sqlplus <PREFIX>_SOAINFRA@<sourceDB>
      SQL> COLUMN name FORMAT A32
      SQL> SELECT name,enqueue_enabled,dequeue_enabled  FROM USER_QUEUES where queue_type = 'NORMAL_QUEUE' order by name;
      
      NAME                             ENQUEUE DEQUEUE
      -------------------------------- ------- -------
      B2B_BAM_QUEUE                     YES        YES
      EDN_EVENT_QUEUE                   YES        YES
      EDN_OAOO_QUEUE                    YES        YES
      IP_IN_QUEUE                       YES        YES
      IP_OUT_QUEUE                      YES        YES
      TASK_NOTIFICATION_Q               YES        YES
      
      6 rows selected.
    2. 各キューを開始します。
      SQL> BEGIN
      
      DBMS_AQADM.START_QUEUE ('B2B_BAM_QUEUE');
      
      DBMS_AQADM.START_QUEUE ('EDN_OAOO_QUEUE');
      
      DBMS_AQADM.START_QUEUE ('EDN_EVENT_QUEUE');
      
      DBMS_AQADM.START_QUEUE ('IP_IN_QUEUE');
      
      DBMS_AQADM.START_QUEUE ('IP_OUT_QUEUE');
      
      DBMS_AQADM.START_QUEUE ('TASK_NOTIFICATION_Q');
      
      END;
      
      /
      exit
RMANを使用したデータベースのクローニング

RMANを使用して、ソース環境からターゲット環境にデータベースをクローニングします。RMANを使用したデータの送信に関する項を参照してください。

Data Guardを使用したデータベースのクローニング

Data Guardを使用して、フィジカル・スタンバイ・データベースを手動で作成できます。『Oracle Data Guard概要および管理』フィジカル・スタンバイ・データベースの作成に関する項を参照してください。

Oracleバイナリのクローニング

任意のバックアップ/リストア・ツールを使用して、MW_HOMEバイナリおよびOraInventoryディレクトリをアーカイブおよび転送します。

この項には次のトピックが含まれます:

バックアップ/リストア・ツールを使用したOracle Identity Managerドメインのクローニング

ノート:

この実行では、使い慣れた任意のバックアップおよびリストア・ツールを使用できます。次の例では、tarツールを使用します。ただし、ディレクトリとサブディレクトリをバックアップおよびリストアできるコマンドは使用できます。ドメインおよびNodeManagersをオンラインまたはオフラインでバックアップできます。ただし、すべてのFMWプロセスを停止した状態でバックアップを実行することをお薦めします。

バックアップの作成:

次のステップに従って、ソース環境のバイナリとOracle Inventoryのバックアップを作成します:

  1. 任意のバックアップ・ツールを使用して、ソース環境の次のディレクトリのバックアップを作成します:

    • oraInventory

    • MW_HOME

    たとえば、OAMHOST1のコマンドは次のようになります:

    tar cfzP /u01/oracle/backups/oamhost1_binaries.tar.gz /u01/oracle/oraInventory MW_HOME
  2. 別の製品バイナリ・ボリュームを使用して、追加ノードでコマンドを繰り返します。

    ノート:

    Oracle製品のMW_HOMEの場所に共有ファイルシステム・ボリュームを使用する場合は、ボリュームごとに1つのホストからバイナリ・バックアップのみを取得する必要があります。

    たとえば、OAMHOST2のコマンドは次のようになります:

    tar cfzP /u01/oracle/backups/oamhost2_binaries.tar.gz /u01/oracle/oraInventory MW_HOME
  3. 結果のバックアップ・ファイルを適切なターゲット環境ホストにコピーします。

バックアップのリストア

任意の抽出ツールを使用して、バックアップをターゲット環境ノードに抽出します。

ノート:

Oracle製品のMW_HOMEの場所に共有ファイルシステム・ボリュームを使用する場合、バイナリ・バックアップのみをボリュームごとに1つのホストにリストアする必要があります。

たとえば:

OAMHOST1で、次のコマンドを実行します:

tar xvfzP oamhost1.tar.gz

OAMHOST2で、次のコマンドを実行します:

tar xvfzP oamhost2.tar.gz

構成のクローニング

任意のバックアップ/リストア・ツールを使用して、構成をクローニングします。

この項には次のトピックが含まれます:

バックアップ/リストア・ツールを使用したOracle Identity Managerドメインのクローニング

ノート:

この実行では、使い慣れた任意のバックアップおよびリストア・ツールを使用できます。次の例では、tarツールを使用します。ただし、ディレクトリとサブディレクトリをバックアップおよびリストアできるコマンドは使用できます。ドメインおよびNodeManagersをオンラインまたはオフラインでバックアップできます。ただし、すべてのFMWプロセスを停止した状態でバックアップを実行することをお薦めします。

バックアップの作成:

次のステップを実行して、ソース環境のバイナリとOracle Inventoryのバックアップを作成します:

  1. 任意のバックアップ・ツールを使用して、ソース・サイトのOIMHOST1から次の場所のバックアップを作成します:

    • oraInventory

    • Nodemanager

    • アプリケーション・サーバーのドメイン・ホーム(ASERVER_HOME)

    • エンタープライズ・デプロイメント・ガイドで説明されているように、別の場所がある場合は管理対象サーバーのドメイン・ホーム(MSERVER_HOME)

    • Keystores

    • ランタイム・ディレクトリ

    ノート:

    エンタープライズ・デプロイメント・ガイドで説明されているように、分離されたものではなく結合されたDOMAIN_HOMEがある場合は、ASERVER_HOMEおよびMSERVER_HOMEではなくDOMAIN_HOMEを含めます。

    たとえば、OIMHOST1のコマンドは次のようになります:

    tar cvzPpsf oimhost1.tar.gz \
       /u01/oracle/oraInventory \
       /u01/oracle/config/nodemanager/OIMHOST1 \
       /u01/oracle/config/nodemanager/OIMHOST2 \
       /u01/oracle/config/nodemanager/IGDADMINVHN \
       /u01/oracle/config/keystores \
       /u01/oracle/runtime/domains/IAMGovernanceDomain \
       /u01/oracle/config/domains/IAMGovernanceDomain \
       /u02/private/oracle/config/domains/IAMGovernanceDomain
  2. 追加ノードでコマンドを繰り返します。たとえば、OIMHOST2のコマンドは次のようになります:

    tar cvzPpsf OIMHOST2.tar.gz /u02/private/oracle/config/domains/IAMGovernanceDomain
  3. 結果のバックアップ・ファイルを適切なターゲット環境ホストにコピーします。

  4. ソース環境からレプリケートされたドメイン内のロック・ファイルおよびログ・ファイルを削除します。

    • 次のコマンドを実行して、適切なクローン環境ホスト上のすべてのNodeManagerフォルダのロック・ファイルを削除します:

      find /u01/oracle/config/nodemanager -type f -name "*.lck" -exec rm -f {} \;

    • 次のコマンドを実行して、適切なクローン環境ホストのASERVER_HOMEおよびMSERVER_HOMEフォルダからロック・ファイルを削除します:

      ノート:

      エンタープライズ・デプロイメント・ガイドで説明されているように、分離されたものではなく結合されたDOMAIN_HOMEがある場合は、ASERVER_HOMEおよびMSERVER_HOMEではなくDOMAIN_HOMEを含めます。

      たとえば、OIMHOST1で次のコマンドを実行します:

      # Lock Files Cleanup:
      
      find /u01/oracle/config/nodemanager -type f -name "*.lck" -exec rm -f {} \;
      
      find  /u01/oracle/config/domains/IAMGovernanceDomain \
          -type f  \( -name "*.lck" -or -name "*.lok" \) -print -exec rm -f {} \;
      
      find  /u02/private/oracle/config/domains/IAMGovernanceDomain \
          -type f  \( -name "*.lck" -or -name "*.lok" \) -print -exec rm -f {} \;
      
      # Log File Cleanup:
      
      find /u01/oracle/config/nodemanager/OIMHOST1 \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
      
      find /u01/oracle/config/nodemanager/OIMHOST2 \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
      
      find /u01/oracle/config/nodemanager/IGDADMINVHN \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
      
      find ${ASERVER_HOME}/servers/AdminServer/logs \
          -type f ! -size 0c -print -exec rm -f {} \+
      
      find ${MSERVER_HOME}/servers/*/logs \
          -type f ! -size 0c -print -exec rm -f {} \+

      たとえば、OIMHOST2で次のコマンドを実行します:

      # Lock Files Cleanup:
      
      find  /u02/private/oracle/config/domains/IAMGovernanceDomain \
          -type f  \( -name "*.lck" -or -name "*.lok" \) -print -exec rm -f {} \;
      
      # Log File Cleanup:
      
      find ${MSERVER_HOME}/servers/*/logs \
          -type f ! -size 0c -print -exec rm -f {} \+
    • オプションで、クローン・ドメインのNodeManagerおよび管理対象サーバーのフォルダから古いログ・ファイルを削除します:

      たとえば、OIMHOST1で次のコマンドを実行します:

      find /u01/oracle/config/nodemanager/OIMHOST1 \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
      find /u01/oracle/config/nodemanager/OIMHOST2 \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
      
      find /u01/oracle/config/nodemanager/IGDADMINVHN \
          -type f \( -name '*.log' -or -name '*.out' \) -print -exec rm -f {} \;
       
      find ASERVER_HOME/servers/AdminServer/logs \
          -type f ! -size 0c -print -exec rm -f {} \+
       
      find MSERVER_HOME/servers/*/logs \
          -type f ! -size 0c -print -exec rm -f {} \+
      

      たとえば、OIMHOST2で次のコマンドを実行します:

      find MSERVER_HOME/servers/*/logs \ -type f ! -size 0c -print -exec rm -f {} \+

クローン環境でのバックアップのリストア

任意の抽出ツールを使用して、バックアップをターゲット環境ノードに抽出します。

ノート:

tarを使用する場合は、権限およびルート・パスを保持してください。

たとえば:

OIMHOST1で、次のコマンドを実行します:

tar xvzPpsf oimhost1.tar.gz

OIMHOST2で、次のコマンドを実行します:

tar xvzPpsf oimhost2.tar.gz

OIMドメインの起動

バックアップをターゲット環境インスタンスに正常にリストアした後、次のことを実行してドメインを起動します:

  • ASERVER_HOMEのノード・マネージャを起動します。
  • すべてのノードでMSERVER_HOMEのノード・マネージャを起動します。

    ノート:

    単一のDOMAIN_HOMEがある場合は、そのDOMAIN_HOMEに関連付けられているノード・マネージャを起動します。
  • 管理サーバーを起動し、ログを確認します。
  • SOA管理対象サーバー/クラスタを起動し、ログを確認します。
  • Business Intelligence Platform管理対象サーバー/クラスタを起動し、ログを確認します。
  • OIM管理対象サーバー/クラスタを起動し、ログを確認します。
OIM LDAP統合された完全リコンシリエーション・ジョブの実行

ドメインをクローニングした後、完全リコンシリエーション・ジョブを実行する必要があります。『Oracle Identity Manager管理者ガイド』ジョブに関する項を参照してください。

リコンシリエーション・ジョブを実行するには:

ノート:

リコンシリエーション・ジョブを実行する必要があるのは、12.2.1.3設定でLDAPコネクタを使用している場合のみです。アップグレードの完了後にLDAPSyncが無効になるため、設定でLDAPSyncを使用している場合、このステップは必要ありません。
  1. https://igdadmin.example.com/sysadminにログインし、xelsysadmとして認証します。
  2. 左ペインの「システム構成」で、「スケジューラ」をクリックします。ポップアップ・ウィンドウが表示されます。
  3. 「アイデンティティ・システム管理」ポップアップ・ウィンドウで、スケジュール済ジョブ「LDAP統合された完全リコンシリエーション」を検索します。
  4. 検索結果の「LDAP統合された完全リコンシリエーション」のエントリをクリックして、ジョブの詳細を表示します。
  5. 「即時実行」をクリックしてジョブを実行し、確認メッセージ「ジョブは実行中です」を確認します。
  6. 定期的に「リフレッシュ」ボタンをクリックして、ジョブ・ステータスを確認します。
  7. 「ジョブ・ステータス」に「停止済」が表示されたら、「実行ステータス」が「成功」であることを確認します。ログを確認し、必要に応じてトラブルシューティングを行います。
  8. 「イベント管理」タブをクリックし、最近のすべてのリコンシリエーション・イベントに対して空の検索を実行します。
  9. イベントをスポットチェックして、現在のステータスが「作成に成功しました」または「更新に成功しました」であることを確認します。

インプレース・クローン環境の12cへのアップグレード

12c (12.2.1.3)ドメインをターゲット・システムにクローニングした後で、ターゲット・システムをOracle 12.2.1.4.0にアップグレードできます。手順については、次を参照してください:

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

アップグレード後のタスクの一環として、最大メッセージ・サイズをデフォルト値の10MBから100MBに変更することをお薦めします。この値は、ノード間でセッション・データをレプリケートするために使用されます。

すべての管理対象サーバーおよび管理サーバーに対してこのステップを実行する必要があります。

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

setDomainEnv.shのmaxdepth値を増やす

maxdepthパラメータの推奨値は250です。この値を更新するには:
  1. テキスト・エディタで$DOMAIN_HOME/bin/setDomainEnv.shファイルを開きます。
  2. 次のコード・ブロックを探します。
    ALT_TYPES_DIR="${OIM_ORACLE_HOME}/server/loginmodule/wls,${OAM_ORACLE_HOME}/a
    gent/modules/oracle.oam.wlsagent_11.1.1,${ALT_TYPES_DIR}"
    export ALT_TYPES_DIR
    CLASS_CACHE="true"
    export CLASS_CACHE
  3. 前述のコード・ブロックの最後に次の行を追加します。
    JAVA_OPTIONS="${JAVA_OPTIONS} -Dweblogic.oif.serialFilter=maxdepth=250"
    export JAVA_OPTIONS
  4. setDomainEnv.shファイルを保存して閉じます。