Upgrade Testing – Online Clone a PDB to 19c

Posted on March 6, 2020 by Single-/Multitenant Upgrade / Migration 46

In the past I wrote some articles about cloning PDBs to new environments. And I added a post about RELOCATE as well. But I realized that I have no specific blog post about a very typical scenario: Upgrade Testing – Online Clone a PDB to 19c.

Upgrade Testing - Online Clone a PDB to Oracle 19c

Photo by Jørgen Håland on Unsplash

My Setup

I have an Oracle 12.2.0.1 CDB with a PDB, and another Oracle 19.6.0 CDB. I will hot clone the PDB from 12.2.0.1 to the higher version CDB, and then upgrade the PDB.

Upgrade Testing - Online Clone a PDB to Oracle 19c

The motivation to do it this way is to allow testing for the application teams within my test environment being already on 19.6.0. As soon as AutoUpgrade supports this scenarios as well, you can automate this every night.

Hot Cloning

You can use Hot Cloning since the introduction of Local Undo with Oracle 12.2.0.1. Hence, if my source is at least Oracle 12.2.0.1 and if I use the default, Local Undo, this works. As usual, I show the sequence of actions:

CDB1 CDB2
Create a common user for the relocate operation and assign necessary privileges:

CREATE USER c##borg IDENTIFIED BY oracle DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp CONTAINER=ALL;
GRANT CREATE SESSION, CREATE PLUGGABLE DATABASE, SYSOPER TO c##borg CONTAINER = ALL;
Create the public database link for the relocate operation:

CREATE public DATABASE link clonemypdb CONNECT TO c##borg IDENTIFIED BY oracle USING 'CDB1';
Initiate the relocation:

CREATE PLUGGABLE DATABASE PDB1 FROM PDB1@clonemypdb file_name_convert=('CDB1','CDB2');
Open the PDB:

ALTER PLUGGABLE DATABASE PDB1 OPEN UPGRADE;

The PDB will open with errors in RESTRICTED mode only.

Then I need to open PDB1 in CDB2 in UPGRADE mode because its dictionary is still an Oracle 12.2.0.1 dictionary whereas it operates now within a 19c database.

I need to upgrade it.

Upgrade of the PDB

This step is simple as I just avoid the preupgrade step. In my environment there are no extra tasks necessary for PDB1 before upgrading it.

Invoke the upgrade in the CDB2 environment:

$ dbupgrade -c "PDB1" -l /home/oracle/logs

Argument list for [/u01/app/oracle/product/19/rdbms/admin/catctl.pl]
For Oracle internal use only A = 0
Run in                       c = PDB1
Do not run in                C = 0
Input Directory              d = 0
Echo OFF                     e = 1
Simulate                     E = 0
Forced cleanup               F = 0
Log Id                       i = 0
Child Process                I = 0
Log Dir                      l = /home/oracle/logs
Priority List Name           L = 0
Upgrade Mode active          M = 0
SQL Process Count            n = 0
SQL PDB Process Count        N = 0
Open Mode Normal             o = 0
Start Phase                  p = 0
End Phase                    P = 0
Reverse Order                r = 0
AutoUpgrade Resume           R = 0
Script                       s = 0
Serial Run                   S = 0
RO User Tablespaces          T = 0
Display Phases               y = 0
Debug catcon.pm              z = 0
Debug catctl.pl              Z = 0

catctl.pl VERSION: [19.0.0.0.0]
           STATUS: [Production]
            BUILD: [RDBMS_19.6.0.0.0DBRU_LINUX.X64_191217]


/u01/app/oracle/product/19/rdbms/admin/orahome = [/u01/app/oracle/product/19]
/u01/app/oracle/product/19/bin/orabasehome = [/u01/app/oracle/product/19]
catctlGetOraBaseLogDir = [/u01/app/oracle/product/19]

Analyzing file /u01/app/oracle/product/19/rdbms/admin/catupgrd.sql

Log file directory = [/home/oracle/logs]

catcon::set_log_file_base_path: ALL catcon-related output will be written to [/home/oracle/logs/catupgrd_catcon_17267.lst]

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/catupgrd*.log] files for output generated by scripts

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/catupgrd_*.lst] files for spool files, if any


Number of Cpus        = 2
Database Name         = CDB2
DataBase Version      = 19.0.0.0.0
PDB Parallel SQL Process Count = [2] is higher or equal to CPU Count = [2]
Concurrent PDB Upgrades defaulting to CPU Count [2]
Parallel SQL Process Count (PDB)      = 2
Parallel SQL Process Count (CDB$ROOT) = 4
Concurrent PDB Upgrades               = 2
Generated PDB Inclusion:[PDB3]
CDB$ROOT  Open Mode = [OPEN]
Concurrent PDB Upgrades Reset           = 1

