注意:
「Oracle Fusion Middlewareのアップグレード前チェックリスト」で説明されているアップグレード前に必要な全タスクを完了してくださいアップグレード・プロセスの開始前にオリジナルのODIマスターおよび作業リポジトリのそれぞれをコピー(クローニング)することをお薦めします。マスター・リポジトリのアップグレード・プロセスの間に、アップグレードするマスター・リポジトリをアップグレード・アシスタントで選択できます。
次の項では、ODIリポジトリのホストをサポートするデータベースについて、基本的なスキーマのクローニング手順を説明します。詳細は、各データベースのドキュメントを参照してください。
注意:
この項の目的は、アップグレード・プロセスの開始前に11gリポジトリのそれぞれをクローニング(コピー)することの重要性について強調することです。この項に記載されているクローニング手順は、11gでサポートされているデータベースごとのサンプルの手順です。これらの手順は制限なく使用できます。常に、要求に合ったクローニング手順を使用してください。
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スキーマを同じホストまたはプラットフォームでクローニングするために使用できます。
次の手順は、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)という名前の作業リポジトリ・スキーマがあります。この例では、スキーマの名前変更を行いません。すべてのスキーマを別々のデータベース・インスタンスにリストアします。
スキーマを新しいデータベース・インスタンスにリストアするには、次の手順を実行します。
スキーマを新しいデータベース・インスタンスにリストアし、同時にスキーマ名も変更する場合は、schema_names
とJDBC_URL
の両方を更新します。
リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。
これを確認する手順は、次のとおりです。
注意:
この項のドキュメント・リンクは、11g リリース1 (11.1.1.7.0)のドキュメントを参照しています。
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または12.1.3からアップグレードする場合は、Oracle Data Integratorを新しいORACLE_HOMEにインストールする必要があります。
必ず特定の環境に合ったインストール手順に従ってください。
「Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマの作成」では、RCUを実行し、12cの新規スキーマ(サービス表スキーマなど)を作成します。
新規ドメインの構成には構成ウィザードを実行する必要はありません。アップグレード・シナリオでは、アップグレード・アシスタントによって自動的に処理されます。
アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードするには、この項の手順に従います。
アップグレード・アシスタントを実行してスキーマをアップグレードする前に、ドメインのすべてのサーバーおよびプロセスが停止していることを確認してください。
注意:
リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。詳細は、「外部パスワード記憶域の設定」を参照してください。ORACLE_HOME
/oracle_common/upgrade/bin
ディレクトリに移動し、次のコマンドを入力します。注意:
アップグレード・アシスタントを起動する前に、外部認証から内部認証に戻していることを確認してください。詳細は、パスワード記憶域の切替えに関する項を参照してください。UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合:
ua.bat
アップグレード・アシスタントを起動(「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リポジトリの追跡に使用されます。
リポジトリ・スキーマをアップグレードした後、再構成ウィザードを実行して、Java EEエージェント環境のアップグレードを完了します。
再構成ウィザードは12cの新しいツールです。ドメインを12cにアップグレードするとき、アップグレード・アシスタントとともに実行します。
再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。
WLSコア・インフラストラクチャ
ドメイン・バージョン
注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.1)に更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成ウィザードの実行中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
再構成ウィザードでは表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コンポーネント・スキーマ |
各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。 注意:
|
JDBCコンポーネント・スキーマ・テスト |
前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。 テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。 |
ノード・マネージャ |
この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。 ドメインごととホストごとのノード・マネージャの構成の詳細は、「ノード・マネージャのデフォルト構成」を参照してください。 |
拡張構成 |
この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。 たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。
「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。 |
管理対象サーバー |
ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。 デフォルトの 実際のホスト名を、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)」をクリックして再構成ウィザードを終了します。 |
リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインなし)環境をアップグレードします。
アップグレード・アシスタントを起動するには、ORACLE_HOME
/oracle_common/upgrade/bin
ディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合:
ua.bat
アップグレード・アシスタントを起動した後(「Upgrade Assistantの起動」)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、スタンドアロン・システム・コンポーネント構成をアップグレードします。
リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント(WebLogicドメインあり)環境をアップグレードします。
「Java EEエージェント環境のアップグレード」の手順に従い、再構成ウィザードを使用して11g、12.1.2または12.1.3ドメインを再構成します。
アップグレード・アシスタントを起動するには、ORACLE_HOME
/oracle_common/upgrade/bin
ディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合:
ua.bat
アップグレード・アシスタントを起動した後(「Upgrade Assistantの起動」)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、WebLogicドメイン・コンポーネント構成をアップグレードします。
アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。
アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。
トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください
アップグレード・ログ・エラーのトラブルシューティング
アップグレード・アシスタント・ログ・ファイルに<#>, 11g interfaces are converted with errors.
が含まれている場合は、アップグレード・アシスタント・ログでインタフェース名およびIDをチェックし、11gリポジトリでODI Studioを使用して問題を修正してください。インタフェース変換中のエラーは、11gインタフェースの検証の失敗(式のカッコが一致しないなど)により発生することがあります。変換エラーがある場合、結果のマッピングが不完全になることがありますが、他の変換に影響を与えることはありません。
このようなインタフェース・アップグレード・エラーが発生した場合の対処方法は次のとおりです。
アップグレード・アシスタント・ログ・ファイルで強調表示されているインタフェースが使用されておらず、無視できる場合は、アップグレード済の12cリポジトリを引き続き使用できます。
インタフェースを有効な12cマッピングに変換する場合は、エラーのある各インタフェースを11g環境で修正し、次の2つの方法のいずれかを使用して再変換する必要があります。
これらのインタフェースのみエクスポートし、アップグレード済の12cリポジトリにインポートします。インポート・プロセスによって、内部的に11gインタフェースが12cマッピングにアップグレードされます。12cリポジトリへのインタフェースのインポートの詳細は、『Oracle Data Integratorの管理』を参照してください。
修正したインタフェースを使用してアップグレード全部を再度実行します。エラーのあるインタフェースが多数ある場合は、この方法をお薦めします。
アップグレードのパフォーマンス・エラーのトラブルシューティング
リポジトリに存在するセッションの数が、アップグレードのパフォーマンスに影響します。アップグレードのパフォーマンス向上を図るには、セッションのログをアーカイブしてパージすることをお薦めします。
これらは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リポジトリの場合、このオプションは無視され、リポジトリはアップグレード前と同じモードのままになります。
アップグレード後にリポジトリを完全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暗号化アルゴリズムの使用」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。