プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Data Integratorのアップグレード
12c (12.2.1.0)
E72515-01
目次へ移動
目次
前
前 		次
次

7 既存のOracle Data Integrator環境のアップグレード

この手順では、既存のOracle Data Integrator環境を、このリリースのOracle Data Integratorにアップグレードする際の具体的な手順について説明します。

7.1 Oracle Data Integratorのアップグレードの準備

この項では、Oracle Data Integrator 12c (12.2.1.0)へのアップグレードを開始する前に実行する必要がある重要なタスクを説明します。

注意:

「Oracle Fusion Middlewareのアップグレード前チェックリスト」で説明されているアップグレード前に必要な全タスクを完了してください

7.1.1 既存のマスターおよび作業リポジトリのクローニング

アップグレード・プロセスの開始前にオリジナルのODIマスターおよび作業リポジトリのそれぞれをコピー(クローニング)することをお薦めします。マスター・リポジトリのアップグレード・プロセスの間に、アップグレードするマスター・リポジトリをアップグレード・アシスタントで選択できます。

次の項では、ODIリポジトリのホストをサポートするデータベースについて、基本的なスキーマのクローニング手順を説明します。詳細は、各データベースのドキュメントを参照してください。

注意:

この項の目的は、アップグレード・プロセスの開始前に11gリポジトリのそれぞれをクローニング(コピー)することの重要性について強調することです。この項に記載されているクローニング手順は、11gでサポートされているデータベースごとのサンプルの手順です。これらの手順は制限なく使用できます。常に、要求に合ったクローニング手順を使用してください。

7.1.1.1 Oracle Databaseでのスキーマのクローニング・プロセス

ODI用にOracle Databaseスキーマをクローニングするには、次の手順を実行します。

  1. Oracleエクスポート・ユーティリティ(exp)を使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。
    exp userid=odi_master_11g/odi_master_11g file=/tmp/odi_master_11g.dmp
exp userid=odi_work_11g/odi_work_11g file=/tmp/odi_work_11g.dmp
exp userid=odi_work1_11g/odi_work1_11g file=/tmp/odi_work1_11g.dmp

    Datapumpユーティリティ(expdp)を使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。

    expdp odi_tmp/odi_tmppwd schemas=odiw11117 dumpfile=odiw11117.dmp
  2. SQL*Plusを使用して、クローンのマスターおよび作業スキーマを作成し、接続権限とリソース権限を付与します。次に例を示します。
    create user odi_master_11g_cp identified by odi_master_11g_cp;
create user odi_work_11g_cp identified by odi_work_11g_cp;
create user odi_work1_11g_cp identified by odi_work1_11g_cp;
grant connect,resource to odi_master_11g_cp, odi_work_11g_cp, odi_work1_11g_cp;
  3. Oracleインポート(imp)を使用して、ODI 11gのマスターおよび作業スキーマ・ダンプをクローニングされたマスターおよび作業スキーマにインポートします。次に例を示します。
    imp userid='system/manager' touser=odi_master_11g_cp fromuser=odi_master_11g file=/tmp/odi_master_11g.dmp
imp userid='system/manager' touser=odi_work_11g_cp fromuser=odi_work_11g file=/tmp/odi_work_11g.dmp
imp userid='system/manager' touser=odi_work1_11g_cp fromuser=odi_work1_11g file=/tmp/odi_work1_11g.dmp

    Datapumpユーティリティ(impdp)を使用して、ODI 11gのマスターおよび作業スキーマをインポートします。次に例を示します。

    impdp ODI_TMP/ODI_TMPPWD dumpfile=odim11117 remap_tablespace=repo11117:odi11g remap_schema=odim11117:odim1113

    impdpを使用して、データ・ストレージのスキーマ名と表領域を変更することもできます。remap_xxパラメータはオプションです。

7.1.1.2 MySQLデータベースでのスキーマのクローニング・プロセス

次の手順は、MySQLデータベース・スキーマをクローニングするために使用できます。

  1. mysqldumpを使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。
    mysqldump -h localhost -u root -p DEV_ODI_REPO > /scratch/dump.sql
  2. mysqlを使用して、ODIスキーマを新しいスキーマにリストアします。次に例を示します。

    最初に、クローニングされたスキーマを作成します。

    mysql -h localhost -u root -p
create schema NEW_ODI_REPO default character set=utf8 default collate=utf8_bin;

    その後、ODIスキーマをクローニングされたスキーマにインポートします。

    mysql -h localhost -u root -p NEW_ODI_REPO < /scratch/dump.sql
  3. mysqlを使用して、クローニングされたスキーマのログインを作成します。次に例を示します。
    mysql -h localhost -u root -p
