5 Upgrading Your Oracle Data Integrator Environment

This chapter provides specific instructions for the tasks involved in upgrading your existing Oracle Data Integrator 11g environment to Oracle Data Integrator 12c (see Section 1.1 for valid 11g starting points).

If you are upgrading an existing 11g environment to a newer 11g version of Oracle Data Integrator, see the Oracle Fusion Middleware Patching Guide in the 11g documentation library.

This chapter contains the following sections:

5.1 Preparing to Upgrade Oracle Data Integrator

This section contains important tasks that should be performed before you begin your upgrade to Oracle Data Integrator 12c (12.1.2).

5.1.1 Planning Your Upgrade

Before you begin, you should read Planning an Upgrade of Oracle Fusion Middleware, which provides a high-level overview of how to plan and prepare for your upgrade to Oracle Fusion Middleware 12c (12.1.2).

5.1.2 Backing Up Your Existing 11g Environment

Before you begin, you should make a complete backup of your 11g environment. For details, see "Backup and Recovery Strategies for Upgrade" in the Planning an Upgrade of Oracle Fusion Middleware.

5.1.3 Upgrading the Database Containing the ODI Repository

The database that contains the Oracle Data Integrator repositories must be supported by Oracle Fusion Middleware 12c. For the latest list of certified databases, see System Requirements and Supported Platforms for Oracle Fusion Middleware 12c (12.1.2) on the Oracle Fusion Middleware Supported System Configurations page.

For instructions on verifying that your database meets the requirements of Oracle Fusion Middleware 11g, see "Upgrading and Preparing Your Oracle Databases for 12c (12.1.2)" in Planning an Upgrade of Oracle Fusion Middleware. Oracle recommends that you refer to your database-specific upgrade documentation for additional information.

Note:

If your database was supported in Oracle Data Integrator 11g but is no longer supported in Oracle Data Integrator 12c, use the ODI 11g version to do the following before you upgrade:

  1. Export the ODI 11g repositories from the unsupported database systems/versions.

  2. Import Master and Work Repositories into new repositories created with the 11g version into supported database systems/versions.

For additional information, see "Repository-Level Export/Import" in the Developer's Guide for Oracle Data Integrator.

5.1.4 Re-Associating a File-Based Security Store

If you are using a file-based security store in your existing 11g environment, you must perform the following tasks before you begin the upgrade process.

Refer to the following tasks for more information:

Task 1   Creating 11g OPSS and IAU Schemas

Create new 11g Oracle Platform Security Services (OPSS) and Audit Schemas (IAU) schemas in a supported Database using the 11g Repository Creation Utility.

For more information about creating 11g schemas, see "Obtaining and Running Repository Creation Utility" in the Oracle Fusion Middleware Repository Creation Utility User's Guide for 11g Release 1 (11.1.1.7.0).

Task 2   Reassociating the 11g Security Store with the Database-Based Security Store and OPSS Schema

If you are using a file-based security store in your 11g environment, then reassociate the file-based store with the database-based repository and OPSS schema.

For information about reassociating OPSS schema with Database-based repository, see "Reassociating the OPSS Security Store" in the Oracle Fusion Middleware Application Security Guide in the 11g Release 1 (11.1.1.7.0) documentation library.

Task 3   Configuring the Audit Data Store

If the audit data store is file based, then you must enable audit loading on the database to change from storing audit records in a file to using a database audit data store.

For information about enabling audit loading, see "Configure the Audit Data Store and Bus-Stop Storage" in Securing Applications with Oracle Platform Security Services.

5.1.5 Cloning Existing Master and Work Repositories

Oracle recommends that you clone (copy) each original ODI Master and Work repository before beginning the upgrade process. During the Master Repository upgrade process, the Upgrade Assistant will prompt you for the location and credentials of the cloned Master Repository and Work Repositories.

The following sections provide basic schema cloning procedures for databases that are supported to host ODI repositories. For detailed information, refer to your database-specific documentation.

Note:

The goal of this section is to stress the importance of creating a clone (or copy) of each of the 11g repositories before you begin the upgrade process. The cloning procedures documented in this section are sample procedures for each of the 11g supported databases. You are not restricted to using these procedures. Always use the cloning procedures that suit your specific needs.

5.1.5.1 Schema Cloning Process for Oracle Database

