Updating Existing Oracle 11.2.4 and 11.2.5 to 11.2.6

Updating Existing Oracle 11.2.4 and 11.2.5 to 11.2.6

Overview

Oracle has released 11.2.6 with some important security fixes and some new features:

  • Top of the list is that it now supports MSSQL Server 2019!
  • A bit less common, but important to those who have been waiting for it – FDMEE now has a SAP adapter.  Direct connection is now possible from FDMEE to SAP.
  • For those on the backend admin side, Oracle has included documentation on changing the WL rcu passwords – something that has not been allowed until now.

These updates will now be planned once a quarter – they are expected to be released about the same time as the Critical Patch Updates notifications happen.  They are to contain all the patches to-date needed (Hyperion and the supported technologies – WebLogic, FMW, etc.).

With these new policies / update processes, they plan to limit the in-place updates to the last 2 update versions.  This means 11.2.6 can only be applied to 11.2.5 and 11.2.4.  You will need to be to at least 11.2.5 before the next release if you want to apply it directly.  This doesn’t mean you can’t get from 11.2.2 to 11.2.6 – it simply means you must update to 11.2.4 or 11.2.5 (in place), and then apply the 11.2.6 update.

The idea appears to be to replace patching with quarterly in-place updates.  On the up side, no more searching every single product name separately for patches, checking compatibility and prerequisites every quarter.  On the downside, this is closer to an in-place upgrade than a patch.  The risk is higher than a patch, but lower than a full upgrade.  Plan and test accordingly.

There are three ways to update to this version:

    1. This version can be installed clean (like any other version) and migration from 11.1.2.4 or 11.2.x (If you’re not at least 11.1.2.4, you will have to upgrade to 11.1.2.4, then to 11.2.6)
    2. This version can be applied as a maintenance patch to 11.2.4
    3. This version can be applied as a maintenance patch to 11.2.5

The new install has followed the same patterns as the other 11.2.x versions to date.  It installed without any immediate issues and validated.

Update from 11.2.4:

I ran the 11.2.4 to 11.2.6 upgrade on a Windows 2019 server with a Oracle 19c DB, and several issues occurred during the update from 11.2.4 to 11.2.6:

FDMEE:

The installer ran fine, but following the steps ran into immediate trouble.  After installing and before running configuration utility, FDMEE schema has to be updated – ODI changed versions and it has to be upgraded accordingly.  When I tried to run the ua.bat, I followed the instructions and connected ‘sys as sysdba’ and immediately got an error: 

UPGAST-00224: 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.

So after looking into this, I found that the upgrade assistant expects an entry in a table that requires sysdba rights.  As most people, I didn’t run the initial FDMEE configuration with sysdba rights, so there was no entry added to the table.

After some work and finally a SR with Oracle, the entry was added by using sql commands provided.

I connected to the FDMEE instance as ‘sys as sysdba’ (if you’re not in a lab where nobody cares about that access level, you’ll need to pass this off the the DBA to do this step). I then ran:

Grant all on system.schema_version_registry$ to <FDMEESCHEMA>;

Grant all on system.schema_version_registry to <FDMEESCHEMA>;

Replacing placeholder <FDMEESCHEMA> with actual FDMEE schema name LAB_FDMEE, this was:

Grant all on system.schema_version_registry$ to LAB_FDMEE;

Grant all on system.schema_version_registry to LAB_FDMEE;

I then disconnected as sys and connected as my schema owner.  I then ran:

INSERT INTO SYSTEM.schema_version_registry$ (comp_id,comp_name,mrc_name,mr_name,mr_type,owner,version,status,upgraded,start_time,modified,EDITION) SELECT ‘ODI’,’Master and Work Repository’,’FDMEE’,’ODI_REPO’,’ODI_REPO’,’,’<FDMEESCHEMA>‘, (SELECT CASE rep_version WHEN ‘05.02.02.07’ THEN ‘12.2.1.3.0’ WHEN ‘05.02.02.09’ THEN ‘12.2.1.4.0’ ELSE rep_version END FROM snp_loc_rep WHERE rep_short_id=500 AND rep_type = ‘M’),’VALID’,’N’,NULL,NULL,NULL FROM dual WHERE NOT EXISTS (SELECT 1 FROM schema_version_registry WHERE mr_type = ‘ODI_REPO’ AND mrc_name = ‘FDMEE’);

Again, replacing <FDMEESCHEMA> with schema name:

INSERT INTO SYSTEM.schema_version_registry$ (comp_id,comp_name,mrc_name,mr_name,mr_type,owner,version,status,upgraded,start_time,modified,EDITION) SELECT ‘ODI’,’Master and Work Repository’,’FDMEE’,’ODI_REPO’,’ODI_REPO’,’,’LAB_FDMEE’, (SELECT CASE rep_version WHEN ‘05.02.02.07’ THEN ‘12.2.1.3.0’ WHEN ‘05.02.02.09’ THEN ‘12.2.1.4.0’ ELSE rep_version END FROM snp_loc_rep WHERE rep_short_id=500 AND rep_type = ‘M’),’VALID’,’N’,NULL,NULL,NULL FROM dual WHERE NOT EXISTS (SELECT 1 FROM schema_version_registry WHERE mr_type = ‘ODI_REPO’ AND mrc_name = ‘FDMEE’);

After you get a successful ‘row added’, run ‘commit;’ to finalize the added entry.  After that was done, ua.bat worked and the ODI schema components were upgraded. But becaust it has to run ‘sys as sysdba’, you’ll need your DBA if you don’t have that access.

After finishing the FDMEE update, I ran the config utility and deployed applications and configured Essbase and Web Server again.  But when I tried to start services, I hit 2 more problems:

Essbase:

Essbase wouldn’t start.  OPMN started and tried to start the Essbase1 component, but it failed without any error message in the logs.  After some research, I found that Essbase, EAS, APS and Essbase Runtime components weren’t patched.  Since Essbase is still 11.1.2.4, the installer is supposed to patch it to 11.1.2.4.040, but no patch at all was applied to any.  I downloaded and applied the 11.1.2.4.040 patches (.043 for APS) and Essbase started as expected.

Provider Services:

Now with the Essbase components patched, I thought I was clear, but Provider Services failed to start.  The service would start and it would listen on port 13080 like it’s supposed to, but it wouldn’t allow connections.  It kept throwing a classDevNotFound error at startup and the aps and SmartView subcomponents failed to start.

APS patch 11.1.2.4.043 was supposed to be applied.  I had to manually apply it, but it was now in place, yet it still wouldn’t start.  I had noticed that a new APS patch was available, so I checked the readme and found:

FMW: APS STARTUP FAILS DURING FMW UPGRADE TO 12.2.1.4 – THIRDPARTY APPROVAL DIGESTER 3

Well, that SOUNDS related.  After all, 11.2.6 uses FMW 12.2.1.4.  So I downloaded and applied it (11.1.2.4.044).  APS started up without errors, and I was in business.  Everything else checked out fine.

Update from 11.2.5:

I also ran the 11.2.5 to 11.2.6 upgrade on a Windows 2019 server with a Oracle 19c DB.  This time things went much more smoothly.  I only had one issue – Provider Services.  I had the same issue I did with 11.2.4 upgrade with the same solution.  It appears that the 11.1.2.4.044 patch should have part of the 11.2.6 release but wasn’t.

 

Thoughts on the process:

The in-place updates remove all current patches.  You can see the installer ‘uninstall’ and install components one at a time.  The patch dates get updated and if you’ve patched beyond the new update, you’ll have to patch it again (I tried the 11.1.2.4.044 APS patch before applying the update to see what would happen and it was removed).  Keep this in mind if you’re waiting a bit between updates but are keeping WebLogic patched for security.  You’ll need to check your WebLogic after applying the update to make sure you’re still at the desired level.

Overall, the in-place, quarterly maintenance release looks to be an attempt to make keeping your system up-to-date overall easier.  Or as the 11.2.6 readme says:

Updates are expected to be easy to apply and have minimum impact for you to absorb.

I don’t think it’s there yet, but I see the direction.  Had this not been in my lab, it would most definitely have had more than ‘minimum impact’.

But I can see the positive.  One more-than-patching effort each quarter vs patching each quarter (individual products, etc.) and then doing an upgrade, migration, etc. every year or 2.  I have always had a hesitancy to use in-place upgrades, but I can see how this might work well.

Leave a Reply

  • Oracle EPM Cloud Update – Jan’22 (22.01)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Jan 8, 2022 (test environments) and on or after 2AM ET on Saturday, Jan 22, 2022 (production environments)

    January 7, 2022
  • Oracle EPM Cloud Update – Dec’21 (21.12)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Dec 3, 2021 (test environments) and on or after 2AM ET on Saturday, Dec 17, 2021 (production environments).

    December 2, 2021
  • Oracle EPM Cloud Update – Nov’21 (21.11)

    These Oracle EPM updates are scheduled to take place during the first nightly maintenance period on or after 2AM ET on Saturday Nov 5, 2021 (test environments) and on or after 2AM ET on Saturday, Nov 19, 2021 (production environments).

    November 3, 2021
  • Block Creation in Essbase – Part 2

    The previous post ended with a discussion on using DATACOPY to create blocks. I stated that it was my preferred method of making sure the right blocks were created for use. However, we may run into a situation requiring an “IF” test to determine when we create the blocks. In this situation, we cannot use DATACOPY as it is not syntactically valid inside an IF test.

    October 22, 2021