grant all on NEW_ODI_REPO.* to NEW_ODI_REPO1@'localhost' identified by 'password';
grant process on *.* to NEW_ODI_REPO1@'localhost'

7.1.1.3 Microsoft SQL Serverデータベースでのスキーマのクローニング・プロセス

Microsoft SQL 2005/2008データベース・スキーマをクローニングするには、次の手順を実行します。

  1. SQL Management Studioを使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。

    例:

    BACKUP DATABASE [odi_11g] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\odi_11g.bak' WITH INIT, NOSKIP;

  2. SQL Management Studioを使用して、マスターおよび作業スキーマを新しいデータベースでリストアします。

    SQL Management Studio Expressを使用して、次の手順を実行します。

    1. マスターおよび作業スキーマをリストアします。

    2. データベースを格納するために使用するファイルの論理名を出力します。

    3. データベースを格納するために使用するファイルを移動します。

    例:

    RESTORE DATABASE [odi_11g_cp] FROM DISK = N'C:\Program Files\Microsoft SQL 
Server\MSSQL.1\MSSQL\Backup\odi_11g.bak' 
WITH FILE = 1, MOVE N'odi_11g' TO N'C:\Program Files\Microsoft SQL 
Server\MSSQL.1\MSSQL\DATA\odi_11g_cp.mdf', 
MOVE N'odi_11g_log' TO N'C:\Program Files\Microsoft SQL 
Server\MSSQL.1\MSSQL\DATA\odi_11g_cp_log.ldf', NOUNLOAD; 
go

  3. SQL Management Studioを使用して、クローニングされたマスターおよび作業スキーマ用のログインとユーザーを作成します。

    SQL Management Studio Expressを使用して、クローニングされたマスターおよび作業スキーマにアクセスするログインとユーザーを作成します。SQL Management Studio Expressで適切なデータベース・インスタンスを選択します。これらのコマンドが選択したデータベース・インスタンスに適用されます。

    例:

    create login odi_11g_cp with password=N'odi_11g_cp', 
default_database=odi_11g_cp,  check_expiration = off, check_policy = off; 
go 
USE odi_11g_cp
go 
create user odi_11g_cp  for login odi_11g_cp; 
go 
USE odi_11g_cp 
go

  4. 古いスキーマを新しいスキーマの場所に移動するには、次のSQLスクリプトを実行します。

    注意: 次の例では古いスキーマの名前がodi_11gで、新しいスキーマの名前がodi_11g_cpです。 

    CREATE SCHEMA [odi_11g_cp] AUTHORIZATION odi_11g_cp
go
.
DECLARE @OldSchema AS varchar(255)
DECLARE @NewSchema AS varchar(255)
. 
SET @OldSchema = 'odi_11g'
SET @NewSchema = 'odi_11g_cp'
.
DECLARE @sql AS varchar(MAX)
SET @sql = CHAR(13) + CHAR(10)
.
SELECT @sql = @sql + 'ALTER SCHEMA [' + @NewSchema + '] TRANSFER [' + 
TABLE_SCHEMA + '].[' + TABLE_NAME + ']' + CHAR(13) + CHAR(10) 
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = @OldSchema
.
EXEC (@sql)
go

  5. スキーマの移動を完了するには、次のSQLクエリを実行します。 

    DROP SCHEMA [odi_11g] 
go 
drop user odi_11g; 
go 
alter user odi_11g_cp with default_schema = odi_11g_cp; 
go 
grant create table, create view, create procedure,create function to 
odi_11g_cp; 
go

7.1.1.4 IBM DB2 Universal Databaseでのスキーマのクローニング・プロセス

次のいずれかの手順を選択して、IBMのDB2 Universal Databaseスキーマをクローニングします。

注意:

データベースのページ・サイズは32768 (32K)に設定する必要があります。さらに、オペレーティング・システム・ユーザーのODI_MASTER_11G_CPおよびODI_WORK_11G_CPを手動で作成する必要があります。

7.1.1.4.1 ODI 11gマスターおよび作業スキーマに対する共通のホストのクローニング・プロセス

