请问哪位能提供rac+dataguard有文档吗？

biti_rainy · 发表于 2005-6-28 12:07

没什么不一样的

raw device ,使用 dd /rman copy
或者rman backup 都可以啊

bpmfhu · 发表于 2005-6-28 13:56

ok,多谢大师的指点

wangjw2000 · 发表于 2005-6-30 09:49

PURPOSE
-------
This document will provide the reader with step-by-step instructions on how to create a Data Guard Logical Standby environment from a RAC Primary using a Cold Backup. For additional explanation or information on any of these steps, please see the references listed at the end of this document.
SCOPE & APPLICATION
-------------------
For Customers and Support Analysts to have a quick step by step that has been validated to create the Logical Standby from a RAC Primary.
Creating a Data Guard Logical Standby Configuration from A RAC Primary in Oracle 9i
=====================================================================
Test Environment:
-----------------
   This note followed testing on 2 Nodes of a Fujitsu PrimeCluster running Solaris 5.8 and Oracle 9.2.0.4.
   This Note assumes use of Server Parameter files (spfile) for the Primary Database.
   For Documentation compliance the primary nodes will be called Chicago1 and Chicago2, and the Standby will be on Boston.
The primary database name will be sales (instances sales1 and sales2), and the logical will be reports.
The Logical Standby Database exists on the same node as the Primary for this example, so the Logical database name has to be changed from sales to reports.
The Configuration
-----------------
1) Ensure the Primary database is in ARCHIVELOG mode and automatic archiving enabled:
SQL> archive log list
      Database log mode             Archive Mode
      Automatic archival          Enabled
      Archive destination          /disk1/oradata/sales/arch
      Oldest online log sequence    2
      Next log sequence to archive 3
      Current log sequence          3

      If the Database is not in archive log mode then you will have to
      a) SQL> alter system set cluster_database=false scope=spfile
      b) shutdown both instances
      c) Startup mount one instance
      d) SQL> alter database archivelog;
      e) SQL> alter system set cluster_database=true scope=spfile
      f) Shutdown that instance
      g) restart both instances
      If Automatic Archiving is not enabled then
      SQL> alter system set log_archive_start=true
2) Force Logging and check Datatype Support:
a) Force logging to ensure all operations generate redo:
      SQL> ALTER DATABASE FORCE LOGGING;
   This statement can take a considerable amount of time to complete,because it waits for all unlogged direct write I/O to finish.  It is only required to be run on one instance.
b) Determine Support for Datatypes and Storage Attributes for Tables:
   Check Dataguard Concepts Guide - Section 4.1.4 for a list of supported attributes.
   The following query will show objects with unsupported types.
      SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED;
   Use the rows generated to refine the query.  Assuming CUSTOMERS table had unsupported types:
      SQL> SELECT COLUMN_NAME, DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED
         WHERE OWNER=?OE? AND TABLE_NAME = ?CUSTOMERS?;
   If the primary database contains unsupported tables, log apply services automatically exclude these tables when applying redo logs to the logical standby database.
c) Ensure Supplemental logging is applied on the Primary Database:
   Supplemental logging must be enabled on the primary database before you  create the logical standby database. Because Oracle only logs the columns that were modified, this is not always sufficient to uniquely identify the row that changed and additional (supplemental) information must be put into the redo log. The supplemental information that is added to the redo logs helps log apply services to correctly identify and maintain tables in the logical standby database.
   Use this Query to determine if supplemental logging is enabled:
      SQL> SELECT SUPPLEMENTAL_LOG_DATA_PK AS PK_LOG,
         SUPPLEMENTAL_LOG_DATA_UI AS UI_LOG
         FROM V$DATABASE;
            PK_LOG UI_LOG
            ------ ------
               NO    NO
   The following commands will turn supplemental logging on:
      SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
         (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
      SQL> ALTER SYSTEM SWITCH LOGFILE; #  Do this on all running instances
   We switch logfiles to ensure we don't have logs with a mix of supplemental and non-supplemental logged transactions.
3) Create an Alternate Tablespace
If you expect to perform switchover operations between the primary database and a logical standby database, you should create an alternate tablespace in the primary database and move the logical standby system tables to that separate tablespace.
SQL> CREATE TABLESPACE logmnrts DATAFILE '/disk1/oradata/sales/logmnrts.dbf?
      SIZE 25M AUTOEXTEND ON MAXSIZE UNLIMITED;
