Brovanture Services Director
I encountered an issue this week when upgrading an 11.2.2 Oracle Hyperion EPM environment to version 11.2.8.
Note that is is only an issue when using an Oracle database and when upgrading from a version older than 11.2.5.
The problem occurred at the “Manual Configuration Tasks for FDMEE” task where you run the RCU Upgrade Assistant (UA.bat) to manually upgrade the version of ODI used by your FDMEE instance. I got the following errors:
- The specified database does not contain any schemas for Oracle Data Integrator or the database user lacks privilege to view the schemas.
- Cause: The database you have specified does not contain any schemas registered as belonging to the component you are upgrading, or else the current database user lacks privilege to query the contents of the schema version registry.
- Action: Verify that the database contains schema entries in schema version registry. If it does not, specify a different database. Verify that the user has DBA privilege. Connect to the database as DBA.
The problem is that the UA assumes that we used the RCU to create our ODI repository which is not the case. In the Oracle Hyperion EPM world your ODI repository is created inside your FDMEE repository when you configure FDMEE.
The UA will look at the SYSTEM.schema_version_registry table to check the version of ODI but it is missing from our table:
So, the UA errors with the messages listed above.
You also see the following error message if you try and connect to the ODI repository using the ODI Studio:
- ODI-10179 / ODI-26168: Client requires a repository with version 05.02.02.09 but the repository version found is 05.02.02.07
There’s a support document (2699076.1) which explains how the ODI version matches with the schema version. We’ll use this in our hack later:
- The “05.02.02.07” corresponds to ODI Version 126.96.36.199.0.
- And “05.02.02.09” is for Versions 188.8.131.52.190708, 184.108.40.206.0 and 220.127.116.11.200123.
To get around the issue I ran the RCU to create a bogus ODI repository. This also creates the entry in the SYSTEM.schema_version_registry table necessary for me to run the upgrade assistant:
This creates the entry for ODI in my SYSTEM.schema_version_registry:
However, as you can see above it is pointing to the new bogus ODI repository and the version is incorrect because I used the upgraded Oracle Hyperion EPM 11.2.8 version of the RCU (18.104.22.168.0) to create the entry.
I ran the following SQL to change the schema from EPM_ODI_REPO to my FDMEE schema EPM_FDMEE and changed the version from 22.214.171.124.0 to 126.96.36.199.0:
update system.schema_version_registry set OWNER=’EPM_FDMEE’, VERSION=’188.8.131.52.0′ where COMP_ID=’ODI’;
Now you can see the schema and version are correct:
I was then able to run the UA successfully:
The SYSTEM.schema_version_registry is then updated with the upgraded information:
The upgrade was successful and I was also able to login to ODI using the ODI Studio as there was no longer a mismatch between client and repository versions.
If I were to run into this again I would just insert the ODI row into the SYSTEM.schema_version_registry table directly using SQL with the correct schema and version rather than running the RCU and then editing.