The following steps can be used to clone Oracle Database schemas for ODI:

  1. Export ODI 11g Master and Work schemas using the Oracle Export Utility (exp). For example:

    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

    Export ODI 11g Master and Work schemas using the Datapump Utilities (expdp). For example:

    expdp odi_tmp/odi_tmppwd schemas=odiw11117 dumpfile=odiw11117.dmp

  2. Using SQL*Plus, create Master and Work clone schemas and grant connect/resource privileges. For example:

    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. Using Oracle Import (imp), import the ODI 11g Master and Work schema dump into the cloned Master and Work schemas. For example:

    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

    Import ODI 11g Master and Work schemas using the Datapump Utilities (impdp). For example:

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

    Note that with impdp it is also possible to modify the schema name and tablespace for data storage. The remap_xx parameters are optional.

5.1.5.2 Schema Cloning Process for MySQL Database

The following steps can be used to clone MySQL database schemas:

  1. Export the ODI 11g Master and Work schemas using mysqldump. For example:

    mysqldump -h localhost -u root -p DEV_ODI_REPO > /scratch/dump.sql

  2. Restore the ODI schema into a new schema using mysql. For example:

    First, create a cloned schema:

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

    Then, import the ODI schema into the cloned schema.

    mysql -h localhost -u root -p NEW_ODI_REPO < /scratch/dump.sql

  3. Create a login for the cloned schema using mysql. For example:

    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'

5.1.5.3 Schema Cloning Process for Microsoft SQL Server Database

The following steps can be used to clone Microsoft SQL 2005/2008 database schemas:

  1. Export the ODI 11g Master and Work schemas using SQL Management Studio.

    Example:

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

  2. Restore Master and Work schemas into the new database using SQL Management Studio.

    Using SQL Management Studio Express perform the following:

    1. Restore the Master and Work schemas.

    2. Print logical names of files used to store the database.

    3. Move the files used to store database.

    Example:

    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. Create login and user for cloned Master and Work schemas using SQL Management Studio.

    Using SQL Management Studio Express, create logins and users to access cloned Master and Work schemas. Be sure to select the correct database instance in SQL Management Studio Express, as these commands are applied to the selected database instance.

    Example:

    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. To move the old schema to the new schema location, run the following SQL script:

    NOTE: In the example below, the old schema name is odi_11g and the new schema name is 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. To finalize the schema move, run the following SQL query:

    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

5.1.5.4 Schema Cloning Process for IBM DB2 Universal Database

Chose one of the following procedures to clone IBM's DB2 Universal Database schemas:

Note:

The Page size for database has to be 32768 (32k) and operating system users ODI_MASTER_11G_CP and ODI_WORK_11G_CP have to be created manually.

5.1.5.4.1 Same Host Cloning Process for ODI 11g Master and Work Schemas

Use the following steps to clone IBM DB2 schemas on the same host or platform:

  1. Create DB2 Database using Command Line Processor.

    Example:

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

  2. Copy ODI 11g Master and Work schemas using DB2 Database Movement Tool to new schema.

    Master Schema Example:

    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

    Work Schema Example:

    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
5.1.5.4.2 Different Host Cloning Process for ODI 11g Master and Work Schemas

Use the following steps to clone IBM DB2 schemas on different hosts or platforms:

  1. Export DDL and Data from Master and Work schemas using DB2 Database Movement Tool and DDL Extracting Tool.

    DB2 Database Movement Tool produces PC/IXF files with data and db2move.lst file with list of tables, Files are produced in the folder where the tool was called. The DDL Extracting Tool produces db2master.sql and db2work.sql with SQL queries to recreate database structure.

    Example:

    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. Transfer exported files to new location.

    1. Ensure that the PC/IXF files were transferred in binary mode, and that the db2move.lst file and the db2master.sql and db2work.sql files were transferred in ASCII mode.

    2. Place the PC/IXF files where the DB2 Database Movement Tools is located.

  3. Create DB2 database using Command Line Processor.

    Example:

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

  4. Import the exported DDL to the new database using the Command Line Processor.

    Example:

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

  5. Import exported data to new database using DB2 Database Movement Tool.

    Example:

    db2move ODI11G load

  6. Verify that cloned schemas are intact; some tables may be in "check pending" state (because of check constraint).

    Use command set integrity to move to the normal state.

    Example:

    db2 set integrity for table_name immediate checked

