oracle 9i创建physical standby（data guard）官方手册

最新推荐文章于 2024-07-16 10:28:31 发布

ctw3969

最新推荐文章于 2024-07-16 10:28:31 发布

阅读量130

点赞数

文章标签：数据库网络

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 Creating a Physical Standby Database

This chapter steps you through the process of creating a physical standby database.

It includes the following main topics:

_ Preparing the Primary Database for Standby Database Creation

_ Creating a Physical Standby Database

_ Verifying the Physical Standby Database

3.1 Preparing the Primary Database for Standby Database Creation

Table 3–1 provides a checklist of the tasks that you perform. on the primary databaseto prepare for physical standby database creation. There is also a reference to the section that describes the task in more detail.

Table 3–1 Preparing the Primary Database for Physical Standby Database Creation

Reference	Task
Section 3.1.1	Enable Forced Logging
Section 3.1.2	Enable Archiving and Define a Local Archiving Destination

3.1.1 Enable Forced Logging

Place the primary database in FORCE LOGGING mode after database creation using the following SQL statement:

SQL> ALTER DATABASE FORCE LOGGING;

This statement may take a considerable amount of time to complete, because it waits for all unlogged direct write I/O operations to finish.

3.1.2 Enable Archiving and Define a Local Archiving Destination

Ensure that the primary database is in ARCHIVELOG mode, that automatic

archiving is enabled, and that you have defined a local archiving destination.

Set the local archive destination using the following SQL statement:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=’LOCATION=/disk1/oracle/oradata/payroll MANDATORY’ SCOPE=BOTH;

3.2 Creating a Physical Standby Database

Table 3–2 provides a checklist of the tasks that you perform. to create a physical standby database and the database or databases on which you perform. each task.There is also a reference to the section that describes the task in more detail.

Table 3–2 Creating a Physical Standby Database

Reference	Task	Database
Section 3.2.1	Identify the Primary Database Datafiles	Primary
Section 3.2.2	Make a Copy of the Primary Database	Primary
Section 3.2.3	Create a Control File for the Standby Database	Primary
Section 3.2.4	Prepare the Initialization Parameter File to be Copied to the Standby Database	Primary
Section 3.2.5	Copy Files from the Primary System to the Standby System	Primary
Section 3.2.6	Set Initialization Parameters on a Physical Standby Database	Standby
Section 3.2.7	Create a Windows Service	Standby
Section 3.2.8	Configure Listeners for the Primary and Standby Databases	P and S
Section 3.2.9	Enable Dead Connection Detection on the Standby System	Standby
Section 3.2.10	Create Oracle Net Service Names	P and S
Section 3.2.11	Create a Server Parameter File for the Standby Database	Standby
Section 3.2.12	Start the Physical Standby Database	Standby
Section 3.2.13	Initiate Log Apply Services	Standby
Section 3.2.14	Enable Archiving to the Physical Standby Database	Primary

3.2.1 Identify the Primary Database Datafiles

On the primary database, query the V$DATAFILE view to list the files that will be used to create the physical standby database, as follows:

SQL> SELECT NAME FROM V$DATAFILE;

NAME

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

/disk1/oracle/oradata/payroll/system01.dbf

3.2.2 Make a Copy of the Primary Database

On the primary database, perform. the following steps to make a closed backup copy of the primary database.

Step 1 Shut down the primary database.

Issue the following SQL*Plus statement to shut down the primary database:

SQL> SHUTDOWN IMMEDIATE;

Step 2 Copy the datafiles to a temporary location.

Copy the datafiles that you identified in Section 3.2.1 to a temporary location using an operating system utility copy command. The following example uses the UNIX

cp command:

cp /disk1/oracle/oradata/payroll/system01.dbf

/disk1/oracle/oradata/payroll/standby/system01.dbf

Copying the datafiles to a temporary location will reduce the amount of time that the primary database must remain shut down.

Step 3 Restart the primary database.

Issue the following SQL*Plus statement to restart the primary database:

SQL> STARTUP;
3.2.3 Create a Control File for the Standby Database

On the primary database, create the control file for the standby database, as shown in the following example:

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS

2> '/disk1/oracle/oradata/payroll/standby/payroll2.ctl';

The filename for the newly created standby control file must be different from the filename of the current control file of the primary database. The control file must also be created after the last time stamp for the backup datafiles.

3.2.4 Prepare the Initialization Parameter File to be Copied to the Standby Database

Create a traditional text initialization parameter file from the server parameter file used by the primary database; a traditional text initialization parameter file can be copied to the standby location and modified. For example:

SQL> CREATE PFILE=’/disk1/oracle/dbs/initpayroll2.ora’ FROM SPFILE;

Later, in Section 3.2.11, you will convert this file back to a server parameter file after it is modified to contain the parameter values appropriate for use with the physical standby database.

3.2.5 Copy Files from the Primary System to the Standby System

On the primary system, use an operating system copy utility to copy the following binary files from the primary system to the standby system:

_ Backup datafiles created in Section 3.2.2

_ Standby control file created in Section 3.2.3

_ Initialization parameter file created in Section 3.2.4

3.2.6 Set Initialization Parameters on a Physical Standby Database

Although most of the initialization parameter settings in the text initialization parameter file that you copied from the primary system are also appropriate for the physical standby database, some modifications need to be made.

Example 3–1 shows the portion of the standby initialization parameter file where values were modified for the physical standby database. Parameter values that changed are shown in bold typeface.

Example 3–1 Modifying Initialization Parameters for a Physical Standby Database

db_name=PAYROLL

