| Oracle® Fusion Middleware Oracle Data Integratorのアップグレード 12c (12.1.3) E59407-02 |
|
 前 |
 次 |
この章では、既存のOracle Data Integrator 11g環境をOracle Data Integrator 12cにアップグレードする場合のタスクの具体的な手順について説明します(有効な11g開始ポイントについては第1.1項を参照)。
既存の11g環境を新しい11gバージョンのOracle Data Integratorにアップグレードする場合は、11gドキュメント・ライブラリの『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。
この章の内容は次のとおりです。
この項では、Oracle Data Integrator 12c (12.1.3)へのアップグレードを開始する前に実行する必要がある重要なタスクを説明します。
始める前に、Oracle Fusion Middleware 12cへのアップグレードをプランニングおよび準備する方法の大まかな概要が記載されている『Oracle Fusion Middlewareのアップグレードのプランニング』に目を通す必要があります。
始める前に、11g環境の完全バックアップを実行する必要があります。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。
Oracle Data Integratorリポジトリを含むデータベースは、Oracle Fusion Middleware 12cによってサポートされている必要があります。動作保証されたデータベースの最新のリストについては、「Oracle Fusion Middlewareのサポートされるシステム構成」ページのOracle Fusion Middleware 12c (12.1.3)のシステム要件およびサポート対象プラットフォームを参照してください。
OracleデータベースがOracle Fusion Middleware 11gの要件を満たしているかどうかを確認する手順については、『Oracle Fusion Middlewareのアップグレードのプランニング』の「12c (12.1.3)のためのOracle Databaseアップグレードおよび準備」を参照してください。関連情報として、データベース独自のアップグレードに関するドキュメントを参照することをお薦めします。
|
注意: 使用していたデータベースがOracle Data Integrator 11gでサポートされていたが、Oracle Data Integrator 12cでサポートされなくなった場合は、アップグレードする前にODI 11gバージョンで、次の手順を実行します。
詳細は、『Oracle Data Integrator開発者ガイド』のリポジトリレベルのエクスポート/インポートに関する項を参照してください。 |
既存の11g環境でファイルベースのセキュリティ・ストアを使用している場合、アップグレード・プロセスを開始する前に、次のタスクを実行する必要があります。
11g Repository Creation Utilityを使用して、サポートされているDatabaseで新しい11g Oracle Platform Security Services (OPSS)および監査スキーマ(IAU)のスキーマを作成します。
11gスキーマ作成の詳細は、11gリリース1 (11.1.1.7.0)の『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』のRepository Creation Utilityの入手と実行に関する説明を参照してください。
11g環境でファイルベースのセキュリティ・ストアを使用している場合、ファイルベースのストアをデータベースベースのリポジトリおよびOPSSスキーマに再関連付けします。
OPSSスキーマとデータベースベースのリポジトリの再関連付けの詳細は、11gリリース1 (11.1.1.7.0)ドキュメント・ライブラリのOracle Fusion Middlewareアプリケーション・セキュリティ・ガイドのDBベースのOPSSセキュリティ・ストアの使用に関する項を参照してください。
監査データ・ストアがファイルベースである場合、データベースで監査ロードを有効にし、監査レコードをファイルに格納する方式からデータベース監査データ・ストアを使用する方式に変更する必要があります。
監査ロードの有効化の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の監査データ・ストアおよびバスストップ・ストレージの構成に関する項を参照してください。
アップグレード・プロセスの開始前にオリジナルのODIマスターおよび作業リポジトリのそれぞれをコピー(クローニング)することをお薦めします。マスター・リポジトリのアップグレード・プロセスの間に、アップグレード・アシスタントによって、クローニングされたマスター・リポジトリおよび作業リポジトリの場所と資格証明が要求されます。
次の項では、ODIリポジトリのホストをサポートするデータベースについて、基本的なスキーマのクローニング手順を説明します。詳細は、各データベースのドキュメントを参照してください。
|
注意: この項の目的は、アップグレード・プロセスの開始前に11gリポジトリのそれぞれをクローニング(コピー)することの重要性について強調することです。この項に記載されているクローニング手順は、11gでサポートされているデータベースごとのサンプルの手順です。これらの手順は制限なく使用できます。常に、要求に合ったクローニング手順を使用してください。 |
ODI用にOracle Databaseスキーマをクローニングするには、次の手順を実行します。
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
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;
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パラメータはオプションです。
次の手順は、MySQLデータベース・スキーマをクローニングするために使用できます。
mysqldumpを使用して、ODI 11gのマスターおよび作業スキーマをエクスポートします。次に例を示します。
mysqldump -h localhost -u root -p DEV_ODI_REPO > /scratch/dump.sql
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
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'
Microsoft SQL 2005/2008データベース・スキーマをクローニングするには、次の手順を実行します。
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;
SQL Management Studioを使用して、マスターおよび作業スキーマを新しいデータベースでリストアします。
SQL Management Studio Expressを使用して、次の手順を実行します。
マスターおよび作業スキーマをリストアします。
データベースを格納するために使用するファイルの論理名を出力します。
データベースを格納するために使用するファイルを移動します。
次に例を示します。
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
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
古いスキーマを新しいスキーマの場所に移動するには、次の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
スキーマの移動を完了するには、次の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
次のいずれかの手順を選択して、IBMのDB2 Universal Databaseスキーマをクローニングします。
|
注意: データベースのページ・サイズは32768 (32K)に設定する必要があります。さらに、オペレーティング・システム・ユーザーのODI_MASTER_11G_CPおよびODI_WORK_11G_CPを手動で作成する必要があります。 |
次の手順は、IBM DB2スキーマを同じホストまたはプラットフォームでクローニングするために使用できます。
コマンド・ライン・プロセッサを使用してDB2データベースを作成します。
次に例を示します。
db2 CREATE DATABASE ODI12 AUTOMATIC STORAGE YES ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768
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
次の手順は、IBM DB2スキーマを異なるホストまたはプラットフォームでクローニングするために使用できます。
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
新しい場所にエクスポートされたファイルが転送されます。
PC/IXFがバイナリ・モードで転送され、db2move.lstファイルとdb2master.sqlおよびdb2work.sqlファイルがASCIIモードで転送されたことを確認します。
PC/IXFファイルをDB2 Database Movement Toolが配置されている場所に配置します。
コマンド・ライン・プロセッサを使用してDB2データベースを作成します。
次に例を示します。
db2 CREATE DATABASE ODI11G AUTOMATIC STORAGE YES ON 'C:\' DBPATH ON 'C:\' USING CODESET IBM-1252 TERRITORY US COLLATE USING SYSTEM PAGESIZE 32768
コマンド・ライン・プロセッサを使用してエクスポート済のDDLを新しいデータベースにインポートします。
次に例を示します。
db2 -tvf c:/db2backup/db2master.sql db2 -tvf c:/db2backup/db2work.sql
DB2 Database Movement Toolを使用してエクスポート済のデータを新しいデータベースにインポートします。
次に例を示します。
db2move ODI11G load
クローニングされたスキーマが完全であることを確認します。一部の表は、チェック・ペンディング状態になる場合があります(チェック制約が原因)。
set integrityコマンドを使用して通常状態に移行します。
次に例を示します。
db2 set integrity for table_name immediate checked
Oracle Data Integratorリポジトリをクローニングすると、クローニングされたマスター・リポジトリには、元のソース・リポジトリの作業リポジトリ接続詳細が埋め込まれます。クローニングする際は、必ずクローニングされるリポジトリのマスター・リポジトリに接続してください。各作業リポジトリを開いて、スキーマ名とパスワード、およびJDBC URL(あるいはその両方)を変更します。
この手順を行わないと、意図せずに元のスキーマがアップグレードされる可能性があります。
例1: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマを、すべて同じデータベース・インスタンスにリストアします。
作業リポジトリのJDBC URLを更新するには、次の手順を実行します。
次のコマンドでスキーマCUST1およびCUST2をエクスポートすることにより、Oracle Datapumpを使用して単純なクローンを実行します。
Expdb System/Password Directory=Dumpdir Schemas=cust1,cust2 Dumpfile=Filename.dmp
CUST1およびCUST2をクローニングして、新しいスキーマ(NEWCUST1、NEWCUST2)を作成します。
Impdp System/Password Directory=Dumpdir Schemas=cust1,cust2 Remap_schemas=cust1:newcust1, cust2:newcust2 Dumpfile=Filename.dmp
NEWCUST1のみのマスター・リポジトリに接続します。
workrep1を開いて、schema_nameをCUST1からNEWCUST1に更新します。
workrep2を開いて、schema_nameをCUST2からNEWCUST2に更新します。
例2: CUST1という名前のソース・リポジトリ・スキーマ、CUST1 (workrep1)という名前の作業リポジトリ・スキーマ、およびCUST2 (workrep2)という名前の作業リポジトリ・スキーマがあります。この例では、スキーマの名前変更を行いません。すべてのスキーマを別々のデータベース・インスタンスにリストアします。
スキーマを新しいデータベース・インスタンスにリストアするには、次の手順を実行します。
次のコマンドを実行します。
Impdp System/Password Directory=Dumpdie Schemas=cust1,cust2 Dumpfile=Filename.dmp
CUST1のみのマスター・リポジトリに接続します。
workrep1を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。
workrep2を開いて、新しいデータベース・インスタンスを指すようにJDBC URLを更新します。
スキーマを新しいデータベース・インスタンスにリストアし、同時にスキーマ名も変更する場合は、schema_namesとJDBC_URLの両方を更新します。
リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。
これを確認する手順は、次のとおりです。
|
注意: この項のドキュメント・リンクは、11g リリース1 (11.1.1.7.0)のドキュメントを参照しています。 |
既存のODIクライアント(アップグレード前のバージョン)を使用してODIマスター・リポジトリに接続します。
詳細は、『Oracle Data Integrator開発者ガイド』のマスター・リポジトリへの接続に関する項を参照してください。
作業リポジトリが正しい作業リポジトリのスキーマおよびホストにアタッチされていることを検証します。
詳細は、『Oracle Data Integrator開発者ガイド』の作業リポジトリへの接続に関する項と作業リポジトリのアタッチおよび削除に関する項を参照してください。
ODIマスターおよび作業リポジトリのそれぞれのバックアップを作成することをお薦めします。バックアップにより、必要時にアップグレード前の状態にリストアできます。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのバックアップ計画に関する項を参照してください。
アップグレードに失敗した場合、schema_version_registry表の内容をアップグレード前の状態にリストアする必要があります。そのため、SYSTEM.SCHEMA_VERSION_REGISTRY$表をバックアップの一部に含める必要があります。
アップグレード・アシスタントの前提条件の画面ではODIリポジトリのバックアップが完了したかどうかを確認されます。ただし、アップグレード・アシスタントではバックアップが完了したことが検証されない点に注意してください。
|
警告: これは、特にリポジトリをクローニングしていない場合には、アップグレード・プロセスの重要な手順です。アップグレードの結果に問題がある場合、リポジトリはロックされ、使用できません。ODIリポジトリのバックアップ・コピーを作成することで、重要なデータを失うことがなくなるだけでなく、アップグレード失敗後にリストアする唯一の手段となります。失敗した状態からアップグレードを再開することはできません。 バックアップの作成の詳細は、データベースのバックアップおよびリカバリのドキュメントを参照してください。 |
アップグレードを開始する前に、Oracle Universal Installerを使用して、12cバージョンのOracle Fusion Middleware製品をインストールします。『Oracle Data Integratorのインストールと構成』の次の項の手順に従います。
「Oracle Data Integratorインストールの計画」では、12c Java EEエージェントのインストール・トポロジに関する重要な情報を理解します。
この章では、12cの重要な概念の一部を説明し、必要な製品ディストリビューションの入手場所に関する情報も提供します。Java EEエージェント環境の場合、Oracle Data Integratorをインストールするための前提条件として、Oracle Fusion Middleware Infrastructureも必要です。
「Oracle Data Integratorのインストール」では、環境にあわせてOracle Data Integratorをインストールします。
|
注意: 12.1.2からアップグレードする場合は、Oracle Data Integratorを新しいORACLE_HOMEにインストールする必要があります。 |
必ず特定の環境に合ったインストール手順に従ってください。
「Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマの作成」では、RCUを実行し、12cの新規スキーマ(サービス表スキーマなど)を作成します。
新規ドメインの構成には構成ウィザードを実行する必要はありません。アップグレード・シナリオでは、アップグレード・アシスタントによって自動的に処理されます。
アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードするには、この項の手順に従います。
アップグレード・アシスタントを実行してスキーマをアップグレードする前に、ドメインのすべてのサーバーおよびプロセスが停止していることを確認してください。
詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動(第6.3.2項)した後、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、製品スキーマをアップグレードします。
|
注意: アップグレード・アシスタントは、ODIマスター・リポジトリのデータおよび構造を使用して、リポジトリがすでにアップグレード済でないかどうかを判定します。アップグレード・アシスタントは、次の状況の場合には、リポジトリがアップグレード済であることを示すメッセージを返します。
リポジトリ・カタログ情報をデバッグまたは表示するには、(ODIスキーマ/リポジトリ内ではなく)Adminユーザーに格納されている Oracleデータベースでは、この表の名前は SELECT COMP_ID,COMP_NAME,MRC_NAME,OWNER,VERSION,STATUS,UPGRADED FROM schema_version_registry; DB2/400オペレーティング・システムの場合、Adminユーザーは ODIコンポーネントの行は、ODIリポジトリの追跡に使用されます。 |
「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。
「スキーマ」を選択します。次の画面でアップグレード・アシスタントにより、アップグレード可能なスキーマがリストされます。
「スキーマ」を選択すると、画面のタイトルが「スキーマ」に変わります。
「使用可能なコンポーネント」画面には、アップグレード可能なスキーマがリストされます。
マスターおよび作業リポジトリ・スキーマをアップグレードするには、「Oracle Data Integrator」を選択します。依存スキーマは自動的に選択されることに注意してください。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』の使用可能なコンポーネントに関する項を参照してください。 |
ドメイン・ディレクトリ画面で、アップグレードするドメイン用のWebLogicディレクトリを入力します。
「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。
続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。
スキーマの選択画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力します。「接続」をクリックしてデータベースに接続します。
その後、マスターおよび作業リポジトリのスキーマ・ユーザー名とパスワードを指定します。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のスキーマの選択に関する項を参照してください。 |
「ODIオプション」画面で、この画面のすべてのオプションを選択します。
各オプションについて次の表で説明します。
| オプション | 説明 |
|---|---|
| ナレッジ・モジュールを必須更新で置換 | これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。
ODIのアップグレードを行わない場合は、『Oracle Data Integratorでの統合プロジェクトの開発』の「互換性モードの使用」を参照してください。 |
| トポロジおよびセキュリティ・メタデータのアップグレード | これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。
手動でのアップグレード方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。 |
| GUIDを使用するようにリポジトリをアップグレード | これを選択すると、リポジトリが12c完全モードに設定されます。すべてのオブジェクトが、内部IDではなく12c GUIDを使用して参照されます。
Oracle Data Integrator 12c全体で真に一意の識別スキームを利用するには、このオプションを選択しておく必要があります。 注意: このオプションは、11gリポジトリからアップグレードする場合にのみ適用されます。12.1.2リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。
アップグレード後にリポジトリを完全GUIDモードに変更するには(アップグレード中にアップグレード・アシスタントでオプションを選択していない場合)、Studioに移動し、ODIドロップダウン・メニューでオプション「リポジトリ互換性モードの切替え」を選択します。これによって、完全GUIDモードに切り替えるためのオプションが表示されます。すでにリポジトリが完全GUIDモードになっている場合、そのオプションはグレー表示されます。 |
| 12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われます | この選択により、すべての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暗号化アルゴリズムの使用 | 128ビットのキーを持つAESは機密情報に対し十分な保護を提供します。より重要度の高い機密情報を保護するには256ビットのキーを持つAESが必要です。このオプションが選択されていない場合は、AES-256暗号化が使用されます。 |
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIオプションに関する項を参照してください。 |
表6-1で、この画面で選択できるオプションと選択できないオプションの組合せについて説明します。
表6-1 「ODIオプション」画面で選択できる組合せ
| ナレッジ・モジュールを必須更新で置換 | GUIDを使用するようにリポジトリをアップグレード | 12cマッピングを使用するようにインタフェースをアップグレード | |
|---|---|---|---|
|
X |
X |
X |
これが最もよく使用される組合せで、新しい12cリポジトリの作成時に使用する構成です。この組合せでは、すべてのオブジェクトで新しいGUID識別が使用され、すべてのインタフェースが完全な12cマッピングに変換されます(OID Studioエディタで変更可能)。 |
|
X |
X |
この組合せでは、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数ある場合は、この組合せを使用してください。 |
|
|
X |
この選択では、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。また、リポジトリはID互換性モードのままとなります。デフォルトのナレッジ・モジュールを変更したが、完全12cマッピングを使用する場合は、この組合せを使用してください。 |
||
|
X |
X |
この組合せでは、11gインタフェースが11g互換性マッピングに変換されます(11gインタフェースSDKを介してアクセスおよび変更可能)。これらのマッピングは、ODI Studioエディタでは読取り専用です。11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。 |
|
|
X |
この選択では、リポジトリはID互換性モードのままとなり、従来の数字の識別子を使用するodiRef APIが引き続き機能します。また、11gインタフェースが11g互換性マッピングに変換されます(11g SDKを介してアクセスおよび変更可能)。ただし、これらはODI Studioエディタでは読取り専用です。数字のIDを引数とするodiRef APIを使用するカスタム・ナレッジ・モジュールまたはプロシージャが多数あり、11gインタフェースSDKを使用するプログラムまたはスクリプトへの投資が大きい場合は、この組合せを使用してください。 |
||
|
いずれのオプションも選択しない場合、リポジトリに存在するナレッジ・モジュールは保持され、新しい12cの更新で上書きされません。これらのマッピングの読取りまたは変更を行うODI 11g SDKを使用するアプリケーションが存在するが、自身の目的でOracle提供のナレッジ・モジュールを変更していない場合は、この組合せを使用してください。 |
表6-2で、「ODIオプション」画面の無効な組合せについて説明します。
表6-2 「ODIオプション」画面の無効な組合せ
| ナレッジ・モジュールを必須更新で置換 | GUIDを使用するようにリポジトリをアップグレード | 12cマッピングを使用するようにインタフェースをアップグレード | |
|---|---|---|---|
|
X |
この選択では、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。 |
||
|
X |
X |
この組合せでは、従来の数字のIDを使用する非推奨のodiRef APIが使用されるため、ほとんどのナレッジ・モジュールは正しく機能しません。 |
|
注意: 「トポロジおよびセキュリティ・メタデータのアップグレード」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。また、「AES-128暗号化アルゴリズムの使用」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。 |
「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。
インストールされているスーパーバイザ・アカウントはSUPERVISOR (すべて大文字)です。正しいアカウント名およびパスワードについては、ODI管理者に確認してください。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIスーパーバイザに関する項を参照してください。 |
アップグレード・キーは、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換する際に使用します。
|
注意: このタスクは、ODI 12.1.2からODI 12.1.3へのアップグレードには適用されません。 |
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アップグレード・キーに関する項を参照してください。 |
「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。
|
ヒント: この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。 |
「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。
スキーマがアップグレードされたことを確認するには、データベース・ホストから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 = DEV1213_ODI_REPO OWNER VERSION STATUS ------------------------------ ------------------------------ ----------- DEV1213_ODI_REPO 12.1.3.0.0 VALID
出力で、「VERSION」列においてスキーマ・バージョン番号が「12.1.3.0.0」であることを確認します。
リポジトリ・スキーマをアップグレードした後、再構成ウィザードを実行して、Java EEエージェント環境のアップグレードを完了します。
再構成ウィザードを起動する手順は、次のとおりです。
12c Oracle Data Integratorソフトウェアがインストールされたシステムにログインします。
次のディレクトリの場所に移動します。
UNIXオペレーティング・システムの場合:
ORACLE_HOME/oracle_common/common/bin
Windowsオペレーティング・システムの場合
ORACLE_HOME\oracle_common\common\bin
ORACLE_HOMEは、Oracle Data Integratorがインストールされている場所です。
再構成ウィザードを起動します。
UNIXオペレーティング・システムの場合:
./reconfig.sh -log=log_file
Windowsオペレーティング・システムの場合
reconfig.cmd -log=log_file
log_fileのかわりにフルパスおよびファイル名を指定します。このログ・ファイルを作成すると、再構成プロセスのトラブルシューティングが必要な場合に非常に役立ちます。
|
注意: 再構成ウィザードを実行すると、デフォルトのキャッシュ・ディレクトリが有効ではないことを示す、次のエラー・メッセージが表示される場合があります。*sys-package-mgr*: can't create package cache dir 環境変数
CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory
|
この項の手順を実行して、再構成ウィザードの各画面を移動します。
「ドメインの選択」画面を使用して、11g Oracle Data Integratorドメインの場所へのフルパスを指定します。また、「参照」をクリックし、ファイル・マネージャのウィンドウを使用してドメインの場所を選択できます。
「再構成セットアップの進行状況」画面では、再構成テンプレートの適用の進行状況が表示されます。
ドメイン・モードは変更できません。
ドメイン内の使用するJDKを選択するか、「参照」をクリックして、使用するJDKに移動します。
|
注意: Oracle Fusion Middleware 12cにはJava SE 7が必要です。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。 |
「JDBCデータ・ソース」画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。
この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを構成します。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。
「JDBCデータ・ソース・テスト」画面を使用して、構成したデータ・ソース接続をテストします。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソース・テストに関する項を参照してください。
まだ選択していない場合、「RCUデータ」を選択します。
ドメインに含まれるアップグレード可能スキーマのスキーマ情報を取得するためのデータベース資格証明を指定します。このオプションを選択すると、この画面のフィールドがアクティブになります。リポジトリ作成ユーティリティ(RCU)でSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。
|
注意: 以前のインストールで、ODI Studioを使用してODIリポジトリを作成した場合、STBスキーマを作成する必要はありません。『Oracle Data Integratorのインストールと構成』のリポジトリ作成ユーティリティの起動に関する項を参照してください。RCUで最初にODIスキーマを選択すると、すべての依存スキーマが選択されるため、これによりODIの依存スキーマを作成します。ODIスキーマの選択を解除し、この手順からカスタムODIリポジトリ接続を指定します。 |
接続情報を入力した後、「RCU構成の取得」をクリックしてスキーマ情報を取得します。
詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。
各スキーマ名の横のチェック・ボックスを選択して、「JDBCコンポーネント・スキーマ」画面に表示された各スキーマのデータ・ソース設定を指定します。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。
「ノード・マネージャ」画面は、再構成するドメインで、ドメインごとのデフォルトの場所のノード・マネージャが使用されている場合にのみ表示されます。
「既存の構成を移行」を選択して、ドメインごとのデフォルトの場所の場所を指定します。
「Oracle推奨デフォルトの適用」を有効にします。
ノード・マネージャ資格証明を指定します。これは、ノード・マネージャを管理するために作成される、新しい「ユーザー」です。ノード・マネージャにより処理されるようになったコンポーネント(OHSを含む)には、起動時にパスワードが要求されます。
注意:ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、カスタム・スクリプトを使用してWebLogic Server環境を起動および停止する場合、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のデフォルトのノード・マネージャの構成に関する項を参照してください。
この画面を使用して、ドメイン内の各キーの資格証明を提供します。ドメインで以前に定義された資格証明は、表にすでに含まれています。
資格証明の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解に関する項を参照してください。
「キーストア」画面を使用して、各キーストアの信頼する証明書へのパス、各キーストアの秘密鍵へのパス、秘密鍵のパスワード、および秘密鍵のアイデンティティ証明書へのパスを指定します。
信頼できる証明書、「秘密鍵」またはアイデンティティ証明書フィールドをクリックすると、フィールドの右側に参照アイコンが表示されます。このアイコンをクリックして、適切なファイルを参照します。
ODIサーバー構成画面を使用して、ドメイン内のコロケートODIエージェントを構成します。
表6-3 ODIサーバー構成画面のフィールド
| フィールド | 説明 |
|---|---|
|
システム・コンポーネント |
このドロップダウン・リストから、構成するODIエージェントを選択します。 |
|
サーバー・リスニング・アドレス |
このエージェントが存在するホスト・システムのホスト名またはIPアドレスを入力します。localhostを使用しないでください。 |
|
サーバー・リスニング・ポート |
ODIエージェントに使用するリスニング・ポートを入力します。 |
|
スーパーバイザ名 |
スーパーバイザ権限を持つODIユーザー名を入力します。 |
|
スーパーバイザ・パスワード |
スーパーバイザ・ユーザーのパスワードを入力します。 |
|
優先データソース |
このドロップダウン・リストから、選択したODIエージェントに使用するデータソースを選択します。 |
「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。
再構成が終了したら、「終了(F)」をクリックして再構成ウィザードを終了します。
リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインなし)環境をアップグレードします。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動した後(第6.5.1項)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、スタンドアロン・システム・コンポーネント構成をアップグレードします。
「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。
12c (12.1.2)より、スタンドアロン・システム・コンポーネントには、独自のスタンドアロン・ドメインがそれぞれ作成されます。11gスタンドアロン・システム・コンポーネント(以前にドメインの関連付けをしていない)をアップグレードする場合、最初にシステム・コンポーネントに新規スタンドアロン・ドメインを作成する必要があります。
「スタンドアロン・コンポーネント」画面で、「スタンドアロン・システム・コンポーネント構成」を選択し、次に「新規ドメインの作成」を選択します。
「ドメイン・ディレクトリ」フィールドで、作成するドメインのフルパスを指定します。ドメイン・ホームがOracleホーム・ディレクトリの外部にある場合、『Oracle Fusion Middlewareのインストールのプランニング』の推奨されるディレクトリ構造の理解に関する項に要約されているディレクトリ構造に従って、ドメイン・ホームを配置することをお薦めします。このディレクトリ構造によって、ソフトウェアをアップグレードまたは再インストールする必要があるときに問題が起きにくくできます。
|
ヒント: 「既存のドメインの更新」オプションは、別のシステム・コンポーネントのアップグレードまたは以前の部分的なOracle Data Integratorアップグレードのいずれかにより、アップグレードがすでに実行され、ドメインが作成されている場合に使用できます。このような場合、新規ドメインの作成が不要となります。この画面の詳細は、『Upgrade Assistantによるアップグレード』のスタンドアロン・コンポーネントに関する項を参照してください。 |
「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。
システム・コンポーネント・インフラストラクチャ
Oracle Data Integrator
「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。
続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。
「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上の11g Oracleインスタンス・ディレクトリの場所を指定します。
「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。
|
ヒント: この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』のノード・マネージャに関する項を参照してください。 |
すべての検証が成功していることを確認します。
|
ヒント: この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。 |
「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。
リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインあり)環境をアップグレードします。
第6.4項の手順に従って、再構成ウィザードを使用して11gまたは12.1.2ドメインを再構成します。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動した後(第6.6.2項)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、WebLogicドメイン・コンポーネント構成をアップグレードします。
「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。
管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細の入力を求められます。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。 |
「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。
「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。
続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。
「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。
|
ヒント: この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。 |
「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。
アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。
アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。
トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください。
アップグレード・ログ・エラーのトラブルシューティング
アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errors.が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。
このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。
アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。
インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。
これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、『Oracle Data Integratorの管理』を参照してください。
修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。
