/
Create Standby Database (CSD)

Create Standby Database (CSD)

May 26, 2020

Introduction

Dbvisit Standby can assist in creating the standby database.  Dbvisit Standby supports the creation of standby databases even if ASM or OMF are used.  If you are still using RAW devices, Dbvisit Standby version 9 can also support this.

Dbvisit Standby version 9 also supports the creation of an Oracle RAC enabled standby database.  There are a number of prerequisites before this can be performed. For example, the standby environment must already have the Clusterware (GI) installed and ASM storage configured, as well as have the Oracle Database software installed, this option will be discussed in more detail in this section.

Before getting into the more advanced configurations it is important to first make sure you understand the basics and then move onto the more advanced configurations.  

Dbvisit Standby version 9 will guide you through the creation of the standby process, and by answering a few short questions you will be ready to start the process.

Creating a standby database can be done in three ways:

  • Creating the standby database manually  (this option will not be discussed in this guide - for more detail please see the Oracle Documentation)

  • Creating the standby database using the Dbvisit Standby Core - Command Line Interface

  • Creating the standby database using the Central Console - GUI

 

Please note that this guide will refer to the Create Standby Database process as the CSD process.

 

If using ASM based databases, we do not recommend the use of ASM aliases but to rather use Oracle Managed File naming.

If you do create a standby database where ASM is used and the primary database is making use of ASM aliases, the standby database will only end up with OMF datafiles and ASM aliases will not be created.  

ASM Aliases can be created post CSD either using a post-processing script or by manually creating them.

For more detail see: Pre/Post Processing#Pre/PostProcessing-ASMAliases

As a prerequisite, you have to make sure that the Primary database uses SPFILE and not PFILE before running the Create Standby Database process.

If you are using ODA machines, It is required that you create the dbstorages before creating the standby databases using Dbvisit. Please refer the blog for further details.

http://blog.dbvisit.com/configuring-dbvisit-standby-on-an-oda/

On this page:

2.  Creating The Standby Database - Command Line

Creating the Standby Database is an easy process if you are familiar with your Database environment and have followed all the pre-requisites when installing the Dbvisit Standby software. Create Standby Database via command line has to be started from Primary server.

Please ensure you have adequate available space on the standby server to copy the RMAN backup and restore backup copy that this process does.

This section will focus on using the command line interface using the dbvctl command:  ./dbvctl --csd


To quickly obtain the usage (syntax) of the CSD command run: "./dbvctl -h --csd"

[oracle@dbv1 standby]$ ./dbvctl -d DEV --csd -h Create a new standby database dbvctl -d <ddc> --csd [--mode CLI|BATCH|GUI] [--restart] [--noprompt] [-j json_file] [--dump_template] --mode CLI default --restart Restart previous run in BATCH mode if incompleted --json Json file in GUI mode --noprompt No confirmation prompts --dump_template Json file to write an existing template to [oracle@dbv1 standby]$

 

When running the CSD process from the command line, you are not required to use the options listed in brackets [] example: 

[--mode CLI|BATCH|GUI] [--restart] [--noprompt] [-j json_file] [--dump_template]

These are optional parameters.

2.1.  Creating Single Instance Standby (non-RAC)

 

In the following example we will create a standby database based on the following information:

  • Primary Server Details:

    • Server Name: dbv1

    • DB_NAME: DEV

    • DB_UNIQUE_NAME: DEV

    • The database is in archivelog mode

    • Database archive log destination is set to the default recovery area (FRA) - /u01/app/oracle/fast_recovery_area

    • There is a local backup folder /u01/app/oracle/backup which has sufficient space to hold a full compressed backup of the primary DEV database (RMAN Backup)

    • The database data files are located in /u01/app/oracle/oradata/DEV

    • NON-OMF is used 

    • One controlfiles are located in /u01/app/oracle/oradata/DEV and the second one in the FRA - /u01/app/oracle/fast_recovery_area/DEV

 

  • Standby Server Details:

    • Server Name: dbv2

    • The DB_NAME and DB_UNIQUE_NAME will be the same as the primary

    • The same folder structure as the primary will be used 

    • The Oracle Database software is already installed on the standby server and match the same version and edition of the primary

    • The standby server also has a /u01/app/oracle/backup folder with sufficient space for a full RMAN database backup

 