5.1.6 Verifying that Work Repositories are Attached to the Correct Schemas

After cloning the repositories, you should check the repository connections to see verify that the cloned master repository points to the correct cloned work repository schema. The upgrade process retrieves the work repository information from its master repository; in order to have a successful upgrade of the work repositories, you must ensure that the repositories are attached to the correct schema and host before you upgrade.

To verify this:

Note:

The documentation links in this section refer to 11g Release 1 (11.1.1.7.0) documentation.

  1. Connect to the ODI master repository using your existing ODI client (pre-upgraded version).

    For information, see "Connecting to the Master Repository" in the Developer's Guide for Oracle Data Integrator.

  2. Validate that the work repositories are attached to the correct work repository schema and host.

    For more information, see: "Connecting to a Work Repository" and "Attaching and Deleting a Work Repository" in the Developer's Guide for Oracle Data Integrator.

5.1.7 Creating a Backup of the ODI Repositories to be Upgraded

Oracle recommends that you create a backup for each ODI Master and Work repository. The backup enables you to restore to a pre-upgrade state if necessary. For more information, see "Backup Strategies for Upgrade," in Planning an Upgrade of Oracle Fusion Middleware.

If an upgrade fails you also need to restore the contents of schema_version_registry table back to its pre-upgrade state; therefore, the SYSTEM.SCHEMA_VERSION_REGISTRY$ table must be included as part of any backup.

The Upgrade Assistant Prerequisite screen prompts you to indicate whether the backup of the ODI repositories has been completed. It is important to note, however, that the Upgrade Assistant will not validate that a backup has been created.

Caution:

This is a critical step of the upgrade process; especially if the repositories were not cloned. In the event that upgrade results are unsatisfactory, the repository locked and unable to be used.

Having a backup copy of the ODI repositories not only ensures that you will not lose important data, but it is the only way to restore after a failed upgrade; there is no capability to restart the upgrade from a failed state.

For more information on creating a backup, refer to your database backup and recovery documentation.

5.2 Installing Oracle Fusion Middleware 12c Products

Before beginning your upgrade, use the Oracle Universal Installer to install the 12c version of your Oracle Fusion Middleware products. Follow the instructions in the following section in Installing and Configuring Oracle Data Integrator:

  1. "Planning Your Oracle Data Integrator Installation" to understand important information about the 12c Java EE agent installation topology.

    This chapter introduces some important 12c concepts and also provides information for where to obtain the necessary product distributions. Note that for Java EE agent environment, Oracle Fusion Middleware Infrastructure is also required as a prerequisite for installing Oracle Data Integrator.

  2. "Installing Oracle Data Integrator" to install Oracle Data Integrator for your environment.

    Be sure to follow the installation instructions for your particular environment.

  3. "Creating the Oracle Data Integrator Master and Work Repository Schema" to run RCU and create the schemas that are new in 12c (for example, the Service Table schema).

You do not need to run the configuration wizard to configure a new domain; the Upgrade Assistant will take care of this for you in an upgrade scenario.

5.3 Upgrading Your Master and Work Repository Schema

Follow the instructions in this section to use the Upgrade Assistant to upgrade your Master and Work Repository schema.

5.3.1 Stopping Servers and Processes

Before running the Upgrade Assistant to upgrade your schemas, make sure all servers and processes in the domain are stopped.

For more information, see "Starting and Stopping Oracle Fusion Middleware" in Administering Oracle Fusion Middleware.

5.3.2 Starting the Upgrade Assistant

To start the Upgrade Assistant, go to the ORACLE_HOME/oracle_common/upgrade/bin directory, and enter the following command:

On UNIX operating systems:

./ua

On Windows operating systems:

ua.bat

5.3.3 Navigating the Upgrade Assistant Screens

After the Upgrade Assistant is started (Section 5.3.2), follow the instructions in this section to navigate through the screens in the Upgrade Assistant to upgrade your product schemas.

Note:

The Upgrade Assistant uses the data and structure of the ODI Master repository to determine if a repository has already been upgraded. The Upgrade Assistant will return a message stating that the repository has already been upgraded if the following conditions exist:

  • The schema version registry has valid state and version for the repository

  • The repository is 12c

  • The version of the repository is equal to or greater than the version of ODI SDK used by the Upgrade Assistant

To debug or view the repository catalog information, use the following query on the schema_version_registry table, which is stored in the Admin user (not in the ODI schema/repository).

