Oracle Data Integrator (ODI) is now available as a Cloud Service: Oracle Data Integrator Cloud Service (ODICS). For customers who are interested in a subscription model for their ODI installation and want to integrate and transform data in the Cloud, this is the solution.
Customers who already have ODI developments on premises will want to migrate their existing, on premises repository to the Cloud. For these use cases, we provide here a quick solution to perform this repository migration.
If the version you are using is older than the version used for ODICS, the first thing to do is to upgrade your on-premises repository.
The following steps will allow you to create a copy of your existing installation so that you can continue working with the existing repository. Then you will be able to upgrade and copy this repository without any impact on your production environment. When you will be satisfied that the Cloud installation works as expected, you’ll be able to stop the on-premises executions and switch to the Cloud environment.
if you are using ODI as part of a BI Applications installation, do not follow the steps described here. Make sure that you follow the steps described in Oracle Support Document 1984269.1: OBIA 11g How to Migrate Configurations and Customizations from Development to a Test or a Production Environment. As of the time of writing of this post, BI Application is NOT compatible with ODICS.
Here are 8 steps for a quick and easy upgraded clone of your on premises repository
1- Purge the logs in the repository (if you purge before you export the repository, the export and import processes will be much faster).
2- (11g repository only) Run the RCC tool that can obtained from support. Fix all errors reported by the tool.
3- Backup the original repository (I like to use oracle expdp for that – fast, flexible, reliable)
4- Create a brand new repository (using the RCU tool that comes with your installation of ODI) in the same version as the one you want to upgrade from (yes, FROM): this will setup Oracle inventory tables as needed without any need to monkey around with these tables.
5- Overwrite the freshly created repository with the backup of the repository to upgrade: if you used expdp in step 3, you can use impdp to import that file– in essence we are creating a clone of the original repository, properly referenced in the Oracle inventory tables (if you are using impdp, make sure to map the imported tables to the new schema name, and to overwrite the existing tables)
6- Now this step is very important: Connect to the Master repository of this new repository using the ODI Studio and update the connection parameters of the Work repository to make sure that it points to the NEW schema (as is, it still points to the original, on premises schema)
7- Optional – backup your cloned repository. Doing so will save you a lot of time if anything goes wrong with the upgrade, otherwise you would have to redo steps 4 and 5.
8- Download and install the version that matches that of ODICS (126.96.36.199.0 as of February 10, 2017): use the upgrade assistant of that version to upgrade the cloned repository.
You now have a repository in the same version as the one used by ODICS. Time to migrate this over to the cloud...
The steps to migrate the repository to the cloud are very similar to the ones described to upgrade the repository. Just follow these additional steps:
1- Backup your 188.8.131.52.0 repository (I like to use oracle expdp for that – fast, flexible, reliable)
2- Copy the backup file to the cloud, on the file system where ODICS will be installed
3- In the cloud, create a brand new repository using the RCU tool that comes with the installation of ODICS (instructions for the installation are available here). Again, this ensures that all administrative tables are in place. This will be important in the future when you will want to further upgrade this repository;
4- Overwrite the freshly created repository with the backup of the 184.108.40.206.0 repository: if you used expdp in step 1, you can use impdp to import that file– in essence we are creating a clone of the original repository, properly referenced in the Oracle inventory tables (if you are using impdp, make sure to map the imported tables to the new schema name, and to overwrite the existing tables)
5- Now this step is very important: Connect to the Master repository of this new repository using ODICS Studio and update the connection parameters of the Work repository to make sure that it points to the CLOUD schemas (as is, it still points to the original, on premises schema)
6- Do not forget to update the cloud agents and studios with 3rd party JDBC drivers that are used on premises, if any.
7- Test your cloud environment: remember to validate your topology connections as your databases – or at least some of them – must have moved to the Cloud as well. You will also have to update your agents’ definitions: your new agents will be in the Cloud, along with this new repository. Note that during this time, the original environment is still up and running.
8- Once you are satisfied with your tests in the Cloud, switch over to ODICS.
You are now the proud owner of a fully operational ODICS repository!
Having your repository in the cloud will only make sense if your ODI agent is in the Cloud (that is the purpose of ODICS), and so is the Studio used by the developer. Stay tuned for more blogs that will look into the details of ODICS best practices in the cloud: installing ODICS, deploying studio for development teams, and more!
With a limited number of steps, we have quickly upgraded and migrated an on-premises ODI repository to the Cloud, and made it usable as an ODICS repository.
For more ODI and ODICS best practices, tips, tricks, and guidance that the A-Team members gain from real-world experiences working with customers and partners, visit “Oracle A-Team Chronicles for ODI”.