cloning


gDBClone – Good and easy Oracle cloning tool with potential

Instead of writing and adapting cloning scripts for each client, I was looked today at gDBClone script, provided by Oracle note gDBClone Powerful Database Clone/Snapshot Management Tool (Doc ID 2099214.1).

Ruggero Citton did an excellent work and I believe that for most of situations and mainly in a development environment with the need of fast DB Snapshots this tool provides an alternative to developing new tools.

I find great that for database cloning it creates a temporary listener, and does not mixup with existing configuration. Another great thing is the possibility to use a pre-created passwordfile to clone remote DBs, without the need to provide any password at run time (or hardcode, or having a wallet).

It is a tool that works with DBs from Oracle 11.2 up, and also with RAC, RAC One node, it can perform upgrades, create standby, it works in ODA, etc.

The long set of pre-checks is very nice:

MacroStep1 - Getting information and validating setup...
INFO: 2022-01-13 15:40:09: Validating environment
INFO: 2022-01-13 15:40:09: Checking superuser usage
INFO: 2022-01-13 15:40:09: Checking if target database name 'xpto' is a valid name
INFO: 2022-01-13 15:40:09: Checking if target database home 'OraHome3' exists
INFO: 2022-01-13 15:40:09: Checking if Oracle Restart
INFO: 2022-01-13 15:40:09: Checking ping to host 'server27'
INFO: 2022-01-13 15:40:09: Getting ORACLE_BASE path from orabase
INFO: 2022-01-13 15:40:09: Checking if target database 'xpto' exists
INFO: 2022-01-13 15:40:09: Checking registered instance 'xpto'
INFO: 2022-01-13 15:40:12: Checking listener on 'server27:1521'
INFO: 2022-01-13 15:40:12: Checking ASM command options
INFO: 2022-01-13 15:40:15: Checking if '+U02' is a valid ASM diskgroup
INFO: 2022-01-13 15:40:15: Checking '+U02' RDBMS compatible
INFO: 2022-01-13 15:40:16: Checking if '+U01' is a valid ASM diskgroup
INFO: 2022-01-13 15:40:16: Checking '+U01' RDBMS compatible
INFO: 2022-01-13 15:40:16: Checking if '+U01' is a valid ASM diskgroup
INFO: 2022-01-13 15:40:17: Checking '+U01' RDBMS compatible
INFO: 2022-01-13 15:40:20: Checking source and target database version
INFO: 2022-01-13 15:40:21: Checking source database size
INFO: 2022-01-13 15:40:23: Checking source database role
INFO: 2022-01-13 15:40:23: Checking source log mode
INFO: 2022-01-13 15:40:24: Checking Flash Cache setting
SUCCESS: 2022-01-13 15:40:24: Environment validation complete

At the client I’m these days however I would be happy with some more flexibility.

  • The database unique name convention include underscores (xptodb_2 for instance). gDBClone only accepts alphanumeric elements to the clone database name.
  • gDBClone needs to run with root privileges. You can (recommended) configure in /etc/sudoers, however this is far too much for my client.
  • Cloning a dataguard protected database configured with broker failed at the end of the duplicate, as the clone automatically started the broker and connected back to the primary, failing then with ORA-16649: possible failover to another database prevents this database from being opened . The half-baked clone needs to be dropped manually.
  • It would be nice to have commands (or be part of clone) to create new ACFS mountpoints

At the end I get the impression that gDBClone was developed for specific customer needs and I’m sure it does it really well. For the needs and restrictions I’ve in different clients unfortunately I still need to use my set of tools. Luckily with the most recent Oracle versions the cloning, snapping, upgrades has become much easier and scripting it does not require many lines of code.


CloneDB: terminating the instance due to error 17514

While getting adventureous and trying to enable clonedb on a RAC database running on ASM (set clonedb parameter=true and restart the database), I got this error on alert log:

Mon Nov 16 11:11:40 2015
CloneDB: created bitmap file RAC_bitmap.dbf
USER (ospid: 15767): terminating the instance due to error 17514

RAC is the name of the database. The <SID>_bitmap.dbf file was correctly created on $ORACLE_HOME/dbs