次の手順は、IBM DB2スキーマを同じホストまたはプラットフォームでクローニングするために使用できます。

  1. コマンド・ライン・プロセッサを使用してDB2データベースを作成します。

    例:

    db2 CREATE DATABASE ODI12 AUTOMATIC STORAGE YES  ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768
  2. DB2 Database Movement Toolを使用して、ODI 11gのマスターおよび作業スキーマを新しいスキーマにコピーします。

    マスター・スキーマの例:

    db2move ODI11G COPY -sn odi_master_11g -co TARGET_DB ODI11GCP USER db2admin USING welcome SCHEMA_MAP ((odi_master_11g,odi_master_11g_cp)) TABLESPACE_MAP ((USERSPACE1,USERSPACE1),SYS_ANY) owner odi_master_11g_cp

    作業スキーマの例:

    db2move ODI11G COPY -sn odi_work_11g -co TARGET_DB ODI11GCP USER db2admin USING welcome SCHEMA_MAP ((odi_work_11g,odi_work_11g_cp)) TABLESPACE_MAP ((USERSPACE1,USERSPACE1),SYS_ANY) owner odi_work_11g_cp
7.1.1.4.2 ODI 11gマスターおよび作業スキーマに対する異なるホストのクローニング・プロセス

次の手順は、IBM DB2スキーマを異なるホストまたはプラットフォームでクローニングするために使用できます。

  1. DB2 Database Movement ToolおよびDDL抽出ツールを使用して、マスターおよび作業スキーマからDDLおよびデータをエクスポートします。

    DB2 Database Movement Toolは、PC/IXFファイルとデータ、およびdb2move.lstファイルと表のリストを生成します。ファイルは、このツールが呼び出したフォルダに生成されます。DDL Extracting Toolは、SQL問合せによってdb2master.sqlおよびdb2work.sqlを生成し、データベース構造を再作成します。

    例:

    db2move ODI11G export -sn odi_master_11g,odi_work_11g
db2look -d ODI11G -z odi_master_11g -e -o c:/db2master.sql
db2look -d ODI11G -z odi_work_11g -e -o c:/db2work.sql

  2. 新しい場所にエクスポートされたファイルが転送されます。

    1. PC/IXFがバイナリ・モードで転送され、db2move.lstファイルとdb2master.sqlおよびdb2work.sqlファイルがASCIIモードで転送されたことを確認します。

    2. PC/IXFファイルをDB2 Database Movement Toolが配置されている場所に配置します。

  3. コマンド・ライン・プロセッサを使用してDB2データベースを作成します。

    例:

    db2 CREATE DATABASE ODI11G AUTOMATIC STORAGE YES  ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768

  4. コマンド・ライン・プロセッサを使用してエクスポート済のDDLを新しいデータベースにインポートします。

    例:

    db2 -tvf c:/db2backup/db2master.sql
db2 -tvf c:/db2backup/db2work.sql

  5. DB2 Database Movement Toolを使用してエクスポート済のデータを新しいデータベースにインポートします。

    例: 

    db2move ODI11G load

  6. クローニングされたスキーマが完全であることを確認します。一部の表は、チェック・ペンディング状態になる場合があります(チェック制約が原因)。

    set integrityコマンドを使用して通常状態に移行します。

    例:

    db2 set integrity for table_name immediate checked

7.1.2 作業リポジトリのJDBC URLの更新

Oracle Data Integratorリポジトリをクローニングすると、クローニングされたマスター・リポジトリには、元のソース・リポジトリの作業リポジトリ接続詳細が埋め込まれます。クローニングする際は、必ずクローニングされるリポジトリのマスター・リポジトリに接続してください。各作業リポジトリを開いて、スキーマ名とパスワード、およびJDBC URL(あるいはその両方)を変更します。

この手順を行わないと、意図せずに元のスキーマがアップグレードされる可能性があります。

例1: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマを、すべて同じデータベース・インスタンスにリストアします。

作業リポジトリのJDBC URLを更新するには、次の手順を実行します。

  1. 次のコマンドでスキーマCUST1およびCUST2をエクスポートすることにより、Oracle Datapumpを使用して単純なクローンを実行します。

    Expdb System/Password Directory=Dumpdir Schemas=cust1,cust2 Dumpfile=Filename.dmp

  2. CUST1およびCUST2をクローニングして、新しいスキーマ(NEWCUST1、NEWCUST2)を作成します。

    Impdp System/Password Directory=Dumpdir Schemas=cust1,cust2 Remap_schemas=cust1:newcust1, cust2:newcust2 Dumpfile=Filename.dmp

  3. NEWCUST1のみのマスター・リポジトリに接続します。

  4. workrep1を開いて、schema_nameをCUST1からNEWCUST1に更新します。

  5. workrep2を開いて、schema_nameをCUST2からNEWCUST2に更新します。

例2: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマがあります。この例では、スキーマの名前変更を行いません。すべてのスキーマを別々のデータベース・インスタンスにリストアします。

スキーマを新しいデータベース・インスタンスにリストアするには、次の手順を実行します。

  1. 次のコマンドを実行します。
    Impdp System/Password Directory=Dumpdie Schemas=cust1,cust2 Dumpfile=Filename.dmp
  2. CUST1のみのマスター・リポジトリに接続します。
  3. workrep1を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。
  4. workrep2を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。

スキーマを新しいデータベース・インスタンスにリストアし、同時にスキーマ名も変更する場合は、schema_namesとJDBC_URLの両方を更新します。

7.1.3 作業リポジトリが正しいスキーマにアタッチされていることの確認

リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。

これを確認する手順は、次のとおりです。

注意:

この項のドキュメント・リンクは、11g リリース1 (11.1.1.7.0)のドキュメントを参照しています。

  1. 既存のODIクライアント(アップグレード前のバージョン)を使用してODIマスター・リポジトリに接続します。

    詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のマスター・リポジトリへの接続に関する項を参照してください。

  2. 作業リポジトリが正しい作業リポジトリのスキーマおよびホストにアタッチされていることを検証します。

    詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の作業リポジトリへの接続に関する項と作業リポジトリのアタッチおよび削除に関する項を参照してください。

7.1.4 アップグレードするODIリポジトリのデータベース・バックアップの作成

ODIマスターおよび作業リポジトリのそれぞれのバックアップを作成することをお薦めします。バックアップにより、必要時にアップグレード前の状態にリストアできます。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのバックアップ計画に関する項を参照してください。

アップグレードに失敗した場合、schema_version_registry表の内容をアップグレード前の状態にリストアする必要があります。そのため、SYSTEM.SCHEMA_VERSION_REGISTRY$表をバックアップの一部に含める必要があります。

アップグレード・アシスタントの前提条件の画面ではODIリポジトリのバックアップが完了したかどうかを確認されます。ただし、アップグレード・アシスタントではバックアップが完了したことが検証されない点に注意してください。

注意:

これは、特にリポジトリをクローニングしていない場合には、アップグレード・プロセスの重要な手順です。アップグレードの結果に問題がある場合、リポジトリはロックされ、使用できません。

ODIリポジトリのバックアップ・コピーを作成することで、重要なデータを失うことがなくなるだけでなく、アップグレード失敗後にリストアする唯一の手段となります。失敗した状態からアップグレードを再開することはできません。

バックアップの作成の詳細は、データベースのバックアップおよびリカバリのドキュメントを参照してください。

7.2 Oracle Fusion Middleware 12c製品のインストール

アップグレードを開始する前に、Oracle Universal Installerを使用して、12cバージョンのOracle Fusion Middleware製品をインストールします。『Oracle Data Integratorのインストールと構成』の次の項の手順に従います。

  1. 「Oracle Data Integratorインストールの計画」では、12c Java EEエージェントのインストール・トポロジに関する重要な情報を理解します。

    この項では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。Java EEエージェント環境の場合、Oracle Data Integratorをインストールするための前提条件として、Oracle Fusion Middleware Infrastructureも必要です。

  2. 「Oracle Data Integratorのインストール」では、環境にあわせてOracle Data Integratorをインストールします。

    注意:

    12.1.2または12.1.3からアップグレードする場合は、Oracle Data Integratorを新しいORACLE_HOMEにインストールする必要があります。

    必ず特定の環境に合ったインストール手順に従ってください。

  3. 「Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマの作成」では、RCUを実行し、12cの新規スキーマ(サービス表スキーマなど)を作成します。

新規ドメインの構成には構成ウィザードを実行する必要はありません。アップグレード・シナリオでは、アップグレード・アシスタントによって自動的に処理されます。

7.3 マスターおよび作業リポジトリ・スキーマのアップグレード

アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードするには、この項の手順に従います。

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、ドメインのすべてのサーバーおよびプロセスが停止していることを確認してください。

詳細は、「Oracle Fusion Middlewareの起動と停止」を参照してください。

注意:

リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、「外部パスワード記憶域の設定」を参照してください。

7.3.2 Upgrade Assistantの起動

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

注意:

アップグレード・アシスタントを起動する前に、外部認証から内部認証に戻していることを確認してください。詳細は、パスワード記憶域の切替えに関する項を参照してください。

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

./ua

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

ua.bat

7.3.3 アップグレード・アシスタント画面のナビゲート

アップグレード・アシスタントを起動(「Upgrade Assistantの起動」)した後、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、製品スキーマをアップグレードします。

注意:

アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。

  • スキーマ・バージョン・レジストリが有効な状態で、リポジトリのバージョンを保持している

  • リポジトリが12cである

  • リポジトリのバージョンが、アップグレード・アシスタントが使用するODI SDKのバージョン以上である

リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されているschema_version_registry表に対して次の問合せを使用します。