Start processing of PDBs (PDB1)
[/u01/app/oracle/product/19/perl/bin/perl /u01/app/oracle/product/19/rdbms/admin/catctl.pl -c 'PDB3' -l /home/oracle/logs -I -i pdb3 -n 2 /u01/app/oracle/product/19/rdbms/admin/catupgrd.sql]

Argument list for [/u01/app/oracle/product/19/rdbms/admin/catctl.pl]
For Oracle internal use only A = 0
Run in                       c = PDB1
Do not run in                C = 0
Input Directory              d = 0
Echo OFF                     e = 1
Simulate                     E = 0
Forced cleanup               F = 0
Log Id                       i = pdb1
Child Process                I = 1
Log Dir                      l = /home/oracle/logs
Priority List Name           L = 0
Upgrade Mode active          M = 0
SQL Process Count            n = 2
SQL PDB Process Count        N = 0
Open Mode Normal             o = 0
Start Phase                  p = 0
End Phase                    P = 0
Reverse Order                r = 0
AutoUpgrade Resume           R = 0
Script                       s = 0
Serial Run                   S = 0
RO User Tablespaces          T = 0
Display Phases               y = 0
Debug catcon.pm              z = 0
Debug catctl.pl              Z = 0

catctl.pl VERSION: [19.0.0.0.0]
           STATUS: [Production]
            BUILD: [RDBMS_19.6.0.0.0DBRU_LINUX.X64_191217]


/u01/app/oracle/product/19/rdbms/admin/orahome = [/u01/app/oracle/product/19]
/u01/app/oracle/product/19/bin/orabasehome = [/u01/app/oracle/product/19]
catctlGetOraBaseLogDir = [/u01/app/oracle/product/19]

Analyzing file /u01/app/oracle/product/19/rdbms/admin/catupgrd.sql

Log file directory = [/home/oracle/logs]

catcon::set_log_file_base_path: ALL catcon-related output will be written to [/home/oracle/logs/catupgrdpdb3_catcon_17545.lst]

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/catupgrdpdb3*.log] files for output generated by scripts

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/catupgrdpdb3_*.lst] files for spool files, if any


Number of Cpus        = 2
Database Name         = CDB2
DataBase Version      = 19.0.0.0.0
PDB3 Open Mode = [MIGRATE] 
Generated PDB Inclusion:[PDB1]
CDB$ROOT  Open Mode = [OPEN]
Components in [PDB3]
    Installed [CATALOG CATPROC OWM XDB]
Not Installed [APEX APS CATJAVA CONTEXT DV EM JAVAVM MGW ODM OLS ORDIM RAC SDO WK XML XOQ]

------------------------------------------------------
Phases [0-107]         Start Time:[2020_03_06 14:32:27]
Container Lists Inclusion:[PDB1] Exclusion:[NONE]
------------------------------------------------------
***********   Executing Change Scripts   ***********
Serial   Phase #:0    [PDB1] Files:1    Time: 23s
***************   Catalog Core SQL   ***************
Serial   Phase #:1    [PDB1] Files:5    Time: 50s
Restart  Phase #:2    [PDB1] Files:1    Time: 0s
***********   Catalog Tables and Views   ***********
Parallel Phase #:3    [PDB1] Files:19   Time: 27s
Restart  Phase #:4    [PDB1] Files:1    Time: 2s
*************   Catalog Final Scripts   ************
Serial   Phase #:5    [PDB1] Files:7    Time: 22s
*****************   Catproc Start   ****************
Serial   Phase #:6    [PDB1] Files:1    Time: 18s
*****************   Catproc Types   ****************
Serial   Phase #:7    [PDB1] Files:2    Time: 13s
Restart  Phase #:8    [PDB1] Files:1    Time: 2s
****************   Catproc Tables   ****************
Parallel Phase #:9    [PDB1] Files:67   Time: 37s
Restart  Phase #:10   [PDB1] Files:1    Time: 1s
*************   Catproc Package Specs   ************
Serial   Phase #:11   [PDB1] Files:1    Time: 64s
Restart  Phase #:12   [PDB1] Files:1    Time: 2s
**************   Catproc Procedures   **************
Parallel Phase #:13   [PDB1] Files:94   Time: 15s
Restart  Phase #:14   [PDB1] Files:1    Time: 1s
Parallel Phase #:15   [PDB1] Files:121  Time: 15s
Restart  Phase #:16   [PDB1] Files:1    Time: 2s
Serial   Phase #:17   [PDB1] Files:22   Time: 9s
Restart  Phase #:18   [PDB1] Files:1    Time: 1s
*****************   Catproc Views   ****************
Parallel Phase #:19   [PDB1] Files:32   Time: 28s
Restart  Phase #:20   [PDB1] Files:1    Time: 2s
Serial   Phase #:21   [PDB1] Files:3    Time: 18s
Restart  Phase #:22   [PDB1] Files:1    Time: 2s
Parallel Phase #:23   [PDB1] Files:25   Time: 227s
Restart  Phase #:24   [PDB1] Files:1    Time: 2s
Parallel Phase #:25   [PDB1] Files:12   Time: 131s
Restart  Phase #:26   [PDB1] Files:1    Time: 1s
Serial   Phase #:27   [PDB1] Files:1    Time: 0s
Serial   Phase #:28   [PDB1] Files:3    Time: 8s
Serial   Phase #:29   [PDB1] Files:1    Time: 0s
Restart  Phase #:30   [PDB1] Files:1    Time: 2s
***************   Catproc CDB Views   **************
Serial   Phase #:31   [PDB1] Files:1    Time: 6s
Restart  Phase #:32   [PDB1] Files:1    Time: 2s
Serial   Phase #:34   [PDB1] Files:1    Time: 0s
*****************   Catproc PLBs   *****************
Serial   Phase #:35   [PDB1] Files:294  Time: 21s
Serial   Phase #:36   [PDB1] Files:1    Time: 0s
Restart  Phase #:37   [PDB1] Files:1    Time: 2s
Serial   Phase #:38   [PDB1] Files:6    Time: 8s
Restart  Phase #:39   [PDB1] Files:1    Time: 1s
***************   Catproc DataPump   ***************
Serial   Phase #:40   [PDB1] Files:3    Time: 42s
Restart  Phase #:41   [PDB1] Files:1    Time: 2s
******************   Catproc SQL   *****************
Parallel Phase #:42   [PDB1] Files:13   Time: 116s
Restart  Phase #:43   [PDB1] Files:1    Time: 1s
Parallel Phase #:44   [PDB1] Files:11   Time: 10s
Restart  Phase #:45   [PDB1] Files:1    Time: 1s
Parallel Phase #:46   [PDB1] Files:3    Time: 8s
Restart  Phase #:47   [PDB1] Files:1    Time: 1s
*************   Final Catproc scripts   ************
Serial   Phase #:48   [PDB1] Files:1    Time: 16s
Restart  Phase #:49   [PDB1] Files:1    Time: 0s
**************   Final RDBMS scripts   *************
Serial   Phase #:50   [PDB1] Files:1    Time: 9s
************   Upgrade Component Start   ***********
Serial   Phase #:51   [PDB1] Files:1    Time: 7s
Restart  Phase #:52   [PDB1] Files:1    Time: 1s
**********   Upgrading Java and non-Java   *********
Serial   Phase #:53   [PDB1] Files:2    Time: 23s
*****************   Upgrading XDB   ****************
Restart  Phase #:54   [PDB1] Files:1    Time: 1s
Serial   Phase #:56   [PDB1] Files:3    Time: 12s
Serial   Phase #:57   [PDB1] Files:3    Time: 9s
Parallel Phase #:58   [PDB1] Files:10   Time: 10s
Parallel Phase #:59   [PDB1] Files:25   Time: 12s
Serial   Phase #:60   [PDB1] Files:4    Time: 14s
Serial   Phase #:61   [PDB1] Files:1    Time: 0s
Serial   Phase #:62   [PDB1] Files:32   Time: 10s
Serial   Phase #:63   [PDB1] Files:1    Time: 0s
Parallel Phase #:64   [PDB1] Files:6    Time: 13s
Serial   Phase #:65   [PDB1] Files:2    Time: 21s
Serial   Phase #:66   [PDB1] Files:3    Time: 27s
****************   Upgrading ORDIM   ***************
Restart  Phase #:67   [PDB1] Files:1    Time: 2s
Serial   Phase #:69   [PDB1] Files:1    Time: 8s
Parallel Phase #:70   [PDB1] Files:2    Time: 9s
Restart  Phase #:71   [PDB1] Files:1    Time: 2s
Parallel Phase #:72   [PDB1] Files:2    Time: 9s
Serial   Phase #:73   [PDB1] Files:2    Time: 8s
*****************   Upgrading SDO   ****************
Restart  Phase #:74   [PDB1] Files:1    Time: 1s
Serial   Phase #:76   [PDB1] Files:1    Time: 8s
Serial   Phase #:77   [PDB1] Files:2    Time: 8s
Restart  Phase #:78   [PDB1] Files:1    Time: 1s
Serial   Phase #:79   [PDB1] Files:1    Time: 8s
Restart  Phase #:80   [PDB1] Files:1    Time: 2s
Parallel Phase #:81   [PDB1] Files:3    Time: 9s
Restart  Phase #:82   [PDB1] Files:1    Time: 1s
Serial   Phase #:83   [PDB1] Files:1    Time: 8s
Restart  Phase #:84   [PDB1] Files:1    Time: 2s
Serial   Phase #:85   [PDB1] Files:1    Time: 8s
Restart  Phase #:86   [PDB1] Files:1    Time: 2s
Parallel Phase #:87   [PDB1] Files:4    Time: 9s
Restart  Phase #:88   [PDB1] Files:1    Time: 2s
Serial   Phase #:89   [PDB1] Files:1    Time: 8s
Restart  Phase #:90   [PDB1] Files:1    Time: 1s
Serial   Phase #:91   [PDB1] Files:2    Time: 8s
Restart  Phase #:92   [PDB1] Files:1    Time: 2s
Serial   Phase #:93   [PDB1] Files:1    Time: 6s
Restart  Phase #:94   [PDB1] Files:1    Time: 2s
*******   Upgrading ODM, WK, EXF, RUL, XOQ   *******
Serial   Phase #:95   [PDB1] Files:1    Time: 6s
Restart  Phase #:96   [PDB1] Files:1    Time: 2s
***********   Final Component scripts    ***********
Serial   Phase #:97   [PDB1] Files:1    Time: 8s
*************   Final Upgrade scripts   ************
Serial   Phase #:98   [PDB1] Files:1    Time: 122s
*******************   Migration   ******************
Serial   Phase #:99   [PDB1] Files:1    Time: 6s
***   End PDB Application Upgrade Pre-Shutdown   ***
Serial   Phase #:100  [PDB1] Files:1    Time: 7s
Serial   Phase #:101  [PDB1] Files:1    Time: 4s
Serial   Phase #:102  [PDB1] Files:1    Time: 6s
*****************   Post Upgrade   *****************
Serial   Phase #:103  [PDB1] Files:1    Time: 117s
****************   Summary report   ****************
Serial   Phase #:104  [PDB1] Files:1    Time: 6s
***   End PDB Application Upgrade Post-Shutdown   **
Serial   Phase #:105  [PDB1] Files:1    Time: 6s
Serial   Phase #:106  [PDB1] Files:1    Time: 5s
Serial   Phase #:107  [PDB1] Files:1     Time: 0s