In Oracle databases, the name of this table is SYSTEM.SCHEMA_VERSION_REGISTRY$ and it is stored in the SYSTEM schema. There is also a view named SYSTEM.SCHEMA_VERSION_REGISTRY and a public synonym SCHEMA_VERSION_REGISTRY that points to the view:

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

On DB2/400 operating systems, the Admin user is QSECOFR, and the schema_version_registry table is located in the schema 'NULLID'.

Rows with the component "ODI" are used to track ODI repositories.

Task 1   Introducing the Upgrade Assistant

The Welcome screen contains important reminders to consider before proceeding with your upgrade. Make sure you read these and verify that you are ready to proceed.

Task 2   Selecting an Upgrade Operation

Select Schemas. The Upgrade Assistant will list the schemas available for upgrade on the next screen.

The title of the screen will change to "Schemas" when you select Schemas.

Task 3   Selecting Component Schemas

The Available Components screen lists the schemas that are available for upgrade.

Select Oracle Data Integrator to upgrade the Master and Work Repository schema.

Description of ua_schema_components.gif follows
Description of the illustration ua_schema_components.gif

Tip:

More information about this screen can be found in Available Components in Upgrading with the Upgrade Assistant.

Task 4   Verifying Prerequisites

The Prerequisites screen lists items that you must check and verify before you can proceed.

You must check the boxes before you can continue. The Upgrade Assistant will not verify that the prerequisites have been met.

Task 5   Specifying Database and Schema Credentials

On the Select Schemas screen, enter the connection credentials for the database containing the schema you want to upgrade. Click Connect to connect to your database.

Then, specify the schema user name and password for the Master and Work Repository.

Description of ua_db_schema_creds.png follows
Description of the illustration ua_db_schema_creds.png

Tip:

More information about this screen can be found in Select Schemas in Upgrading with the Upgrade Assistant.

Task 6   Selecting the ODI Upgrade Option

On the ODI Options screen, select all of the options on this screen.

Description of ua_odi_options.gif follows
Description of the illustration ua_odi_options.gif

Each option is described in the following table.

Option Description

Replace KMs with mandatory updates

This selection replaces standard KMs with the newest version. Any customizations to standard KMs will be lost.

Upgrade topology and security metadata

This selection replaces topology and security artifacts such as Technologies, Datatypes, Security Profiles and others with the newest version. Any customizations will be lost.

Upgrade repository to use GUIDs

This selection sets the repository to 12c full mode. All objects will be referenced using 12c GUID rather than the internal ID.

You should leave this option checked in order to take advantage of the truly universally unique identification scheme in Oracle data Integrator 12c.

If you have custom KMs and procedures that use odiRef substitution APIs, which take internal identifiers as parameters, you may choose to not select this option, leaving your repository in "11g compatibility mode." Scenarios generated from objects using such KMs and procedures continue to work in "11g compatibility mode" but will not work in 12c full mode. "11g compatibility mode" can be used to smoothly transition the custom KMs and procedures to use the new odiRef substitution APIs (the ones that take GUIDs as parameters). After all custom KMs and procedures have been modified to use the new odiRef substitution APIs, the repository can be switched to 12c full mode.

Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility

This selection converts all 11g interfaces are converted to 12c mappings. Once converted to 12c mappings, all of the existing scenarios must be regenerated before use. There is no ability to use existing 11g SDK applications; they must be upgraded to use the 12c SDK.

Some conversion is performed, but the resulting mappings are left in 11g compatible mode, which allows them to be modified using 11g Java SDK. But they can only be modified using 11g SDK; in Studio UI they are read-only.

If this option is not selected, some conversion to 12c mappings are performed but the resulting mappings are left in "11g compatibility mode." The interfaces can be only modified by the 11g SDK; in the ODI Studio user interface they are read-only. After these interfaces are modified using the 11g SDK, they can then be converted to 12c mappings using the ODI Studio graphical interface or the 12c SDK.

Oracle recommends leaving this option checked, unless you have significant amount of Java code that uses the 11g SDK to read or update existing interfaces.

