Guys, I couldn' t find any thread about this subject, so I'm starting a new one.

I managed to configure properly both standby and primary servers for my HADR in DB2. Lines from db cfg follow:

standby:
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) = SRIBSA019946C02
HADR local service name (HADR_LOCAL_SVC) = DB2_HADR_2
HADR remote host name (HADR_REMOTE_HOST) = SRIBSA01994608
HADR remote service name (HADR_REMOTE_SVC) = DB2_HADR_1
HADR instance name of remote server (HADR_REMOTE_INST) = DB2
HADR timeout value (HADR_TIMEOUT) = 10
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 120

primary:
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOST) = SRIBSA019946C08
HADR local service name (HADR_LOCAL_SVC) = DB2_HADR_1
HADR remote host name (HADR_REMOTE_HOST) = SRIBSA019946C02
HADR remote service name (HADR_REMOTE_SVC) = DB2_HADR_2
HADR instance name of remote server (HADR_REMOTE_INST) = DB2
HADR timeout value (HADR_TIMEOUT) = 10
HADR log write synchronization mode (HADR_SYNCMODE) = SYNC
HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 120

Also, made a backup from PRIMARY and restored it into STANDBY with clause REPLACE HISTORY FILE

Machines are equal, configs are equal, etc.

Thing is that I can start HADR at the STANDBY machine, but not at the PRIMARY. I obtain the message:

SQL1768N Unable to start HADR. Reason code = "7".

I've already raised HADR_TIMEOUT from 3 to 5 then to 10 on both servers.
What would be the common reasons for that to happen?

thanks in advance

Zevang

These two statements contradict each other, don't you think?

What does this return on both servers:

grep DB2_HADR /etc/services

Thanks for your reply.
Sorry if I could not express myself properly. English is my second language.

In my case both servers have Windows Server installed. Anyway their contents (only DB2 related) at C:\Windows\System32\drivers\etc are:

standby:
db2c_DB2 50000/tcp
db2c_DB2T 50004/tcp
db2j_DB2 55000/tcp
DB2_DB2 60000/tcp
DB2_DB2_1 60001/tcp
DB2_DB2_2 60002/tcp
DB2_DB2_END 60003/tcp

DB2_HADR_1 55001/tcp
DB2_HADR_2 55002/tcp

primary:
DB2_DB2 60000/tcp
DB2_DB2_1 60001/tcp
DB2_DB2_2 60002/tcp
DB2_DB2_END 60003/tcp
db2c_DB2 50000/tcp

DB2_HADR_1 55001/tcp
DB2_HADR_2 55002/tcp


regards,
Zevang

Try restarting both DB2 instances.

Most people use an HADR_TIMEOUT of more than 20 seconds.

Also, not sure why you are using SYNC mode. NEARSYNCH should provide the same level of data integrity in 99.9999% of installations. Even if you want SYNCH, you should probably try NEARSYNCH first to see if you can get it working OK.

Also, please post output of db2level command.

I'd be very cautious using symbolic host and port names on Windows. Try numeric values instead. Check that there's no firewall(s) blocking communications.

db2level output:

standby:
DB21085I Instance "DB2" uses "64" bits and DB2 code release "SQL09055" with level identifier "06060107".
Informational tokens are "DB2 v9.5.500.784", "s091123", "WR21458", and Fix Pack "5".
Product is installed at "C:\PROGRA~1\IBM\SQLLIB" with DB2 Copy Name "DB2COPY1".

primary:
DB21085I Instance "DB2" uses "64" bits and DB2 code release "SQL09055" with level identifier "06060107".
Informational tokens are "DB2 v9.5.500.784", "s091123", "WR21458", and Fix Pack "5".
Product is installed at "C:\PROGRA~1\IBM\SQLLIB" with DB2 Copy Name "DB2COPY1".

I will make the cfg changes you suggested on monday and send you the results.
Thanks a lot
Zevang

No, there isn't.

The names are stablished upon the rules of the company. Anyway, the net where these two servers communicate is totally isolated from the outside, but thanks.

I think there is a typo in one of them:

HADR remote host name (HADR_REMOTE_HOST) = SRIBSA01994608
HADR local host name (HADR_LOCAL_HOST) = SRIBSA019946C08

Marcus, I just did the changes but the same result occurred.

standby:
DB20000I The START HADR ON DATABASE command completed successfully.

primary:
SQL1768N Unable do start HADR. Reason code = "7".

Now using on both:
HADR timeout value (HADR_TIMEOUT) = 25
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC


Would a difference of almost 3 minutes between the two server's clocks cause this problem? Just noted that they are not equal.

thanks again,

Just checked that. It's right at the cfg of both servers. Curious that I did CTRL-C/CTRL-V to post it here...
Thanks anyway :-)

Can standby access the logs? Rename your db2diag.log, retry the command and then check the errors.

Indeed the folder "C:\LOGARCHIVE" was missing at the standby. There were many errors regarding that the path could not be found.
Now at the db2diag.log the errors are pretty reduced and are:

2011-02-11-20.04.19.607000-120 E11012F396 LEVEL: Event
PID : 5924 TID : 6284 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000
EDUID : 6284 EDUNAME: db2hadrs (COSURA) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-RemoteCatchupPending (was S-LocalCatchup)

2011-02-11-20.04.20.511000-120 I11410F471 LEVEL: Severe
PID : 5924 TID : 6284 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000
EDUID : 6284 EDUNAME: db2hadrs (COSURA) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20280
MESSAGE : Failed to connect to primary. rc:
DATA #1 : Hexdump, 4 bytes
0x000000000ECFF0E0 : 1900 0F81 ....

2011-02-11-20.04.20.511000-120 I11883F405 LEVEL: Severe
PID : 5924 TID : 6284 PROC : db2syscs.exe
INSTANCE: DB2 NODE : 000
EDUID : 6284 EDUNAME: db2hadrs (COSURA) 0
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20280
RETCODE : ZRC=0x810F0019=-2129723367=SQLO_CONN_REFUSED "Connection refused"

Would using clause "BY FORCE" be too risky?

I still think you have communication problems to deal with. Don't forget that on Windows you have built-in firewalls.

Both have them deactivated actually. I will do some more tests tomorrow and see.
Thank you all for your kind assistance.