Creating a Data Guard Configuration

Subject:
Creating a Data Guard Configuration

Doc ID:
180031.1
Type: 
REFERENCE
Modified Date: 
21-OCT-2005
Status: 
PUBLISHED
This document will provide the reader with step-by-step instructions on how to 
create a Data Guard environment.  For additional explanation or information on any 
of these steps, please see the references listed at the end of this document.
Creating a Data Guard Configuration
=======================================
 
1) Ensure the Primary database is in ARCHIVELOG mode:
 SQL> archive log list
 Database log mode              No Archive Mode
 Automatic archival             Disabled
 Archive destination            /export/home/oracle/temp/oracle/arch
 Oldest online log sequence     7
 Current log sequence           9
 SQL> alter database close;     
 Database altered.
 SQL> alter database archivelog;     
 Database altered.
 SQL> shutdown immediate                      
 ORA-01109: database not open
 Database dismounted.
 ORACLE instance shut down.
   Modify the Primary database init.ora so that log_archive_start=true and restart 
   the instance. Verify that database is in archive log mode and that automatic 
   archiving is enabled.
 SQL> archive log list
 Database log mode              Archive Mode
 Automatic archival             Enabled
 Archive destination            /export/home/oracle/temp/oracle/arch
 Oldest online log sequence     7
 Next log sequence to archive   9
 Current log sequence           9
2) Create a backup of the Primary database:
   You can use an existing backup of the Primary database as long as you have the 
   archive logs that have been generated since that backup.  You may also take a 
   hot backup as long as you have all archive logs through the end of the backup 
   of the last tablespace.  To create a cold backup do the following: 
 SQL> 
 SQL> select name from v$datafile;
 NAME
 ----------------------------------------------------------------------
        /export/home/oracle/temp/oracle/data/sys.dbf
 
 SQL>
 SQL> shutdown immediate
 Database closed.
 Database dismounted.
 ORACLE instance shut down.
 SQL> exit
   Create a backup of all datafiles and online redo logs using an OS command or 
   utility.  A backup of the online redo logs is necessary to facilitate switchover.
   Once complete startup the instance:
 SQL> startup
 ORACLE instance started.
 Total System Global Area   80512156 bytes
 Fixed Size                   279708 bytes
 Variable Size              71303168 bytes
 Database Buffers            8388608 bytes
 Redo Buffers                 540672 bytes
 Database mounted.
 Database opened.
3)  Connect to the primary database and create the standby control file:
 SQL> alter database create standby controlfile as 
             '/export/home/oracle/temp/oracle/data/backup/standby.ctl';
 Database altered.
4)  Copy files to the Standby host:
   Copy the backup datafiles, standby controlfile, all available archived redo logs,
   and online redo logs from the primary site to the standby site.  Copying of the
   online redo logs is necessary to facilitate switchover.
   If the standby is on a separate site with the same directory structure as the 
   primary database then you can use the same path names for the standby files as 
   the primary files. In this way, you do not have to rename the primary datafiles 
   in the standby control file. If the standby is on the same site as the primary 
   database, or the standby database is on a separate site with a different 
   directory structure the you must rename the primary datafiles in the standby 
   control file after copying them to the standby site.   This can be done using 
   the db_file_name_convert and log_file_name_convert parameters or by manually 
   using the alert database statements.
5)  Set the initialization parameters for the primary database:
   It is suggested that you maintain two init.ora’s on both the primary and the 
   standby.  This allows you to facilitate role reversal during switchover 
   operations more easily. 
 Primary init.ora on Primary host:
 log_archive_dest_1='LOCATION=/export/home/oracle/temp/oracle/arch'
 log_archive_dest_2='SERVICE=DGD01_hasunclu2 reopen=60'
 log_archive_dest_state_1=enable
 log_archive_dest_state_2=enable
 log_archive_format=%t_%s.dbf
 log_archive_start=true
 remote_archive_enable=true
   Create the standby initialization parameter file and set the initialization 
   parameters for the standby database. Depending on your configuration, you may 
   need to set filename conversion parameters.
 Standby init.ora on Primary host:
 log_archive_dest_1='LOCATION=/export/home/oracle/temp/oracle/arch'
 log_archive_dest_state_1=enable
 log_archive_format=%t_%s.dbf
 log_archive_start=true
 standby_archive_dest=/export/home/oracle/temp/oracle/arch
 standby_file_management=auto
 fal_server=DGD01_hasunclu2
 fal_client=DGD01_hasunclu1
 remote_arhive_enable=true
   NOTE:  In the above example db_file_name_convert and log_file_name_convert are 
   not needed as the directory structure on the two hosts are the same.  If the 
   directory structure is not the same then setting of these parameters is 
   recommended.  Please reference notes 47325.1 and 47343.1 for further 
   information.
   Copy the two init.ora’s from the Primary host to the Standby host.  You must 
   modify the Primary init.ora on the Standby host to have log_archive_dest_2 use 
   the alias that points to the Primary host (ie DGD01_hasunclu1).  You must 
   modify the Standby init.ora on the standby host to have fal_server and 
   fal_client use the aliases when standby is running on the Primary host 
   (ie fal_server=DGD01_hasunclu1 and fal_client=DGD01_hasunclu2).
