ORA-00600: internal error code, arguments: [kziaVrfyAcctStatInRootCbk: !user], [APEX_PUBLIC_USER] after noncdb_to_pdb.sql

I found a bug last week after the creation of a PDB from NON-CDB in an empty 12.2 CDB with the noncdb_to_pdb.sql script :

After a successful conversion from NON-CDB to PDB, here is the error when trying to connect in the PDB as APEX_PUBLIC_USER :

In the PDB, I looked at the APEX users more closely and found that APEX_PUBLIC_USER and APEX_050000 were defined as common users. Even if they are not available in the root container, see the result of the CDB_USERS view below :

So to make a long story short, the noncdb_to_pdb.sql did not "convert" the APEX_PUBLIC_USER and APEX_050000 schemas as local users but left them as common users. A service request was raised and until an official fix is available, here is a workaround that Oracle Support gave to bypass the issue :

After this UNSUPPORTED modification to the data dictionary of the PDB, we were able to connect as APEX_PUBLIC_USER as it should be (without ORA-00600) :

Oracle will release a patch to correct the problem to the noncdb_to_pdb.sql script. The script will convert the common APEX users to local users only if they are not already available on the root container (default 12.2):

Bug 25979661 : ORA-00600: [KZIAVRFYACCTSTATINROOTCBK: !USER] [APEX_PUBLIC_USER]
https://support.oracle.com/epmos/faces/BugDisplay?id=25979661

Once again the workaround provided here is NOT SUPPORTED by Oracle and was used only to diagnose the problem.

Repartitioning a root persistent disk on Linux Red Hat 7 (Google Cloud)

You can take this procedure from the Google Cloud Platform documentation: Repartitioning a root persistent disk

Or you can take this shell script ... https://raw.githubusercontent.com/DarkAngelStrike/GoogleCloud/master/fdisk.sh

Here is an example on a new Red Hat 7 instance ...

Modifying firewall rule of Google Cloud VM with command line tools.

Here's how to modify and add port 1522 to an already defined firewall rule named "allow-tns" of a Google Cloud VM.

And the links to gcloud commands ...

gcloud compute firewall-rules list
gcloud compute firewall-rules update

Adding Oracle ASM disks to Google Cloud VM with command line tools.

This is what the web portal looks like and if you haven't tried the Google Cloud Platform yet you really should do so.

Google Cloud Platform

Here is some links to the docs of the gcloud commands used in this post ...

gcloud compute instances describe
gcloud compute instances list
gcloud compute disks describe
gcloud compute disks create
gcloud compute instances attach-disk
gcloud compute instances detach-disk

dbaascli - CLI for different tools to be used with Oracle Cloud DB

Enable EPEL Repository - Oracle Database Cloud Service

PSU bundle patch: Installed in the CDB but not in the PDB.

Adding Oracle ASM disk to Amazon EC2 with command line tools.

DBMS_METADATA generating incorrect syntax for the CREATE TABLE statements with ROW ARCHIVAL enabled (12.1.0.2)

While experiencing with the In-Database Archiving feature in 12.1, I stumble upon this unpublished bug with DBMS_METADATA.GET_DDL.

The clause "ILM ENABLE LIFECYCLE MANAGEMENT" was returned instead of "ROW ARCHIVAL" which causing an ORA-00933 at creation time. And here is what I found on My Oracle Support about this issue who is also impacting datapump imports in 12c:

CAUSE
The cause of this problem has been identified in:
unpublished Bug:17653443 - DBMS_METADATA.GET_DDL GENERATES WRONG DDL FOR TABLE WITH ROW ARCHIVAL
closed as duplicate of:
unpublished Bug:17654567 - DATA FROM ROW ARCHIVAL COLUMN ORA_ARCHIVE_STATE NOT TRANSFERRED WITH DATA PUMP
It is caused by DBMS_METADATA generating incorrect syntax for the CREATE TABLE statement in the dump file.
Bug:17654567 is fixed in RDBMS 12.2.

ORA-39083 and ORA-0093 When Using IMPDP to Import a Table With Row Archival Enabled (Doc ID 1999047.1)

Move datafile like a "lying child" - Oracle 12c

I tried to move a PDB datafile (PDB1) with the fullpath name from the CDB$ROOT container.

And the database is acting like a "lying child" responding it doesn't know file #13 ...

As you can see, you need to be in the right container to make it work.