Troubleshooting
Problem
After a DB2 upgrade or migration you may receive: SQL1770N rc=5 after a 'takeover' command on the standby.
Symptom
After a DB2 upgrade or migration you may receive: SQL1770N rc=5 after a 'takeover' command on the standby database.
On the current standby issue the takeover command:
$ db2 takeover hadr on db SAMPLE
SQL1770N Takeover HADR cannot complete. Reason code = "5".
Reason code 5 means:
db2 \? SQL1770:
5:
"The command was issued against an inactive standby database."
A subsequent activate db will work:
$ db2 activate database SAMPLE
DB20000I The ACTIVATE DATABASE command completed successfully.
But another 'takeover' might fail again:
$ db2 takeover hadr on db SAMPLE
SQL1770N Takeover HADR cannot complete. Reason code = "5".
The primary database will show as being in 'disconnected' state:
On primary issue: db2pd -d sample -hadr:
Database Member 0 -- Database SAMPLE -- Active -- Up 10 days 10:25:18
-- Date 2016-05-05-10.25.18.856777
HADR_ROLE = PRIMARY
REPLAY_TYPE = PHYSICAL
HADR_SYNCMODE = NEARSYNC
STANDBY_ID = 1
LOG_STREAM_ID = 0
HADR_STATE = DISCONNECTED
HADR_FLAGS =
PRIMARY_MEMBER_HOST = xx.xx.xx.xxx
PRIMARY_INSTANCE = db2inst1
PRIMARY_MEMBER = 0
STANDBY_MEMBER_HOST = xx.xx.xx.xxx
STANDBY_INSTANCE = SAMPLE
STANDBY_MEMBER = 0
HADR_CONNECT_STATUS = DISCONNECTED
HADR_CONNECT_STATUS_TIME = 05/04/2016 15:58:01.946995 (1462391881)
Cause
One possible cause is a version mismatch and the primary and standby database are at different levels.
Diagnosing The Problem
Check the db2diag.log for these messages. They will appear just before HADR is started as primary:
Some of the messages have been annotated to add context and meaning:
2016-05-06-12.45.03.558066-240 E6618322E531 LEVEL: Event
PID : 13998 TID : 140080542902016 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
APPHDL : 0-7 APPID: *LOCAL.SAMPLE.160506164503
AUTHID : db2inst1 HOSTNAME: xxxxx.com
EDUID : 21 EDUNAME: db2agent (SAMPLE) 0
FUNCTION: DB2 UDB, base sys utilities,
sqeDBMgr::StartUsingLocalDatabase, probe:13
START : Received START HADR PRIMARY command.
....
2016-05-05-10.35.42.848196-240 I21964221E1033 LEVEL: Error
PID : 23160 TID : 140023701694208 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB : SAMPLE
HOSTNAME: xxxxx.com
EDUID : 116 EDUNAME: db2hadrp.0.1 (SAMPLE) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery,
hdrVerifyDBCompatibility, probe:15511
MESSAGE : ZRC=0x87800140=-2021654208=HDR_ZRC_CONFIGURATION_ERROR
"One or both databases of the HADR pair is configured incorrectly"
DATA #1 : String, 132 bytes
Rolling fixpack update is taking place, and the DB2 architecture level
on this machine is different from that on the remote machine.
DATA #2 : String, 53 bytes
Current effective architecture level of this database
DATA #3 : SqlzDB2Version, PD_TYPE_SqlzDB2Version, 8 bytes
V:10 R:5 M:0 F:6 I:0 SB:0 <<===Indicates 10.5 fixpack 6 on the primary SAMPLE
database.
DATA #4 : String, 66 bytes
Current effective architecture level received in handshake message
DATA #5 : SqlzDB2Version, PD_TYPE_SqlzDB2Version, 8 bytes
V:10 R:5 M:0 F:3 I:0 SB:0 <<===Indicates 10.5 fixpack 3 on the standby side during the handshake initialisation.
You may see these messages too on the standby during the activation of takeover:
Resolving The Problem
1) Ensure that both the primary and the standby instances have precisely the same version of DB2 installed. The db2level command as the instance owner will verify this.
2) Check the logs in /tmp for any errors during the upgrade / migration process.
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21983881