NOTE: In order for this migration to work properly, all interfaces in 11g repository must be valid (for example, they should not return any errors when validating from 11g Studio, for example). If an 11g interface is not valid, the Upgrade Assistant will try to migrate it into a 12c mapping, but there are no guarantees about the result: the migration of that interface may fail, or exceptions may printed out the in log file. In any case the resulting mapping will be invalid. The best way to ensure a smooth upgrade is to make sure all interfaces in 11g repository as valid to start with.

The upgrade process does not stop even if some 11g interfaces fail during the migration; the upgrade will continue until all interfaces are processed.

Tip:

For more information about this screen, see "ODI Options" in Upgrading with the Upgrade Assistant.

Below are descriptions of the combinations of options that may or may not be selected on this screen.

Note:

The Upgrade topology and security metadata option can be selected or not selected independently of all the other options and has no affect on the other options.

  • If Replace KMs with mandatory updates is selected, then any combination of the remaining options can be selected:

    • Both Upgrade repository to use GUIDs and Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility are both selected.

      This is the most common case and is the configuration with which the new 12c repositories are created. It means that all objects use the new GUID identification and all interfaces are converted into full 12c mappings, which can be modified in OID Studio editors.

    • Select Upgrade repository to use GUIDs but do not select Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility.

      In this case, the 11g interfaces are converted to 11g compatible mappings, which can be accessed and modified through 11g interface SDK, but are read-only in ODI Studio editors. Use this combination if you have significant investment in programs/scripts that use the 11g interface SDK.

    • Do not select Upgrade repository to use GUIDs but select Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility.

      In this case, the repository will stay in ID compatibility mode, which means that odiRef APIs that use legacy numeric identifiers will continue to work. Use this combination if you have significant number of custom KMs or procedures that use odiRef APIs with numeric IDs as arguments.

    • Neither Upgrade repository to use GUIDs nor Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility are selected.

      In this case, the repository will stay in ID compatibility mode, which means that odiRef APIs that use legacy numeric identifiers continue to work. Also, the 11g interfaces are converted to 11g compatible mappings, which can be accessed and modified through the 11g SDK, but are read-only in ODI Studio editors. Use this combination if you have significant number of custom KMs or procedures that use odiRef APIs with numeric IDs as arguments, and you have significant investment in programs/scripts that use 11g interface SDK.

  • If Replace KMs with mandatory updates is not selected, then neither Upgrade repository to use GUIDs nor Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility may be selected.

    In this case, the KMs existent in the repository are going to be preserved and not overwritten with the new 12c updates. Use this combination if you have modified Oracle supplied KMs for your own purpose, and would like to prevent them from being overwritten during the upgrade. You should still plan on manually importing the new 12c KMs at your earliest convenience and migrate your customizations, preferably to your own copies of the KMs.

    • If Replace KMs with mandatory updates is not selected and Upgrade repository to use GUIDs is selected, most KMs will not function correctly since they will be using deprecated odiRef APIs, which use legacy numeric IDs.

    • If Replace KMs with mandatory updates is not selected and Upgrade interfaces to use 12c mappings - losing 11g SDK compatibility is selected, your mappings may not function correctly because they need the new 12c KMs.

Task 7   Specifying Supervisor Account Credentials

On the ODI Supervisor screen, enter the Supervisor account credentials for the ODI repository to be upgraded.

The Supervisor user should be SUPERVISOR (all CAPS).

Description of ua_supervisor_credentials.gif follows
Description of the illustration ua_supervisor_credentials.gif

Tip:

For more information about this screen, see "ODI Supervisor" in Upgrading with the Upgrade Assistant.

Task 8   Selecting the ODI Upgrade Key

The upgrade key is used to convert 11g IDs for repository objects into unique GUIDs.

ODI objects exist in ODI repositories and also in XML files exported from such repositories, which can be used, for example, in metadata exchanges between repositories. As such, there may be multiple copies of the same object, in different repositories and XML files.

In 12c, ODI uses GUIDs instead of internal numeric IDs for object identification.In order to make sure the object identity is preserved after upgrade, a deterministic algorithm is applied to calculate GUIDs from the internal IDs for existing objects (note that for new objects, ODI will generate random GUIDs).

Because of the fact that the internal numeric IDs were not really universally unique, and were dependent on the repository ID to achieve a "pseudo-uniqueness," ODI allows the user to specify the upgrade key in order to reduce the likelihood of generating duplicated GUIDs. The upgrade key is fed into the GUID generation algorithm together with the internal numeric ID, to calculate the GUID.

