There are quite a number of things to think about with APEX and
multitenant. For those who want to dive into some of the details and
understand some additional aspects, consider looking at the OTN page for
APEX at
http://www.oracle.com/technetwork/developer-tools/apex/learnmore/apex-and-12c-1968249.html
and the docs at
http://docs.oracle.com/database/121/HTMIG/db_pluggable.htm#HTMIG29169
/Hans
On 18/07/2016 1:47 PM, Chris Taylor wrote:
Ok, I just went through my reinstall with 12.1.0.2.0 using dbca.
I installed ONLY a CDB which comes with the seed pdb only.
I ran apxremov_con.sql from $ORACLE_HOME/apex.
After execution 2 objects are invalid:
*OWNER* *OBJECT_NAME* *OBJECT_TYPE* *SHARING* *ORACLE_MAINTAINED* *STATUS*
PUBLIC APEX_PKG_APP_INSTALL_LOG SYNONYM METADATA LINK Y
INVALID
PUBLIC APEX_SPATIAL SYNONYM METADATA LINK Y INVALID
So, I check PDB_PLUG_IN_VIOLATIONS - shows a PDB error.
TIME NAME CAUSE TYPE ERROR_NUMBER LINE MESSAGE STATUS
ACTION
7/18/16 20:37 PDB$SEED APEX ERROR 0 1 APEX mismatch: PDB has installed common APEX. CDB has not installed APEX. PENDING Please contact Oracle Support.
So, I recompile invalid objects...
SQL> @?/rdbms/admin/utlrp.sql
The invalid Synonyms disappear - I have no idea why.
The Pluggable database violation still occurs however in the SEED database.
Can you confirm on your side that it shows in your PDB_PLUG_IN_VIOLATIONS?
Chris
On Mon, Jul 18, 2016 at 12:40 PM, Tim Hall <tim@xxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxx>> wrote:
OK. Just checked. It definitely removes stuff from the seed. Check
out the log files it produces. For example, if I check out the
"apxremov1_con0.log" log file it produces, I can see this kind of
thing.
SQL>
NOW_CONNECTED_TO
--------------------------------------------------------------------------------
==== Current Container = CDB$ROOT Id = 1 ====
SQL>
NOW_CONNECTED_TO
--------------------------------------------------------------------------------
==== Current Container = CDB$ROOT Id = 1 ====
SQL> 2
Session altered.
SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL>
SQL> SQL> SQL> SQL> SQL> SQL> SQL> 2
CATCONSECTION
--------------------------
==== CATCON EXEC ROOT ====
SQL>
BEGIN_RUNNING
--------------------------------------------------------------------------------
==== @apxremov1.sql Container:CDB$ROOT Id:1 16-07-18 06:28:08
Proc:0 ====
.
.
.
.
.
SQL>
NOW_CONNECTED_TO
--------------------------------------------------------------------------------
==== Current Container = PDB$SEED Id = 2 ====
SQL>
NOW_CONNECTED_TO
--------------------------------------------------------------------------------
==== Current Container = PDB$SEED Id = 2 ====
SQL> 2
CATCONSECTION
-----------------------------------
==== CATCON EXEC IN CONTAINERS ====
SQL>
BEGIN_RUNNING
--------------------------------------------------------------------------------
==== @apxremov1.sql Container:PDB$SEED Id:2 16-07-18 06:28:15
Proc:0 ====
When I create a new PDB I see this.
CREATE PLUGGABLE DATABASE pdb1 ADMIN USER pdb_adm IDENTIFIED BY
Password1
FILE_NAME_CONVERT=('/u01/app/oracle/oradata/cdb3/pdbseed/','/u01/app/oracle/oradata/cdb3/pdb1/');
ALTER PLUGGABLE DATABASE pdb1 OPEN;
ALTER PLUGGABLE DATABASE pdb1 SAVE STATE;
ALTER SESSION SET CONTAINER=pdb1;
SQL> show con_name
CON_NAME
------------------------------
PDB1
SQL> select username from dba_users order by 1;
USERNAME
--------------------------------------------------------------------------------
ANONYMOUS
APPQOSSYS
AUDSYS
CTXSYS
DBSNMP
DIP
DVF
DVSYS
GSMADMIN_INTERNAL
GSMCATUSER
GSMUSER
USERNAME
--------------------------------------------------------------------------------
LBACSYS
MDDATA
MDSYS
OJVMSYS
OLAPSYS
ORACLE_OCM
ORDDATA
ORDPLUGINS
ORDSYS
OUTLN
PDB_ADM
USERNAME
--------------------------------------------------------------------------------
SI_INFORMTN_SCHEMA
SPATIAL_CSW_ADMIN_USR
SPATIAL_WFS_ADMIN_USR
SYS
SYSBACKUP
SYSDG
SYSKM
SYSTEM
WMSYS
XDB
XS$NULL
33 rows selected.
SQL>
No APEX users left behind...
Cheers
Tim...
On Mon, Jul 18, 2016 at 6:00 PM, Chris Taylor
<christopherdtaylor1994@xxxxxxxxx
<mailto:christopherdtaylor1994@xxxxxxxxx>> wrote:
Yeah I'm getting ready to blow away this POC and do it again
before creating my own PDB and remove APEX from the container
and see what happens.
Chris
On Mon, Jul 18, 2016 at 11:51 AM, Tim Hall
<tim@xxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxx>> wrote:
When you remove APEX from the root container, it should
remove it from the seed also.
If you remove it on the clean installation, then create a
new PDB from the seed, none of the APEX pieces are in the
seed. I'm just going to create a new CDB to double check. :)
Cheers
Tim...
On Mon, Jul 18, 2016 at 5:45 PM, Chris Taylor
<christopherdtaylor1994@xxxxxxxxx
<mailto:christopherdtaylor1994@xxxxxxxxx>> wrote:
Yeah I followed your instructions and the SEED PDB
wasn't touched - I didn't unplug it or do anything
with it and the Apex removal definitely did not remove
Apex from the SEED db. :) It did remove it from the
container with no problem.
I think you're right - I should have remove Apex from
the PDB first, then unplugged it, then removed it from
the container. Then plugged the PDB back in.
You think we should unplug the SEED pdb before
removing Apex from the container, or leave it plugged
in? I left it plugged in and clearly that doesn't
seem to be good LOL
Chris
On Mon, Jul 18, 2016 at 11:37 AM, Tim Hall
<tim@xxxxxxxxxxxxxxx <mailto:tim@xxxxxxxxxxxxxxx>> wrote:
Questions:
You said, "I dropped APEX from the CDB following
your instructions...", then later you said, "I'm
going to drop APEX from both the SEED and my PDB
to see if it clears up." If you have followed my
instructions, APEX will have been removed from the
SEED anyway.
In my instructions, I said, "so either drop
existing PDBs, or unplug the PDBs and move them to
another container before starting.". I didn't
actually say plug them back in without doing
anything to them.
It would probably (haven't tried it) work if you
manually clean up all the APEX schemas from the
PDB before unplugging it, so they are not present
when you plug it back in.
Cheers
Tim...
On Mon, Jul 18, 2016 at 5:16 PM, Chris Taylor
<christopherdtaylor1994@xxxxxxxxx
<mailto:christopherdtaylor1994@xxxxxxxxx>> wrote:
Hey Tim,
I thought you should know about this. I'm
playing with Apex and 12c Multi-Tenant so all
I have is a base CDB install, and 2 PDBs - the
SEED and a new PDB created with DBCA.
So, it's very basic right? I noticed that APEX
was installed in all 3, then I found your post
here:
https://oracle-base.com/articles/12c/multitenant-uninstall-apex-from-the-cdb-12cr1
Here's the interesting bit:
I unplugged AND dropped my PDB following the
instructions here:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/pdb/pdb_unplug_plug/pdb_unplug_plug.html
I dropped APEX from the CDB following your
instructions but guess what?
The Unplugged PDB is now incompatible with the
CDB LOL.
I went ahead and plugged it in anyway to see
what would happen.
I get the following in PDB_PLUG_IN_VIOLATIONS
after dropping Apex from CDB:
TIME NAME CAUSE TYPE ERROR_NUMBER LINE
MESSAGE STATUS ACTION
7/18/16 11:01 APEXPDBP APEX ERROR 0
1
APEX mismatch: PDB has installed common APEX.
CDB has not installed APEX. PENDING Please
contact Oracle Support.
7/18/16 16:53 PDB$SEED APEX ERROR 0
1
APEX mismatch: PDB has installed common APEX.
CDB has not installed APEX. PENDING Please
contact Oracle Support.
Just thought you should know as there might be
more to dropping APEX from CDB than what we think.
I'm going to drop APEX from both the SEED and
my PDB to see if it clears up.
Thanks,
Chris
