Time for action – changing the database name

Follow these steps to change DB_UNIQUE_NAME of a database in the Data Guard broker configuration.

  1. Prior to changing the database name, disable the database from the configuration as follows:
     DGMGRL> show database 'INDIA_UN';
Database - INDIA_UN
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: ON
  Instance(s):
    INDIA
Database Status:
SUCCESS
DGMGRL> disable database 'INDIA_UN';
Disabled.
  2. Change the DB_UNIQUE_NAME value of the standby database as follows:
    SQL> select db_unique_name,database_role from v$database;
DB_UNIQUE_NAM DATABASE_ROLE
------------- ----------------
india_un      PHYSICAL STANDBY
SQL> alter system set db_unique_name='INDIA_NEW' scope=spfile;
System altered.

    DB_UNIQUE_NAME is a static parameter, so you must use scope with SPFILE. If you are using PFILE, edit PFILE and bounce the database.

  3. Now shut down and start up the database and check for the new value of DB_UNIQUE_NAME as shown in the following query:
    SQL> select db_unique_name,database_role from v$database;
DB_UNIQUE_NAM DATABASE_ROLE
------------- ----------------
INDIA_NEW     PHYSICAL STANDBY
  4. Rename the database name in the Data Guard broker as follows:
    DGMGRL> edit database 'INDIA_UN' rename to 'INDIA_NEW';
Succeeded.
  5. Enable the database as follows:
    DGMGRL> enable database 'INDIA_NEW';
Enabled.
DGMGRL> show configuration;
Configuration - PACKT
  Protection Mode: MaxPerformance
  Databases:
    TURKEY_UN - Primary database
    INDIA_NEW - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Tip

After making changes in the database name, perform a couple of log switches and check for synchronization between both sites and also check the configuration status.

What just happened?

We've changed the database unique name of the standby database that is managed with the Data Guard broker.

Changing the state of the database

In order to perform state changes in databases, you must use Data Guard broker interfaces when these are managed with the databases.

For example, use the following command in order to turn off redo transport to all remote destinations on the primary database:

DGMGRL> edit database 'TURKEY_UN' SET STATE="LOG-TRANSPORT-OFF";
Succeeded.

To stop and start redo transport services to specific standby databases, use the following command:

DGMGRL> edit database 'INDIA_UN' SET PROPERTY 'LogShipping'='OFF';
Property "LogShipping" updated
DGMGRL> SHOW DATABASE 'INDIA_UN' 'LogShipping';
  LogShipping = 'OFF'
DGMGRL> edit database 'INDIA_UN' SET PROPERTY 'LogShipping'='ON';
Property "LogShipping" updated
DGMGRL>  SHOW DATABASE 'INDIA_UN' 'LogShipping';
  LogShipping = 'ON'

Have a go hero – more examples on state changes

Now try changing the states of the standby database using the following parameters. Also monitor the broker logfile and alert logfile whenever changing the configuration to track the operations behind as shown in the following commands:

DGMGRL> EDIT DATABASE 'INDIA_UN' SET STATE='READ-ONLY';
DGMGRL> EDIT DATABASE 'INDIA_UN' SET STATE='OFFLINE';
DGMGRL> EDIT DATABASE 'INDIA_UN' SET STATE='APPLY-OFF';
DGMGRL> EDIT DATABASE 'INDIA_UN' SET STATE='TRANSPORT-OFF';
DGMGRL> EDIT DATABASE 'INDIA_UN' SET STATE='ONLINE' WITH APPLY INSTANCE='INDIA_UN2';

Do not forget that some of the operations restart the instance.

Troubleshooting Data Guard broker

In this section, we will discuss the most common issues that may arise when Data Guard is managed with the broker. In the case of an outage or problem, we first consider gathering diagnostic information. We must refer to the alert logfile in the Automatic Diagnostic Repository destination starting from Oracle 11g. In earlier versions, the alert logfile is located in BACKGROUND_DUMP_DEST. The trace file drc<sid>.log for the Data Guard broker is also located in the ADR destination.

The v$diag_info view can be used to list all the important ADR locations for the Oracle database instance as shown in the following code:

SQL> SELECT NAME,VALUE FROM V$DIAG_INFO;
NAME                      VALUE
------------------------- -------------------------------------------
Diag Enabled              TRUE
ADR Base                  /u01/app/oracle
ADR Home                  /u01/app/oracle/diag/rdbms/turkey_un/TURKEY
..........
Default Trace File        /u01/app/oracle/diag/rdbms/turkey_un 
   /TURKEY/trace/TURKEY_ora_16735.trc
Active Problem Count      0
Active Incident Count     0

Data Guard tracing

The LOG_ARCHIVE_TRACE parameter is used to trace redo transport and apply services on both the primary and standby databases. By default, the parameter is disabled and its value is 0. The Data Guard tracing levels are as follows. Depending on the required tracing value, the level can be changed online:

  • 0: Disable archived log tracing (default)
  • 1: Track archival of the redo logfile
  • 2: Track the archival status of each archived log destination
  • 4: Track archival operational phase
  • 8: Track the archived log destination activity
  • 16: Track the detailed archived log destination activity
  • 32: Track archived log destination parameter modifications
  • 64: Track the ARCn process state activity
  • 128: Track FAL (fetch archived log) server related activities
  • 256: Track RFS logical client
  • 512: Track the LGWR redo shipping network activity
  • 1024: Track the RFS Physical client
  • 2048: Track RFS/ARCn Ping Heartbeat
  • 4096: Track Real Time Apply
  • 8192: Track Redo Apply (media recovery or physical standby)

If you want to turn on more than one tracing level, you can set LOG_ARCHIVE_TRACE to the sum of these levels. For example, setting it to 3 will turn on tracing archival of the redo logfile and the archival status of each archived log destination.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.24.106