Showing posts with label file. Show all posts
Showing posts with label file. Show all posts

Friday, April 18, 2014

Oracle Data Guard Broker Configuration management

Configuration management

1.       Change parameter, database property using DGMGRL

We will change the property 'StandbyFileManagement' for database ORCL2 to AUTO from MANUAL which is default setting for the parameter STANDBY_FILE_MANAGEMENT.

                edit database orcl2 set property 'StandbyFileManagement'='AUTO';
      
      
       DGMGRL> show database verbose orcl2
      
       Database - orcl2
      
         Role:            PHYSICAL STANDBY
         Intended State:  APPLY-ON
         Transport Lag:   0 seconds
         Apply Lag:       0 seconds
         Real Time Query: OFF
         Instance(s):
           orcl2
      
         Properties:
           DGConnectIdentifier             = 'orcl2'
           ObserverConnectIdentifier       = ''
           LogXptMode                      = 'ASYNC'
           DelayMins                       = '0'
           Binding                         = 'OPTIONAL'
           MaxFailure                      = '0'
           MaxConnections                  = '1'
           ReopenSecs                      = '300'
           NetTimeout                      = '30'
           RedoCompression                 = 'DISABLE'
           LogShipping                     = 'ON'
           PreferredApplyInstance          = ''
           ApplyInstanceTimeout            = '0'
           ApplyParallel                   = 'AUTO'
           StandbyFileManagement           = 'AUTO'
           ArchiveLagTarget                = '0'
           LogArchiveMaxProcesses          = '4'
           LogArchiveMinSucceedDest        = '1'
           DbFileNameConvert               = 'orcl1, orcl2'
           LogFileNameConvert              = 'orcl1, orcl2'
           FastStartFailoverTarget         = ''
           StatusReport                    = '(monitor)'
           InconsistentProperties          = '(monitor)'
           InconsistentLogXptProps         = '(monitor)'
           SendQEntries                    = '(monitor)'
           LogXptStatus                    = '(monitor)'
           RecvQEntries                    = '(monitor)'
           HostName                        = 'dg3'
           SidName                         = 'orcl2'
           StaticConnectIdentifier         = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dg3)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl2_DGMGRL)(INSTANCE_NAME=orcl2)(SERVER=DEDICATED)))'
           StandbyArchiveLocation          = 'USE_DB_RECOVERY_FILE_DEST'
           AlternateLocation               = ''
           LogArchiveTrace                 = '0'
           LogArchiveFormat                = '%t_%s_%r.dbf'
           TopWaitEvents                   = '(monitor)'
      
       Database Status:
       SUCCESS

We can change the ‘LogXptMode’ property as below. This will update the LOG_ARCHIVE_DEST_n parameter appropriately.
      
       edit database [orcl1|orcl2] set property logxptmode=SYNC;

2.       Change the broker configuration file location

The location of the broker configuration files is determined by the parameters DG_BROKER_CONFIG_FILEn (where n in {1,2}).

Default location is $ORACLE_HOME/dbs
Default names of configuration files are:  dr{1|2}<db_unique_name>             

CHANGING CONFIG FILE LOCATION:
               
The location of the configuration file can only be changed when DMON is not running.
                               
·         set DG_BROKER_START=FALSE
·         alter system set DG_BROKER_CONFIG_FILEn=new loc;
·         manually move files at OS level to new location
                                IF old/new location is ASM, use DBMS_FILE_TRANSFER.COPY_FILE
·         start DMON process

3.       Change DB STATEs

Turn off redo apply,

                edit database orcl2 set STATE='APPLY-OFF';

        Activate active DG aka REAL TIME QUERY,
               
                edit database orcl2 set STATE='APPLY-OFF';

       SQL> alter database open;

       edit database orcl2 set STATE='APPLY-ON';
      
       DGMGRL> show database orcl2
      
       Database - orcl2
      
         Role:            PHYSICAL STANDBY
         Intended State:  APPLY-ON
         Transport Lag:   0 seconds
         Apply Lag:       0 seconds
         Real Time Query: ON
         Instance(s):
           orcl2
      
       Database Status:
       SUCCESS

4.       Change protection mode

a)      Configure the SRL if necessary
b)      Set LogXptMode aptly
                               
edit database orcl1 set property 'LogXptMode'='SYNC';
edit database orcl2 set property 'LogXptMode'='SYNC';
                               