Thus, choosing different upgrade keys protects from getting duplicated GUIDs for objects that accidentally have the same internal numeric IDs. However, when multiple copies of the same object exists (in a repository or exported in XML files), the same GUID should be produced for all copies of the object. For this reason, the same upgrade key must be used for all upgrade operations involving the copies of that particular object.

For example, suppose you have a product with 1001 as the ID in the 11g repository, and you also have a file exported from the same repository, which contains the same project (ID = 1001). In this case, the upgrade key used to upgrade the repository should be the same as the upgrade key used to import the XML file into the upgraded 12c repository. This ensures that the project object in the import file will be properly matched with the project object in the repository (when using one of SYNONYM import modes). However, if there is an 11g XML export file provided from a source containing objects created in another repository of which you have no information, there is a chance that it may contain a project that accidentally has the same internal ID (1001). In this case, to protect from erroneous object matching, which may corrupt the metadata, a different, custom upgrade key should be used when importing that file into the repository.

Tip:

For more information, see "ODI Upgrade Key" in Upgrading with the Upgrade Assistant.

Task 9   Completing the Upgrade Validation

On the Examine screen, the Upgrade Assistant performs a series of validations before upgrading the selected components. Ensure that all validations have succeeded.

Tip:

More information about the options on this screen can be found in Examine in Upgrading with the Upgrade Assistant.

Task 10   Beginning and Completing the Upgrade

Click Upgrade on the Upgrade Summary screen to begin the upgrade. The Upgrade Progress screens shows information about the progress of the upgrade, and the Upgrade Success screen summarizes the upgrade.

Task 11   Verifying the Schema Version

To verify that the schema has been upgraded, run SQL*Plus from the database host and use the following command:

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

Replace prefix with the custom prefix of your repository schema created in RCU. Below is an example:

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

In the output, verify that the schema version number is "12.1.2.0.0" in the "VERSION" column.

5.4 Upgrading Your Java EE Agent Environment

After your repository schemas are upgraded, run the reconfiguration wizard to complete the upgrade of your Java EE agent environment.

5.4.1 Starting the Reconfiguration Wizard

To start the reconfiguration wizard:

  1. Log in to the system where the 12c Oracle Data Integrator software was installed.

  2. Go to the following directory location:

    On UNIX operating systems:

    ORACLE_HOME/oracle_common/common/bin

    On Windows operating systems:

    ORACLE_HOME\oracle_common\common\bin

    where ORACLE_HOME is the location where Oracle Data Integrator is installed.

  3. Start the reconfiguration wizard.

    On UNIX operating systems:

    ./reconfig.sh -log=log_file

    On Windows operating systems:

    reconfig.cmd -log=log_file

    Specify the full path and file name in place of log_file; creating this log file can be very helpful if you need to troubleshoot the reconfiguration process.

    Note:

    When you run the reconfiguration wizard, the following error message might be displayed to indicate that the default cache directory is not valid:

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

    You can change the cache directory by setting the environment variable CONFIG_JVM_ARGS. For example:

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

5.4.2 Navigating the Reconfiguration Wizard Screens to Reconfigure the Domain

Follow the instructions in this section to navigate through the screens in the reconfiguration wizard.

Task 1   Selecting the 11g Domain

Use the Select Domain screen to specify the full path to the domain location of your 11g Oracle Data Integrator domain. You can also click Browse and use the file manager window to help you select the domain location.

Task 2   Viewing the Reconfiguration Setup Progress

The Reconfiguration Setup Progress screen shows you the progress of the application of reconfiguration templates.

Task 3   Selecting the Domain Mode and JDK

Domain mode cannot be changed.

Select the JDK to use in the domain or click Browse to navigate to the JDK you want to use.

Note:

Oracle Fusion Middleware 12c requires Java SE 7. For more information, see "Verifying Certification and System Requirements" in Planning an Installation of Oracle Fusion Middleware.

Task 4   Selecting the Database Configuration Type

Select Manual Configuration, and click Next.

Note that if you are not upgrading any schemas from 11g, then you can use the RCU Data option to connect to the Server Table (STB) schema. The Repository Creation Utility will automatically use service table to load the other 12c schema credentials automatically.

However, in many cases, during domain reconfiguration, you must select a combination of new 12c and upgraded 11g schemas, so Oracle recommends that you use the Manual Configuration option, and that you enter the data source information manually to be sure you are connecting to the correct schemas.