SQL> EXECUTE DBMS_LOGMNR_D.SET_TABLESPACE(?logmnrts?);
4) Create a backup of the Primary database:
Creating a logical standby using a Hot backup is not covered in this document.
To create the standby using a cold backup do the following:
SQL> column name format A70;
      SQL> select name from v$datafile;
      NAME
      ---------------------------------------------------------------------
      /disk1/oradata/sales/system01.dbf
      /disk1/oradata/sales/undotbs01.dbf
      /disk1/oradata/sales/indx01.dbf
      /disk1/oradata/sales/tools01.dbf
      /disk1/oradata/sales/undotbs02.dbf
      /disk1/oradata/sales/users01.dbf
      /disk1/oradata/sales/logmnrts.dbf
      SQL> column member format A70;
      SQL> select member from v$logfile;
      MEMBER
      ---------------------------------------------------------------------
      /disk1/oradata/sales/redo1_1.log
      /disk1/oradata/sales/redo1_2.log
      /disk1/oradata/sales/redo2_1.log
      /disk1/oradata/sales/redo2_2.log
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.  Once complete startup mount just one instance:
SQL> startup mount
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.
5) Connect to the mounted primary instance and create the standby control file:
SQL> alter database backup controlfile to '/disk1/oradata/sales/logstandby.ctl';
Database altered.
6) Build the LogMiner Dictionary - in a restricted session
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
System altered.
SQL> ALTER DATABASE OPEN;
Database altered.
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
PL/SQL procedure successfully completed.
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
System altered.
You can now open the other primary instances.
7) Identify the latest archived redo log on all instances.  Run the following on all instances:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
      System altered.
SQL> SELECT NAME FROM V$ARCHIVED_LOG
         WHERE FIRST_CHANGE# <= (SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG
         WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO')
         AND NEXT_CHANGE# >= (SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG
         WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO') ;
NAME
-----------------------------------------------------------
/disk1/oradata/sales/arch/archive1_15.dbf
/disk1/oradata/sales/arch/archive2_15.dbf
/disk1/oradata/sales/arch/archive1_16.dbf
/disk1/oradata/sales/arch/archive2_16.dbf
SQL> SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG
          WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST= 'NO';
MAX(FIRST_CHANGE#)
------------------
            252811
8) Prepare Primary Server parameter file for use with logical Standby
      SQL> alter system set
         log_archive_dest_1='LOCATION=/disk1/oradata/sales/arch/'
         scope=both;
      SQL> alter system set
         log_archive_dest_2='SERVICE=Boston_Reports LGWR ASYNC REOPEN=10'
         scope=both;
      SQL> alter system set log_archive_dest_state_2=defer scope=both;
      SQL> alter system set
         standby_archive_dest='/disk1/oradata/sales/stdby_dest/'
         scope=both;
      SQL> alter system set standby_file_management='auto' scope=both;
Note: We cannot set the convert parameters for Logical Standby so we must be careful when adding new datafiles and not use REUSE, as when this command reaches the Logical it may overwrite the primary file.  See
      Note 246937.1 for handling alter tablespace add datafile DDL when it reaches the Logical.
We will create the text parameter file initially from our Primary's spfile  so that it can easily be editted and then it can be converted back to an spfile later on the logical:
   SQL> CREATE PFILE='/tmp/initbostonr.ora' FROM SPFILE;
File created.

9) Copy backed up Primary files to the Standby host:
Copy the backup datafiles, standby controlfile, all available archived redo logs written during/after the backup, and online redo logs from the primary site to the standby site. A copy of the online redo logs is necessary to facilitate faster switchover, though is not mandatory.
The standby controlfile should be copied to the file names as specified in the Standby databases control_files parameter in the init.ora.
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 then you must manually rename the primary datafiles in the standby control file (later step).
10) Adjust the initialisation parameters for the Standby instances:
Edit the pfile you copied from/created on the Primary host (/tmp/initbostonr.ora):
Showing only parameters that may need to change:
Note: If you are only single instance standby set cluster_database=false  and remove instance specific parameters
   such as
      sales1.instance_name='sales1'.
*.background_dump_dest='/u01/app/oracle/admin/reports/bdump'
*.compatible='9.2.0.0.0'
*.control_files='/ocfsdisk3/oracle/logical/DGRAC/control01.ctl'
*.core_dump_dest='/u01/app/oracle/admin/reports/cdump'
*.log_archive_dest_1='LOCATION=/ocfsdisk3/oracle/logical/oradata/DGRAC/archive'
*.user_dump_dest='/u01/app/oracle/admin/reports/udump'
      *.undo_tablespace=UNDOTBS1
*.parallel_max_servers=9  # minimum value
      *.standby_archive_dest='/disk1/oradata/reports/stdby_dest'
      *.lock_name_space=bostonr