In this example, the ideal configuration is used. This means that the primary and standby database servers are an exact match with regards to storage and the directory structure.

In this case, it will not be required to set any additional parameters such as the db_file_name_convert or log_file_name_convert parameters.

We can now start the process by running the following command from the primary server:  ./dbvctl -d DEV --csd

The example output below shows the detail steps followed:

[oracle@dbv1 standby]$ ./dbvctl -d DEV --csd >>> Running pre-checks please wait... done What would you like to do: 1 - Create standby database (and optionally save settings in template) 2 - Help 3 - Terminate processing Please enter your choice [1]: 1 ------------------------------------------------------------------------------- =>Do you want to use TRANSPORTABLE MEDIA to transfer the database backup to the standby server? Transportable media is an external device such as a USB drive that is first plugged into the primary server and then manually transferred to the standby site and plugged into the standby server to continue the process. It can be used for large databases or slow networks. Specifying No means the network will be used to transfer the database backup. [N]: Your input: N Is this correct? <Yes/No> [Yes]: ------------------------------------------------------------------------------- =>Do you want to perform backup, transfer and restore operations in parallel when possible? [Y]: Y Your input: Y Is this correct? <Yes/No> [Yes]: ------------------------------------------------------------------------------- A temporary location must be specified on dbv1 where the database will be backed up to first. This location must be big enough to hold RMAN backup of the whole database (1.39GB). =>Specify the location on this server: [/usr/tmp]: /u01/app/oracle/backup Your input: /u01/app/oracle/backup Is this correct? <Yes/No> [Yes]: ------------------------------------------------------------------------------- A temporary location must be specified on dbv2 where the database backup will be copied to before moving to specified locations. =>Specify location on remote server: [/u01/app/oracle/backup]: /u01/app/oracle/backup Your input: /u01/app/oracle/backup Is this correct? <Yes/No> [Yes]: The following oracle database parameters will be set in the standby database pfile or spfile: ------------------------------------------------------------------------------- SID NAME VALUE * audit_file_dest /u01/app/oracle/admin/DEV/adump * compatible 11.2.0.4.0 * control_files /u01/app/oracle/oradata/DEV/control01.ctl,/u01/app/oracle/fast_recovery_area/DEV/control02.ctl * db_block_size 8192 * db_domain * db_name DEV * db_recovery_file_dest /u01/app/oracle/fast_recovery_area * db_recovery_file_dest_size 4385144832 * db_unique_name DEV * diagnostic_dest /u01/app/oracle * dispatchers (PROTOCOL=TCP) (SERVICE=DEVXDB) * java_jit_enabled false * open_cursors 300 * pga_aggregate_target 222298112 * processes 150 * remote_login_passwordfile EXCLUSIVE * sga_target 667942912 * spfile OS default * undo_tablespace UNDOTBS1 ------------------------------------------------------------------------------- What would you like to do: 1 - Proceed with creating the standby database 2 - Edit oracle database parameters for the standby database pfile/spfile 3 - Terminate processing Please enter your choice [1]: 1 Validating oracle database parameters... please wait =>SUCCEEDED ------------------------------------------------------------------------------- =>Create standby database template for DEV using provided answers? [Y]: Y Your input: 1 Is this correct? <Yes/No> [Yes]: ------------------------------------------------------------------------------- =>Continue with creating a standby database? (If No processing will terminate, the saved template will be available for future use) [Y]: Y Your input: 1 Is this correct? <Yes/No> [Yes]: >>> dbvctl will now run a pre-flight check for standby database creation. An attempt will be made to create a standby (s)pfile using oracle standby database parameters, followed by trying to start the standby instance. If this step fails, then please double-check the following items before re-running dbvctl again: 1) Review the standby database parameters you have supplied and provide valid values unless a template is used. 2) Recreate the template to provide valid values for standby database parameters if a template is used. >>> Running pre-flight check for standby creation, please wait... done >>> Creating standby control file... done WARNING: FORCE_LOGGING is disabled in the primary database! >>> Total database size for DEV is 1.39GB >>> Backing up primary database... Backing up datafile 1... done Backing up datafile 2... done Backing up datafile 3... done Backing up datafile 4... done >>> Transferring backup from dbv1 to dbv2... Transferring /u01/app/oracle/backup/DBV_DEV_CSD_DBF_1_02u0745n_1_1.RMAN... done Transferring /u01/app/oracle/backup/DBV_DEV_CSD_DBF_1_03u07466_1_1.RMAN... done Transferring /u01/app/oracle/backup/DBV_DEV_CSD_DBF_2_04u07468_1_1.RMAN... done Transferring /u01/app/oracle/backup/DBV_DEV_CSD_DBF_3_05u0746g_1_1.RMAN... done Transferring /u01/app/oracle/backup/DBV_DEV_CSD_DBF_4_06u0746n_1_1.RMAN... done >>> Starting standby database DEV on dbv2 mount... done >>> Restoring datafiles on dbv2... Restoring datafile 1... done Restoring datafile 2... done Restoring datafile 3... done Restoring datafile 4... done >>> Renaming standby redo logs and tempfiles on dbv2... done >>> Completing standby database creation... done >>> Standby database created. >>> Performing checkpoint and archiving logs... done >>> Synchronising standby... done PID:266 TRACE:266_dbvctl_csd_DEV_201904291308.trc

 