Oracleデータベースでは、この表の名前はSYSTEM.SCHEMA_VERSION_REGISTRY$であり、SYSTEMスキーマに格納されています。また、SYSTEM.SCHEMA_VERSION_REGISTRYというビューと、このビューを示すパブリック・シノニムSCHEMA_VERSION_REGISTRYがあります。

SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry;

DB2/400オペレーティング・システムの場合、AdminユーザーはQSECOFRで、schema_version_registry表はスキーマ'NULLID'内に配置されています。

ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。

  1. アップグレード・アシスタントの導入

    「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

  2. アップグレード操作の選択

    「スキーマ」を選択します。次の画面でアップグレード・アシスタントにより、アップグレード可能なスキーマがリストされます。

    「スキーマ」を選択すると、画面のタイトルが「スキーマ」に変わります。

  3. コンポーネント・スキーマの選択

    「使用可能なコンポーネント」画面には、アップグレード可能なスキーマがリストされます。

    マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。

    GUID-1E1273E9-F15B-434D-A44E-DEE9429ACA79-default.gifの説明が続きます
    図GUID-1E1273E9-F15B-434D-A44E-DEE9429ACA79-default.gifの説明

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』の使用可能なコンポーネントに関する項を参照してください。

  4. WebLogicディレクトリの指定

    ドメイン・ディレクトリ画面で、アップグレードするドメイン用のWebLogicディレクトリを入力します。

  5. 前提条件の検証

    「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

    続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

  6. データベースおよびスキーマ資格証明の指定

    スキーマの選択画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力します。「接続」をクリックしてデータベースに接続します。

    その後、マスターおよび作業リポジトリのスキーマ・ユーザー名とパスワードを指定します。

    GUID-526DD471-3303-40EB-968A-DF8CA2527933-default.pngの説明が続きます
    図GUID-526DD471-3303-40EB-968A-DF8CA2527933-default.pngの説明

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』のスキーマの選択に関する項を参照してください。

  7. ODIアップグレード・オプションの選択

    「ODIオプション」画面で、この画面のすべてのオプションを選択します。

    img/GUID-0D1C1836-387D-4108-B8F8-0D8D052741E2-default.png

    各オプションについて次の表で説明します。

    表7-1 ODIのオプション

    オプション 説明

    ナレッジ・モジュールを必須更新で置換

    これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。

    ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の「互換性モードの使用」 を参照してください。

    トポロジおよびセキュリティ・メタデータのアップグレード

    これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

    手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。

    高度なアップグレード・オプションの詳細は、「高度なアップグレード・オプション」を参照してください。

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIオプションに関する項を参照してください。

  8. スーパーバイザ・アカウント資格証明の指定

    「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

    インストールされているスーパーバイザ・アカウントはSUPERVISOR (すべて大文字)です。正しいアカウント名およびパスワードについては、ODI管理者に確認してください。

    GUID-7CDFA583-C70D-4F84-B6CC-783B36C85619-default.gifの説明が続きます
    図GUID-7CDFA583-C70D-4F84-B6CC-783B36C85619-default.gifの説明

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIスーパーバイザに関する項を参照してください。

  9. ODIアップグレード・キーの選択

    アップグレード・キーは、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換する際に使用します。

    注意:

    このタスクは、ODI 11gからODI 12.2.1へのアップグレードのみに適用されます

    ODIオブジェクトは、ODIリポジトリ、ならびにこうしたリポジトリからエクスポートされたXMLファイルに存在し、リポジトリ間のメタデータ交換などで使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

    12cにおいて、ODIによるオブジェクト識別では数字の内部IDのかわりにGUIDが使用されます。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

    数字の内部IDが実際にはユニバーサルに一意ではなく、疑似的な一意性を実現するためにリポジトリIDに依存していたため、ODIではユーザーがアップグレード・キーを指定して、重複したGUIDが生成される可能性を下げることができます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

    このように異なるアップグレード・キーを選択することで、偶然同じ数字の内部IDを持つオブジェクトについて重複したGUIDを取得せずに済みます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

    たとえば、11gリポジトリにIDとして1001を持つ製品があり、また同じリポジトリからエクスポートされたファイルに、同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

    ヒント:

    詳細は、『Upgrade Assistantによるアップグレード』のODIアップグレード・キーに関する項を参照してください。

  10. アップグレードの検証の完了

    「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

    ヒント:

    この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

  11. アップグレードの開始と完了

    「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

  12. スキーマ・バージョンの確認

    スキーマがアップグレードされたことを確認するには、データベース・ホストからSQL*Plusを実行し、次のコマンドを使用します。

    select owner, version, status from schema_version_registry where owner = 'prefix_ODI_REPO';

    prefixを、RCUで作成されたリポジトリ・スキーマのカスタム接頭辞で置き換えます。次に、例を示します。

    select owner, version, status from schema_version_registry where owner = DEV1221_ODI_REPO
OWNER                          VERSION                        STATUS
------------------------------ ------------------------------ -----------
DEV1221_ODI_REPO               12.2.1.0.0                     VALID

    出力で、「VERSION」列においてスキーマ・バージョン番号が「12.2.1.0.0」であることを確認します。

7.4 Java EEエージェント環境のアップグレード

リポジトリ・スキーマをアップグレードした後、再構成ウィザードを実行して、Java EEエージェント環境のアップグレードを完了します。

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

再構成ウィザードは12cの新しいツールです。ドメインを12cにアップグレードするとき、アップグレード・アシスタントとともに実行します。

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

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

  • ドメイン・バージョン

注意:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
具体的には、ドメインを再構成すると、次のようになります。

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.1)に更新されます。

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

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

注意:

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

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

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

  1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
    たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。
  2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
  3. ドメインのバックアップしたバージョンが完全であることを確認します。
ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

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

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

  1. ドメインが存在するシステムにログインします。
  2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
  3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。

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

    ALTER DATABASE DEFAULT EDITION = edition_name;

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

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

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

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

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

  5. 次のコマンドを実行します。
    (UNIX Operating Systems) ./reconfig.sh -log=<log_file> -log_priority=ALL
(Windows Operating Systems) reconfig.cmd -log=<log_file> -log_priority=ALL

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

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

    注意:

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

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

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

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

7.4.1.3 ドメインの再構成

再構成ウィザードでは表7-2 に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。

表7-2 再構成ウィザードの画面

再構成ウィザードの画面 説明および必要なアクション

ドメインの選択

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

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、「動作保証要件とシステム要件の確認」を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

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

詳細は、「ヘルプ」をクリックするか、データベース構成タイプに関する項を参照してください。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、JDBCデータ・ソースに関する項を参照してください。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、JDBCデータ・ソース・テストに関する項を参照してください。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

注意:

  • アップグレードしたスキーマに、11gスキーマの詳細を指定する必要があります。それ以外については、12.2.1スキーマの詳細を指定します。

  • このページのフィールドの詳細は、「ヘルプ」をクリックするか、 JDBCコンポーネント・スキーマに関する項を参照してください。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。

ドメインごととホストごとのノード・マネージャの構成の詳細は、「ノード・マネージャのデフォルト構成」を参照してください。

拡張構成

この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。

たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。

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

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

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

管理対象サーバー

ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

デフォルトのlocalhostまたはAll Local Addressesオプションは使用しないでください。

実際のホスト名を、hostname.company.comのように指定する必要があります。

12.1.3から12.2.1にアップグレードするときは、適切なサーバー・グループにサーバーを割り当てる必要があります。

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当て

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:

SOA UPGRADES ONLY: OWSMPMが独自のクラスタにあり、SOAまたはOSBクラスタの一部でない場合、SOAクラスタにはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲットし、OSBクラスタにはOSB-MGD-SVRS-ONLYをターゲットし、OWSMにはWSMPM-MAN-SVERサーバー・グループのみをターゲットする必要があります。12.1.3から12.2.1にアップグレードするときは、BAMクラスタにBAM-MGD-SVRS-ONLYをターゲットする必要もあります。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

7.5 スタンドアロン・エージェント環境(WebLogicドメインなし)のアップグレード

リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインなし)環境をアップグレードします。

7.5.1 Upgrade Assistantの起動

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

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

./ua

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

ua.bat

7.5.2 スタンドアロン・システム・コンポーネント構成のアップグレード

アップグレード・アシスタントを起動した後(「Upgrade Assistantの起動」)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、スタンドアロン・システム・コンポーネント構成をアップグレードします。

  1. アップグレード・アシスタントの導入

    「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

  2. アップグレード操作の選択

    12c (12.1.2または12.1.3)より、スタンドアロン・システム・コンポーネントには、独自のスタンドアロン・ドメインがそれぞれ作成されます。11gスタンドアロン・システム・コンポーネント(以前にドメインの関連付けをしていない)をアップグレードする場合、最初にシステム・コンポーネントに新規スタンドアロン・ドメインを作成する必要があります。

    「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択し、次に「新規ドメインの作成」を選択します。

    「ドメイン・ディレクトリ」フィールドで、作成するドメインのフルパスを指定します。ドメイン・ホームがOracleホーム・ディレクトリの外部にある場合、「推奨されるディレクトリ構造の理解」に要約されているディレクトリ構造に従って、ドメイン・ホームを配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になったときに問題を回避するために役立ちます。

    img/GUID-D9389485-1707-4CD4-ACBC-43C9033167A8-default.gif

    ヒント:

    「既存のドメインの更新」オプションは、別のシステム・コンポーネントのアップグレードまたは以前の部分的なOracle Data Integratorアップグレードのいずれかにより、アップグレードがすでに実行され、ドメインが作成されている場合に使用できます。このような場合、新規ドメインの作成が不要となります。

  3. アップグレード対象のコンポーネントの確認

    「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

    • システム・コンポーネント・インフラストラクチャ

    • Oracle Data Integrator

  4. 前提条件の検証

    「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

    続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

  5. インスタンス・ディレクトリの指定

    「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上のOracleインスタンス・ディレクトリの場所を指定します。

    GUID-FB5B72EC-826A-4942-9DE1-3F8BB8D6D687-default.gifの説明が続きます
    図GUID-FB5B72EC-826A-4942-9DE1-3F8BB8D6D687-default.gifの説明
  6. ノード・マネージャの作成

    「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。

  7. アップグレードの検証の完了

    すべての検証が成功していることを確認します。

  8. アップグレードの開始と完了

    「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

7.6 スタンドアロン・エージェント環境(WebLogicドメインあり)のアップグレード

リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインあり)環境をアップグレードします。

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

「Java EEエージェント環境のアップグレード」の手順に従い、再構成ウィザードを使用して11g、12.1.2または12.1.3ドメインを再構成します。

7.6.2 Upgrade Assistantの起動

アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。

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

./ua

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

ua.bat

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

アップグレード・アシスタントを起動した後(「Upgrade Assistantの起動」)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、WebLogicドメイン・コンポーネント構成をアップグレードします。

  1. アップグレード・アシスタントの導入

    「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。

  2. アップグレード操作の選択

    管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細の入力を求められます。

    img/GUID-316648C4-6C86-43C8-A267-49128EE233BD-default.gif

    ヒント:

    この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。

  3. アップグレード対象のコンポーネントの確認

    「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。

  4. 前提条件の検証

    「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。

    続行する前にボックスを確認してください。Upgrade Assistantでは前提条件が満たされていることを確認できません。

  5. アップグレードの検証の完了

    「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。

    ヒント:

    この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。

  6. アップグレードの開始と完了

    「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。

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

アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。

アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。

トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください

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

アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errors.が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。

このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。

  • アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。

  • インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。

    • これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、『Oracle Data Integratorの管理』を参照してください。

    • 修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。

アップグレードのパフォーマンス・エラーのトラブルシューティング

リポジトリに存在するセッションの数が、アップグレードのパフォーマンスに影響します。アップグレードのパフォーマンス向上を図るには、セッションのログをアーカイブしてパージすることをお薦めします。

7.8 高度なアップグレード・オプション

これらは12.1.3アップグレード・アシスタントで表示されていた追加のオプションですが、12.2.1アップグレード・アシスタントでは非表示になっています。これらのオプションが必要な場合は、サイレント・モードで使用するレスポンス・ファイルで設定します。

表7-3 高度なアップグレード・オプション

12.1.3でのオプション名 12.2.1レスポンス・ファイルのオプション名 想定される値(デフォルト＝yes) 説明

GUIDを使用するようにリポジトリをアップグレード

ODI_GUID.option

yesまたはno

これを選択すると、リポジトリが12c完全モードに設定されます。すべてのオブジェクトが、内部IDではなく、12c GUIDを使用して参照されます。

Oracle Data Integrator 12c全体で真に一意の識別スキームを利用するには、このオプションを選択しておく必要があります。

注意: このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12.1.2リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

odiRef代替APIを使用するカスタム・ナレッジ・モジュールおよびプロシージャがある場合、これらは内部識別子をパラメータとみなすため(getFlexFieldValue()など)、このオプションを選択せずに、リポジトリを11g互換性モードにしておくことができます。こうしたナレッジ・モジュールおよびプロシージャを使用してオブジェクトから生成されたシナリオは、引き続き11g互換性モードで動作しますが、12c完全モードでは動作しません。11g互換性モードを使用することで、新しいodiRef代替API (GUIDをパラメータとみなすAPI)を使用するようカスタム・ナレッジ・モジュールおよびプロシージャをスムーズに遷移できます。すべてのカスタム・ナレッジ・モジュールおよびプロシージャが新しいodiRef代替APIを使用するよう変更された後で、リポジトリを12c完全モードに切り替えることができます。

アップグレード後にリポジトリを完全GUIDモードに変更するには(アップグレード中にアップグレード・アシスタントでオプションを選択していない場合)、Studioに移動し、ODIドロップダウン・メニューでオプション「リポジトリ互換性モードの切替え」を選択します。これで、フルGUIDモードに切り替えるオプションが使用可能になります。リポジトリがすでに完全GUIDモードだった場合、このオプションは無効です。

GUID変更の影響を受ける代替メッセージすべてのリストは、付録A-1を参照してください。

12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われます

ODI_SDK.option

yesまたはno

この選択により、すべての11gインタフェースが12cマッピングに変換されます。12cマッピングに変換されたら、使用前に既存のすべてのシナリオを再生成する必要があります。既存の11g SDKアプリケーションは使用できないため、12c SDKを使用するように、それらをアップグレードする必要があります。

変換が実行されても、結果のマッピングが11g互換性モードになる場合、11g Java SDKを使用してマッピングを変更できます。ただし、11g SDKを使用した場合のみ変更できます。Studio UIでは読取り専用です。

このオプションを選択しない場合、12cマッピングへの変換が実行されますが、結果のマッピングは11g互換性モードのままになります。11g SDKを使用してこれらのインタフェースを変更した後、ODI Studioグラフィカル・インタフェースまたは12c SDKを使用して12cマッピングに変換できます。

既存のインタフェースの読取りまたは更新のために11g SDKを使用するJavaコードが大量にある場合を除いて、このオプションは選択しておくことをお薦めします。このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12.1.2リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。

注意: この移行が正しく機能するためには、11gリポジトリのすべてのインタフェースが有効である必要があります(11g Studioからの検証時にエラーを返さないなど)。11gインタフェースが無効である場合、アップグレード・アシスタントは12cマッピングへの移行を試行しますが、結果は保証されません。インタフェースの移行が失敗したり、例外がログ・ファイルに出力される場合があります。いずれの場合も、結果のマッピングが無効になります。スムーズにアップグレードする最良の方法は、最初に11gリポジトリのすべてのインタフェースが有効であることを確認することです。

移行中に一部の11gインタフェースで失敗があっても、アップグレード・プロセスは停止しません。すべてのインタフェースが処理されるまでアップグレードは続行されます。

AES-128暗号化アルゴリズムの使用

ODI_AES.option

yesまたはno

128ビットのキーを持つAESは機密情報に対し十分な保護を提供します。より重要度の高い機密情報を保護するには256ビットのキーを持つAESが必要です。このオプションが選択されていない場合は、AES-256暗号化が使用されます。

表7-4で、「ODIオプション」画面で選択できるオプションと選択できないオプションの組合せについて説明します。

表7-4 「ODIオプション」画面で選択できる組合せ

ナレッジ・モジュールを必須更新で置換 GUIDを使用するようにリポジトリをアップグレード 12cマッピングを使用するようにインタフェースをアップグレード

×

×

×

これが最もよく使用される組合せで、新しい12cリポジトリの作成時に使用する構成です。この組合せでは、すべてのオブジェクトで新しいGUID識別が使用され、すべてのインタフェースが完全な12cマッピングに変換されます(ODI Studioエディタで変更可能)。

×

×

この組合せでは、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数ある場合は、この組合せを使用してください。

×

この選択では、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。また、リポジトリはID互換性モードのままとなります。デフォルトのナレッジ・モジュールを変更したが、完全12cマッピングを使用する場合は、この組合せを使用してください。

×

×

この組合せでは、11gインタフェースが11g互換性マッピングに変換されます(11gインタフェースSDKを介してアクセスおよび変更可能)。これらのマッピングは、ODI Studioエディタでは読取り専用です。11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

×

この選択では、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。また、11gインタフェースが11g互換性マッピングに変換されます(11g SDKを介してアクセスおよび変更可能)。ただし、これらはODI Studioエディタでは読取り専用です。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数あり、11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。

いずれのオプションも選択しない場合、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。これらのマッピングの読取りまたは変更を行うODI 11g SDKを使用するアプリケーションが存在するが、自身の目的でOracle提供のナレッジ・モジュールを変更していない場合は、この組合せを使用してください。

表7-5 で、「ODIオプション」画面の無効な組合せについて説明します。

表7-5 「ODIオプション」画面の無効な組合せ

ナレッジ・モジュールを必須更新で置換 GUIDを使用するようにリポジトリをアップグレード 12cマッピングを使用するようにインタフェースをアップグレード

×

この選択では、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

×

×

この組合せでは、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。

注意:

「トポロジおよびセキュリティ・メタデータのアップグレード」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

また、「AES-128暗号化アルゴリズムの使用」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。

前
前 		次
次
目次へ移動
目次