*.standby_file_management=auto
      Note: Parallel_max_servers must be set to 9 or above as the logical apply uses PQ Slaves.  The lock_name_space has to be set to allow us to bring this instance up at the same time as the primary on this node.
      Also for Logical Standby the standby_archive_destination must be different to the default archive destination as a Logical Standby has it's own redo as well as the redo coming in from the primary, and there is a chance of a clash in logfiles.
      Finally ensure all the required directories are created for logical trace files, log files etc as set above.
11) Configure networking components:
On the Primary host create net service names that the Primary instance can use to connect to the Standby instances.  On the Primary host create net service names that Standby instances, when running on the Primary hosts,can use to connect to the Primary instances, when running on the Standby host.  It is a good idea here to simply reference all instances within all tnsnames.ora files.  Note as Chicago is a RAC instance we can provide a second address to connect to for fal gap resolution.
      Chicago_Sales =
      (DESCRIPTION =
         (ADDRESS_LIST =
            (ADDRESS = (PROTOCOL = TCP)(HOST = chicago1)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = chicago2)(PORT = 1521))
         )
         (CONNECT_DATA =
            (SERVICE = SALES) #Sales - Primary Database
            (SERVER = DEDICATED)
         )
      )
      Boston_Reports =
      (DESCRIPTION =
         (ADDRESS_LIST =
            (ADDRESS = (PROTOCOL = TCP)(HOST = boston)(PORT = 1521))
         )
         (CONNECT_DATA =
            (SERVICE = BOSTONR) #Reports - Logical Standby
            (SERVER = DEDICATED)
         )
      )
Dead Connection detection should also be setup to ensure a network failure does not cause excessive hanging.  Set sqlnet_expire_time in your sqlnet.ora file.
      SQLNET_EXPIRE_TIME=2
You must also configure listeners on the Primary and Standby database nodes.
12) Create a password file for the standby instance ..
orapwd file=$ORACLE_HOME/dbs/orapwbonstonr password=<SYS Password>
13) Start Standby Database instance
oracle@rcbstint3>sqlplus '/ as sysdba'
SQL*Plus: Release 9.2.0.4.0 - Production on Mon Sep 22 16:34:31 2003
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to an idle instance.
SQL> startup mount pfile='/tmp/initbostonr.ora'
ORACLE instance started.
Total System Global Area  269554828 bytes
Fixed Size                451724 bytes
Variable Size          234881024 bytes
Database Buffers          33554432 bytes
Redo Buffers                667648 bytes
Database mounted.
14) Rename datafiles and log files from primary to logical name - if required.
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/system01.dbf'
TO '/disk1/oradata/sales/reports.dbf';
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/undotbs01.dbf'
TO '/disk1/oradata/sales/reports.dbf';
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/indx01.dbf'
TO '/disk1/oradata/sales/reports.dbf';
.......

ALTER DATABASE RENAME FILE '/disk1/oradata/sales/redo1_1.log' TO '/disk1/oradata/reports/redo1_1.log';
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/redo1_2.log' TO '/disk1/oradata/reports/redo1_2.log';
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/redo2_1.log' TO '/disk1/oradata/reports/redo2_1.log';
ALTER DATABASE RENAME FILE '/disk1/oradata/sales/redo2_2.log' TO '/disk1/oradata/reports/redo2_2.log';
15) Turn on the dataguard guard on the logical Standby to protect local update on all objects and open resetlogs:
SQL> ALTER DATABASE GUARD ALL;
      Database altered.
      SQL> ALTER DATABASE OPEN RESETLOGS;
      Database altered.
16) Rename the Database..
Changing the name prevents any interaction between this copy of the primary database and the original primary database.  Ensure 2 restarts prior to doing this:
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT PFILE='/tmp/initbostonr.ora'
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP MOUNT PFILE='/tmp/initbostonr.ora'
SQL> exit
nid target=sys/<SYS Password>@Chicago_Sales dbname=reports
DBNEWID: Release 9.2.0.4.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.
Connected to database DGRAC (DBID=3832537865)
Control Files in database:
      /disk1/oradata/reports/control01.ctl
Change database ID and database name sales to reports? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 3832537865 to 449492431
Changing database name from sales to reports
   Control File /disk1/oradata/reports/control01.ctl - modified
   Datafile /disk1/oradata/reports/system01.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/undotbs01.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/tools01.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/indx01.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/undotbs02.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/users01.dbf - dbid changed, wrote new name
   Datafile /disk1/oradata/reports/logmnrts.dbf - dbid changed, wrote new name
   Control File /disk1/oradata/reports/control01.ctl - dbid changed, wrote new name
Database name changed to reports.
Modify parameter file and generate a new password file before restarting.
Database ID for database reports changed to 449492431.
All previous backups and archived redo logs for this database are unusable.
Shut down database and open with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID - Completed succesfully.
NOTE: Ensure you edit the dbname in pfile and recreate password file.
      NOTE2: You can now remove lock_name_space from the init file..
17) Create spfile from pfile previously used, and open database resetlogs.
SQL> SHUTDOWN IMMEDIATE
SQL> create spfile from pfile='/tmp/initbostonr.ora';
SQL> STARTUP MOUNT
SQL> ALTER DATABASE OPEN RESETLOGS
18) Create a local tempfile
Determine if one exists ..
SQL> SELECT * FROM V$TEMPFILE;
      FILE# CREATION_CHANGE# CREATION_       TS#    RFILE# STATUS  ENABLED
---------- ---------------- --------- ---------- ---------- ------- ----------
      BYTES    BLOCKS CREATE_BYTES BLOCK_SIZE
---------- ---------- ------------ ----------
NAME
--------------------------------------------------------------------------------
         1             0                   2       1 ONLINE  READ WRITE
   41943040    5120    41943040    8192
/disk1/oradata/sales/temp01.dbf
If one exists ( row returned above ) drop it and create a new one
SQL> ALTER DATABASE TEMPFILE '/disk1/oradata/sales/temp01.dbf' DROP;
Database altered.
SQL> ALTER TABLESPACE TEMP ADD TEMPFILE
      '/disk1/oradata/reports/temp01.dbf' SIZE 40M REUSE;
Tablespace altered.
19) Register the log files that were determined in step 7.
Note: These archive files were copied into the remote archive directory (standby_archive_dest).
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
      '/disk1/oradata/reports/stdby_dest/archive1_15.dbf';
Database altered.
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
      '/disk1/oradata/reports/stdby_dest/archive1_16.dbf';
Database altered.
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
      '/disk1/oradata/reports/stdby_dest/archive2_15.dbf';
Database altered.
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE
      '/disk1/oradata/reports/stdby_dest/archive2_16.dbf';
Database altered.
20) Start Logical Apply to build dictionary.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL;
21) Start Shipping redo from the Primary Instance:
On the Primary Instance:
SQL> ALTER SYSTEM SET log_archive_dest_state_2=enable scope=both;
SQL> ALTER SYSTEM SWITCH LOGFILE;
         System altered.
At this point you will be able to check the alert.log of the primary instance to confirm that the redo logs are being shipped correctly to the standby.
22) Confirm redo is being applied on the Logical Standby Check to see if the logs are registered on the Standby
      SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';
      SQL> COLUMN DICT_BEGIN FORMAT A10
      SQL> COLUMN DICT_END FORMAT A8
      SQL> SELECT THREAD#,SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END
         FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
   THREAD#  SEQUENCE# FIRST_TIME       NEXT_TIME       DICT_BEGIN DICT_END
---------- ---------- ------------------ ------------------ ---------- --------
         1       7 22-SEP-03 14:30:22 22-SEP-03 16:31:01 NO       NO
         2       7 22-SEP-03 16:30:59 22-SEP-03 16:31:20 NO       NO
         1       8 22-SEP-03 16:31:01 22-SEP-03 16:31:26 YES       YES
         1       9 22-SEP-03 16:31:26 22-SEP-03 16:31:45 NO       NO
         1       10 22-SEP-03 16:31:45 23-SEP-03 10:43:04 NO       NO
         1       11 23-SEP-03 10:43:04 23-SEP-03 10:49:52 NO       NO
         2       11 22-SEP-03 16:31:52 23-SEP-03 10:43:08 NO       NO
         1       12 23-SEP-03 10:49:52 23-SEP-03 10:50:42 NO       NO
         2       12 23-SEP-03 10:43:08 23-SEP-03 10:49:58 NO       NO
         2       13 23-SEP-03 10:49:58 23-SEP-03 10:50:48 NO       NO
10 rows selected.
Switch logs a couple of times on the Primary and check again.
      SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END
         FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
......... as above and
         2       12 23-SEP-03 10:43:08 23-SEP-03 10:49:58 NO       NO
         1       13 23-SEP-03 10:50:42 23-SEP-03 10:55:24 NO       NO
         2       13 23-SEP-03 10:49:58 23-SEP-03 10:50:48 NO       NO
   THREAD#  SEQUENCE# FIRST_TIME       NEXT_TIME       DICT_BEGIN DICT_END
---------- ---------- ------------------ ------------------ ---------- -
         1       14 23-SEP-03 10:55:24 23-SEP-03 10:55:46 NO       NO