Once the above process is complete, you should be able to send and apply logs which are shown below.

2.1.1.  Sending Logs 

Sending archive logs to the standby database can be done by running the following command:  ./dbvctl -d <DDC>

Example:

[oracle@dbv1 standby]$ ./dbvctl -d DEV ============================================================= Dbvisit Standby Database Technology (9.0.0_1271_g4b00fb49) (pid 629) dbvctl started on dbv1: Mon Apr 29 13:22:34 2019 ============================================================= >>> Obtaining information from standby database (RUN_INSPECT=Y)... done Thread: 1 Archive log gap: 0. Transfer log gap: 0 Note FORCE_LOGGING is disabled in the primary database. >>> Sending heartbeat message... skipped >>> Performing a log switch... done >>> Transferring Log file(s) from DEV on dbv1 to dbv2: thread 1 sequence 11 (o1_mf_1_11_gddngxc5_.arc)... done ============================================================= dbvctl ended on dbv1: Mon Apr 29 13:22:41 2019 =============================================================

 

2.1.2.  Applying Logs

Applying archive logs on the standby database run the following command:  ./dbvctl -d <DDC>

Example:

[oracle@dbv2 standby]$ ./dbvctl -d DEV ============================================================= Dbvisit Standby Database Technology (9.0.0_1271_g4b00fb49) (pid 1164) dbvctl started on dbv2: Mon Apr 29 13:23:15 2019 ============================================================= >>> Applying Log file(s) from dbv1 to DEV on dbv2: thread 1 sequence 11 (1_11_1004372670.arc)... done Last applied log(s): thread 1 sequence 11 Next SCN required for recovery 1128090 generated at 2019-04-29:13:22:37 +12:00. Next required log thread 1 sequence 12 ============================================================= dbvctl ended on dbv2: Mon Apr 29 13:23:16 2019 =============================================================

2.1.3.  Running the log gap report

To ensure the primary and standby databases are up to date, you can run the Log Gap Report using the following command from the primary database server:./dbvctl -d <DDC> -i 

Example:

[oracle@dbv1 standby]$ ./dbvctl -d DEV -i ============================================================= Dbvisit Standby Database Technology (9.0.0_1271_g4b00fb49) (pid 666) dbvctl started on dbv1: Mon Apr 29 13:23:49 2019 ============================================================= Dbvisit Standby log gap report for DEV at 201904291323: ------------------------------------------------------------- Description | SCN | Timestamp ------------------------------------------------------------- Source 1128122 2019-04-29:13:23:49 +12:00 Destination 1128090 2019-04-29:13:22:37 +12:00 Standby database time lag (DAYS-HH:MI:SS): +00:01:12 Report for Thread 1 ------------------- SOURCE Current Sequence 12 Last Archived Sequence 11 Last Transferred Sequence 11 Last Transferred Timestamp 2019-04-29 13:22:41 DESTINATION Recovery Sequence 12 Transfer Log Gap 0 Apply Log Gap 0 ============================================================= dbvctl ended on dbv1: Mon Apr 29 13:23:51 2019 =============================================================