Well … it’s been a while … but I would like to continue my journey to the cloud …
What happened so far on my Journey to the Cloud?
- Part I – Push a Button (Dec 3, 2015)
- Part II – Switch On/Off and Remove (Dec 4, 2015)
- Part III – Patch, patch, patch (Dec 22, 2015)
- Part IV – Clean Up APEX (Jan 19, 2016)
- Part V – TDE is wonderful (Jan 28, 2016)
- Part VI – Patching does not work (Apr 18, 2016)
- You are here ==> Part VII – APEX is in CDB$ROOT again (Dec 21, 2016)
Oracle Database 12.2.0.1 in the Cloud
Since November 2016 Oracle Database 12.2.0.1 is available in the Oracle DBaaS Cloud. And I received this question in my inbox yesterday:
I have a customer who wants to migrate Apex 4.2 applications to DBCS and ORDS.war to Weblogic on Compute.
I recently went through your blog on removing Apex from CDB Root. The customer is planning to do something similar but had questions on repercussions of doing so in Oracle Public Cloud.
What are the factors that need to be considered. Also how would DBCS patching work in this scenario.
Is APEX is in CDB$ROOT again
I haven’t checked this yet as we’ve had a very productive conversation with the APEX folks a while back. And I’m 100% sure that the APEX group wasn’t involved in this decision as they recommend clearly in the doc to NOT HAVE APEX installed in the CDB$ROOT 😉
Ok, I did connect to our Cloud environment and … voila …
COLUMN VERSION FORMAT A15 COLUMN NAME FORMAT A12 COLUMN COMP_ID FORMAT A10 SQL> select r.comp_id, r.version, c.name from cdb_registry r, v$containers c where r.con_id=c.con_id and r.comp_id='APEX' order by 3 COMP_ID VERSION NAME ---------- --------------- ------------ APEX 5.0.4.00.12 CDB$ROOT APEX 5.0.4.00.12 ROYPDB1
Ouch …
The presence of APEX in the CDB$ROOT may have to do with the Oracle DBaaS Monitor Console. This is just an assumption but when I removed the APEX in my old 12.1.0.2 cloud deployment I had to clean-up the DBaaS Monitor as well.
See:
for my experience a few months ago.
Solution?
Well, having APEX in the CDB$ROOT is still a brilliant [IRONY!] idea. As soon as you start unplug/plug operations with APEX in the PDB only or with a different APEX version you are asking for trouble.
See this blog post for the potential pitfalls:
Which options does the customer have assuming that his APEX 4.2 application is in a non-CDB?
- Upgrade APEX locally to 5.0.4.00.12 before migrating the database to the DBaaS cloud
This would be the easiest workaround if it wouldn’t involve an application software upgrade. Through the Oracle glasses this looks simple – but from a customer’s and application developer’s standpoint this isn’t trivial as most likely it will involve application testing - Export the APEX application and import it
I haven’t done this by myself but first of all with APEX 4.2 (or below) you must take care to move the image files as well – and you’ll have to move data as well. And, of course, you won’t end up in APEX 4.2 but in APEX 5.0 so the above mentioned application upgrade will hit you as well. I don’t see any benefit over solution 1.
See Jason Straub’s blog post about:
Convert Common Oracle Application Express in a CDB to Local APEX in PDBs - Remove APEX from the 12.2.0.1 DBaaS Cloud deployment’s CDB$ROOT
This is – in my humble opinion – the only viable solution here if the customer can’t upgrade APEX in the current environment for whatever reason. But this will most likely remove the DBaaS Monitor as well. I can live without it but I know that it offers a lot of good stuff especially when dealing with encrypted tablespaces which is otherwise hard to handle on the command line. The good part of this solution is the freedom and flexibility you’ll get once APEX is removed from the CDB$ROOT for unplug/plug operations in the future.
The ugly part: this is hanging in my deployment and can’t be solved right now. I’m waiting for a newer DBaaS deployment release and will retest again.
Finally, regarding patching:
I don’t see any issues. And the same for a future upgrade as we decouple APEX upgrades from the database upgrade with Oracle Database 12.2.0.
–Mike
