The Oracle New Release Model is very young, and thus suffers of some small inconsistencies in the release naming.
Oracle already announced that 18c was a renaming of what was intended to be 12.2.0.2 in the original roadmap.
I though that 19c would have been 12.2.0.3, but now I have some doubts when looking at the local inventory contents.
I am consistently using my functions lsoh and setoh, as described in my posts:
and:
Oracle Home Management – part 5: Oracle Home Inventory and Naming Conventions
What I do, basically, is to get the list of attached Oracle Homes from the Central Inventory, and then get some details (like version and edition) from the local inventory of each Oracle Home.
But now that Oracle 18.3 is out, my function shows release 18.0.0.0.0 when I try to get it in the previous way.
|
1 2 3 4 5 6 |
# [ oracle@server1:/u01/app/grid/crs1830 [08:53:50] [18.0.0.0.0 [GRID] SID=+ASM1] 0 ] # # lsoh HOME LOCATION VERSION EDITION ---------------------- ---------------------------------- ------------ --------- OraGI18Home1 /u01/app/grid/crs1830 18.0.0.0.0 GRID |
The fact is that prior to 18c, the component version was showing the actual version (without patches):
|
1 |
<COMP NAME="oracle.rdbms" VER="12.1.0.2.0" [...] " ACT_INST_VER="12.1.0.2.0" [...]> |
but now, it shows the “base release” 18.0.0.0.0, whereas the ACT_INST_VER property shows the “Active” version:
|
1 |
<COMP NAME="oracle.rdbms" VER="18.0.0.0.0" [...] ACT_INST_VER="12.2.0.4.0"[...]> |
You can see that ACT_INST_VER is 12.2.0.4.0! does it indicate that 18.3 was planned to be 12.2.0.4?
like …
12.2.0.2 -> 18.1
12.2.0.3 -> 18.2
12.2.0.4 -> 18.3
?
This is in contrast with MOS Doc ID 230.1 that states that 18c was a “sort of” 12.2.0.2, so probably I get it wrong.
My first reflex has been to search, in the local inventory, where the string 18.3.0 was written down, but with my surprise, it is just a description, not a “real value”:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
<ONEOFF REF_ID="28090523" UNIQ_ID="22329768" ROLLBACK="T" XML_INV_LOC="oneoffs/28090523/" ACT_INST_VER="12.2.0.4.0" INSTALL_TIME="2018.Jul.18 20:06:33 CEST"> <DESC>Database Release Update : 18.3.0.0.180717 (28090523)</DESC> [...] # grep '18\.3\.0' comps.xml <DESC>Database Release Update : 18.3.0.0.180717 (28090523)</DESC> <DESC>OCW RELEASE UPDATE 18.3.0.0.0 (28090553)</DESC> <DESC>ACFS RELEASE UPDATE 18.3.0.0.0 (28090557)</DESC> <DESC>DBWLM RELEASE UPDATE 18.3.0.0.0 (28090564)</DESC> <DESC>TOMCAT RELEASE UPDATE 18.3.0.0.0 (28256701)</DESC> <DESC>OJVM RELEASE UPDATE: 18.3.0.0.180717 (27923415)</DESC> |
Again, the ACT_INST_VER property reports 12.2.0.4.0.
So, where can we extract the version we would expect (18.3.0.0.0)?
Oracle 18c provides a new binary oraversion that gives us this information:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# oraversion This program prints release version information. These are its possible arguments: -compositeVersion: Print the full version number: a.b.c.d.e. -baseVersion: Print the base version number: a.0.0.0.0. -majorVersion: Print the major version number: a. -buildStamp: Print the date/time associated with the build. -buildDescription: Print a description of the build. -help: Print this message. # oraversion -compositeVersion 18.3.0.0.0 |
Note that 18.3.0.0.0 differs from the description:
|
1 |
Database Release Update : 18.3.0.0.180717 |
which is, as far as I understand, just a bad way to use the old notation to give the idea of the release date of such release update.
Also note that baseVersion has always the format <MAJOR>.0.0.0.0.
In the future I expect that ACT_INST_VER will be consistent with the compositeVersion, but I cannot be sure.
—
Ludo
Latest posts by Ludovico (see all)
- When it comes to using Oracle, trust Oracle… - July 14, 2023
- Video: Where should I put the Observer in a Fast-Start Failover configuration? - November 29, 2022
- Video: The importance of Fast-Start Failover in an Oracle Data Guard configuration - November 29, 2022