6)  Configure networking components:
   On the Primary host create a net service name that the Primary database can 
   use to connect to the Standby database.  On the Primary host create a net 
   service name that Standby, when running on the Primary host, can use to 
   connect to the Primary, when it is running on the Standby host.  Example from 
   Primary’s host tnsnames.ora:
 DGD01_hasunclu1 =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = hasunclu1)(PORT = 1521))
     )
     (CONNECT_DATA =
       (SID = DGD01)
      (SERVER = DEDICATED)
     )
   )
 DGD01_hasunclu2 =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = hasunclu2)(PORT = 1521))
     )
     (CONNECT_DATA =
       (SID = DGD01)
       (SERVER = DEDICATED)
     )
   )
   The above two net service names must exist in the Standby hosts tnsnames.ora 
   also.
   You must also configure a listener on the standby database. If you plan to 
   manage this standby database using the Data Guard broker, you must configure 
   the listener to use the TCP/IP protocol and statically register the standby 
   database service using its SID.
7)  Start the standby instance and mount the standby database.
 oracle@hasunclu2:/export/home/oracle/temp/oracle> sqlplus "/ as sysdba"    
 SQL*Plus: Release 9.0.1.0.0 - Production on Thu Mar 14 18:00:57 2002
 (c) Copyright 2001 Oracle Corporation.  All rights reserved.
 Connected to an idle instance.
 SQL> startup nomount pfile=?/dbs/initDGD.ora
 ORACLE instance started.
 Total System Global Area   80512156 bytes
 Fixed Size                   279708 bytes
 Variable Size              71303168 bytes
 Database Buffers            8388608 bytes
 Redo Buffers                 540672 bytes
 SQL> alter database mount standby database;
 Database altered.
 SQL>
8)  Create standby redo log files, if necessary:
   Standby redo logs are necessary for the higher protection levels such as 
   Guaranteed, Instant, and Rapid.  In these protection modes LGWR from the 
   Primary host writes transactions directly to the standby redo logs.  
   This enables no data loss solutions and reduces the amount of data loss 
   in the event of failure.  Standby redo logs are not necessary if you are using 
   the delayed protection mode. 
   If you configure standby redo on the standby then you should also configure 
   standby redo logs on the primary database. Even though the standby redo logs
   are not used when the database is running in the primary role, configuring 
   the standby redo logs on the primary database is recommended in preparation 
   for an eventual switchover operation. 
   Standby redo logs must be archived before the data can be applied to the 
   standby database. The standby archival operation occurs automatically, even if 
   the standby database is not in ARCHIVELOG mode. However, the archiver process 
   must be started on the standby database. Note that the use of the archiver 
   process (ARCn) is a requirement for selection of a standby redo log.
   You must have the same number of standby redo logs on the standby as you have 
   online redo logs on production.  They must also be exactly the same size.
   The following syntax is used to create standby redo logs:
 SQL> alter database add standby logfile
   2  '/export/home/oracle/temp/oracle/data/srl_1.dbf' size 20m;
 Database altered.
 SQL> alter database add standby logfile
   2  '/export/home/oracle/temp/oracle/data/srl_2.dbf' size 20m;
 Database altered.
 SQL> alter database add standby logfile
   2  '/export/home/oracle/temp/oracle/data/srl_3.dbf' size 20m;
 Database altered.
 SQL>
9)  Manually change the names of the primary datafiles and redo logs in the 
   standby control file for all files not automatically renamed using 
   DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT as noted in step 5.  Datafile 
   names can be changed on the standby at a mounted state with the following 
   syntax:
 SQL> alter database rename file
   2  '/export/home/oracle/temp/oracle/data/sys.dbf'
    3  to
   4  '/export/home/oracle/temp/oracle/data2/sys.dbf';
10)  Stop and restart the listeners:
   On the primary database, and start the listener on the standby database so that 
   changes made to the listener.ora can be implemented.
11)  Activate parameter changes:
   Manually enable initialization parameter changes on the primary database 
   so that it can initiate archiving to the standby site.
   At runtime, the LOG_ARCHIVE_DEST_n initialization parameter can be changed 
   using ALTER SYSTEM and ALTER SESSION statements.  Activate the changes made to 
   these parameters by either bouncing the instance or activating via alter system.  
   For example:
 SQL> alter system set log_archive_dest_2='SERVICE=DGD01_hasunclu2 reopen=60';
 System altered.
12)  Verify that automatic archiving is occurring:
   On the Primary database switch a log and verfy that it has been shipped 
   properly using the v$archive_dest view.
 SQL> alter system switch logfile;
 System altered.
 SQL> select status, error from v$archive_dest where dest_id=2;
 STATUS    ERROR
 --------- -------------------------------------------------------
 VALID
 SQL>
13)  Optionally place Standby database in managed recovery:
 SQL> recover managed standby database disconnect;
 Media recovery complete.
 SQL> exit
RELATED DOCUMENTS
-----------------
Oracle9i Data Guard Concepts and Administration
Oracle9i Data Guard Broker
Oracle9i SQL Ref

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11780477/viewspace-705094/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11780477/viewspace-705094/