Duplicating a Database on ODA


Every so often, we get a request to duplicate a database for one of our customers using an Oracle Database Appliance (ODA). The process for doing that is relatively straightforward, but there are a couple of nuances along the way so I thought I’d write it up as a blog post in case it’s of use to others. Obviously, I have obfuscated any customer-specific information to protect their identity.


The first nuance is to understand what database is being used as the source for the clone. Generally, a request for cloning will be something like this:

“We are creating a new environment which needs a new database to be set up. Please copy P1_SRV_T and restore as P1_SRV_F”.

The important thing to understand here is what the customer is providing is what they know – how they connect to the database. These are service names, not database names, so you need to be able to translate that into the relevant entities needed for cloning.

To do this, we have created two scripts in this environment that are invaluable – dbstatus (database status) and sstatus (service status) – as you can guess by the output below these are wrappers to various srvctl commands. Running dbstatus will show the following (output restricted to the part we require for brevity):

Likewise, running sstatus returns:

From this information, you can see that the P1_SRV_T service referred to as the source for the first database to be cloned is running on oda2, with the instance name ABCSRVT. By logging onto that machine, we can also determine the database name:

So, to summarize, we now have:

Source DB name – ABCSRVT
Source DB Unique Name – P1SRVT
Source Service Names – P1_SRV_T
Source Server – oda2

From that information, and the original request, we can surmise the target information to be:

Target DB name – ABCSRVF
Target DB Unique Name – P1SRVF
Target Service Name – P1_SRV_F
Target Server – oda2

Finally, we know that in this environment, the backups are stored under /backup/[DATABASE_NAME], so for this exercise, the backup we use to duplicate the database is stored under /backup/ABCSRVT.

That is all the information we need to proceed with the cloning request.

Creating the Target Database

To create the target, we will be using the oakcli command. This provides the added benefit of creating the various dump directories etc. To use oakcli, you need to be logged on to node 1 of the ODA as the root user:

Note in this command that the ORACLE_HOME has already been created, and we are passing a parameter file srv. srv actually maps to a file called srv.conf located under /opt/oracle/oak/install/dbconf. In this case, the file contains settings for parameters such as the database block size, language, character set and so forth. You can find more information on what can be included in this file in the Oracle documentation. Next, you will be prompted for the SYSASM password. In our scenario, we use the highly secured password “welcome1”. 🙂

Next, we are prompted for database type, which can be OLTP, DSS, or In-Memory. For this example, we select OLTP:

The next step is to provide the database deployment type – Enterprise Edition, RAC One Node or RAC. For the example we’re doing here, the customer wants a small test database that mimics the source, so we choose EE (as that is what the source is using):

Next, we are asked which node to build the database on. In this example, we choose oda2:

Finally, we are asked for Database Class. As just mentioned, this example is for a small test database so we select 1 core, 8 GB memory. oakcli then builds the database:

Changing the Database Unique Name

One problem with using oakcli is the command does not allow us to change the database unique name, so we have to run a few more commands to do that. Firstly, we login as oracle, set the environment appropriately and remove the database from CRS:

Next, manually cleanup the files created for that database, in the DB_UNIQUE_NAME directories:

We can now use RMAN to duplicate the database. Firstly, we need to create the directory for the control file:

Next, we need to create a standard text parameter file that contains the following entries:

Now we can do a startup nomount:

Prior to using RMAN to duplicate the database, check whether the source database had flashback log files. If it does, the duplicate command will fail with the error:

If you see this error, it’s because flashback logs are in use in the source database. You can check this by using the following SQL on the source database:

If this select returns any rows, you will need to remove the flashback logs from under:

NOTE: This can only be done after the DUPLICATE command fails.

You can then rerun the duplicate command:

Now we need to add the new database to /etc/oratab and CRS, and move the SPFILE to the correct location:

Next, we need to set LOCAL_LISTENER and REMOTE_LISTENER appropriately:

And finally, we need to ad the relevant services to the database:

Duplication is now complete!

Finally, we just need to modify any housekeeping scripts, such as backup scripts, if needed.


After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Data Intensity, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions. I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.


  1. Pete,

    Thank you for your write-up on this procedure. I’m in the beginning of the same process so your article is helping me out. I’ve “inherited” an X5-2 in my new position and finding information about ODA’s has been….difficult. I did read your book and was able to learn some things but there are differences between X3-2 and X5-2. I have to rely on Oracle’s documentation. Thank you again.

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.