Then it just crash the instance. Google and Metalink did not yet indexed this error. But here its description:


$ oerr ora 17514
17514, 00000, "Access to clonedb bitmap file failed"
// *Cause: Accessing the bitmap block file in clonedb environment has
// encountered an error
// *Action: check additional error messages in the trace file and call
// Oracle Support Services

The trace files did not help much. I did not investigate the problem further.


Thin PDB clones on ext4 filesystem with Oracle 12.1.0.2

Oracle 12.1.0.2 brings a great new functionality: you can create thin clones – that is, not copying the source files, just pointers – on ext4 filesystem, the current default on Red Hat Linux 6.

Requirements for example below:
– Oracle 12.1.0.2
– Data files are on ext4 filesystem (or other supporting sparse files)
– Source PDB on read only mode

It is very simple to set up:

SQL> alter system set clonedb=TRUE scope=spfile;
SQL> shutdown immediate
SQL> startup

SQL> show parameter clonedb
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
clonedb                              boolean     TRUE

I will create a clone of the PDB2 database.

SQL> select name,con_id,open_mode,SNAPSHOT_PARENT_CON_ID from v$pdbs;

NAME                               CON_ID OPEN_MODE  SNAPSHOT_PARENT_CON_ID
------------------------------ ---------- ---------- ----------------------
PDB$SEED                                2 READ ONLY                       0
PDB1                                    3 MOUNTED                         0
PDB2                                    4 READ ONLY                       0

For this I need first to create the target directory for the datafiles.

SQL> ! mkdir -p /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1

Then I can do the clone using the ‘snapshot copy’ clause. It took 9 seconds.

SQL> create pluggable database PDB2_C1 from PDB2 snapshot copy file_name_convert=('/u01/app/oracle/oradata/NONRAC/PDB2','/u01/app/oracle/oradata/NONRAC/PDB2_CLONE1');
Pluggable database created.

Elapsed: 00:00:09.35

Note that the new PDB remains in MOUNT state and without showing a connection to its parent. I find unfortunate the lack of that information.

SQL> select name,con_id,open_mode,SNAPSHOT_PARENT_CON_ID from v$pdbs;

NAME                               CON_ID OPEN_MODE  SNAPSHOT_PARENT_CON_ID
------------------------------ ---------- ---------- ----------------------
PDB$SEED                                2 READ ONLY                       0
PDB1                                    3 MOUNTED                         0
PDB2                                    4 READ ONLY                       0
PDB2_C1                                 5 MOUNTED                         0

After we open the clone in READ WRITE mode, then we can see the relationship with the parent.

SQL> alter pluggable database PDB2_C1 open read write;
Pluggable database altered.
Elapsed: 00:00:02.12

SQL> select name,con_id,open_mode,SNAPSHOT_PARENT_CON_ID from v$pdbs;

NAME                               CON_ID OPEN_MODE  SNAPSHOT_PARENT_CON_ID
------------------------------ ---------- ---------- ----------------------
PDB$SEED                                2 READ ONLY                       0
PDB1                                    3 MOUNTED                         0
PDB2                                    4 READ ONLY                       0
PDB2_C1                                 5 READ WRITE                      4

And below we verify that the clone uses 4MB instead of 800MB of the source database.

SQL> ! du -m /u01/app/oracle/oradata/NONRAC/PDB2/*
6       /u01/app/oracle/oradata/NONRAC/PDB2/PDB2_users01.dbf
586     /u01/app/oracle/oradata/NONRAC/PDB2/sysaux01.dbf
261     /u01/app/oracle/oradata/NONRAC/PDB2/system01.dbf
1       /u01/app/oracle/oradata/NONRAC/PDB2/temp01.dbf

SQL> ! du -m /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1/*
1       /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1/PDB2_users01.dbf
1       /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1/sysaux01.dbf
1       /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1/system01.dbf
1       /u01/app/oracle/oradata/NONRAC/PDB2_CLONE1/temp01.dbf

We can also clone non-CDB databases with some more steps, as explained at:
https://dbamarco.wordpress.com/2015/03/09/small-change-big-difference/

The clonedb.pl script (see documentation here) can also be used, even though you might find easier to script yourself to your own environment.