------------------------------------------------------
Phases [0-107]         End Time:[2020_03_06 14:58:28]
Container Lists Inclusion:[PDB1] Exclusion:[NONE]
------------------------------------------------------

Grand Total Time: 1561s [PDB1]

 LOG FILES: (/home/oracle/logs/catupgrdpdb3*.log)

Upgrade Summary Report Located in:
/home/oracle/logs/upg_summary.log

     Time: 1636s For PDB(s)

Grand Total Time: 1636s 

 LOG FILES: (/home/oracle/logs/catupgrd*.log)


Grand Total Upgrade Time:    [0d:0h:27m:16s]

Afterwards, I recompile.

sqlplus / as sysdba

SQL> alter pluggable database PDB1 open;
SQL> alter pluggable database PDB1 save state;
SQL> exit

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'PDB1' -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql

Done.

Finally, I can adjust the time zone of my upgraded PDB. As catcon.pl does not give direct output, I will have to check the log files afterwards. That’s a bit nasty.

$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'PDB1' -l /home/oracle/logs -b utltz_upg_check -d $ORACLE_HOME/rdbms/admin utltz_upg_check.sql

catcon::set_log_file_base_path: ALL catcon-related output will be written to [/home/oracle/logs/utltz_upg_check_catcon_31522.lst]

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/utltz_upg_check*.log] files for output generated by scripts

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/utltz_upg_check_*.lst] files for spool files, if any

