DB2 Version 9.7 for Linux, UNIX, and Windows

Determining the HADR standby database state using the GET SNAPSHOT command

You can determine the state of a DB2® High Availability Disaster Recovery (HADR) standby database by issuing the GET SNAPSHOT command with the DATABASE ON option.

About this task

To determine the state of an HADR standby database in a primary-standby HADR database pair, you can issue the GET SNAPSHOT command from the primary database or the standby database.

Procedure

If you issue the GET SNAPSHOT command from the standby database, the state of the standby database is returned in the State field of the output.
If you issue the GET SNAPSHOT command from a primary database that is connected to the standby database, the state of the standby database is returned in the State field of the output.
If you issue the GET SNAPSHOT command from a primary database that is not connected to the standby database, disconnected is returned in the State field of the output.

Example

For example, if you have standby database MUSIC, you can issue the following command to see its state:

   get snapshot for database on music

The following output shows the HADR status section returned by the GET SNAPSHOT command:

   HADR status

     Role                   = Primary
     State                  = Peer
     Synchronization mode   = Sync
     Connection status      = Connected, 11-03-2002 12:23:09.35092
     Heartbeat missed       = 0
     Local host             = host1.ibm.com
     Local service          = hadr_service
     Remote host            = host2.ibm.com
     Remote service         = hadr_service
     Remote instance        = dbinst2
     timeout(seconds)       = 120
     Primary log position(file, page, LSN) = S0001234.LOG, 12, 0000000000BB800C
     Standby log position(file, page, LSN) = S0001234.LOG, 12, 0000000000BB800C
     Log gap running average(bytes) = 8723

What to do next

While reviewing the output of the GET SNAPSHOT command, you might notice a log gap. A log gap can happen because when a log file is truncated, either as the result of an explicit log truncation, or as a result of stopping and restarting the primary database, the primary moves to the beginning of the next log file. The standby, however, stays at the end of the last log file. As soon as the primary writes any log, the log will be replicated and the standby will update its log position.