For more information, click Help, or refer to "Database Configuration Type" in Upgrading Oracle WebLogic Server.

Task 5   Configuring JDBC Data Sources

The JDBC Data Sources screen is displayed if you created custom data sources for a database-based OPSS security store or Audit Data store in 11g.

Use this screen to configure the JDBC data sources defined in your domain source.

For information about the fields on this page, click Help, or refer to "JDBC Data Sources" in Upgrading Oracle WebLogic Server.

Task 6   Testing the JDBC Data Sources

Use the JDBC Data Sources Test screen to test the data source connections you configured.

For information about the fields on this page, click Help, or refer to "JDBC Data Sources Test" in Upgrading Oracle WebLogic Server.

Task 7   Configuring JDBC Component Schema

Specify the data source settings for each of the schemas listed on the JDBC Component Schema screen by selecting the check box adjacent to each schema name.

Note:

You must specify the 11g schema details for those schemas that you upgraded in Section 5.3. For the others, specify the 12c schema details.

For information about the fields on this page, click Help, or refer to "JDBC Component Schema" in Upgrading Oracle WebLogic Server.

Task 8   Selecting Advanced Configuration

Select Deployments and Services on the Advanced Configuration page.

This is required as part of the OPSS and IAU schema migration to 12c.

Task 9   Targeting Deployments

If you are using Oracle Web Services Manager, then target the owsm-pm application deployment to the Administration Server:

  1. Locate and select wsm-pm in the Deployments list box.

  2. Select AdminServer in the Targets list box.

  3. Click the blue right arrow icon to target wsm-pm to the Administration Server.

Task 10   Targeting Services

If you have created OPSS and IAU 12c schemas as part of the upgrade process, then select opss-audit-DBDS, opss-audit-viewDS, and opss-data-source in the Services list box and target them to the Managed Servers in the domain, which are listed in the Targets list box.

Otherwise, no action is required on this screen when you are upgrading or reconfiguring the domain.

Task 11   Completing Domain Reconfiguration

Review the configuration summary on the Configuration Summary screen, then click Reconfig to reconfigure the domain.

When reconfiguration is finished, click Finish to dismiss the reconfiguration wizard.

5.5 Upgrading Your Standalone Agent Environment (no WebLogic Domain)

After your repository schemas are upgraded, follow the instructions in this section to upgrade your standalone agent (no WebLogic domain) environment.

5.5.1 Starting the Upgrade Assistant

To start the Upgrade Assistant, go to the ORACLE_HOME/oracle_common/upgrade/bin directory, and enter the following command:

On UNIX operating systems:

./ua

On Windows operating systems:

ua.bat

5.5.2 Upgrading the Standalone System Component Configurations

After the Upgrade Assistant is started (Section 5.5.1), follow the instructions in this section to navigate through the Upgrade Assistant screens and upgrade your standalone system component configurations.

Task 1   Introducing the Upgrade Assistant

The Welcome screen contains important reminders to consider before proceeding with your upgrade. Make sure you read these and verify that you are ready to proceed.

Task 2   Selecting an Upgrade Operation

Beginning with 12c (12.1.2), standalone system components will have their own standalone domain. When you are upgrading your 11g standalone system components (which had no previous domain associations), you must first create a new standalone domain for your system components.

On the Standalone Components screen, select Standalone System Component Configurations, then select Create a New Domain.

In the Domain Directory field, specify the full path of the Domain you are creating. It is recommended that you locate your Domain home in accordance with the directory structure summarized in "Understanding the Recommended Directory Structure" in Planning an Installation of Oracle Fusion Middleware, where the Domain home is located outside the Oracle home directory. This directory structure will help you avoid issues when you need to upgrade or reinstall your software.

Description of ua_upgrade_sa_comp.gif follows
Description of the illustration ua_upgrade_sa_comp.gif

Tip:

The Update an Existing Domain option might be used in a situation where an upgrade was already performed and the domain created, either from another system component upgrade, or from a partial previous Oracle Data Integrator upgrade. These are examples of a situation where you would not need to create a new domain.

More information about this screen can be found in Standalone Components in Upgrading with the Upgrade Assistant.

Task 3   Viewing Components to be Upgraded

The Component List screen lists the components that will be upgraded:

  • System Components Infrastructure

  • Oracle Data Integrator

