LOG_ARCHIVE_CONFIG

   在配置DG时有一个参数LOG_ARCHIVE_CONFIG，这个参数可能很多人都配置了，但根本不知道其具体的作用。现在罗列了一些该参数的用途

 

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.