| Oracle® Fusion Middleware Oracle Data Integratorのアップグレード 12c (12.1.2) E49823-01 |
|
 前 |
この章では、既存の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.2)へのアップグレードを開始する前に実行する必要がある重要なタスクを説明します。
始める前に、Oracle Fusion Middleware 12c (12.1.2)へのアップグレードをプランニングおよび準備する方法についての高度な概要が記載されている『Oracle Fusion Middlewareのアップグレードのプランニング』に目を通す必要があります。
始める前に、11g環境の完全バックアップを実行する必要があります。詳細は、『Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。
Oracle Data Integratorリポジトリを含むデータベースは、Oracle Fusion Middleware 12cによってサポートされている必要があります。動作保証されたデータベースの最新のリストについては、「Oracle Fusion Middlewareのサポートされるシステム構成」ページのOracle Fusion Middleware 12c (12.1.2)のシステム要件およびサポート対象プラットフォームを参照してください。
データベースがOracle Fusion Middleware 11gの要件を満たしているかどうかを確認する手順については、『Oracle Fusion Middlewareのアップグレードのプランニング』の12c (12.1.2)向けのOracleデータベースのアップグレードと準備に関する項を参照してください。関連情報として、データベース独自のアップグレードに関するドキュメントを参照することをお薦めします。
|
注意: 使用していたデータベースが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アプリケーション・セキュリティ・ガイドの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)に設定する必要があります。さらに、オペレーティング・システム・ユーザーの |
次の手順は、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
リポジトリをクローニングした後で、リポジトリ接続を確認し、クローニングされたマスター・リポジトリがクローニングされた正しい作業リポジトリ・スキーマを指していることを確認する必要があります。アップグレード・プロセスでは、作業リポジトリ情報がそのマスター・リポジトリから取得されます。作業リポジトリを正常にアップグレードするために、アップグレードの前に、リポジトリが正しいスキーマおよびホストにアタッチされていることを確認する必要があります。
これを確認する手順は、次のとおりです。
|
注意: この項のドキュメント・リンクは、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をインストールします。
必ず特定の環境に合ったインストール手順に従ってください。
「Oracle Data Integratorマスター・リポジトリおよび作業リポジトリ・スキーマの作成」では、RCUを実行し、12cの新規スキーマ(サービス表スキーマなど)を作成します。
新規ドメインの構成には構成ウィザードを実行する必要はありません。アップグレード・シナリオでは、アップグレード・アシスタントによって自動的に処理されます。
アップグレード・アシスタントを使用してマスターおよび作業リポジトリ・スキーマをアップグレードするには、この項の手順に従います。
アップグレード・アシスタントを実行してスキーマをアップグレードする前に、ドメインのすべてのサーバーおよびプロセスが停止していることを確認してください。
詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動(第5.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によるアップグレード』の使用可能なコンポーネントに関する項を参照してください。 |
「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。
続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。
スキーマの選択画面で、アップグレードするスキーマが含まれるデータベースの接続資格証明を入力します。「接続」をクリックしてデータベースに接続します。
その後、マスターおよび作業リポジトリのスキーマ・ユーザー名とパスワードを指定します。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のスキーマの選択に関する項を参照してください。 |
「ODIオプション」画面で、この画面のすべてのオプションを選択します。
各オプションについて次の表で説明します。
| オプション | 説明 |
|---|---|
|
KMを必須更新で置換 |
これを選択すると、標準KMが最新バージョンに置き換えられます。標準KMに対するすべてのカスタマイズが失われます。 |
|
トポロジおよびセキュリティ・メタデータのアップグレード |
これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。すべてのカスタマイズが失われます。 |
|
GUIDを使用するようにリポジトリをアップグレード |
これを選択すると、リポジトリが12c完全モードに設定されます。すべてのオブジェクトが、内部IDではなく12c GUIDを使用して参照されます。 Oracle Data Integrator 12c全体で真に一意の識別スキームを利用するには、このオプションを選択しておく必要があります。
|
|
12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われます |
これを選択すると、11gインタフェースがすべて12cマッピングに変換されます。12cマッピングに変換されたら、使用前に既存のすべてのシナリオを再生成する必要があります。既存の11g SDKアプリケーションは使用できないため、12c SDKを使用するように、それらをアップグレードする必要があります。 変換が実行されても、結果のマッピングが11g互換性モードになる場合、11g Java SDKを使用してマッピングを変更できます。ただし、11g SDKを使用した場合のみ変更できます。Studio UIでは読取り専用です。 このオプションを選択しない場合、12cマッピングへの変換が実行されても、結果のマッピングは11g互換性モードになります。インタフェースは11g SDKによってのみ変更できます。ODI Studioユーザー・インタフェースでは読取り専用です。これらのインタフェースが11g SDKを使用して変更された後で、ODI Studioグラフィカル・インタフェースまたは12c SDKを使用して12cマッピングに変換できます。 既存のインタフェースの読取りまたは更新のために11g SDKを使用するJavaコードが大量にある場合を除いて、このオプションは選択しておくことをお薦めします。 注意: この移行が正しく機能するためには、11gリポジトリのすべてのインタフェースが有効である必要があります(11g Studioからの検証時にエラーを返さないなど)。11gインタフェースが無効である場合、アップグレード・アシスタントは12cマッピングへの移行を試行しますが、結果は保証されません。インタフェースの移行が失敗したり、例外がログ・ファイルに出力される場合があります。いずれの場合も、結果のマッピングが無効になります。スムーズにアップグレードする最良の方法は、最初に11gリポジトリのすべてのインタフェースが有効であることを確認することです。 移行中に一部の11gインタフェースで失敗があっても、アップグレード・プロセスは停止しません。すべてのインタフェースが処理されるまでアップグレードは続行されます。 |
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIオプションに関する項を参照してください。 |
この画面で選択できるオプションと選択できないオプションの組合せについて、次に説明します。
|
注意: 「トポロジおよびセキュリティ・メタデータのアップグレード」オプションは、他のすべてのオプションとは関係なく選択または非選択にすることができ、他のオプションには影響しません。 |
「KMを必須更新で置換」を選択した場合、残りのオプションは任意の組合せで選択できます。
「GUIDを使用するようにリポジトリをアップグレード」および12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますの両方を選択
これは最もよくある例であり、新しい12cリポジトリが作成される際の構成です。これは、すべてのオブジェクトにおいて新しいGUID識別が使用され、すべてのインタフェースが完全な12cマッピングに変換され、OID Studioエディタで変更できることを意味します。
「GUIDを使用するようにリポジトリをアップグレード」を選択し、12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますは選択しない
この場合、11gインタフェースは11g互換マッピングに変換され、11gインタフェースSDKによりアクセスおよび変更できますが、ODI Studioエディタでは読取り専用です。11gインタフェースSDKを使用するプログラム/スクリプトが大量に投入されている場合、この組合せを使用します。
「GUIDを使用するようにリポジトリをアップグレード」は選択せず、12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますを選択
この場合、リポジトリはID互換性モードのままとなりますが、これは従来の数字の識別子を使用するodiRef APIが引き続き機能することを意味します。数字のIDを引数とするodiRef APIを使用するカスタムKMまたはプロシージャが大量にある場合、この組合せを使用します。
「GUIDを使用するようにリポジトリをアップグレード」および12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますをどちらも選択しない
この場合、リポジトリはID互換性モードのままとなりますが、これは従来の数字の識別子を使用するodiRef APIが引き続き機能することを意味します。また、11gインタフェースは11g互換マッピングに変換され、11g SDKによりアクセスおよび変更できますが、ODI Studioエディタでは読取り専用です。数字のIDを引数とするodiRef APIを使用するカスタムKMまたはプロシージャが大量にあり、11gインタフェースSDKを使用するプログラム/スクリプトも大量に投入されている場合、この組合せを使用します。
「KMを必須更新で置換」を選択しない場合、「GUIDを使用するようにリポジトリをアップグレード」および12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますのどちらも選択できません。
この場合、リポジトリに存在するKMは保持され、新しい12cの更新で上書きされません。Oracle提供のKMを独自の目的にあわせて変更済で、アップグレード時にそれらが上書きされないようにする場合は、この組合せを使用します。その場合でも、なるべく早く新しい12c KMを手動でインポートするよう計画し、(できればKMのコピーに)カスタマイズを移行する必要があります。
「KMを必須更新で置換」を選択せず、「GUIDを使用するようにリポジトリをアップグレード」を選択した場合、多くのKMは従来の数字のIDを使用する非推奨のodiRef APIを使用するため、正しく機能しません。
「KMを必須更新で置換」を選択せず、12cマッピングを使用するようにインタフェースをアップグレードします - 11g SDKの互換性が失われますを選択した場合、マッピングは新しい12c KMを必要とするため正しく機能しない可能性があります。
「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。
スーパーバイザ・ユーザーはSUPERVISOR (すべて大文字)である必要があります。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のODIスーパーバイザに関する項を参照してください。 |
アップグレード・キーは、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換する際に使用します。
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 = DEV1212_ODI_REPO OWNER VERSION STATUS ------------------------------ ------------------------------ ----------- DEV1212_ODI_REPO 12.1.2.0.0 VALID
出力で、「VERSION」列においてスキーマ・バージョン番号が「12.1.2.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のインストールのプランニング』の動作保証とシステム要件の検証に関する項を参照してください。 |
「手動構成」を選択して「次へ」をクリックします。
11gのスキーマをアップグレードしない場合、「RCUデータ」オプションを使用してサーバー表(STB)スキーマに接続できることに注意してください。Repository Creation Utilityはサービス表を自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。
ただし、多くの場合、ドメイン再構成時に新しい12cとアップグレードした11gのスキーマの組合せを選択する必要があるため、正しいスキーマに確実に接続できるように、「手動構成」オプションを使用して、データ・ソース情報を手動で入力することをお薦めします。
詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のデータベース構成タイプに関する項を参照してください。
「JDBCデータ・ソース」画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。
この画面では、ドメイン・ソースに定義されているJDBCデータ・ソースを構成します。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソースに関する項を参照してください。
「JDBCデータ・ソース・テスト」画面を使用して、構成したデータ・ソース接続をテストします。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCデータ・ソース・テストに関する項を参照してください。
各スキーマ名の横のチェック・ボックスを選択して、「JDBCコンポーネント・スキーマ」画面に表示された各スキーマのデータ・ソース設定を指定します。
このページのフィールドの詳細は、「ヘルプ」をクリックするか、『Oracle WebLogic Serverのアップグレード』のJDBCコンポーネント・スキーマに関する項を参照してください。
「拡張構成」ページで「デプロイメントとサービス」を選択します。
これは、OPSSおよびIAUスキーマの12cへの移行の一部として必要です。
Oracle Web Services Managerを使用している場合、owsm-pmアプリケーション・デプロイメントのターゲットに管理サーバーを指定します。
「デプロイメント」リスト・ボックスで「wsm-pm」を探して選択します。
「ターゲット」リスト・ボックスで「AdminServer」を選択します。
青の右矢印アイコンをクリックして、wsm-pmのターゲットに管理サーバーを指定します。
アップグレード・プロセスでOPSSおよびIAUの12cスキーマを作成している場合、「サービス」リスト・ボックスで「opss-audit-DBDS」、「opss-audit-viewDS」および「opss-data-source」を選択し、それらのターゲットに、「ターゲット」リスト・ボックスに表示されるドメインの管理対象サーバーを指定します。
そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。
「構成のサマリー」画面で構成のサマリーを確認し、「再構成」をクリックしてドメインを再構成します。
再構成が終了したら、「終了(F)」をクリックして再構成ウィザードを終了します。
リポジトリ・スキーマをアップグレードした後、この項の手順に従って、スタンドアロン・エージェント環境(WebLogicドメインなし)をアップグレードします。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動した後(第5.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ドメインあり)をアップグレードします。
再構成ウィザードを使用して11gドメインを再構成するには、第5.4項の手順に従います。
WebLogicドメイン・コンポーネントをアップグレードする前に、そのドメインで管理サーバーを起動する必要があります。
管理サーバーを起動するには、DOMAIN_HOME/binディレクトリに移動し、次のコマンドを実行します。
UNIXオペレーティング・システムの場合:
./startWebLogic
Windowsオペレーティング・システムの場合
startWebLogic.cmd
プロンプトが表示されたら、管理ユーザーのログイン資格証明を指定してサーバーを起動します。
アップグレード・アシスタントを起動するには、ORACLE_HOME/oracle_common/upgrade/binディレクトリに移動し、次のコマンドを入力します。
UNIXオペレーティング・システムの場合:
./ua
Windowsオペレーティング・システムの場合
ua.bat
アップグレード・アシスタントを起動した後(第5.6.3項)、この項の手順に従ってアップグレード・アシスタントの各画面を移動し、WebLogicドメイン・コンポーネント構成をアップグレードします。
「ようこそ」画面には、アップグレードに進む前に考慮する重要な注意事項が含まれています。これらに目を通し、作業を進める準備が整っていることを確認します。
管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「WebLogicコンポーネント構成」オプションを選択します。ドメインを管理しているWebLogic Administration Serverに接続するために必要な接続詳細の入力を求められます。
|
ヒント: この画面の詳細は、『Upgrade Assistantによるアップグレード』のWebLogicコンポーネント構成に関する項を参照してください。 |
「コンポーネント・リスト」画面には、アップグレード対象のコンポーネントが表示されます。
「前提条件」画面には、先に進む前に確認が必要な項目がリストされます。
続行する前にボックスを確認してください。アップグレード・アシスタントでは前提条件が満たされていることを確認できません。
「調査」画面では、アップグレード・アシスタントにより、選択したコンポーネントをアップグレードする前に、一連の検証が実行されます。すべての検証が成功していることを確認します。
|
ヒント: この画面のオプションの詳細は、『Upgrade Assistantによるアップグレード』の調査に関する項を参照してください。 |
「アップグレード・サマリー」画面で「アップグレード」をクリックし、アップグレードを開始します。「アップグレードの進行状況」の各画面には、アップグレードの進行状況に関する情報が示され、「アップグレード成功」画面にアップグレードが要約されます。
アップグレード・プロセスが失敗した場合は、アップグレード・アシスタントを閉じて問題を修正し、アップグレード・アシスタントを再起動する必要があります。
アップグレード・プロセスの起動後にアップグレード・プロセスが失敗した場合は、クローニングされたリポジトリを削除して、根本的な問題を修正してから、新たにクローニングしたリポジトリで起動する必要があります。失敗したアップグレード・プロセスを再起動することはできません。
トラブルシューティングの詳細は、『Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項を参照してください。
