How to Create a Physical Standby Database

Version 1

    How to Create a Physical Standby Database

    For some, the process of creating a physical standby database for an Oracle primary can be a daunting task. This document intends to show how easy it really is. The reader should be able to follow the steps in this document and create a physical standby database in short order. This document does assume the reader has a basic understanding of what a physical standby database is.

     

    The Setup

    I am writing this paper using two virtual machines on my laptop. Any reader should be able to follow the same steps on their system as well. I am using Oracle’s Virtual Box for the hypervisor. I created two virtual machines, one for the primary database and one for the standby database. The following list the details of each machine:

     

     

     

    Host:         prim                             stdby
    OS:           Oracle Linux 6.5         Oracle Linux 6.5

    Oracle:      Oracle 12.1.0.2 EE      Oracle 12.1.0.2 EE

    Database:  orcl                              orcls



     

     

    On host ‘prim’, I have installed Oracle EE and used the DBCA to create a database named ‘orcl’. On host ‘stdby’, I have installed Oracle EE but no database is there yet. Part of this paper will be to create the ‘orcls’ database, the standby to ‘orcl’.

     

    If you use Virtual Box, then you will have to take a few additional steps. Each VM was created with two network interfaces. One was created as ‘host-only’ and the other as ‘NAT’. The first, host-only network adapter, is the interface each machine will use to talk to each other. The optional NAT adapter is used to download updates from the Internet. Additionally, I assigned each host-only adapter a static IP address as follows:

     

    prim 192.168.56.110

    stdby 192.168.56.111

     

    I updated each VM’s hosts file to have these IP addresses. I verified I could ping from one to the other and SSH from one to the other. I also added these IP entries in my laptop’s hosts file as well and verified I could SSH from a terminal program on my laptop to each machine.

     

    With my initial setup complete, I can now proceed with the task of creating a physical standby database. You may have a similar setup in place already. If not, create VM’s with Virtual Box and follow along!

     

    In my examples, I set my host prompt to indicate which server I am connected to, similar to the following:

     

     

    [oracle@prim ~]$

    [oracle@stdby dbs]$

    If you’re confused which system I executed a command on, look for the prompt. In the above, the first prompt is on the ‘prim’ host and the second prompt on the ‘stdby’ host. In my SQL*Plus sessions, the prompt will show either ORCL for the primary or ORCLS for the standby. Lastly, all of my connections in SQL*Plus are done as SYSDBA.

     

     

    The Basics

    Before showing how to create a physical standby database, it is important to understand the basic steps involved. Too often, if we go straight to the implementation details, we can become overwhelmed and lose sight of the big picture. At a high level, the basic steps are as follows:

     

     

    1. Prepare the primary to support a physical standby
    2. Create the standby database
    3. Start the standby and apply recovery

     

    That’s all there is to it!

     

    Obviously, there is more to it than just 3 steps. For now, these 3 steps will serve as our guide. This will help make the process of creating the standby database less daunting. The next three sections of this document will follow these three steps. Each section will expand on the work involved. Each section will start by breaking down the high-level steps into subtasks.

     

     

    Prepare the Primary

     

    The first major step in creating a physical standby is to prepare the primary database. Oracle transmits changes from the primary to the physical standby database by transporting its redo stream from one to the other. Preparing the primary means we need to ensure redo records are always in the redo stream, that the primary knows where to ship the redo, and that the redo stream is archived. In other words, the steps to prepare the primary are:

     

    1. Enable Forced Logging
    2. Set Initialization Parameters
    3. Enable Archive Logging

     

    This section will handle each of these subtasks in order.

     

    So why do we need to enable forced logging? Many, many versions ago, Oracle introduced the ability to define a table as NOLOGGING. Performance tuning specialists loved this feature because bulk data loads to a table could avoid the overhead of writing redo records to the Log Buffer and subsequently to the Online Redo Logs (ORLs). Bulk loads were faster. As with just about anything in database systems, there is a tradeoff. That increased speed came with a penalty. One could not recover the results of a bulk data load. The DBA needed to either backup the database after the bulk load or have the ability to re-load the data. For many, the tradeoff was worth it. Unfortunately for physical standby databases, there is no tradeoff. Remember that the physical standby database must be an exact copy of the primary. We cannot have an exact copy if some of the transactions are never in the redo stream. We could ensure that all tables are not defined as NOLOGGING, but what if a developer slips one past the DBA? Any DML on that NOLOGGING table would break the physical standby. We need a mechanism to force all DML to be logged to the redo stream no matter what. This entire paragraph took much longer than it does to enable force logging. The DBA needs to issue the following:

     

    SQL ORCL> alter database force logging; Database altered.
    SQL ORCL> select force_logging from v$database;

    FORCE_LOGGING

    ---------------------------------------

    YES

     

    Next, we need to define some initialization parameters. Some of these may already be defined already in your system but we’ll review them here just in case. These are the list of parameters I need to ensure are defined properly in the primary and what they are used for:

     

    • DB_NAME – both the primary and the physical standby database will have the same database name. After all, the standby is an exact copy of the primary and its name needs to be the same.
    • DB_UNIQUE_NAME – While both the primary and the standby have the same database name, they have a unique name. In the primary, DB_UNIQUE_NAME equals DB_NAME. In the standby, DB_UNIQUE_NAME does not equal DB_NAME.  The DB_UNIQUE_NAME will match the ORACLE_SID for that environment.
    • LOG_ARCHIVE_FORMAT – Because we have to turn on archive logging, we need to specify the file format of the archived redo logs.
    • LOG_ARCHIVE_DEST_1 – The location on the primary where the ORLs are archived. This is called the archive log destination.
    • LOG_ARCHIVE_DEST_2 – The location of the standby database.
    • REMOTE_LOGIN_PASSWORDFILE – We need a password file because the primary will sign on to the standby remotely as SYSDBA.

     

     

    I used a text editor to modify the PFILE’s contents as follows:

    *.audit_file_dest='/u01/app/oracle/admin/orcl/adump'
    *.audit_trail='db'
    *.compatible='12.1.0.2.0' *.control_files='/u01/app/oracle/oradata/orcl/control01.ctl','/u01/app/ora cle/oradata/orcl/control02.ctl'

    *.db_block_size=8192
    *.db_domain=''
    *.db_name='orcl'
    *.db_unique_name='orcl'
    *.diagnostic_dest='/u01/app/oracle'

    *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'

    *.log_archive_dest_1='LOCATION="/u01/app/oracle/oradata/arch"' 

    *.log_archive_dest_2='SERVICE="orcls", ASYNC NOAFFIRM'

    *.log_archive_format=%t_%s_%r.arc

    *.open_cursors=300

    *.pga_aggregate_target=500m

    *.processes=300

    *.remote_login_passwordfile='EXCLUSIVE'

    *.sga_target=2000m

    *.undo_tablespace='UNDOTBS1'

     

    Most of the parameters above were defined by the DBCA when the database was created. The ones in red are important to support the standby configuration. LOG_ARCHIVE_DEST_1 points to a location on disk for the archive log destination. LOG_ARCHIVE_DEST_2 points to an alias we will add in our TNSNAMES.ORA file soon. We also specified ASYNC NOAFFIRM because in this example, we will configure for maximum performance, not zero data loss.

     

    We’ve nearly completed the first two subtasks in this section. Our initialization parameters changes are not complete until we create the SPFILE from this text file and startup the instance. Since this requires downtime, we will also use that same downtime window to configure archive logging. This downtime window should be brief. We will shutdown the instance, create the SPFILE with our parameter changes, start the instance in MOUNT mode, and start archive logging.

     

    SQL ORCL> shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL ORCL> create spfile from pfile='/home/oracle/pfile.txt';

    File created.

    SQL ORCL> startup mount ORACLE instance started.

    Total System Global Area 2097152000 bytes

    Fixed Size                  2926320 bytes

    Variable Size             603982096 bytes

     

    Database Buffers         1476395008 bytes

    Redo Buffers               13848576 bytes

    Database mounted.

    SQL ORCL> alter database archivelog;

    Database altered.
    SQL ORCL> alter database open; Database altered.

     

    One thing we haven’t done yet is to configure TNSNAMES.ORA. Remember that LOG_ARCHIVE_DEST_2 is saying to use the service ORCLS. We need a TNS alias for this service. In our $ORACLE_HOME/network/admin/tnsnames.ora configuration file, the following entry is placed:

    ORCLS = (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = stdby)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = orcls)

      )

    )

     

    Before we leave this section, it is important that the database administrator verifies the configuration. First, we verify archive logging is working correctly.

     

     

    SQL ORCL> archive log list

    Database log mode                Archive Mode

    Automatic archival          Enabled

    Archive destination             /u01/app/oracle/oradata/arch

    Oldest online log sequence     227

    Next log sequence to archive   229

    Current log sequence            229

    SQL ORCL> alter system switch logfile;

    System altered.

    SQL ORCL> !ls -l /u01/app/oracle/oradata/arch

    total 15688

    -rw-r-----. 1 oracle oinstall  3663360 Jun  7 08:20 1_227_909527034.arc

    -rw-r-----. 1 oracle oinstall 12386816 Jun  7 08:25 1_228_909527034.arc

    -rw-r-----. 1 oracle oinstall     5632 Jun  7 08:25 1_229_909527034.arc

     

    The log files are in the archive destination as expected. The current log was sequence #229. When the log switch was forced, we can see the archiver created the archived redo log for that sequence number. We can also examine this activity in the database’s Alert Log.

     

     

    Thread 1 advanced to log sequence 230 (LGWR switch)

      Current log# 2 seq# 230 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log

    Tue Jun 07 08:25:39 2016

    Archived Log entry 3 added for thread 1 sequence 229 ID 0x55abbf78 dest 1:

    Tue Jun 07 08:25:43 2016

    Error 12154 received logging on to the standby

     

    The Alert Log shows us that the thread of redo was advanced to sequence #230. Sequence #229 is archived. We also see an ORA-12154 error when trying to log into the standby database. This is acceptable at this point because the standby does not yet exist.

     

    The primary is ready to go. That wasn’t so hard. Now let’s create our standby database.

     

     

    Create the Standby Database

     

    This is the second major task to complete. In this section, we will create a backup of the primary and use it to create the standby database. We need to create a special standby control file. A password file, a parameter file, and a similar TNS alias will complete the setup. The subtasks are outlined below.

     

    1. Create a backup of the primary.
    2. Create a standby controlfile.
    3. Copy the password file.
    4. Create a parameter file.
    5. Create a TNSNAMES.ORA file.

     

    Steps 4 and 5 above are nearly duplicates of our work in the previous section. The rest are not that difficult, so let’s get started.

     

    Remember that a physical standby database is an exact copy of the primary database. So we need to duplicate the primary. There are many methods to do so. I’m simply going to bring down the primary database and copy its datafiles to a backup location. This will work well for me because this is a small database and because its only a testbed. I can handle the downtime. For larger databases and or ones with little or no downtime window, then use the RMAN DUPLICATE functionality.

     

    All of my database’s files for this testbed database reside in one directory so my life is easy here. I will determine the file location, shutdown the database, copy the files to the backup location, and then start the primary instance again.

    SQL ORCL> connect / as sysdba
    Connected.

    SQL ORCL> select file_name from dba_data_files;

    FILE_NAME

    ----------------------------------------------------------------

    /u01/app/oracle/oradata/orcl/system01.dbf

    /u01/app/oracle/oradata/orcl/sysaux01.dbf

    /u01/app/oracle/oradata/orcl/users01.dbf

    /u01/app/oracle/oradata/orcl/undotbs01.dbf

    SQL ORCL> shutdown immediate
    Database closed.
    Database dismounted.
    ORACLE instance shut down.
    SQL ORCL> !mkdir /u01/app/oracle/oradata/orcl/bkup

    SQL ORCL> !cp /u01/app/oracle/oradata/orcl/* /u01/app/oracle/oradata/orcl/bkup/.
    cp: omitting directory `/u01/app/oracle/oradata/orcl/bkup'

    SQL ORCL> startup

    ORACLE instance started.

     

    Total System Global Area 2097152000 bytes

    Fixed Size             2926320 bytes

    Variable Size        603982096 bytes

    Database Buffers 1476395008 bytes

    Redo Buffers          13848576 bytes

    Database mounted.

    Database opened.

     

     

     

    Now that I have a backup of the primary database, I need to copy it to the standby server.

     

     

     

    [oracle@prim bkup]$ scp /u01/app/oracle/oradata/orcl/bkup/* oracle@stdby:/u01/app/oracle/oradata/orcl/.
    oracle@stdby's password:

    control01.ctl                               100% 9808KB   9.6MB/s 00:00   

    control02.ctl                               100% 9808KB   9.6MB/s 00:00   

    redo01.log                                  100%   50MB  50.0MB/s   00:00

    redo02.log                                  100%   50MB  50.0MB/s   00:01   

    redo03.log                                  100%   50MB  50.0MB/s   00:00   

    sysaux01.dbf                                100% 1090MB  99.1MB/s   00:11

    system01.dbf                                100%  800MB 100.0MB/s   00:08

    temp01.dbf                                  100%   60MB 60.0MB/s   00:01   

    undotbs01.dbf                               100%   60MB 60.0MB/s   00:00   

    users01.dbf                                 100% 5128KB  5.0MB/s   00:00

     

     

     

    The next step is to create a standby control file. Of the many pieces of information in a control file, the control file keeps the current role of the database. In ORCL, that role is PRIMARY. We need to create a control file that has the role PHYSICAL STANDBY so that when the instance starts, it knows the expected role in the configuration. In the primary, we will create the standby control file and then copy it to the standby server.

     

    SQL ORCL> alter database create standby controlfile

    2 as '/home/oracle/control.stdby';

    Database altered.
    SQL ORCL> !scp /home/oracle/control.stdby 
    oracle@stdby:/u01/app/oracle/oradata/orcl/.

     

     

     

    oracle@stdby's password:
    control.stdby 100% 9808KB 9.6MB/s 00:00

     

    On my standby host, I now have three control files.

     

    [oracle@stdby orcl]$ ls -l control*

    -rw-r-----. 1 oracle oinstall 10043392 Oct  4 19:50 control01.ctl

    -rw-r-----. 1 oracle oinstall 10043392 Oct  4 19:50 control02.ctl

    -rw-r-----. 1 oracle oinstall 10043392 Oct  4 20:00 control.stdby

     

     

    The first two are from the backup of the primary database. These have the wrong database role. The last one is the standby control file we just created and copied over here. We need to remove the copies of the primary control files and make the standby control files have the same names.

     

     

    [oracle@stdby orcl]$ rm control01.ctl control02.ctl

    [oracle@stdby orcl]$ cp control.stdby control01.ctl

    [oracle@stdby orcl]$ mv control.stdby control02.ctl

     

     

    Remember in the Alert Log in the primary that we saw that ORA-12154 error? In case you missed it, here is that entry:

     

    Tue Jun 07 08:25:43 2016
    Error 12154 received logging on to the standby

     

    This is the primary trying to log into the standby instance. The instance isn’t up and running yet. We’ll start it in the next section. But those connections are coming to the standby instance from a remote machine. As such, the standby must have a password file. Not only must it have a password file, it needs to be a duplicate of the primary’s password file. So for the next subtask, we will copy the password file over from the primary to the standby.

     

     

    [oracle@prim bkup]$ cd $ORACLE_HOME/dbs

    [oracle@prim dbs]$ scp orapworcl oracle@stdby:/u01/app/oracle/product/12.1.0.2/dbs/.

    oracle@stdby's password:

    orapworcl                                 100% 7680     7.5KB/s 00:00    

     

    The next subtask is to create a parameter file for the standby database to use. To make my life easier, I will use the primary database’s parameter file as a template. If I do that, I have very little to change. Below is the standby database’s parameter file. The text in red are the only differences between the primary and the standby database’s parameters.

     

    *.audit_file_dest='/u01/app/oracle/admin/orcls/adump'
    *.audit_trail='db'
    *.compatible='12.1.0.2.0' *.control_files='/u01/app/oracle/oradata/orcl/control01.ctl','/u01/app/ora
    cle/oradata/orcl/control02.ctl'

    *.db_block_size=8192
    *.db_domain=''
    *.db_name='orcl'
    *.db_unique_name='
    orcls'
    *.diagnostic_dest='/u01/app/oracle'

    *.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'

    *.log_archive_dest_1='LOCATION="/u01/app/oracle/oradata/arch"' 

    *.log_archive_dest_2='SERVICE="orcl", ASYNC NOAFFIRM'

    *.log_archive_format=%t_%s_%r.arc

    *.open_cursors=300

    *.pga_aggregate_target=500m

    *.processes=300

    *.remote_login_passwordfile='EXCLUSIVE'

    *.sga_target=2000m

    *.undo_tablespace='UNDOTBS1'

     

    Notice that I only have three differences! The Audit Dest has a slightly different directory path since the ORACLE_SID will be different. The DB_UNIQUE_NAME is different because they cannot be the same...they have to be unique. I also set LOG_ARCHIVE_DEST_2 to point back to the primary. If we perform a switchover operation we will want ORCLS, which will be the new primary, to transport redo to ORCL, what is now the new standby. I make sure to set the following environment variables:

     

    [oracle@stdby ~]$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0.2

    [oracle@stdby ~]$ export ORACLE_SID=orcls
    [oracle@stdby ~]$ export PATH=$ORACLE_HOME/bin:$PATH

     

    I now use SQL*Plus to create a SPFILE from this text file.

     

    SQL ORCLS> connect / as sysdba
    Connected to an idle instance.
    SQL ORCLS> create spfile from pfile='/home/oracle/pfile.txt';

    File created.

     

    When I connected a SYSDBA, I received a message that the instance was idle. We have yet to start it, so this is expected. The SPFILE was then created. I now verify that the password file and the SPFILE are in $ORACLE_HOME/dbs.

     

     

    [oracle@stdby ~]$ cd $ORACLE_HOME/dbs

    [oracle@stdby dbs]$ ls -l

    total 16

    -rw-r-----. 1 oracle oinstall 7680 Oct  4 20:07 orapworcl

    -rw-r-----. 1 oracle oinstall 2560 Oct  4 20:14 spfileorcls.ora

     

    Oops! I have a mistake. Do you see it? This is a common mistake that people make. On the standby server, the instance name is ORCLS with a ‘S’ at the end. Because I copied the file from the primary, the password file name is not correct. The ORCLS instance will never find the password file it is looking for. This is a quick fix.

     

    [oracle@stdby dbs]$ mv orapworcl orapworcls

     

    The only subtask that remains is to create our TNS alias. Remember that in the standby database, we set LOG_ARCHIVE_DEST_2 to point back to the old primary. We now need an alias in the TNSNAMES.ORA file to point to it similar to the following:

     

    ORCL = (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = prim)(PORT = 1521))

    (CONNECT_DATA =

    (SERVER = DEDICATED)

    (SERVICE_NAME = orcl) )

    )

     

    That’s it! We’ve completed the second major step. Our standby database is now configured and ready to go. All that remains is to start it up, start recovery, and verify the configuration.

     

    Start Standby and Recovery

     

    We are now at the proverbial moment of truth. There are two simple tasks here:

       1. Start the standby instance in MOUNT mode
       2. Start managed recovery.

    We will also add a third step for good measure.

       3. Verify configuration is working correctly.

     

    For the first two subtasks, we’ll mount the instance and start recovery as follows:

     

     

     

    SQL ORCLS> connect / as sysdba

    Connected to an idle instance.

    SQL ORCLS> startup mount

    ORACLE instance started.

     

    Total System Global Area 2097152000 bytes

    Fixed Size             2926320 bytes

    Variable Size        603982096 bytes

    Database Buffers 1476395008 bytes

    Redo Buffers          13848576 bytes

    Database mounted.

    SQL ORCLS> alter database recover managed standby database                    

      2  disconnect from session;

     

    Database altered.

     

     

    Everything is operational. We now need to verify it all works as intended.  In the standby, we confirm that managed recover is taking place.

     

     

    SQL ORCLS> select process,thread#,sequence#,status

      2  from v$managed_standby

      3  where process='MRP0';

     

    PROCESS      THREAD#  SEQUENCE# STATUS

    --------- ---------- ---------- ------------

    MRP0               1         233 WAIT_FOR_LOG

     

     

    Note the sequence number above. That will be important in a minute.

     

    MRP0 is the process that governs managed recovery. In the standby Alert Log, we should see messages indicating that Managed Recovery has started.

     

    Tue Oct 04 20:42:26 2016
    Attempt to start background Managed Standby Recovery process (orcls) Starting background process MRP0
    Tue Oct 04 20:42:26 2016
    MRP0 started with pid=28, OS id=3281
    Tue Oct 04 20:42:26 2016
    MRP0: Background Managed Standby Recovery process started (orcls) Tue Oct 04 20:42:31 2016
    Serial Media Recovery started
    Managed Standby Recovery not using Real Time Apply

     

    Next, I’ll perform a log switch in the primary.

     

     

    SQL ORCL> archive log list

    Database log mode         Archive Mode

    Automatic archival        Enabled

    Archive destination       /u01/app/oracle/oradata/arch

    Oldest online log sequence 231

    Next log sequence to archive 233

    Current log sequence         233

    SQL ORCL> alter system switch logfile;

     

    System altered.

     

    Remember that the output from V$MANAGED_RECOVERY said it was waiting on log sequence number 233. That is the current log sequence number in the primary. When we force a log switch, the sequence will be #234. Querying in the standby, we can now see it is waiting on the next log sequence.

     

    SQL ORCLS> select process,thread#,sequence#,status

      2  from v$managed_standby

      3  where process='MRP0';

     

    PROCESS      THREAD#  SEQUENCE# STATUS

    --------- ---------- ---------- ------------

    MRP0               1         234 WAIT_FOR_LOG

     

    In the Alert Log of the primary, we can see the log switch occurring.

     

    Tue Jun 07 09:42:12 2016
    Thread 1 advanced to log sequence 234 (LGWR switch)

    Current log# 3 seq# 234 mem# 0: /u01/app/oracle/oradata/orcl/redo03.log Tue Jun 07 09:42:12 2016
    Archived Log entry 10 added for thread 1 sequence
    233 ID 0x55abbf78 dest 1:

     

    More importantly, if we look in the standby’s Alert Log, we can see the Media Recovery apply log sequence #233 then waiting on log sequence #234.

     

    Tue Oct 04 20:51:21 2016
    Media Recovery Log /u01/app/oracle/oradata/arch/1_
    233_909527034.arc

    Media Recovery Waiting for thread 1 sequence 234 (in transit)

     

    So far, so good. We have confirmed log transport and redo apply. But we have yet to confirm that transactions are really taking place as they should. So let’s initiate a transaction and verify it gets applied correctly in the standby. On the primary, I’ll create a table and insert one row. Then I force a log switch.

     

     

    SQL ORCL> create table system.test_tab (id number, msg varchar2(20));

     

    Table created.

     

    SQL ORCL> insert into system.test_tab values (10,'from primary');

     

    1 row created.

     

    SQL ORCL> commit;

     

    Commit complete.

     

    SQL ORCL> alter system switch logfile;

     

    System altered.

     

    In the standby, I’ll stop the instance and open the database as read only, then I will read from that table.

     

     

    SQL> shutdown immediate

    ORA-01109: database not open

     

    Database dismounted.

    ORACLE instance shut down.

    SQL> startup mount

    ORACLE instance started.

     

    Total System Global Area 2097152000 bytes

    Fixed Size             2926320 bytes

    Variable Size        603982096 bytes

    Database Buffers    1476395008 bytes

    Redo Buffers          13848576 bytes

    Database mounted.

    SQL> alter database open read only;

     

    Database altered.

     

    SQL> select * from system.testtab;

     

         ID MSG

    ---------- --------------------

         10 from primary

     

     

     

     

    And there we have it. We have confirmed the table was created in the standby with the row we inserted into it. We’ll now put the standby database back into managed recovery mode.

     

     

     

     

    SQL ORCLS> shutdown immediate

    Database closed.

    Database dismounted.

    ORACLE instance shut down.

    SQL ORCLS> startup mount

    ORACLE instance started.

     

    Total System Global Area 2097152000 bytes

    Fixed Size             2926320 bytes

    Variable Size        603982096 bytes

    Database Buffers    1476395008 bytes

    Redo Buffers          13848576 bytes

    Database mounted.

    SQL ORCLS> alter database recover managed standby database  

      2  disconnect from session;

     

    Database altered.

     

    Conclusion

     

    Hopefully the steps outlined in this paper have made it simple to get a physical standby database up and running. There are three major steps. One, prepare the primary. Two, create the standby database and configuration. Three, mount the standby instance and start managed recovery. This paper broke down the major steps into a series of subtasks, but none of them were too challenging.