Oracle Database 12c Release 2 (12.2) is available now in the Oracle Cloud in DBCS and ECS in both NAS and EMEA zones, as well as being available on Exadata Express Cloud Service. The Oracle Database 12.2 documentation should be published later today.
Just to note down, the versions supporting direct upgrade either with catctl.pl on the command line or with DBUA are:
- Oracle Database 22.214.171.124
- Oracle Database 126.96.36.199
- Oracle Database 188.8.131.52
- Oracle Database 184.108.40.206
No direct upgrades are supported from versions below Oracle Database 220.127.116.11.
For versions older than Oracle Database 18.104.22.168 other tools such as Data Pump or techniques such as Transportable Tablespaces may be used in order to avoid double- or triple-hops jumping from one release to another. And of course those will work when migrating into the Oracle Cloud as well.
For Downgrades you can downgrade back down to the version you have upgraded from for non-CDBs.
Where do I get the 22.214.171.124 upgrade?
I must be missing something because I have searched the Oracle and non Oracle sites, and haven’t found any 126.96.36.199 upgrade to download.
You’ll get the 188.8.131.52 software only in the Cloud right now. There’s no date communicated for the on-premises release yet.
When exactly Oracle Database 12c Release 2 (12.2) released?
and is that possible to upgrade to this new release in our server machine without hosting our database in Cloud?
I can’t tell you. We’ll announce it as soon as it will be available on-premises.
Is there at least hypothetical date (or quarter or year) when the 12.2 will be available on-premises..?
We are planning upgrade from 11.2 and would prefer to upgrade to 12.2 at once..
I recommend to everybody being in my workshops and talks Oracle 184.108.40.206 for quite a while for two simple reasons:
(1) Oracle Database 220.127.116.11 is not available yet on-premises but only in the Oracle Cloud – and no, I don’t have a confirmed date but we’ll announce it as soon as it gets confirmed.
(2) Be honest: Most will wait for the first or even the second patch set (18.104.22.168. or 22.214.171.124) – and usually patch sets based on the experience in the past take 11-14 months after the initial base release.
There is no such thing as a "First" and "Second" release anymore. I know that 126.96.36.199 will need some treatments (patches and parameters) but actually all my customers I helped with going live on 188.8.131.52 are EXTREMELY happy with it. Just at a conference recently somebody mentioned in the audience that for him and his company 184.108.40.206 is the most stable release he has seen since 7.3.4. And yes, there are some treatments necessary.
Any ETA on 12.2 release to on-prem? thanks!
You said it need some treatments necessary.
Can you share, what are they ?
Soon … please be patient 🙂
There will be an update within the next days.
a lot of the treatments are mentioned on the blog (for instance lower job_queue_processes, disable the multiple logwriters etc) and in our slide deck.
The most important thing most likely is this one here:
as the "adaptive" piece and the influence on optimizer_dynamic_sampling in 12.1. caused "some" issues.
Oracle CORP showing the whole world how desperate they are loosing Could to Amazon. Every presentation from Oracle that I have attend lately Oracle are literately forcing to use Oracle Cloud . when you are Oracle shop 100% perhaps Oracle Cloud makes seance. But face it I need to run Casandra , Mongo, Etc. So to attract customers to Oracle Cloud Oracle offering 12.2 on Oracle Cloud only first, from the side it is looks so desperate from Oracle
You for sure haven’t been to any of my presentations lately 😉
No, simply not enough time to attend all oracle related presentation, but those that I did went to Oracle starts with the prayer – ‘O deer Oracle Cloud …" "We are here in the name of Oracle Cloud " etc. But as for me DBA I evaluated both and I can boldly tell that Oracle Cloud is not the same as AWS. AWS is way more robust. and AWS idea of Cloud is way more robust. over 20 +years I notice that Oracle are very good on the core product, never good at GUI representational interface of the product, what’s makes user experience difficult and complex. I went and crated simple oracle db on Oracle Cloud , well took 3 hr to have it ready functional. I am asking myself a question did the Cloud tools created db or some team from India on the background manual ran dbca ???
Will the 12.2 on-premises still has the option to install as non-CDB?
I wonder if the 12cR2 on-premises still has the option to install as non-CDB.
Hi Mike, my client runs 220.127.116.11, is there any impact analysis ( including know issue ) that I can notify the customer.
as I blindly guess – you never been to one of my or Roy’s workshops 😉 If your local user group is willing to host a full day event I would come and show you that not all Oracle presentations have to start with a prayer 😉 😉
And I see your points – but I’m not the right person to give you the best advice. I’m just the "upgrade guy" 😉
yes of course – the non-CDB architecture has been deprecated only meaning we don’t develop it further. But nothing will change in Oracle Database 12.2 – and we’ll see what will happen afterwards.
Yes, of course. That’s a simple but manual exercise.
Search for 161818.1
Click on the 11.2 release link
Click on the "Availability and Known Issues" note for your client’s patch set, for instance 18.104.22.168
Then see the ALERTS, Patch Recommendations and also the ISSUES INTRODUCED.
This is not a complete list but it gives you advice about the most important issues.
Oracle 12c client works fine with 12cR2 , is there a support statement from oracle on this?
Oracle Support Document 207303.1 (Client / Server Interoperability Support Matrix for Different Oracle Versions) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=207303.1
I have been working with Oracle since 9/9i versions and it is undoubtly a great RDBMS.
But considering the issues I have been going through since then, I have no courage to upgrade a critical production environment, running smoothly, from 22.214.171.124 to 12.1. And even a release 12.2 wouldn’t make me upgrade promptly (not whithout creating a environment for exhaustive validation).
Any Oracle tiny new features always bring complex licenses issues together. That will make me wait until I feel comfortable and ready to upgrade.
I’m not even talking about using Oracle cloud.
Some of you running oracle 9.2 – I will tell you that I am still running
Oracle 7.3 on MPRAS OS , on Pentium III and my db is 1+TB on and Oracle Forms V3 with Pro*C, Ha Ha beat me on that lowest point.
no prob – see our slide deck with the Oracle V6 screenshot – that’s from a customer and DB is on OS/2.
Hello, I looked at Oracle Technology Network > Database > Database 12c > Downloads for Oracle 12c Release 1 on Linux x86-64, but it is not there anymore.
Do you happen to know where I can find Oracle Database 12c Release 1 to download for Linux x86-64?
It is there – please see the link here:
2nd paragraph is 12.1
Currently I’m installing 2 fresh 12.2 RACs.
One issue while running the root.sh script was, that I had to change the
/dev/sd* to /dev/mapper to
This is because, we are using multipath devices and root.sh scrip expects the candidate devices under the wrong path (/dev/sd* instead of /dev/mapper/).
My question regarding future upgrades to 126.96.36.199:
Should I update the /u01/app/12.2.0/grid/crs/install/crsconfig_params with new parameters, such as new NICs for private or public networks, paths and so on, which will occured after the initial installation of the RAC? I’m asking this, because I assume that this file is the reference for future upgrades.
Best regards Peter
let me check – and I’ll get back to you asap.
REG> This is because, we are using multipath devices and root.sh scrip expects the candidate devices under the wrong path (/dev/sd* instead of /dev/mapper/).
The discovery string for ASM (devices) can be changed during the installation. root.sh takes the value provided by the installer – it does not “expect” a value. The installer offers to change the discovery string in interactive mode as well as in silent mode. Please, let me know whether you need more information on this part.
For the current system, you don’t need to change crsconfig_params, as it is not required to update crsconfig_params for any configuration changes after the initial deployment. The crsconfig_params file in a GI home is for one-time use only – during root.sh/rootupgrade.sh of that home.
In other words, once the system is installed, any subsequent (in-place) patch or other operations will use the current configuration of the system that is manifested in the OLR and / or the profile. The current crsconfig_params file is not maintained constantly and therefore will not be used directly.
During upgrades, the installer populates the new crsconfig_params in the target home with the up-to-date configuration data of the cluster. This crsconfig_params in the new/target home will be used by rootupgrade.sh of that home. rootupgrade.sh will never access crsconfig_params of the old home for any data.
Concluding, there is no need to maintain the crsconfig_params file.
REG> Should I update the /u01/app/12.2.0/grid/crs/install/crsconfig_params with new parameters, such as new NICs for private or public networks, paths and so on, which will occured after the initial installation of the RAC? I’m asking this, because I assume that this file is the reference for future upgrades.
Your assumption is not correct. See the above clarification.
Hope this helps (and thanks for Markus Michalewicz who got me the answer).
many thanks for your effort. You did realy help me.
However, I could not discover any issues with 12.2 GI and DB.
Swingbench loadtest has reached 6000 TPS per instance, unplug/plug of PDB works very well, restore and recover, too. Solid work!
One issue comes with Oracle Linux (see: https://community.oracle.com/thread/4069268), but this I could resolve.
We want to go in production within the next 2 months…
“Viele Grüße aus Dresden”
We would like to upgrade 188.8.131.52 to 184.108.40.206 using GI home cloning, with GI home gold copy with latest RU applied. The crsconfig_params file (and a few other files) are removed from the gold copy. So, with upgrade steps by cloning (high level) as follows:
1. Deploy the 12.2 GI gold image copy into 12.2/grid home on all 220.127.116.11 nodes.
2. Stop 18.104.22.168 CRS on all nodes.
3. Run clone.pl to register 12.2/grid home in inventory.xml. (=> clone.pl … ORACLE_HOME=”/../12.2/grid” … CRS=true)
4. Before config.sh, set CRS=false for the 12.2/grid home in inventory.xml, as one one GI home can have CRS=true. (=> runInstaller -updateNodeList ORACLE_HOME=”/../12.2/grid” CRS=false)
5. As 12.2/grid/crs/install/crsconfig_params not exist in gold copy, will next step config.sh run?
I.e. will config.sh(rootupgrade.sh) re-create the crsconfig_params file as you mentioned?
6.Execute config.sh -silent -responseFile , with oracle.install.option=UPGRADE.
Are the above steps correct? I hope I do not miss any key steps, e.g. the crsconfig_params management before config.sh (rootupgrade.sh).
Your input are much appreciated!
I just finished a fresh 12.2 GI installation using cloning method. The clone.pl did create the crsconfig_params file, so step 5 in the above is not needed as you mentioned previously.
Thanks for the update 🙂
Are you aware of any manuals describing how to do in-place upgrade of existing DBCS from 12.1 to 12.2?
I’aware how to install a new Oracle 12.2 home and dbua instance to it.
But will it cause problems with existing db cloud tools or service web ui?
the upgrade path currently is to move your database from one to another environment and upgrade it there. You could also install 12.2 in your current env by installing 12.2 via SSH manually. But then you rely on a silent install etc. I know that the team is testing the upgrade option right now – and it should be released soon and ease things.
I will blog about it as soon as things are settled rock solid.
Thank you for the update. Moving DBCS database to other environment seems to be complicated as this database is already tied with existing Java Cloud Services.
Yes, my initial intention was to do a silent dbua (so it is transparent to external services), but I was not sure if I needed to do more steps to make cloud managing tools (/var/opt/oracle/ocde) aware of this change.
Looking forward for the upgrade option.
it should be available within a few weeks hopefully. I will update the blog with a new post as soon as it is ready to go-live. And I fully agree, all other options don’t seem very reasonable.
Please share the details on this blog for Database Downgrade from Oracle 22.214.171.124 to Oracle 126.96.36.199 Non-CDB.
please find it here: