- Posted by Gavin Soorma
- On April 11, 2015
- 0 Comments
Let us look at a common requirement the DBA faces on a regular basis related to performing a database clone.
A developer needs a copy or clone of the production database to test some urgent fixes and requires this database for a short period of time to perform the testing – after which this database can be dropped. There may be further requirement to blow the database away and have another copy of production data in case another round of further testing is required.
We all know how long in a normal case it will take to fulfill this requirement – days and maybe even weeks – and the amount of work involved to provision this database.
Now with Database as a Service (DBaaS) being offered via EM12c, the developer can get his clone of the production database created when he wants with a click of a button using the Cloud Self Service Portal. The DBA does not need to go and perform a backup of the database or be involved in any way.
But at the same time the DBA has total control over the service which is offered to the developer – which host the clone will get created on, the size of the database, disk space it can occupy and even init.ora parameters which will be used to create the cloned database among other things.
In this example we have a source 188.8.131.52.’production’ database – db12c – and we will be creating a provisioning profile to clone this database on a target development host. After a week of use the database will be automatically dropped and the developer has the option of requesting creation of another clone in case more testing is required.
We will base the clone on an existing RMAN backup – note that we need to copy the RMAN backupset to the target server where the clone is being created.
In this case we have a Platform as a Service (PaaS) Infrastructure Zone called development_zone and that zone has two member hosts.Let us say one of the hosts is the production host where the source database is located and the other host is the development or test host where the clone will be created.
To see the details of the PaaS Infrastructure Zone highlight the zone and click on the Edit button.
We now create a Database Pool in the PaaS zone – the Database Resource Pool will be a non-CDB based pool.
We enter the details of the PaaS Infrastructure Zone and the OS platform and based on the database version (in this case 184.108.40.206) the available Oracle Homes located on both hosts which make up the PaaS zone are displayed.
In this case the database will be made available only for a period of 7 days so we specify the retention duration under the Request Settings.
In the Quotas section we limit the number of database requests the SSA user can make as well as the total amount of machine RAM and disk space which will be made available to the user. This is being regulated via the CLOUD_SSA role.
Next is that we create a Database Provisioning Profile. In the Profiles section click on Create.
Select the reference or source database on which the profile will be based.
A clone of the reference database (db12c) will be created using an existing RMAN backup.
After the profile is created we now have to create a Service Template based on that profile.
Note that the Shared Location on the Reference Host (which is the host where the clone is being created) is the location where we have copied the RMAN backup sets. This is the RMAN backup of the source database on which the clone is going to be based.
The location of the data files can be defined as well as the prefix which will be used for the database name. Other things like listener port and passwords can also be defined.
Here we can change some of the init.ora parameters if required – for example we may want to ensure that the clone database is allocated a smaller SGA or PGA than the source production database or change some other parameter related to performance or availability.
After the database has been created we can see the instance dev00000 up and running and can also see the amount of resources like RAM and Disk Space the user has used so far and how much is still available for future requests.