Task 4   Verifying Prerequisites

The Prerequisites screen lists items that you must check and verify before you can proceed.

You must check the boxes before you can continue. The Upgrade Assistant will not verify that the prerequisites have been met.

Task 5   Specifying 11g Instance Directories

On the Instance Directories screen, specify the location of one or more 11g Oracle instance directories to be upgraded.

Description of ua_instance_directories.gif follows
Description of the illustration ua_instance_directories.gif

Task 6   Creating a Node Manager

On the Node Manager screen, specify the credentials of the Node Manager that will be used to create a domain during the upgrade of standalone system components.

Tip:

More information about the options on this screen can be found in Node Manager in Upgrading with the Upgrade Assistant.

Task 7   Completing the Upgrade Validation

On the Examine screen, the Upgrade Assistant performs a series of validations before upgrading the selected components. Ensure that all validations have succeeded.

Tip:

More information about the options on this screen can be found in Examine in Upgrading with the Upgrade Assistant.

Task 8   Beginning and Completing the Upgrade

Click Upgrade on the Upgrade Summary screen to begin the upgrade. The Upgrade Progress screens shows information about the progress of the upgrade, and the Upgrade Success screen summarizes the upgrade.

5.6 Upgrading Your Standalone Agent Environment (with WebLogic Domain)

After your repository schemas are upgraded, follow the instructions in this section to upgrade your standalone agent (with WebLogic domain) environment.

5.6.1 Reconfiguring the Domain Using the Reconfiguration Wizard

Follow the instructions in Section 5.4 to reconfigure your 11g domain using the reconfiguration wizard.

5.6.2 Starting the Administration Server

Before you can upgrade your WebLogic domain components, you must start the Administration Server in that domain.

To start the Administration Server, go to the DOMAIN_HOME/bin directory and run the following command:

On UNIX operating systems:

./startWebLogic

On Windows operating systems:

startWebLogic.cmd

If prompted, provide the Administration user login credentials to start the server.

5.6.3 Starting the Upgrade Assistant

To start the Upgrade Assistant, go to the ORACLE_HOME/oracle_common/upgrade/bin directory, and enter the following command:

On UNIX operating systems:

./ua

On Windows operating systems:

ua.bat

5.6.4 Upgrading Your WebLogic Domain Component Configurations

After the upgrade assistant is started (Section 5.6.3), follow the instructions in this section to navigate through the Upgrade Assistant screens and upgrade your WebLogic domain component configurations.

Task 1   Introducing the Upgrade Assistant

The Welcome screen contains important reminders to consider before proceeding with your upgrade. Make sure you read these and verify that you are ready to proceed.

Task 2   Selecting an Upgrade Operation

Select the WebLogic Component Configurations option to upgrade component configurations for your managed WebLogic Server domain. You will be prompted to supply the connection details required to connect to the WebLogic Administration Server that is managing the domain.

Description of ua_weblogic_components.gif follows
Description of the illustration ua_weblogic_components.gif

Tip:

More information about this screen can be found in WebLogic Component Configurations in Upgrading with the Upgrade Assistant.

Task 3   Viewing Components to be Upgraded

The Component List screen lists the components that will be upgraded.

Task 4   Verifying Prerequisites

The Prerequisites screen lists items that you must check and verify before you can proceed.

You must check the boxes before you can continue. The Upgrade Assistant will not verify that the prerequisites have been met.

Task 5   Completing the Upgrade Validation

On the Examine screen, the Upgrade Assistant performs a series of validations before upgrading the selected components. Ensure that all validations have succeeded.

Tip:

More information about the options on this screen can be found in Examine in Upgrading with the Upgrade Assistant.

Task 6   Beginning and Completing the Upgrade

Click Upgrade on the Upgrade Summary screen to begin the upgrade. The Upgrade Progress screens shows information about the progress of the upgrade, and the Upgrade Success screen summarizes the upgrade.

5.7 Troubleshooting Your Upgrade

If the upgrade process fails, you must close the Upgrade Assistant, correct the issue, and then restart the Upgrade Assistant.

If the upgrade process fails after the upgrade process has started, you must drop the cloned repository and start from a freshly cloned repository in addition to correcting the underlying issue. There is no way to restart the failed upgrade process.

For more troubleshooting information, see "Troubleshooting Your Upgrade" in Upgrading with the Upgrade Assistant.