Skip to main content
NetApp Solutions

Workflow for dev/test bursting to cloud

Contributors kevin-hoke

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

  1. 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.

    Figure showing input/output dialog or representing written content

  2. 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.

    Figure showing input/output dialog or representing written content

  3. Toggled to the mirrored backups view by clicking mirrored backups. The secondary mirror backup(s) is then displayed.

    Figure showing input/output dialog or representing written content

  4. 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.

    Figure showing input/output dialog or representing written content

    Figure showing input/output dialog or representing written content

    Note 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.
  5. Highlight the full database backup copy to be cloned, and then click the clone button to start the DB clone Workflow.

    Figure showing input/output dialog or representing written content

  6. Choose a proper clone DB SID for a complete container database or CDB clone.

    Figure showing input/output dialog or representing written content

  7. Select the target clone host in the cloud, and datafile, control file, and redo log directories are created by the clone workflow.

    Figure showing input/output dialog or representing written content

  8. 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.

    Figure showing input/output dialog or representing written content

  9. Specify the scripts to run before clone operation. More importantly, the database instance parameter can be adjusted or defined here.

    Figure showing input/output dialog or representing written content

  10. 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.

    Figure showing input/output dialog or representing written content

    Figure showing input/output dialog or representing written content

  11. Configure the SMTP server for email notification if desired.

    Figure showing input/output dialog or representing written content

  12. Clone summary.

    Figure showing input/output dialog or representing written content

  13. 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.

    Figure showing input/output dialog or representing written content

Clone a SQL database for dev/test from a replicated Snapshot backup

  1. 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.

    Figure showing input/output dialog or representing written content

  2. 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.

    Figure showing input/output dialog or representing written content

  3. 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.

    Figure showing input/output dialog or representing written content

  4. Choose a backup copy, and then click the Clone button to launch the Clone from Backup workflow.

    Figure showing input/output dialog or representing written content

    Figure showing input/output dialog or representing written content

  5. 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.

    Figure showing input/output dialog or representing written content

  6. Determine a recovery point either by a log backup time or by a specific date and time.

    Figure showing input/output dialog or representing written content

  7. Specify optional scripts to run before and after the cloning operation.

    Figure showing input/output dialog or representing written content

  8. Configure an SMTP server if email notification is desired.

    Figure showing input/output dialog or representing written content

  9. Clone Summary.

    Figure showing input/output dialog or representing written content

  10. Monitor the job status and validate that the intended user database has been attached to a target SQL instance in the cloud clone server.

    Figure showing input/output dialog or representing written content

Post-clone configuration

  1. 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.

  2. Configure an Oracle listener, or register the newly cloned DB with an existing listener for user access.

  3. 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

  1. 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.

  2. 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.