请教LOG_ARCHIVE_CONFIG的含义？

etl2007

文档上这样解释 见  http://space.itpub.net/519536/viewspace-578352


2.DB_UNIQUE_NAME，对应数据库的实例名，每一个数据库需要指定一个唯一的名字
primary端：
*.DB_UNIQUE_NAME=ora10g
standby端：
*.db_unique_name=ora10gdg

3.LOG_ARCHIVE_CONFIG，该参数通过DG_CONFIG 属性罗列同一个Data Guard 中所有DB_UNIQUE_NAME(含primary db 及standby db)，以逗号分隔
primary端和standby端相同
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(ora10g,ora10gdg)'
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(ora10g,ora10gdg)'


我的疑问是我不是很理解为何要有这么一个参数呢？这个参数配置的目的是什么呢？我找了很多文档都没有讲
我不配会怎么样呢？
网上有篇文章是不配这个参数可能导致的影响 http://yangtingkun.itpub.net/post/468/511762

但我依然不是很理解。斑竹能讲述一下这个参数的目的吗？

回忆未来

 For use by Customers and Support analysts in understanding and using the 
    new features.

    Dataguard Configuration:  LOG_ARCHIVE_CONFIG and VALID_FOR in Oracle 10G 
    ------------------------------------------------------------------------
    The Data Guard Configuration feature allows the user to optionally identify 
    the current database as well as all the other databases in the configuration
    using the new LOG_ARCHIVE_CONFIG parameter.  When used, the 
    LOG_ARCHIVE_CONFIG parameter defines the list of databases in this 
    configuration.  Log transport will not be allowed to any database not on 
    the list .  

    Each database in the configuration will have a db_unique_name and the 
    configuration can include 1 or more db_unique_names.
    To set this up you will assign each database a unique name, example:
db_unique_name = 'Chicago_Sales'  # Note this parameter is not dynamic
    You will then add all the databases you want to be in this configuration, 
    example:
log_archive_config='DG_CONFIG=(Chicago_Sales,Denver_Sales)'
  In this Simple Configuration we will only allow log transport between these 
    2 databases, uniquely identified as: Chicago_Sales and Denver_Sales
    Following this you can now specify the db_unique_name for each log archive 
    destination. This will be used along with the VALID_FOR parameter to 
    determine what logs to transport dependent on the database's current ROLE
    in the configuration.  The advantage of this feature is that we can 
    switchover without having to change parameters to defer/enable destinations.
    Is should be noted that although the DG_CONFIG attribute is an optional 
    attribute of the optional LOG_ARCHIVE_CONFIG initialization parameter, 
    it must be set to enable the dynamic addition of a standby database to a 
    Data Guard configuration that has a Real Application Clusters primary 
    database running in either maximum protection or maximum availability mode. 
    How does the VALID_FOR Parameter Work ?
    ---------------------------------------
    The VALID_FOR Parameter states that a specific log transport destination is 
    VALID_FOR only when this database is in a certain ROLE (STANDBY/PRIMARY).

    In this way you can set up a transport destination that will only be 
    enabled when this db_unique_name is in a specific ROLE.

    The default setting is ..

        VALID_FOR=(ALL_LOGFILES, ALL_ROLES)
    That setting will state that the log_archive_dest_n is valid for online 
    redo log and standby redo log archival. It is also Valid if the database 
    is currently in PRIMARY or STANDBY ROLE.
        More simply put: always archive to this destination.

    The full syntax for a local archive destination would be like this..
        log_archive_dest_1='LOCATION=/u01/Sales/oradata/arch VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' db_unique_name='Chicago_Sales'                                                 db_unique_name=CHicago_Sales' 

    or if using a flash_recovery_area

        log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)' db_unique_name='Chicago_Sales'                                                             db_unique_name=Chicago_Sales' 

  The real use of this parameter is to dynamically enable/defer destinations 
    dependent on whether the database is mounted in the PRIMARY or STANDBY ROLE.




    In a real situation you may set..
       
        db_unique_name='Chicago_Sales'
        log_archive_config='DG_CONFIG=(Chicago_Sales,Denver_Sales)'
        log_archive_dest_2='SERVICE=Denver_Sales LGWR ASYNC REOPEN=10
             VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=Denver_Sales'

    So we would only ship redo to Denver_Sales if Chicago_sales is running in
    the PRIMARY ROLE. Clearly if you were to Switchover and Chicago_Sales would 
    take on the STANDBY_ROLE then this destination would become deferred 
    dynamically.

    What views show the Setup ?
    ---------------------------




    The view V$ARCHIVE_DEST has new columns to handle the new values.
        SQL> column DEST_NAME format A19
        SQL> column DB_UNIQUE_NAME format A15
        SQL> column VALID_NOW format A9
        SQL> column VALID_TYPE format A15
        SQL> column VALID_ROLE format A15
        SQL> select DEST_NAME,DB_UNIQUE_NAME,VALID_NOW as CURRENT,VALID_TYPE,VALID_ROLE
             from V$ARCHIVE_DEST WHERE DB_UNIQUE_NAME <> 'NONE';




        DEST_NAME           DB_UNIQUE_NAME  VALID_NOW  VALID_TYPE      VALID_ROLE
        ------------------- --------------  ---------  --------------- ---------------
        LOG_ARCHIVE_DEST_2  Denver_Sales    YES        ONLINE_LOGFILE  PRIMARY_ROLE
        LOG_ARCHIVE_DEST_10 Chicago_sales   YES        ALL_LOGFILES    ALL_ROLES








    So this shows us that in fact both the destinations are currently in use 
    as the database Chicago_Sales is the Primary..  
    
    Note LOG_ARCHIVE_DEST_10 is the default log_archive_dest_n parameter used
    when making use of a flash recovery area.

