Top 10 OBIEE Upgrade Strategies and considerations

In this post, I list top OBIEE upgrade strategies and consideration, not necessarily in any specific order, as the order of significance would depend upon individual implementation scenarios.

Oracle offers multiple starting points for OBIEE upgrade. The strategy that would be best applicable to a situation is dependent upon multiple factors. Following the considerations that any organization must review before selecting an upgrade strategy:

1. What is the current version of OBIEE / Siebel Analytics - Some upgrades are performed in-place while others are fresh install. The method applicable will be dependent upon starting and target versions, and also on known issues on upgrading between these versions. An in-place upgrade is best when the upgrade is performed of relatively recent prior version. This would typically mean less issue, less testing, and easier upgrade. However when the upgrade has to be made on a very old version of OBIEE, it would require out of place upgrade. Even if technically it was possible, it makes sense to upgrade on a sandbox, and to find out how the upgrade process responds in terms of issues or ease of upgrade. However in case of an in-place upgrade, typically if dev environment is upgraded to newer version, its very difficult to go back to older version. So even in that case, my personal recommendation is to perform an out of place upgrade on a sandbox and make sure the process goes smoothly and any issue encountered is manageable / non show stoppers, before  doing an in-place upgrade of development.   

2. For some cases, you may have to make multiple hops for the upgrade. For example if someone is still on Siebel Analytics version 7 (or earlier), they will have to go to version 10.1.3.4.1 and then finally upgrade to 11g. Obviously this poses significant upgrade risks in terms of number of issue and unknown problems that could creep up. Best process is to keep doing incremental upgrade every year or every other year and avoid such problems down the road.


3. When do you expect to go live with new version (considering time required for testing, and commitment from business to verify the upgrade along with other factors) - Duration of upgrade projects vary and depend on volume of reports / dashboards that are in production. It also depends how many components are being upgraded and factors like:
1. Do you have BIAPPS in OBIEE?
2. How many modules of BI Apps are implemented?
3. Is BIAPPS being upgraded too?
4. Is Informatica / ODI / ETL tool being upgraded too?
5. Is database platform being upgraded too. ?
6. Finally, is source system getting upgraded too?
More the number of components, higher is the complexity of the upgrade. Some upgrade decisions are made by companies to be able to stay supported by Oracle, because Oracle stops supporting older versions after a period of time.


4. When can we commit on getting a code freeze in the current version of OBIEE - this should be calculated backward from the expected go live date - This is one of the toughest piece to pull off for a larger upgrade. Often OBIEE upgrade ends up being an in-flight upgrade. Meaning, changes are made to current production version of OBIEE while the upgrade is being done to a newer version. In such cases, upgrade team has to make sure any additions / changes to current version are brought over to upgraded version before the go live. There are two ways of doing this:
1. Rebuild additions in the new version
2. Re-migrate OBIEE in a sand box, and copy over the changes.

The choice of path to bring additions will also depend on where the changes are? RPD, Reports, Dashboards, Scheduler, BIP etc? In no case you want to allow significant changes to be made to older version once upgrade process has kicked in. Significant 'addition' of completely new models although might still be ok, which can be easily copied over. Finally, going for a re-upgrade with all changes would be the last option, as this would mean doing a complete sanity check all over again, and a headache for upgrade team as well as the end user testers.

5. Do you have BI Publisher content in current installation ? If yes, then how many reports are there in BIP?  - BIP has had significant architecture changes from 10g to 11g. Some of which would require rebuilding the code.

6. Do you have iBots/Agents in current install? If yes, then how many?  - Again this might mean re scheduling of jobs, as database structures over the years have changed. The decision is a factor of difference between new and older versions.

7. Do you want to upgrade all code at once (big-bang) or in parts (this might mean two OBIEE environments in production running in parallel till everything is brought over). - Although not recommended, but sometime due to the volume of code partial upgrade might be the only option. The separation could be made between independent departments or subject areas, which don’t use conformed dimensions. Only caveat to this approach would be if there are users who access all areas, they might have to login to different servers for reports.

8. How will the security model be in old vs new version? Will it remain the same or there will be changes made to it?  - Security implementation has significantly changed between 10g and 11g. This is a one time setup, but may mean redoing the security - especially LDAP based security in 10g, which was RPD based, is not weblogic based in 11g. Although data level security may not require any changes, as its often external table driven. But if data level security was applied using RPD group filters, that might have to be redone.

9. Instance strategy and MUD environments - while upgrading you might want to revisit number of instances required 'during' the upgrade as well as final list of instances. During upgrade typically you would have additional sandbox instances. The number of sandboxes might depend on number of components that are being upgraded. For example, if you are upgrading BI Apps as well as underlying database, you might want to keep two instances to better utilize development resources. One team would work on platform upgrade of OBIEE, while the other could perform testing against new database. A key consideration here is for the MUD sandbox. You want to make sure that MUD sandbox where code is tested before being pushed to development is the same environment as the dev/test/prod. If prod OBIEE is on a non windows based machine then it might mean having two boxes for MUD, one for client tools (if you don’t want developers to have client tools on their machines) and second the BI Server on a unix box.


10. Bug fixes available in newer version - decision to upgrade could also be based on the fact that newer version has a bug fix or a functionality that is required by the organization. This is more important if the issue is in production, and needs a solution. Other factors like Essbase integration of OBIEE makes a strong case for some organizations to upgrade. 

In addition to above considerations, while upgrading, you might want to take advantage of new features of the target version, for example mobile platform support in 11g, like iPads i.e. iOS mobile devices. Android fans no need to be broken hearted yet, as OBIEE has plans for android support in its pipeline. They plan to have their charts and graphs delivered in  HTML5 language, which will slowly transition to support in Android I believe at some point in 2014 or 2015.

Oracle BI Disconnected Analytics Missing?

Have you noticed that Oracle BI disconnected analysis that used to come with OBIEE 10g is missing? This was the component where users download some of the reports on their laptop and use it in disconnected / 'offline' mode. It was helpful for sales guys give real looking demos to their clients.

Well, Oracle has pulled this product off its stack and this is no longer available from Releases 11.1.1.5 and later. There are no plans to bring it back either. After a little research I found out that this module posed a data security risk, due to which it is discontinued. Once the data is downloaded, OBIEE is no longer able to authenticate the rightful owner of the objects.

Per Oracle, if you still need to use this product, do not upgrade to 11.1.1.5 or higher versions. However you will have to find an alternate to disconnected analytics as not upgrading will eventually make your production version of OBIEE not supported one day. On the other hand OBIEE Mobile capabilities well serve the same purpose of disconnected analytics in a better way!

Upgrading OBIEE 7.9.2 to 7.9.6.1

Upgrading BI apps version is a big process. Following steps were taken while upgrading in our environment:

1 . We will need three repositories to begin with, 7.9.2 original rpd , 7.9.2 customized rpd and 7.9.61 rpd. Its important than in 7.9.6.1 all OOTB modules from 7.9.2 should also be installed in addition to new SAs.

2. Equalize repositories - when installing OBI apps, oracle ships with map files that are requried to equialize the rpds. These have two steps:

StepA: Equalize 7961 to 792, command for this is :

equalizerpds -A Administrator -B SADMIN -C OracleBIAnalyticsApps792.rpd -D Administrator -E SADMIN -F OracleBIAnalyticsApps7961.rpd -J rename792796new.map -O oracleBIAnalyticsApps.rpd

StepB: Equalize CustomRPD to 792

equalizerpds -A Administrator -B SADMIN -C OracleBIAnalyticsApps792.rpd -D Administrator -E custompwd -F OracleBIAnalyticsAppscustom.rpd -J rename792796new.map -O customoracleBIAnalyticsApps.rpd

3. Next step is to use three way merge and create a new RPD. AdminTool has inbuilt merge option which will need to be used. Details of merge and other steps are available in "OBI Apps Upgrade.pdf" page 6-37 to page 6-44.

We had multiple errors during merge process. The goal here is to minimize this so that least manual work is required later. Way to do this is notice pattern of error and then change the custom rpd (equalized custom rpd) before merging and making the objects same as in 7.9.6.1 rpd, so that the algorithm treats the object as equal.

4. After rpds are successfull merged, consistency check needs to be performed. Here again there will be patterns of error, some can be fixed by making changed to rpd before merging and then merging again, others will need to be fixed manually.

We faced an unusuall error that read : "[nQSError: 42001] Missing repository object with ID=3003:338714". This error completely halted the process as we could not fix the error without knowing where the error is comming from. To fix this issue we followed three step process:

StepA: export merged rpd to udml using following syntax:

nqudmlgen.exe -u Administrator -p custompwd-r C:\OracleBI\Upgrade\04AfterManualWork\ManualoracleBIAnalyticsApps.rpd -o
C:\OracleBI\Upgrade\04AfterManualWork\merged.udml

StepB: convert udml file back to rpd file using following command:

nQUDMLExec -u Administrator -p customrpd -i C:\OracleBI\Upgrade\04AfterManualWork\merged.udml -o
C:\OracleBI\Upgrade\04AfterManualWork\ManualoracleBIAnalyticsApps1.rpd

This will create the rpd back , except that it will not bring in objects that was causing unusual errors.

StepC: Compare the new rpd with rpd that was give unusual error. This should be able to point all object which need to be fixed in order to proceed.

5. Once all errors and warningd are resolved, rpd is ready for regression testing. Any errors there after will need to be manually fixed.