Workflow for dev/test bursting to cloud
The agility of the public cloud, the time to value, and the cost savings are all meaningful value propositions for enterprises adopting the public cloud for database application development and testing effort. There is no better tool than SnapCenter to make this a reality. SnapCenter can not only protect your production database on-premises, but can also it quickly clone a copy for application development or code testing in the public cloud while consuming very little extra storage. Following are details of the step-by-step processes for using this tool.
Clone an Oracle Database for dev/test from a replicated snapshot backup
-
Log into SnapCenter with a database management user ID for Oracle. Navigate to the Resources tab, which shows the Oracle databases being protected by SnapCenter.
-
Click the intended on-premises database name for the backup topology and the detailed view. If a secondary replicated location is enabled, it shows linked mirror backups.
-
Toggled to the mirrored backups view by clicking mirrored backups. The secondary mirror backup(s) is then displayed.
-
Choose a mirrored secondary database backup copy to be cloned and determine a recovery point either by time and system change number or by SCN. Generally, the recovery point should be trailing the full database backup time or SCN to be cloned. After a recovery point is decided, the required log file backup must be mounted for recovery. The log file backup should be mounted to target DB server where the clone database is to be hosted.
If log pruning is enabled and the recovery point is extended beyond the last log pruning, multiple archive log backups might need to be mounted. -
Highlight the full database backup copy to be cloned, and then click the clone button to start the DB clone Workflow.
-
Choose a proper clone DB SID for a complete container database or CDB clone.
-
Select the target clone host in the cloud, and datafile, control file, and redo log directories are created by the clone workflow.
-
The None credential name is used for OS-based authentication, which renders the database port irrelevant. Fill in the proper Oracle Home, Oracle OS User, and Oracle OS Group as configured in the target clone DB server.
-
Specify the scripts to run before clone operation. More importantly, the database instance parameter can be adjusted or defined here.
-
Specify the recovery point either by the date and time or SCN. Until Cancel recovers the database up to the available archive logs. Specify the external archive log location from the target host where the archive log volume is mounted. If target server Oracle owner is different from the on-premises production server, verify that the archive log directory is readable by the target server Oracle owner.
-
Configure the SMTP server for email notification if desired.
-
Clone summary.
-
You should validate after cloning to make sure that the cloned database is operational. Some additional tasks, such as starting up the listener or turning off the DB log archive mode, can be performed on the dev/test database.
Clone a SQL database for dev/test from a replicated Snapshot backup
-
Log into SnapCenter with a database management user ID for SQL Server. Navigate to the Resources tab, which shows the SQL Sever user databases being protected by SnapCenter and a target standby SQL instance in the public cloud.
-
Click on the intended on-premises SQL Server user database name for the backups topology and detailed view. If a secondary replicated location is enabled, it shows linked mirror backups.
-
Toggle to the Mirrored Backups view by clicking Mirrored Backups. Secondary Mirror Backup(s) are then displayed. Because SnapCenter backs up the SQL Server transaction log to a dedicated drive for recovery, only full database backups are displayed here.
-
Choose a backup copy, and then click the Clone button to launch the Clone from Backup workflow.
-
Select a cloud server as the target clone server, clone instance name, and clone database name. Choose either an auto-assign mount point or a user-defined mount point path.
-
Determine a recovery point either by a log backup time or by a specific date and time.
-
Specify optional scripts to run before and after the cloning operation.
-
Configure an SMTP server if email notification is desired.
-
Clone Summary.
-
Monitor the job status and validate that the intended user database has been attached to a target SQL instance in the cloud clone server.
Post-clone configuration
-
An Oracle production database on-premises is usually running in log archive mode. This mode is not necessary for a development or test database. To turn off log archive mode, log into the Oracle DB as sysdba, execute a log mode change command, and start the database for access.
-
Configure an Oracle listener, or register the newly cloned DB with an existing listener for user access.
-
For SQL Server, change the log mode from Full to Easy so that the SQL Server dev/test log file can be readily shrunk when it is filling up the log volume.
Refresh clone database
-
Drop cloned databases and clean up the cloud DB server environment. Then follow the previous procedures to clone a new DB with fresh data. It only takes few minutes to clone a new database.
-
Shutdown the clone database, run a clone refresh command by using the CLI. See the following SnapCenter documentation for details: Refresh a clone.
Where to go for help?
If you need help with this solution and use cases, join the NetApp Solution Automation community support Slack channel and look for the solution-automation channel to post your questions or inquires.