APEX is in CDB$ROOT again – Journey to the Cloud VII

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?

DBaaS Oracle Cloud

Oracle Database in the Cloud

Since November 2016 Oracle Database 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 …


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

---------- --------------- ------------

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 cloud deployment I had to clean-up the DBaaS Monitor as well.


for my experience a few months ago.


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 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 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.


Share this: