How to Keep Track of OBIEE 10g Patches Applied? How To Handle Version.Txt Files When You Have Multiple Patches? Are Patches Cumulative?

Upgrading OBIEE 10g Repository To 11g Using The Upgrade Assistant ( UA ) Fails To Start The BI Server
June 29, 2012
OBIEE 11g Upgrade Assistant (UA) Fails When Upgrading A 10g RPD File To OBIEE 11g
July 8, 2012

Applies to:

Business Intelligence Server Enterprise Edition – Version: to [2405] – Release: 10g to 10g
Business Intelligence Suite Enterprise Edition – Version: to [2405]   [Release: 10g to 10g]
Information in this document applies to any platform.


– How to handle VERSION.TXT files when you have multiple patches?

– When Oracle supplies an OBIEE patch, its README file always says to replace the VERSION.TXT file on the [Oracle Home] directory with the one included.

– When you apply a second, unrelated patch to the environment why would we want to replace the entire VERSION.TXT file?

– Would you append the text in the second patch’s VERSION.TXT file to the first?

– How will this display on the Settings > Administration window when it displays the information in the Product Information box?

– Are OBIEE Patches cumulative?


This has been confirmed by Development.

1. Version.txt file should be replaced, following instructions in the readme files of each patch.
New version.txt file should not be appended to the end of the current one, but it should replace the current one.

2. Currently, for 10G versions, OBIEE patch installation does not provide for an automatic way of keeping track of the patches applied.

Nevertheless, Development is working to make 11g use opatch installer. Opatch provides a way to keep track of previous patches installed. There is no official date for 11G release.

3. It is recommended that you keep a record of the patches you have applied.
You could implement that in the way you prefer, but separated from OBIEE installation, and in addition to replace the version.txt file used in OBIEE.

For example, you could:
– Append the version.txt file to another file, with name version_history.txt or something like that, everytime you apply a patch.
– When applying first patch, rename original version.txt from GA release to version0.txt and copy version.txt from the patch.
Then, when applying second patch, rename version.txt to version1.txt and copy new version.txt from the second patch, and so on.
– copy new version.txt file to a file named like version_<YYYY_MM_DD>.txt, indicating the date when you applied it.
That way you can have in a single directory all the previous version.txt with its dates of installation.

4. OBIEE One-off patches are not cumulative at this time.

5. Production patches (the ones that do not require a password), normally, contain the fixes of older production patches.

6. When we create a new patch for you (that is when you report a new issue, never seen before, and then we create a fix for that and provide it to you) we ask you the list of one-off patches you have applied. Development uses it to create a merged patch including all those fixes plus the new one.

7. In the case a one-off patch is already available (so, it was not produced for you), you would need to open an SR to ask for a password to download it. In that same SR, please, provide the list of patches applied previously, so Support can determine if it is ok for you to apply the patch, or if a merged patch needs to be created for you.

8. When in doubt, ask ORACLE Support if a patch can be applied by you without conflict issues.

Leave a Reply