I found the issue - already filed as a bug and fixed:
PDB_PLUG_IN_VIOLATIONS Showing 'APEX mismatch' for PDB$SEED Though APEX has
been Correctly Removed from CDB (Doc ID 2101651.1) [image: To Bottom]To
Bottom
<https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=vr46vdfok_9&_afrLoop=226077698846991#>
------------------------------
*Fixed in 12.2*
On Mon, Jul 18, 2016 at 2:47 PM, Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> 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> 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> 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> 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> 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>
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> 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