compatible=9.2.0.1.0

control_files=’/disk1/oracle/oradata/payroll/standby/payroll2.ctl’

log_archive_start=TRUE

standby_archive_dest=’/disk1/oracle/oradata/payroll/standby’

db_file_name_convert=(’/disk1/oracle/oradata/payroll/’,’/disk1/oracle/oradata/payroll/standby/’)

log_file_name_convert=(’/disk1/oracle/oradata/payroll/’,’/disk1/oracle/oradata/payroll/standby/’)

log_archive_format=log%d_%t_%s.arc

log_archive_dest_1=(’LOCATION=/disk1/oracle/oradata/payroll/standby/’)

standby_file_management=AUTO

remote_archive_enable=TRUE

instance_name=PAYROLL2

# The following parameter is required only if the primary and standby databases

# are located on the same system.

lock_name_space=PAYROLL2

The following list provides a brief explanation about the parameter settings shown in Example 3–1:

_ db_name - Not modified. The same name as the primary database.

_ compatible - Not modified. The same as the primary database, 9.2.0.1.0.

_ control_files - Specify the path name and filename for the standby control file.

_ log_archive_start - Not modified. The same as the setting for the primary database, TRUE.

_ standby_archive_dest - Specify the location of the archived redo logs that will be received from the primary database.

_ db_file_name_convert - Specify the location of the primary database datafiles followed by the standby location of the datafiles. This parameter will convert the filename of the primary database datafiles to the filename of the standby datafile filenames. If the standby database is on the same system as the primary database or if the directory structure where the datafiles are located on the standby site is different from the primary site then this parameter is required. See Section 3.2.1 for the location of the datafiles on the primary database.

_ log_file_name_convert - Specify the location of the primary database logs followed by the standby location of the logs. This parameter will convert the filename of the primary database log to the filenames of the standby log. If the standby database is on the same system as the primary database or if the directory structure where the logs are located on the standby site is different from the primary site then this parameter is required. See Section 3.2.1 for the location of the logs on the primary database.

log_archive_format - Specify the format for the archived redo logs using a DBID (%d), thread (%t), and sequence number (%s).

_ log_archive_dest_1 - Specify the location where the redo logs are to be archived on the standby system. (If a switchover occurs and this instance becomes the primary database, then this parameter will specify the location where the online redo logs will be archived.)

_ standby_file_management - Set to AUTO.

_ remote_archive_enable - Set to TRUE.

_ instance_name - If this parameter is defined, specify a different value for the standby database than the primary database when the primary and standby databases reside on the same host.

_ lock_name_space - Specify the standby database instance name. Use this parameter when you create the physical standby database on the same system as the primary database. Change the INSTANCE_NAME parameter to a value other than its primary database value, and set this LOCK_NAME_SPACE initialization parameter to the same value that you specified for the standby database INSTANCE_NAME initialization parameter.

3.2.7 Create a Windows Service

If the standby system is running on a Windows system, use the ORADIM utility to create a Windows Service. For example:

WINNT> oradim -NEW -SID payroll2 -STARTMODE manual

3.2.8 Configure Listeners for the Primary and Standby Databases

On both the primary and standby sites, use Oracle Net Manager to configure a listener for the respective databases. If you plan to manage the configuration using the Data Guard broker, you must configure the listener to use the TCP/IP protocol and statically register service information for each database using the SID for the database instance.

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

3.2.9 Enable Dead Connection Detection on the Standby System

Enable dead connection detection by setting the SQLNET.EXPIRE_TIME parameter to 2 in the SQLNET.ORA parameter file on the standby system. For example:

SQLNET.EXPIRE_TIME=2

3.2.10 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 log transport services.

The Oracle Net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and SID 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.

3.2.11 Create a Server Parameter File for the Standby Database

On an idle standby database, use the SQL CREATE statement to create a server parameter file for the standby database from the text initialization parameter file that was edited in Section 3.2.6. For example:

SQL> CREATE SPFILE FROM PFILE=’initpayroll2.ora’;

3.2.12 Start the Physical Standby Database

On the standby database, issue the following SQL statements to start and mount the database in standby mode:

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

3.2.13 Initiate Log Apply Services

On the standby database, start log apply services as shown in the following example:

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

The example includes the DISCONNECT FROM SESSION option so that log apply services run in a background session.

3.2.14 Enable Archiving to the Physical Standby Database

This section describes the minimum amount of work you must do on the primary database to set up and enable archiving to the physical standby database.

Step 1 Set initialization parameters to define archiving.

To configure archive logging from the primary database to the standby site the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n parameters must be defined.

The following example sets the initialization parameters needed to enable archive logging to the standby site:

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=payroll2’ SCOPE=BOTH;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

Step 2 Start remote archiving.

Archiving of redo logs to the remote standby location does not occur until after a log switch. A log switch occurs, by default, when an online redo log becomes full.

To force the current redo logs to be archived immediately, use the SQL ALTER SYSTEM statement on the primary database. For example:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

3.3 Verifying the Physical Standby Database

Once you create the physical standby database and set up log transport services,you may want verify that database modifications are being successfully shipped from the primary database to the standby database.

To see the new archived redo logs that were received on the standby database, you should first identify the existing archived redo logs on the standby database,archive a few logs 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 logs.

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

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME 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

1 rows selected.

Step 2 Archiving the current log.

On the primary database, archive the current log using the following SQL statement:

SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

Step 3 Verify that the new archived redo log was received.

On the standby database, query the V$ARCHIVED_LOG view to verify the redo log was received: