Reasons to Conduct an out-of-place upgrade for Oracle BI 11.1.1.x

I received a comment on one of the last posts regarding upgrading an Oracle BI 11.1.1.6 from 11.1.1.5 and why I recommended doing an out-of-place upgrade, i.e. deinstall and re-install of the updated version, versus using a patch of 11.1.1.6 over 11.1.1.5.  So on a plane ride a few weeks ago I made a shortlist of reasons to clarify.

I made the comment that I “recommend conducting a re-install of Oracle BI 11g (for 11.1.1.6) instead of conducting an in-place upgrade” and “…an in place upgrade is a bad idea in my opinion”. Let’s be clear, that this statement was made regarding a minor patch release and not a release patch of Oracle BI 11g.  The former requires the download of all compressed installation files while the latter requires the download of a single one-off patch file/script that is then executed using OPatch.

If that’s clear then here are the top X reasons I would recommend conducting a full de-install and re-install of the Oracle BI 11g platform when upgrading minor releases:

1.  The Oracle documentation does not describe one approach as a best practice versus the other.

2. All major artifacts such as WebLogic Security, Applications Roles/Privilege files, Custom Folders, RPD, web catalog can be easily archived and restored just as easily.  This in my opinion should already be conducted via a weekly backup process so that the key artifacts can be easily retrieved, especially if operating in a highly used OBIEE environment.

3. The RCU database tables, etc. can be data dumped and restored carefully enough into the new RCU MDS/BIPLATFORM schemas.  Selecting just the core pieces from these schemas such as auditing, usage tracking ,etc. can be done quite efficiently using INSERT backups or similar routine with your favorite SQL IDE.

4. Most companies haven’t leveraged Oracle BI 11g to its fullest anyway so conducting this full effort for the larger percentage of users this is no more disruption to the environment that the in-place upgrade and possibly less since the team will have been familiar with the Oracle BI 11g de-install and install process.  The advantage here is experienced gained – see next reason.

5. The OBI team becomes much more versed to the workings of the Oracle BI architecture by doing an uninstall and re-install

6. A de-install prevents the chance of screwing something up in the under pinnings of the FMW environment by modifying critical pieces of the environment using a non-automated upgrade process such as the inlace upgrade.

High-Availability configurations of Oracle BI 11g would be my only hesitation with this logic, but again, the fact that the original installation should have been very well documented should allow a de-install to be more efficient than an in-place upgrade.  Taking also into consideration that if a team wants to move from 11.1.1.5 to 11.1.1.6 then this is already an effort where they will have to schedule time for the process, such as downtime of the system, etc. They might as well do it right the first time with no chance of having backlash later on with an issue that they can’t track down.  We’ve seen how deep that FMW file structure is, right?  So, get the experience, and reduce the chance for any hidden problems from arising.

I’m curious to any feedback you may offer.

Thanks to Robin for asking the burning question which prompted this reply post.

Related articles

• Oracle BI 11.1.1.6 SampleApp VM Image – Do it Yourself (artofbi.com)
• Upgrading Oracle BI 11g Apps (artofbi.com)