c)       now change the mode for the ENTIRE CONFIGURATION
               
                edit configuration set protection mode as MaxAvailability;
                               
         Effects:
               
                In the STANDBY alert log:
                               
                RFS[6]: Assigned to RFS process 7356
RFS[6]: Identified database type as 'physical standby': Client is LGWR SYNC pid 4753
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
RFS[6]: Selected log 4 for thread 1 sequence 65 dbid 1224670660 branch 840221191
Recovery of Online Redo Log: Thread 1 Group 4 Seq 65 Reading mem 0
Mem# 0: /u01/app/oracle/oradata/orcl2/srl04.log
Wed Mar 12 01:05:58 2014
RFS[7]: Assigned to RFS process 7366
RFS[7]: Identified database type as 'physical standby': Client is ARCH pid 4817

On the PRIMARY Site

SQL> select dest_id, dest_name, status, affirm, transmit_mode, process from v$archive_dest where status != 'INACTIVE';

DEST_ID DEST_NAME                      STATUS    AFF TRANSMIT_MOD PROCESS
---------- ------------------------------ --------- --- ------------ ----------
1 LOG_ARCHIVE_DEST_1             VALID     NO  SYNCHRONOUS  ARCH
2 LOG_ARCHIVE_DEST_2             VALID     YES PARALLELSYNC LGWR

On STANDBY site :

SQL> select dest_id, dest_name, status, affirm, transmit_mode, process from v$archive_dest where status != 'INACTIVE';

DEST_ID DEST_NAME                      STATUS    AFF TRANSMIT_MOD PROCESS
---------- ------------------------------ --------- --- ------------ ----------
1 LOG_ARCHIVE_DEST_1             VALID     NO  SYNCHRONOUS  ARCH
2 LOG_ARCHIVE_DEST_2             VALID     NO  ASYNCHRONOUS LGWR

32 STANDBY_ARCHIVE_DEST           VALID     YES SYNCHRONOUS  RFS

Data Guard Broker - Basics

DG BROKER is the management framework for data guard, and allows the DBA’s to automate many of the tasks involved in configuring and monitoring an Oracle Data Guard configuration.

DG Broker provides two interfaces:

1.       DGMGRL utility – this is a command line interface to the DG Broker
2.       OEM  GUI – OEM provides a graphical interface to the DG Broker
Some features such as standby database creation, can be automated and are only available through the GUI interface. If you use the DGMGRL utility and want to create a standby atabase, you must do so manually.

Benefits of DG Broker:

·         Disaster protection
·         High availability and scalability with RAC
·         Automated creation of DG configuration
·         Easy creation of additional standby DB’s (through OEM)
·         Simplified and centralized management
·         Simplified switchover and failover
·         Transparent to applications

DG broker handles the following logical entities:

·         Configuration of databases

A DG Broker configuration consists of following entities:

-          Configuration Object: it is a named collection of database profiles. A database profile in turn is a description of a database object including its current state, status and properties. A configuration object profiles one primary database and its standby databases.
-          Database objects: these correspond to the primary and standby databases. Broker uses the database object’s profile to manage and control the state of a single database on the system.
-          Instance objects: Broker treats databases as a collection of one or more named instances. Broker automatically discovers instances and associates them with their databases.

·         A single database


Data Guard Monitor and DG Configuration files

   The configuration, control and monitoring functions of the Broker are implemented by server-side software and configuration files.
This software is known as Data Guard Monitor.

When the Broker is started, the DMON (data guard monitor) background process runs for every database instance that is managed by the broker. DMON process interacts with the local instance and the DMON processes of all other instances in the broker configuration to perform the requested operation. It is also responsible for monitoring the health of broker configuration and for ensuring that every database has a consistent description of the configuration.

This persistent description of configuration is stored in the binary configuration file. A copy of this file is maintained by the DMON process for each database that belongs to the broker configuration. Configuration file describes the states and properties of the databases in configuration.  

Using SPFile is a must when using DG Broker to ensure that the Broker can update the values of parameters in both the database (parameter file) and the configuration file.

Broker Processes

DMON – Data Guard Monitor process -                This is the main process, responsible for all broker actions, as well as maintaining the configuration files. This process can be enabled or disabled using DG_BROKER_START parameter.

RSM – Broker Resource Manager – This process is responsible for handling SQL commands used by broker that need to be executed on one of the databases in the configuration. These commands need to be run as a result of change in configuration made through the DGMGRL, or the configuration commands run by broker during database startup.