Maclean Liu(刘相兵

The log_archive_config should contain both the primary and standby db_unique_names and must be set exactly the same way on the primary and standby or you will receive ora-16047.
On the Primary and Standby set to same value
sql> alter system set log_archive_config='DG_CONFIG=(primary ,standby)' scope=both sid='*';


==> 该参数罗列 db_unique_name 而非 instance name

ora-16047

[oracle@vrh8 ~]$ oerr ora 16047

16047, 00000, "DGID mismatch between destination setting and standby"
// *Cause:  The DB_UNIQUE_NAME specified for the destination does not match
//          the DB_UNIQUE_NAME at the destination.


// *Action: Make sure the DB_UNIQUE_NAME specified in the LOG_ARCHIVE_DEST_n
//          parameter defined for the destination matches the DB_UNIQUE_NAME
//          parameter defined at the destination.


ODM FINDING:


Getting Ora-16047 While Establishing The Standby DB

Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.1.0.7 - Release: 10.1 to 11.1
Information in this document applies to any platform.
Symptoms
ORA-16047: DGID mismatch between destination setting and standby
reported in a Data Guard Configuration

Cause
The following two Configuration Issues can give this Error:

    db_unique_name-Attribute of the log_archive_dest_n-Parameter on the Primary Database used for Log Transport Services and db_unique_name-Setting of the corresponding Standby Database does not match.
    There is no dg_config set with log_archive_config or it does not contain all db_unique_names participating in this Environment.


Solution

    Set the correct Value for db_unique_name-Attribute of log_archive_dest_n-Parameter so that it matches with the db_unique_name of the Standby Database.
    Set same Value for log_archive_config on both Standby and Primary Database containing all db_unique_names in dg_config.


Examples:

Primary Database db_unique_name:  prim
Standby Database db_unique_name: stdby

so for 1.:

log_archive_dest_2='service=standby valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=stdby'

for 2.: (on both primary and all the standby databases)

log_archive_config='dg_config=(prim,stdby)'