catcon.pl: completed successfully
$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -c 'PDB1' -l /home/oracle/logs -b utltz_upg_apply -d $ORACLE_HOME/rdbms/admin utltz_upg_apply.sql
catcon::set_log_file_base_path: ALL catcon-related output will be written to [/home/oracle/logs/utltz_upg_apply_catcon_31826.lst]

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/utltz_upg_apply*.log] files for output generated by scripts

catcon::set_log_file_base_path: catcon: See [/home/oracle/logs/utltz_upg_apply_*.lst] files for spool files, if any

catcon.pl: completed successfully

Final check:

sqlplus / as sysdba
alter system set "_exclude_seed_cdb_view"=false scope=both;

select value$, con_id from containers(SYS.PROPS$) where NAME='DST_PRIMARY_TT_VERSION' order by 2;

VALUE$ CON_ID
------ ------
32	    1
32	    2
32	    3

All set!

Further Information and Links

–Mike

Tags:

You may also like...

46 Responses

  1. Jeannette Holland says:
    April 1, 2020 at 10:39

    Hi Mike, great approach – any chance you have an idea when AutoUgrade will support this?

    Reply
    • Mike.Dietrich says:
      April 2, 2020 at 19:15

      Hi Jeannette,

      thanks – and unfortunately there are a lot of open projects we are working on right now (e.g. “Unplug/plug/upgrade”). I fear, using an online clone for testing isn’t on the list right now. But I will carry it forward to the team for sure.

      Thanks and kind regards – and take care please!
      Mike

      Reply
      • Jeannette Holland says:
        April 3, 2020 at 09:06

        Thanks for your answer Mike. We are working with a business scenario where this method could also apply to production upgrades (of which we have 100s). We have a fallback scenario which is broken if we unplug/plug/upgrade. This is where the online clone option comes in handy. This is our pitched scenario:

        1. Run AutoUpgrade analyse for PDBx in CDBoldVersion and fix issues reported for PDBx
        2. Clone PDBx over database link to PDBy in CDBnewVersion and start PDBy in upgrade mode
        3. Run AutoUpgrade on PDBy in CDBnewVersion
        4. Any errors in step 2 or 4, open op for continued work in PDBx, else drop PDBx
        5. If no errors open op for continued work in PDBy

        Kind regards and take care as well !

        Reply
        • Mike.Dietrich says:
          April 8, 2020 at 21:24

          Hi Jeannette,

          you are the 2nd one proposing this as the better scenario (online clone instead of relocate), and I agree with you.
          Especially the fact that the relocate – as soon as you start the relocated PDB in STARTUP UPGRADE mode – drops the source whereas the clone leaves the source makes it the better solution.

          Thanks for your suggestion.

          And please take care, too!!! And enjoy the Easter weekend!

          Cheers,
          Mike

          Reply
  2. Frank Palme says:
    June 12, 2020 at 11:03

    Hi Mike,

    in the real world Data Guard is often used. The 19c therefore already has one standby db and no Active Data Guard is used. Do you have already plans for such an article?

    Frank

    Reply
    • Mike.Dietrich says:
      June 14, 2020 at 16:02

      Hi Frank,

      at the moment not – there are so many different topics on my list right now … I will blog more about DG once AutoUpgrade fully handles everything.

      Cheers,
      Mike

      Reply
  3. Emma says:
    July 9, 2020 at 02:24

    Hello Mike,

    Very useful demo. Can you have a similar clone for CDB1 PDB1 which has TDE wallet enable on Oracle 12.2 and clone to CDB2 on Oracle 19c.
    Thank you

    Reply
    • Mike.Dietrich says:
      July 13, 2020 at 18:03

      Hi Emma,

      working on it.

      Example:
      create pluggable database DEV from DEV@clone_link file_name_convert=(‘CDB1’, ‘CDB2’) KEYSTORE IDENTIFIED BY *********;

      Cheers,
      MIke

      Reply
  4. Sri says:
    July 20, 2020 at 19:27

    Mike,

    Thanks for the detailed steps. I ran into Bug 29469563 cloning database(target 19.7) on OCI with TDE. After applying the patch it ran fine.

    Regards
    Sri

    Reply
  5. rp says:
    December 2, 2020 at 16:07

    Hi Mike , will this work from version 12.1 to 19.7 ?

    Regards,
    RP

    Reply
    • Mike.Dietrich says:
      December 8, 2020 at 21:59

      Unfortunately not as 12.1 does not support refreshable PDBs. This is a feature which is based on Local Undo and some other things which aren’t simply there in 12.1.0.2 yet.

      Cheers,
      Mike

      Reply
  6. David L Wallace says:
    January 10, 2021 at 03:08

    Outstanding!

    Reply
  7. Dagmar says:
    January 18, 2021 at 08:02

    Hello Mike,
    Is there a way to clone and upgrade a PDB as you describe without breaking the standby (active dataguard) db? We would like to upgrade our PDBs with a clone, as it is very fast and the original DB remains untouched. But I could not yet find a way without destroying the standby.
    Cheers, Dagmar

    Reply
  8. Femi says:
    January 19, 2021 at 19:25

    very nice!

    Reply
  9. Dagmar Förster says:
    January 22, 2021 at 08:03

    Hello Mike,

    Our setup: Several multitenant databases, 2 node RAC, active Dataguard on 2 Eighth Exadatas, 18c. We want to migrate the PDBs one by one to 19c. Old PDBs should remain untouched for fallback. I built 19.9 CDBs and tried to clone two ways:

    1a.) Clone pdb via dblink
    ————————————————-
    https://oracle-base.com/articles/18c/multitenant-copying-a-pdb-in-a-data-guard-environment-18c
    —> Disadvantage: source in read only, downtime

    Source Primary
    CREATE USER c##remote_clone_user
    open PDB in read only

    Target Standby
    ALTER SYSTEM SET STANDBY_PDB_SOURCE_FILE_DBLINK=’clone_link’ scope=memory sid=’*’;

    Target Primary
    CREATE DATABASE LINK clone_link

    CREATE PLUGGABLE DATABASE new FROM sourcepdb@clone_link;

    or 1b.) Clone pdb via rman ‘FROM ACTIVE DATABASE’
    ————————————————-
    https://apex.oracle.com/pls/apex/germancommunities/dbacommunity/tipp/7001/index.html
    rman> DUPLICATE PLUGGABLE DATABASE ‘soure pdb’ as new TO ‘targetcdb’ FROM ACTIVE DATABASE;

    —> Advantage: source needn’t be in read only
    —> PDB was in unintentionally in refesh mode and I could neither refresh nor switch refresh mode off.

    2.) Upgrade pdb to 19c
    ————————————————-
    https://mikedietrichde.com/2020/03/06/upgrade-testing-online-clone-a-pdb-to-19c/

    Target Primary
    dbupgrade -c “new” -l /logdir
    timezone adjustment

    ===> Standby broken!
    I tried to switch apply off before clone and also before upgrade, no difference.

    Has anybody tried this approach yet? In theory, should the standby remain intact?
    Then I probably do something wrong.

    Regards, Dagmar

    Reply
    • Mike.Dietrich says:
      January 24, 2021 at 23:45

      Hi Dagmar,

      I don’t think that the PDB needs to be in read-only mode. The original MOS note Tim is referring to has this line:

      “The source PDB must be in Read Only mode and remain for the duration of the copies to the primary and all standby databases in the configuration. We do not at this time support automatic maintenance of the standby database of any type with the 12.2 hot cloning or relocate features.”

      And I’m in doubt if that is true. Let me check this.

      And regarding 2), I wonder why the DG team is not aware of such trouble. Let me check this as well.

      Cheers,
      Mike

      Reply
  10. David L Wallace says:
    January 27, 2021 at 17:43

    I performed the procedure and it worked flawlessly. How do I change the compatible parameter for the cloned PDB?

    SYS@cdb19c:SQL> show parameters compatible;
    NAME TYPE VALUE
    ———————————— ———– ——————————
    compatible string 19.0.0
    noncdb_compatible boolean FALSE

    @:SQL> connect system/oracle_4U@ocmpdb;
    Connected.
    SYSTEM@ocmpdb:SQL> show parameters compatible;

    NAME TYPE VALUE
    ———————————— ———– ——————————
    compatible string 12.2.0
    noncdb_compatible boolean FALSE

    Reply
  11. Topher Reeve says:
    March 25, 2021 at 22:35

    Hi Mike
    When running the “create pluggable database” step, I’m receiving this error, even though Oracle Label Security and Oracle Database Vault are NOT installed on either the source or target CDB (and all parameters in v$option have a con_id =0):

    ERROR at line 1:
    ORA-65346: The PDB version is lower and components (DV, OLS) are missing in CDB.

    I am upgrading a 12.2.0.1 PDB to 19c, just like you showed. Have you seen this before?

    Thanks,
    Topher

    Reply
  12. Mark Burgo says:
    August 17, 2021 at 13:09

    Mike, trying to follow this but when doing the create pluggable database I am getting

    ORA-01276: Cannot add file
    OMF file /path and name
    File has an Oracle Managed Files file name.

    Googled and found many items but not having any luck, any idea’s for this

    Reply
  13. Paul says:
    September 30, 2021 at 05:51

    Starting with 12.1.0.2.0, is there a workaround? What would be your advise to get a PDB to 19.12 ?

    Reply
  14. Damodar Veerareddygari says:
    January 31, 2022 at 14:55

    Worked like a charm. Had a few issues with the timezone upgrade, but the clone of 12c pdb and upgrade to 19c worked flawlessly. Thanks a lot Mike.

    Reply
  15. RJ Timtiman says:
    March 11, 2022 at 13:23

    Hi Mike,

    For the recompile, is it an either/or, or both/and, for the perl utlrp and the standard utlrp?

    Reply
  16. Robert Jackson says:
    July 7, 2022 at 18:30

    Hi Mike

    Would like to use this PDB Clone/Upgrade technique with one of my customers as it would certainly save time but would like to know whether on 19c any additional license cost option pack on top of Enterprise Edition would be require to use the PDB cloning feature?

    When referencing the license documentation it would appear this would come under the Oracle Database Lifecycle Management Pack but I am hoping I am mistaken as all other documentation around this feature makes no mention of it being a cost option.

    Kind regards

    Rob Jackson

    Reply
    • Mike.Dietrich says:
      August 8, 2022 at 11:16

      Hi Robert,

      are you referring to this stance:

      “Licensed Links – Database Provisioning Procedures:

      Use of the following Oracle Enterprise Manager pages and links requires a license for Oracle Database Lifecycle Management Pack for Oracle Database:

      From the Enterprise Manager home page, click the Enterprise menu, Provisioning and Patching, then Procedure Library. All Procedures that Clone and Provision a Database are licensed with Oracle Database Lifecycle Management Pack for Oracle Database.
      ”
      https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html#GUID-68A4128C-4F52-4441-8BC0-A66F5B3EEC35

      ??

      Then it clearly says “Use of the following Oracle Enterprise Manager pages and links requires …”.
      I don’t use EM. And I have not found any sort of hint in the license doc that Refreshable PDB clones would require an additional license.

      But please double check with your Oracle contact.

      Cheers
      Mike

      Reply
  17. Daljeet Singh says:
    March 17, 2023 at 22:42

    Hi Mike, I am upgrading 12.1.0.2 Pluggable database to 19.17 using clone over dblink and it clones the pluggable database completely.
    After running
    dbupgrade -c “PDMTSLC” -l /u03/app/oracle/upgradelogs_pdmt
    to upgrade Pluggable to 19.17 I see following errors in upgrade summary

    JServer JAVA Virtual Machine
    ORA-02290: check constraint (SYS.JAVA_DEV_JARS_DISABLED) violated ORA-06512:
    at “SYS.INITJVMAUX”, line 28
    ORA-06512: at line 5

    ORA-06512: at “SYS.INITJVMAUX”, line 28 ORA-06512: at line 5

    ORA-06512: at line 5
    ORA-00604: error occurred at recursive SQL level 1 ORA-02290: check constrai
    nt (SYS.JAVA_DEV_DISABLED) violated

    ORA-02290: check constraint (SYS.JAVA_DEV_DISABLED) violated
    ORA-04045: errors during recompilation/revalidation of SYS.DBMS_JAVA ORA-022
    90: check constraint (SYS.JAVA_DEV_DISABLED) violated

    ORA-02290: check constraint (SYS.JAVA_DEV_DISABLED) violated
    ORA-04045: errors during recompilation/revalidation of SYS.DBMS_JAVA ORA-022
    90: check constraint (SYS.JAVA_DEV_DISABLED) violated

    Can you please help me understand this and how do I fix it?

    Reply
  18. HP says:
    July 14, 2025 at 06:46

    Hi Mike,
    i have a weird cloning issue where support tells me to run catupgrd.sql on the cloned PDBs.
    The goal was to move all PDBs from a CDB on RHEL7 to a newer RHEL9 system, both 19.26 EE CDBs.
    So my approach was clone, test, then relocate. But after cloning any PDB (even a fresh one) via DB-Link it has hundreds of invalid sys objects on the target system.
    One obvious difference between those CDBs is nls_length_semantics (char on source, byte on target) but support didn’t care much about this. They told me to run catupgrd.sql on the target PDB to resolve the issue. It is resolving the errors but i’m struggling to understand what is causing the issue in the first place.
    Have you come across such a situation? Is it common to run catupgrd.sql because it defeats the benefit of almost no downtime with (refreshable) cloning?
    Regards,
    Hans Peter

    Reply
    • Mike.Dietrich says:
      July 14, 2025 at 09:24

      Can you share the SR number with me, please?
      And did you clone with AutoUpgrade, or just with manual commands?

      Cheers,
      Mike

      Reply
      • HP says:
        July 14, 2025 at 09:41

        Hi Mike,
        the SR is 3-41267579121. There’s a spin off too. I cloned using db-link and create pluggable database command.

        Thanks,
        Hans Peter

        Reply
        • Mike.Dietrich says:
          July 14, 2025 at 10:26

          Hi Hans-Peter,

          this is a strange SR. I read both of them, and I am very curious WHY catupgrd.sql being executed in the 12.2.0.1 source fixes the problem.
          I found one matching issue: Bug 32153325 – PDB CLONED DB WITH MESSAGE “EXECUTE XDB.DBMS_XMLSTORAGE_MANAGE.GETTYPEDDL”
          But this isn’t a bug actually, but instead an incorrect order of script execution according to the developer.

          I see that you are not using AutoUpgrade.
          But I think our chances would be higher to find out what’s going on (or wrong) since AU logs everything. You would execute and “-mode analyzer” and “-mode fixups” on the source, and then “-mode deploy” for the cloning operation on the target.

          Usually, the “-mode analyze” tells us what’s missing or wrong, and the “-mode fixups” does check for component integrity and such. Plus, it does the compatibility check for plugin.

          In addition, AU guaranteed executes all scripts in the correct order, cleans up – and it would be interesting to see how it deals with all the invalids you have.
          What I would ask for:
          Do you see the same “positive” result as you reached with catupgrd.sql in the source when you only execute ./datapatch ?
          Datapatch does recompile as well, and it may clean potentially existing inconsistencies – but ONLY in case it finds a discrepancy between patches installed as binaries, and patches applied as metadata to the database. If there is no divergence, datapatch will not execute anything.

          Cheers,
          Mike

          Reply
  19. HP says:
    July 14, 2025 at 11:18

    Hi Mike,
    running datapatch against a fresh (creatd from pdb$seed) source PDB has lead to invalid objects in the cloned PDB again. datapatch on the source PDB reported that no action has to be taken.
    Just to make sure, both sides are 19.26 here. Source has been upgraded from 12.2.0.1 years ago.
    I will check out cloning with AutoUpgrade next.
    Thanks,
    Hans Peter

    Reply
    • Mike.Dietrich says:
      July 14, 2025 at 11:43

      Now you scare me a bit.

      So, both are 19.26 – I did not catch this before.
      Got it now.

      Then something is
      a) either wrong in the source or
      b) your suspicion with relation to NLS_LENGTH_SEMANTICS sounds more reasonable to me

      Normally, for any upgrade NLS_LENGTH_SEMNATICS gets turned into BYTE anyway. But you are not doing any upgrade.

      So, just to clarify:

      Source is 19.26 PDB already
      Target is 19.26 CDB, and you are going to do an online clone into it.

      Is this correct?

      What could have potentially sleeping in your 19.26 source is an incorrect conversion from non-CDB to PDB in the 12.2.0.1 days.

      Cheers,
      Mike

      Reply
      • HP says:
        July 14, 2025 at 12:11

        Exactly, both sides are 19.26 and have been CDB/PDB always. Source started as 12.2.0.1 CDB (dbca -createAsContainerDatabase true) from scratch and was later upgraded to 19c.
        I do online clone a PDB through database link from 19.26 source to 19.26 target.
        Regards,
        Hans Peter

        Reply
      • HP says:
        July 15, 2025 at 06:19

        Hi Mike,
        i tested cloning with AutoUpgrade now but struggle to run analyze phase. On the source the TARGET_CDB_AVAILABILITY check fails because it can’t access the target cdb that is on another server.
        Running analyze on the target gave a similar error: “Analyze and fixup mode is not supported for unplug-relocate when the source resides on a different system.”
        Deploy phase on the target succesfully cloned the pdb but failed on recompiling due to invalid objects. So seems to be the same situation as with manual cloning.
        Am i missing some configuration to properly run analyze in this scenario?
        Regards,
        Hans Peter

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mike Dietrich
Oracle Vice President of Product Management and Development for Database Upgrade, Cloud Migrations and Patching writing just another blog.

Opinions certainly are my own as is this page.

Archives

Categories

Upgrade @YouTube

Subscribe via Email

Join 11.3K other subscribers