NSVn – Data Guard Net Services – These processes are responsible for making contact with remote databases and sending across any work items to remote databases.


DRCn – Data Guard Network Receiver –  The network receiver processes establish connection from source database NSVn process. This is similar to the LNS and RFS mechanism for redo transport.

Wednesday, April 16, 2014

Fiddling with Oracle SCN

­­According to Tom, system change number (SCN) is Oracle's clock - every time we commit, the clock increments. The SCN just marks a consistent point in time in the database.

Transactions are always happening in the database, either user initiated or oracle implicit; hence, the SCN of database would always keep progressing whenever these transactions are committed.

The following exercise aims to show the various SCN numbers and their significance.

CURRENT_SCN : This is the current system change number of database. It will keep change as a result of the various transactions getting committed in the database. If database is not open, it is NULL. For Standby database, it is current standby redo application SCN.

RESETLOGS_CHANGE# : It is the SCN when the last OPEN RESETLOGS statement was issued.
This can be verified from the RMAN repository.

RMAN> list incarnation;


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       ORCL     1369005126       PARENT  1          13-AUG-2009 23:00:48
2       2       ORCL     1369005126       CURRENT 754488     03-MAR-2014 09:26:33

CHECKPOINT_CHANGE# : It is the SCN at the last checkpoint. This changes whenever as checkpoint occurs.

CONTROLFILE_CHANGE# : it is the SCN of when last time the controlfile was updated. This also changes at the checkpoint, as the controlfile is updated by the checkpoint process.

ARCHIVELOG_CHANGE# : it the highest V$ARCHIVED_LOG.NEXT_CHANGE#. This changes when the log switch occurs and the redo logfile is archived.



­ SQL>  select current_scn, resetlogs_change#, checkpoint_change#, controlfile_change#, archivelog_change# from v$database;

CURRENT_SCN RESETLOGS_CHANGE# CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# ARCHIVELOG_CHANGE#
----------- ----------------- ------------------ ------------------- ----------------------------
    1337349            754488            1336728             1336961                  1336727


SQL>  select sequence#, resetlogs_change#, first_change#, next_change#, first_time, next_time from v$archived_log;

 SEQUENCE# RESETLOGS_CHANGE# FIRST_CHANGE# NEXT_CHANGE# FIRST_TIM NEXT_TIME
---------- ----------------- ------------- ------------ --------- ---------
         7            754488        836239       849791 04-MAR-14 04-MAR-14
         8            754488        849791       871897 04-MAR-14 05-MAR-14
         9            754488        871897       899518 05-MAR-14 04-APR-14
        10            754488        899518       927310 04-APR-14 05-APR-14
        11            754488        927310       944887 05-APR-14 05-APR-14
        12            754488        944887       977295 05-APR-14 08-APR-14
        13            754488        977295      1024120 08-APR-14 09-APR-14
        14            754488       1024120      1047871 09-APR-14 09-APR-14
        15            754488       1047871      1059596 09-APR-14 09-APR-14
        16            754488       1059596      1064794 09-APR-14 09-APR-14
        17            754488       1064794      1069996 09-APR-14 09-APR-14
        18            754488       1069996      1078366 09-APR-14 09-APR-14
        19            754488       1078366      1102677 09-APR-14 09-APR-14
        20            754488       1102677      1126438 09-APR-14 09-APR-14
        21            754488       1126438      1133559 09-APR-14 09-APR-14
        22            754488       1133559      1136571 09-APR-14 09-APR-14
        23            754488       1136571      1141765 09-APR-14 09-APR-14
        24            754488       1141765      1150843 09-APR-14 09-APR-14
        25            754488       1150843      1161944 09-APR-14 09-APR-14
        26            754488       1161944      1167053 09-APR-14 09-APR-14
        27            754488       1167053      1179993 09-APR-14 09-APR-14
        28            754488       1179993      1189333 09-APR-14 09-APR-14
        29            754488       1189333      1212452 09-APR-14 09-APR-14
        30            754488       1212452      1237939 09-APR-14 09-APR-14
        31            754488       1237939      1258472 09-APR-14 10-APR-14
        32            754488       1258472      1288770 10-APR-14 10-APR-14
        33            754488       1288770      1311084 10-APR-14 10-APR-14
        34            754488       1311084      1336727 10-APR-14 14-APR-14

28 rows selected.

Observing SCN

-          Check the current_scn, checkpoint_change#, controlfile_change#

SQL>  select current_scn, resetlogs_change#, checkpoint_change#, controlfile_change#, controlfile_sequence#, archivelog_change# from v$database;

CURRENT_SCN RESETLOGS_CHANGE# CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# CONTROLFILE_SEQUENCE# ARCHIVELOG_CHANGE#
----------- ----------------- ------------------ ------------------- --------------------- ------------------
    1337465            754488            1336728             1337459                  2640            1336727

-          Force a checkpoint


SQL> alter system checkpoint;

System altered.

-          Check the current_scn, checkpoint_change#, controlfile_change#

SQL>  select current_scn, resetlogs_change#, checkpoint_change#, controlfile_change#, controlfile_sequence#, archivelog_change# from v$database;

CURRENT_SCN RESETLOGS_CHANGE# CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# CONTROLFILE_SEQUENCE# ARCHIVELOG_CHANGE#
----------- ----------------- ------------------ ------------------- --------------------- ------------------
    1337485            754488            1337482             1337482                  2641            1336727

     Check the current_scn, checkpoint_change#, controlfile_change#

Datafile SCN

The datafile SCN information is stored in the controlfile and in the datafile header. At each checkpoint, the datafile header and controlfile are updated of this information. The V$DATAFILE view presents this information from the controlfile.

CHECKPOINT_CHANGE# : It is the SCN at the last checkpoint. This changes whenever as checkpoint occurs.

OFFLINE_CHANGE# : It is the SCN when the datafile was last offline. Updated when the datafile is made online

ONLINE_CHANGE# : it is the SCN when the datafile was last made online.


Observing Datafile SCN

-          Check the current_scn, checkpoint_change#, controlfile_change# from V$DATABASE


SQL>  select current_scn, resetlogs_change#, checkpoint_change#, controlfile_change#, controlfile_sequence#, archivelog_change# from v$database;


CURRENT_SCN RESETLOGS_CHANGE# CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# CONTROLFILE_SEQUENCE# ARCHIVELOG_CHANGE#
----------- ----------------- ------------------ ------------------- --------------------- ------------------
    1339005            754488            1337482             1338762                  2651            1336727

-          Check the checkpoint_change# from V$DATAFILE


SQL>  select file#, checkpoint_change#, online_change#, offline_change#, plugin_change#, name from v$datafile;


     FILE# CHECKPOINT_CHANGE# ONLINE_CHANGE# OFFLINE_CHANGE# PLUGIN_CHANGE# NAME
---------- ------------------ -------------- --------------- -------------- ------------------------------------------------------------
         1            1337482         754488          754487              0 /u01/app/oracle/oradata/orcl/system01.dbf
         2            1337482         754488          754487              0 /u01/app/oracle/oradata/orcl/sysaux01.dbf
         3            1337482         754488          754487              0 /u01/app/oracle/oradata/orcl/undotbs01.dbf
         4            1337482         754488          754487              0 /u01/app/oracle/oradata/orcl/users01.dbf

-          Force checkpoint


SQL> alter system checkpoint;

System altered.

-          Check the current_scn, checkpoint_change#, controlfile_change# from V$DATABASE


SQL>  select current_scn, resetlogs_change#, checkpoint_change#, controlfile_change#, controlfile_sequence#, archivelog_change# from v$database;

CURRENT_SCN RESETLOGS_CHANGE# CHECKPOINT_CHANGE# CONTROLFILE_CHANGE# CONTROLFILE_SEQUENCE# ARCHIVELOG_CHANGE#
----------- ----------------- ------------------ ------------------- --------------------- ------------------
    1339019            754488            1339016             1339016                  2652            1336727

-          Check the checkpoint_change# from V$DATAFILE


SQL> select file#, checkpoint_change#, last_change#,  online_change#, offline_change#, plugin_change#, name from v$datafile;

     FILE# CHECKPOINT_CHANGE# LAST_CHANGE# ONLINE_CHANGE# OFFLINE_CHANGE# PLUGIN_CHANGE# NAME
---------- ------------------ ------------ -------------- --------------- -------------- ------------------------------------------------------------
         1            1339016                      754488          754487              0 /u01/app/oracle/oradata/orcl/system01.dbf
         2            1339016                      754488          754487              0 /u01/app/oracle/oradata/orcl/sysaux01.dbf
         3            1339016                      754488          754487              0 /u01/app/oracle/oradata/orcl/undotbs01.dbf
         4            1339016                      754488          754487              0 /u01/app/oracle/oradata/orcl/users01.dbf