12 rows selected.
By checking the files on the standby database, archiving a few redo logs,and then checking the standby database again, you can see that the new redo logs were registered.These logs are now available for log apply services to begin applying them.
Check to see if the apply processes are working:
      SQL> COLUMN NAME FORMAT A30 a
      SQL> COLUMN VALUE FORMAT A30
      SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
      NAME                         VALUE
      ------------------------------ ------------------------------
      coordinator state             APPLYING
A VALUE of Initializing would have shown that log apply services are preparing to begin SQL apply.  This INITIALIZING can take a long time the first timme you start SQL Apply.
If no rows are returned then then SQL Apply is not running and you will need to investigate.
Knowing the state of the coordinator process is of particular importance because it is the LSP background process that instructs all of the other logical standby processes.
Finally Check V$LOGSTDBY and V$LOGSTDBY_PROGRESS to check Current Activity.
      SQL> COLUMN STATUS FORMAT A50
      SQL> COLUMN TYPE FORMAT A12
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
      TYPE          HIGH_SCN STATUS
------------ ---------- --------------------------------------------------
COORDINATOR          ORA-16116: no work available
READER                ORA-16117: processing
BUILDER       171148 ORA-16116: no work available
PREPARER       171147 ORA-16116: no work available
ANALYZER       171147 ORA-16116: no work available
APPLIER                ORA-16116: no work available
APPLIER                ORA-16116: no work available
APPLIER                ORA-16116: no work available
APPLIER                ORA-16116: no work available
APPLIER                ORA-16116: no work available
      In this case no new logs are coming in to be applied.
      SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
      APPLIED_SCN NEWEST_SCN
----------- ----------
      171147    226096
      This example shows us the latest recieved and applied SCN's, which shows a gap.
Looking back we can see an archive gap with Thread 2 missing log's 8,9 and 10.
      To Fix Archive Gaps please refer to:
      Note:232649.1 Data Guard Gap Detection and Resolution
      For RAC primary databases:  Ensure you check all threads of redo for a gap.

juniper · 发表于 2005-7-7 09:42

要做逻辑的还是物理的standby?

bpmfhu · 发表于 2005-7-7 09:52

物理的

chenhai20010201 · 发表于 2007-9-18 10:24

Both Data Guard Redo Apply (physical standby database) and Data Guard SQL Apply (logical standby database) can be used with RAC.
http://www.oracle.com/technology ... s/DataGuardRAC.html

chenhai20010201 · 发表于 2007-9-18 11:00

