Data Guard issue handling

Data Guard

• Oracle Data Guard ensures high availability, data protection, and

disaster recovery for enterprise data.

• Data Guard provides a comprehensive set of services that create,

maintain, manage, and monitor one or more standby databases to
enable production Oracle databases to survive disasters.
 Data Guard common issues
1.archive log gap

2.archives logs are not transferring from primary to standby

3.TNS errors:

4. The archives are getting copied to the DR Server, but they are not being applied.

They were being applied properly till the last week.

 How to check status

To check archive log gap :

SQL>select * from v$archive_gap
To check the Max sequence applied
SQL>select max(sequence#) from v$archived_log where applied='YES';
To check the archive sequence
SQL> archive log list
To check the status of RFS and MRP0
SQL>select process , status from v$managed_standby;
To check the archive sequence applied or not
SQL>select sequence#,applied,archived from v$archived_log;
SQL>select message from v$dataguard_status
SQL>select error from v$archive_dest
 Analysis

If the standby site is not receiving the logs, the first thing you should do is obtain information about the archiving
status of the primary database by querying the V$ARCHIVE_DEST view. Check especially for error messages.
If the output of the query does not help you, check the following list of possible issues. If any of the following
conditions is not met, the primary database will fail to archive to the standby site:
•The service name for the standby instance is not configured correctly in the tnsnames.ora file at the primary site.
•The service name listed in the LOG_ARCHIVE_DEST_n parameter of the primary initialization parameter file is
incorrect.
•The LOG_ARCHIVE_DEST_STATE_n parameter specifying the state of the standby archiving destination has the value
DEFER.
•The listener.ora file has not been configured correctly at the standby site.
•The listener is not started.
•The standby instance is not started.
•You used an invalid backup as the basis for the standby database (for example, you used a backup from the wrong
database, or did not create the standby control file using the correct method.
 Parameters
• DB_FILE_NAME_CONVERT :If the standby database is on the same system as the primary database or if the
directory structure where the datafiles are located on the standby site is different from the primary site
• LOG_FILE_NAME_CONVERT
• STANDBY_FILE_MANAGEMENT Set to AUTO so when datafiles are added to or dropped from the primary
database, corresponding changes are made automatically to the standby database
• LOG_ARCHIVE_DEST_STATE_n Specify ENABLE to allow redo transport services to transmit redo data to the
specified destination
• LOG_ARCHIVE_DEST_n
• Ex:

• LOG_ARCHIVE_DEST_1= 'LOCATION=/'
• LOG_ARCHIVE_DEST_2= 'SERVICE='
• LOG_ARCHIVE_DEST_STATE_1=ENABLE
• LOG_ARCHIVE_DEST_STATE_2=ENABLE
 How to handle ORA-00060 error
• If customer complains about deadlock error(ORA-00060),whats needs
to be check first:

1.(Default) Parameters output as per SAP note 1171650

2.Alert log file for the effected time period and effected trace file
 How to analyze ORA-00060 trace
• When we check the trace file we get the below deadlock graph:

         ---------Blocker(s)--------  ---------Waiter(s)-----
Resource Name      process sess. holds waits  process sess. hold waits
TX-00090004-00011000   43  39    X            35     46          S
TX-0006001a-0001397d   35  46    X            43     39          S

Here, the last column that specifies the Waits as type 'S' is important. If an 'X' is displayed instead
at this point in the graph, it is NOT an Oracle deadlock.
And we need to transfer it to responsible application team.

If ‘S’ is displayes means it is oracle deadlock

 INITRANS and MAXTRANS
• In most cases, the problem is caused by the system trying to dynamically extend the block space, but the block is too
full. INITRANS defines the static value reserved for each block for transaction information. However, this value can
increase to MAXTRANS if several transactions try to lock simultaneously.
• To prevent this error from occurring, you have to extend the INITRANS value as much as possible so that a dynamic
extension is not required.
• The value could be extended using the commands
sqlplus "sapr3/<passwd>"
SQL> ALTER TABLE <TABLE NAME> INITRANS 20;
SQL> ALTER INDEX "<INDEX NAME>" INITRANS 20;
This would only apply to newly created blocks.

If you have to adjust maxtrans:

sqlplus "sapr3/<passwd>"
SQL> ALTER TABLE <TABLE NAME> maxtrans 255;
SQL> ALTER TABLE "<INDEX NAME>" maxtrans 255;
Note: After changing these parameters customer has to reorg the table or index to make the changes effected.
1847713-deadlock
Questions?