To restart the listeners (to pick up the new definitions), enter the following LSNRCTL utility commands on both the primary and standby systems:

% lsnrctl stop

% lsnrctl start

See Oracle Database Net Services Administrator's Guide.

Step 4 Create Oracle Net service names.

On both the primary and standby systems, use Oracle Net Manager to create a network service name for the primary and standby databases that will be used by redo transport services. The Oracle Net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and service that you specified when you configured the listeners for the primary and standby databases. The connect descriptor must also specify that a dedicated server be used. See theOracle Database Net Services Administrator's Guideand theOracle Database

Administrator's Guide.

Step 5 Create a server parameter file for the standby database.

On an idle standby database, use the SQL CREATEstatement to create a server parameter file for the standby database from the text initialization parameter file that was edited in Step 2 on page 3-8. For example:

SQL> CREATE SPFILE FROM PFILE='initboston.ora';

3.2.6 Start the Physical Standby Database

Perform the following steps to start the physical standby database and Redo Apply.

Step 1 Start the physical standby database.

On the standby database, issue the following SQL statement to start and mount the database:

SQL> STARTUP MOUNT;

Step 2 Start Redo Apply.

On the standby database, issue the following command to start Redo Apply:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

The statement includes the DISCONNECT FROM SESSIONoption so that Redo Apply runs in a background session. SeeSection 6.3, "Applying Redo Data to PhysicalStandby Databases"for more information.

Step 3 Test archival operations to the physical standby database.

In this example, the transmission of redo data to the remote standby location does not occur until after a log switch. A log switch occurs, by default, when an online redo log file becomes full. To force a log switch so that redo data is transmitted immediately, use the following ALTER SYSTEM statement on the primary database. For example:

SQL> ALTER SYSTEM SWITCH LOGFILE;

3.2.7 Verify the Physical Standby Database Is Performing Properly

Once you create the physical standby database and set up redo transport services, you may want to verify database modifications are being successfully transmitted from the primary database to the standby database. To see that redo data is being received on the standby database, you should first identify the existing archived redo log files on the standby database, force a log switch and archive a few online redo log files on the primary database, and then check the standby database again. The following steps show how to perform these tasks.

Step 1 Identify the existing archived redo log files.

On the standby database, query the V$ARCHIVED_LOG view to identify existing files in the archived redo log. For example:

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME

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

8 11-JUL-02 17:50:45 11-JUL-02 17:50:53

9 11-JUL-02 17:50:53 11-JUL-02 17:50:58

10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

3 rows selected.