MAA / Data Guard 10g Setup Guide –
Creating a Single Instance Physical Standby for a RAC Primary
Oracle Maximum Availability Architecture White Paper
April 2006
Maximum
Availability
Architecture
Oracle Best Practices For High Availability
Maximum Availability Architecture
MAA / Data Guard 10g Setup Guide – Creating a Single Instance Physical Standby for a RAC Primary
Overview.............................................................................................................2
Task 1: Gather Files and Perform Back Up..................................................3
Task 2: Configure Oracle Net SERVICES on the Standby........................3
Task 3: Create the Physical Standby Instance and Database......................4
Task 4: Configure The Primary Database For Data Guard........................7
Task 5: Verify Data Guard Configuration.....................................................9
References..........................................................................................................9
Creating a Single Instance Physical Standby for a RAC Primary Page 1
Maximum Availability Architecture
MAA / Data Guard 10g Setup Guide – Creating a Single Instance Physical Standby for a RAC Primary
OVERVIEW
Oracle Maximum Availability Architecture (MAA) [1] is Oracle's best practices blueprint based on proven Oracle high-availability technologies and recommendations. The goal of MAA is to remove the complexity in designing the optimal high-availability architecture.
Published as part of the MAA series of white papers, this paper focuses on creating a single instance physical standby database for a RAC primary database. This document assumes that there is an existing RAC database and you want to implement Data Guard by adding a physical standby database to the configuration. The end configuration for this document is a RAC primary database with a single-instance physical standby database. The steps outlined in this document use SQL*Plus, apply to both Oracle Database 10g Release 1 and Oracle Database 10g Release 2, and they assume using ASM/OMF, and that the software and ASM instance on the standby host have already been installed/created. The example used in this document has the database unique name of the RAC database as CHICAGO. The instance names of the two RAC instances are CHICAGO1 (on node chicago_host1) and CHICAGO2 (on node chicago_host2). The database unique name of the single-instance physical standby database is BOSTON (on node boston_host1).
This document includes the following tasks:
• Task 1: Gather Files and Perform Back Up
• Task 2: Configure Oracle Net on the Physical Standby
• Task 3: Create the Physical Standby Instance and Database
• Task 4: Configure the Primary Database for Data Guard
• Task 5: Verify Data Guard Configuration
This document assumes that the following conditions are met:
• The primary RAC database is using ASM.
• The standby host has an existing Oracle software installation.
Creating a Single Instance Physical Standby for a RAC Primary Page 2
Maximum Availability Architecture
• The physical standby database storage uses an existing ASM instance.
• The primary and standby databases are using a flash recovery area.
• Oracle Managed Files (OMF) is used for all storage.
TASK 1: GATHER FILES AND PERFORM BACK UP
1. On the primary node, create a staging directory. For example:
[oracle@chicago_host1 oracle]$ mkdir -p /opt/oracle/stage
2. Create the same exact path on the standby host:
[oracle@boston_host1 oracle]$ mkdir -p /opt/oracle/stage
3. On the primary node, connect to the primary database and create a PFILE from the SPFILE in the staging directory. For example:
SQL> CREATE PFILE='/opt/oracle/stage/initCHICAGO.ora' FROM SPFILE;
4. On the primary node, perform an RMAN backup of the primary database that places the backup pieces into the staging directory. For example:
[oracle@chicago_host1 stage]$ rman target /
RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' DATABASE PLUS ARCHIVELOG;
RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' CURRENT CONTROLFILE FOR STANDBY;
5. Place a copy of the listener.ora, tnsnames.ora, and sqlnet.ora files into the staging directory. For example:
[oracle@chicago_host1 oracle]$ cp $ORACLE_HOME/network/admin/*.ora /opt/oracle/stage
6. Copy the contents of the staging directory on the RAC node to the staging directory on the standby host. For example:
[oracle@chicago_host1 oracle]$ scp /opt/oracle/stage/* \
oracle@boston_host1:/opt/oracle/stage
TASK 2: CONFIGURE ORACLE NET SERVICES ON THE STANDBY
1. Copy the listener.ora, tnsnames.ora, and sqlnet.ora files from the staging directory on the standby host to the $ORACLE_HOME/network/admin directory on the standby host.
2. Modify the listener.ora file on the standby host to contain the hostname of the standby host.
3. Modify the tnsnames.ora file on each node, including the primary RAC nodes and standby host, to contain all primary and standby net service
Creating a Single Instance Physical Standby for a RAC Primary Page 3
Maximum Availability Architecture
names. In this example, each tnsnames.ora file should contain all three of the net service names in the following table:
Example Entries in the tnsnames.ora Files
Primary Net Service Names
Standby Net Service Name
CHICAGO1_SERV =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = chicago_host1vip)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = CHICAGO)
(INSTANCE_NAME = CHICAGO1)
)
)
BOSTON =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = boston_host1)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = BOSTON)
)
)
CHICAGO2_SERV =
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = chicago_host2vip)
(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = CHICAGO)
(INSTANCE_NAME = CHICAGO2)
)
)
TASK 3: CREATE THE PHYSICAL STANDBY INSTANCE AND DATABASE
1. To enable secure transmission of redo data, make sure the primary and physical standby databases use a password file, and make sure the password for the SYS user is identical on every system. For example:
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwBOSTON password=oracle
The naming and location of the password file varies on different platforms. See “Creating and Maintaining a Password File” in the Oracle Database Administrator’s Guide for more information.
2. Copy and rename the primary database PFILE from the staging area on the standby host to the $ORACLE_HOME/dbs directory on the standby host. For example:
[oracle@boston_host1 stage]$ cp initCHICAGO.ora $ORACLE_HOME/dbs/initBOSTON.ora
3. Modify the standby initialization parameter file copied from the primary node to remove RAC parameters and to include Data Guard parameters as illustrated in the following table:
Creating a Single Instance Physical Standby for a RAC Primary Page 4
Maximum Availability Architecture
Initialization Parameter Modifications
Parameter
Category
Before
After
RAC Parameters
*.cluster_database=true
*.db_unique_name=CHICAGO
CHICAGO1.instance_name=CHICAGO1
CHICAGO2.instance_name=CHICAGO2
CHICAGO1.instance_number=1
CHICAGO2.instance_number=2
CHICAGO1.thread=1
CHICAGO2.thread=2
CHICAGO1.undo_tablespace=UNDOTBS1
CHICAGO2.undo_tablespace=UNDOTBS2
*.remote_listener=LISTENERS_CHICAGO
CHICAGO1.LOCAL_LISTENER=LISTENER_CHICAGO_HOST1
CHICAGO2.LOCAL_LISTENER=LISTENER_CHICAGO_HOST2
*.cluster_database=false
*.db_unique_name=BOSTON
*.instance_name=BOSTON
*.thread=1
*.undo_tablespace=UNDOTBS1
Data Guard Parameters
*.log_archive_config='dg_config=
(BOSTON,CHICAGO)'
*.log_archive_dest_2='service=CHICAGO1_SERV
valid_for=(online_logfiles,primary_role)
db_unique_name=CHICAGO'
*.db_file_name_convert='+DATA/CHICAGO/',
'+DATA/BOSTON/','+RECOVERY/CHICAGO',
'+RECOVERY/BOSTON'
*.log_file_name_convert='+DATA/CHICAGO/',
'+DATA/BOSTON/','+RECOVERY/CHICAGO',
'+RECOVERY/BOSTON'
*.standby_file_management=auto
*.fal_server='CHICAGO1_SERV','CHICAGO2_SERV'
*.fal_client='BOSTON'
*.service_names='BOSTON'
Other parameters
*.background_dump_dest=
/opt/oracle/admin/CHICAGO/bdump
*.core_dump_dest=
/opt/oracle/admin/CHICAGO/cdump
*.user_dump_dest=
/opt/oracle/admin/CHICAGO/udump
*.audit_file_dest=
/opt/oracle/admin/CHICAGO/adump
*.db_recovery_dest=’+RECOVERY’
*.log_archive_dest_1 =
'LOCATION=+DATA/CHICAGO/'
*.dispatchers=CHICAGOXDB
*.background_dump_dest=
/opt/oracle/admin/BOSTON/bdump
*.core_dump_dest=
/opt/oracle/admin/BOSTON/cdump
*.user_dump_dest=
/opt/oracle/admin/BOSTON/udump
*.audit_file_dest=
/opt/oracle/admin/BOSTON/adump
*.db_recovery_dest=’+RECOVERY’
*.log_archive_dest_1=
'LOCATION=USE_DB_RECOVERY_FILE_DEST'
*.dispatchers=BOSTONXDB
For more information about these initialization parameters, see Chapter 13, “Initialization Parameters” in Oracle Data Guard Concepts and Administration manual.
If you are using an SPFILE instead of an initialization parameter file, then see the “Managing Initialization Parameters Using a Server Parameter File” Creating a Single Instance Physical Standby for a RAC Primary Page 5
Maximum Availability Architecture
section in the Oracle Database Administrator’s Guide for instructions on managing an SPFILE.
4. Connect to the ASM instance on the standby host, and create a directory within the DATA disk group that has the same name as the DB_UNIQUE_NAME of the physical standby database. For example:
SQL> ALTER DISKGROUP data ADD DIRECTORY '+DATA/BOSTON';
5. Connect to the physical standby database, with the standby in the IDLE state, and create an SPFILE in the standby DATA disk group:
SQL> CREATE SPFILE='+DATA/BOSTON/spfileBOSTON.ora' FROM PFILE='?/dbs/initBOSTON.ora';
6. In the $ORACLE_HOME/dbs directory on the standby host, create a PFILE that is named initoracle_sid.ora that contains a pointer to the SPFILE. For example:
[oracle@boston_host1 oracle]$ cd $ORACLE_HOME/dbs
[oracle@boston_host1 dbs]$ echo "SPFILE='+DATA/BOSTON/spfileBOSTON.ora'" > initBOSTON.ora
7. Create the dump directories on the standby host as referenced in the standby initialization parameter file. For example:
[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/bdump
[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/cdump
[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/udump
[oracle@boston_host1 oracle]$ mkdir -p $ORACLE_BASE/admin/BOSTON/adump
8. After setting up the appropriate environment variables on the standby host, such as ORACLE_SID, ORACLE_HOME, and PATH, start the physical standby database instance without mounting the control file.
SQL> STARTUP NOMOUNT
9. From the standby host, duplicate the primary database as a standby into the ASM disk group. For example:
$ rman target sys/oracle@CHICAGO1_SERV auxiliary /
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;
10. Connect to the physical standby database, and create the standby redo logs to support the standby role. The standby redo logs must be the same size as the primary database online logs. The recommended number of standby redo logs is:
(maximum # of logfiles +1) * maximum # of threads
This example uses two online log files for each thread. Thus, the number of standby redo logs should be (2 + 1) * 2 = 6. That is, one more standby redo log file for each thread.
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
GROUP 5 SIZE 10M,
Creating a Single Instance Physical Standby for a RAC Primary Page 6
Maximum Availability Architecture
GROUP 6 SIZE 10M,
GROUP 7 SIZE 10M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2
GROUP 8 SIZE 10M,
GROUP 9 SIZE 10M,
GROUP 10 SIZE 10M;
These statements create two standby log members for each group, and each member is 10MB in size. One member is created in the directory specified by the DB_CREATE_FILE_DEST initialization parameter, and the other member is created in the directory specified by DB_RECOVERY_FILE_DEST initialization parameter. Because this example assumes that there are two redo log groups in two threads, the next group is group five.
You can check the number and group numbers of the redo logs by querying the V$LOG view:
SQL> SELECT * FROM V$LOG;
You can check the results of the previous statements by querying the V$STANDBY_LOG view:
SQL> SELECT * FROM V$STANDBY_LOG;
You can also see the members created by querying the V$LOGFILE view:
SQL> SELECT * FROM V$LOGFILE;
See the “Configure a Standby Redo Log” section in Oracle Data Guard Concepts and Administration manual for more information.
11. Start managed recovery and real-time apply on the standby database:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
TASK 4: CONFIGURE THE PRIMARY DATABASE FOR DATA GUARD
1. Configure the primary database initialization parameters to support both the primary and standby roles.
*.log_archive_config='dg_config=(BOSTON,CHICAGO)'
*.log_archive_dest_2='service=BOSTON
valid_for=(online_logfiles,primary_role)
db_unique_name=BOSTON'
*.db_file_name_convert='+DATA/BOSTON/',’+DATA/CHICAGO/', ’+RECOVERY/BOSTON’,’+RECOVERY/CHICAGO’
*.log_file_name_convert='+DATA/BOSTON/',’+DATA/CHICAGO/', ’+RECOVERY/BOSTON’,’+RECOVERY/CHICAGO’
*.standby_file_management=auto
*.fal_server='BOSTON'
CHICAGO1.fal_client='CHICAGO1_SERV'
CHICAGO2.fal_client='CHICAGO2_SERV'
*.service_names=CHICAGO
Creating a Single Instance Physical Standby for a RAC Primary Page 7
Maximum Availability Architecture
For more information about these initialization parameters, see Chapter 13, “Initialization Parameters” in the Oracle Data Guard Concepts and Administration manual.
If you are using an SPFILE instead of an initialization parameter file, then see the “Managing Initialization Parameters Using a Server Parameter File” section in the Oracle Database Administrator’s Guide for instructions on managing an SPFILE.
Note that all the parameters listed above can be dynamically modified with the exception of the standby role parameters log_file_name_convert and db_file_name_convert. It is recommended to set the parameters with “scope=spfile” so that they can be put into effect upon the next role change.
2. Create standby redo logs on the primary database to support the standby role. The standby redo logs are the same size as the primary database online logs. The recommended number of standby redo logs is one more than the number of online redo logs for each thread. Because this example has two online redo logs for each thread, three standby redo logs are required for each thread.
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
GROUP 5 SIZE 10M,
GROUP 6 SIZE 10M,
GROUP 7 SIZE 10M;
SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2
GROUP 8 SIZE 10M,
GROUP 9 SIZE 10M,
GROUP 10 SIZE 10M;
These statements create two standby log members for each group, and each member is 10MB in size. One member is created in the directory specified by the DB_CREATE_FILE_DEST initialization parameter, and the other member is created in the directory specified by DB_RECOVERY_FILE_DEST initialization parameter. Because this example assumes that there are two redo log groups in two threads, the next group is group five.
You can check the number and group numbers of the redo logs by querying the V$LOG view:
SQL> SELECT * FROM V$LOG;
You can check the results of the previous statements by querying the V$STANDBY_LOG view:
SQL> SELECT * FROM V$STANDBY_LOG;
You can also see the members created by querying the V$LOGFILE view:
SQL> SELECT * FROM V$LOGFILE;
See the “Configure a Standby Redo Log” section in Oracle Data Guard Concepts and Administration manual for more information.
Creating a Single Instance Physical Standby for a RAC Primary Page 8
Maximum Availability Architecture
TASK 5: VERIFY DATA GUARD CONFIGURATION
1. On the physical 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
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
2. On the primary database, issue the following SQL statement to force a log switch and archive the current online redo log file group:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
3. On the physical standby database, query the V$ARCHIVED_LOG view to verify that the redo data was received and archived on the standby database:
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
REFERENCES
1. Oracle Maximum Availability Architecture website on OTN http://www.oracle.com/technology ... lity/htdocs/maa.htm
Creating a Single Instance Physical Standby for a RAC Primary Page 9
MAA / Data Guard 10g Setup Guide – Creating a Single Instance Physical Standby for a RAC Primary
April 2006
Author: Mike Smith
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2006, Oracle. All rights reserved.
This document is provided for information purposes only and the contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

请问哪位能提供rac+dataguard有文档吗？

english doc from oracle gov

浏览过的版块