Pros
- Provides flexibility for a DBA to run multiple APEX versions in an Oracle Multitenant Container Database.
- Customers are always advised to install latest version of APEX. The version of APEX that is bundled with the Oracle Database is quickly out of date.
- Reduces the Oracle Database upgrade time if APEX is not installed.
- Will result in less space consumption on disk and in the Database.
- Consistent with the deployment of Application Express in the Oracle Database Cloud
- Consistent with our recommendations in Oracle documentation and from Mike Dietrich, Product Manager for Oracle Database Upgrade & Migrations.
- Reduces the attack surface for Oracle Multitenant Container Databases which do not require APEX.
Cons
- Requires more steps for customers to get up and running with APEX in a new Oracle Database. (Granted, this would be with the version of APEX that is bundled with the Oracle Database, which as cited earlier, can get out of date rather quickly).
With all this said, a few things remain unchanged:
- Oracle Application Express will continue to be a fully supported and included Oracle Database feature
- Oracle Application Express will continue to ship with the Oracle Database 12cR2, in directory $ORACLE_HOME/apex.
- It will continue to be supported to install and run Oracle Application Express in the "root" of an Oracle Multitenant Container Database
- It will continue to be supported to install and run Oracle Application Express locally in a pluggable database in an Oracle Multitenant Container Database
- Oracle Application Express will be an installable component in the Oracle Database Creation Assistant (DBCA)
I totally understand the Pro's and they make reasonable sense from a technical standpoint.
ReplyDeleteI'm sad, however, about the Con - that Apex used to be installed by default in any Oracle database. This made it very easy to sell a customer on the idea of trying Apex, especially a customer with a bureaucratic organisation.
Up until now when a potential customer who knows nothing about Apex asks about what's involved in getting started, they will ask questions like "can it easily be installed here?", "won't it interfere with our other applications on the same instance?", "how much effort will it be to install it?", etc. etc. The answers to these questions has been "It's already installed, and it's already in your Production instance right now" and the discussion ends there.
Any resistance to installing Apex for a new client for these reasons is, of course, quite irrational; but we will now have this extra psychological roadblock to get past - "we first need to install Apex on the database instance" now gets dropped in the too-hard basket because it's a big unknown. Installing a new product involves getting approvals, DBA project time, doing regression testing on all other applications running in that instance, etc. etc. Upgrading an existing installation is much much easier to get approved and implemented.
It's a pity to see the default installation of Apex go. Technical reasons are fine, but you have to consider the reality that in many organisations, choices are not always made along purely technical lines - fear of the unknown is often difficult to overcome.
Hi Jeff,
ReplyDeleteThanks for your insightful feedback. As you know, I am the last person on the planet who wishes to do anything which harms increased APEX adoption. Your points are valid, and I don't disagree with the "psychological roadblock".
As an example, let me be generous and say that APEX is used in 25% of the Oracle Databases on the planet (25% is a conjured number for this example). We ultimately owed it to the DBA's and administrators and customers of the other 75% of the databases to not endure the increased DB upgrade time, or increased space consumption, or larger attack surface.
Since we advise in our documentation not to install APEX as common (in CDB$ROOT), and the Oracle Database Upgrade & Migration Product Manager blogs about removing APEX from being installed common, then any customer could reasonably ask "Hey Oracle, why doesn't your default installation mirror your advice?" And that's what we tried to provide - our best practice for customers, even at the expense of some of the challenges you cite above.
The one bright spot for your situation - as of today, if a DBA runs DBCA (Database Creation Assistant) in Oracle Database 12cR2 and chooses "Custom" instead of a DB template which includes data files, then the APEX component is still checked by default. So you may still get your wish.
Thanks again for the candid feedback.
Joel
Combating fear of the unknown is best done with facts. The official Oracle docs for Apex could help, if they were up to the standards we see in the regular database docs.
ReplyDeleteHi Greg,
ReplyDeleteAre there specific deficiencies you think should be addressed in the APEX documentation, which is not up to the standards of the Oracle Database documentation? We welcome your guidance.
Joel
One could start with a high-to-mid level overview explaining how it works and helping set the stage with the data driven mindset. A sort of logical data model would be nice. A process map to show what gets called and when. These can be intuited by using it and digging into the apex schema but the point of documentation is to not have to do that.
ReplyDeleteHere's a super concrete example: When and what issues a commit?
As a developer relying on this black box I think I want to know that and I have been surprised more than once by this one. This is an important concept for a developer yet a search of the docs returns nothing about it except under APEX_UTIL.SET_SESSION_STATE (thank you so much for that p_commit parameter by the way).
A better explanation of session state would be helpful. Since on the rendering side I can use :PX_ITEM, I could assume that I could keep finding the value of PX_ITEM without posting it somehow..say in an onload dynamic action. Can the documentation tell me if I can or not? I think that it should.
But also the person you should be asking is the person who has not been using Apex since Marvel. I get frustrated but I'm willing (and empowered by years of experience) to tinker until I figure it out. The comment I was addressing here was about adoption by new users. I could be wrong of course, but I think that the documentation plays into this.
@Jeffrey - I agree and think this will have a huge impact on us here in AU/NZ as it seems that we have more "psychological roadblock" clients where US and EU do not have these problems.
ReplyDeleteI am conflicted. :)
ReplyDeletePersonally, I much prefer the local installation of APEX in a PDB, rather than the shared installation. It irks me to have to create a new CDB, remove the shared APEX installations, then create my PDB. I understand why the shared installation is great for some people, but it's not what I need. :)
I think there is another aspect to the "not having it installed by default issue". Some of the the PL/SQL utilities that APEX brings with it are really useful. Having APEX installed means these were always available for use. If it is no longer installed, they are gone until someone chooses to do an install. Bummer.
Cheers
Tim...
Having just gone through a significant application migration to 12c and experienced some of the pains involved when APEX is installed in the CDB, I can honestly say this is really good news for APEX Developers.
ReplyDelete@Jeff - I take your point, however having APEX installed in the DB is often only half the battle. I've experienced more friction trying to get buy-in on setting up the new webservers (ORDS etc).
With Oracle Multi-tenant, I think it becomes an easier sell to say lets spin up a new PDB (licensing issues aside) and install APEX in it (without affecting the Prod PDB), so it can be evaluated before installing into Prod.
John
Hi,
ReplyDeleteFor technical issues, I should drop and recreate the oracle insctance which is linked to APEX 4.2.6.
If I drop the instance, will be there an impact on the APEX envoronnement? (APEX objects like tables, jobs, schedules and views.... and the application....)
Thanks in advance.
Hi King,
ReplyDeleteWhat kind of "technical issues"? Why would you drop and recreate the Oracle DB instance?
If you drop the instance, you'll lose everything - your application definitions, your data, everything. Of course, you can always export your data, export your APEX applications, etc. But I can't imagine a common situation which would require you to destroy your DB instance simply because of "technical issues".
Joel