Start hadr primary db failed with SQL1768N, reason code 7.

**Mark A** · Jun 30 '06, 03:25 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

"Challenge" <hanna_shaw@yah oo.com> wrote in message
news:1151677749 .637675.17910@7 5g2000cwc.googl egroups.com...[color=blue]
> Hi,
>
> I got error, SQL1768N Unable to start HADR. Reason code = "7", when I
> tried to start hadr primary database. Here are the hadr configuration
> of my primary db:
>
> HADR database role = STANDARD
> HADR local host name (HADR_LOCAL_HOS T) = testserver
> HADR local service name (HADR_LOCAL_SVC ) = 56000
> HADR remote host name (HADR_REMOTE_HO ST) = testserver
> HADR remote service name (HADR_REMOTE_SV C) = 56001
> HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance2
> HADR timeout value (HADR_TIMEOUT) = 120
> HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
> Failover log archive path (FAILARCHPATH) =
> /logdir1/hadr/
> Index re-creation time and redo index build (INDEXREC) = RESTART
> Log pages during index build (LOGINDEXBUILD) = ON
>
> Here are the hadr configuration of my standby db:
>
> HADR database role = STANDBY
> HADR local host name (HADR_LOCAL_HOS T) = testserver
> HADR local service name (HADR_LOCAL_SVC ) = 56001
> HADR remote host name (HADR_REMOTE_HO ST) = testserver
> HADR remote service name (HADR_REMOTE_SV C) = 56000
> HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance1
> HADR timeout value (HADR_TIMEOUT) = 120
> HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
> Failover log archive path (FAILARCHPATH) =
> /logdir2/hadr/
> Index re-creation time and redo index build (INDEXREC) = RESTART
> Log pages during index build (LOGINDEXBUILD) = ON
>
> The two instances are on the same server. So firewall is not the issue.
> Could anyone please help me to find out why?
>
> Thanks.
>[/color]

Make sure that the standby database is activated:

db2 activate db sample

If you receive a message that says that the standby database is already
active, then activate the primary database, then start it for HADR as
primary.

**Challenge** · Jun 30 '06, 05:55 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Can a hadr standby be started on an active db? I did what you said and
got error:

SQL1767N Start HADR cannot complete. Reason code = "3".

Thanks for replying.

Mark A wrote:[color=blue]
> "Challenge" <hanna_shaw@yah oo.com> wrote in message
> news:1151677749 .637675.17910@7 5g2000cwc.googl egroups.com...[color=green]
> > Hi,
> >
> > I got error, SQL1768N Unable to start HADR. Reason code = "7", when I
> > tried to start hadr primary database. Here are the hadr configuration
> > of my primary db:
> >
> > HADR database role = STANDARD
> > HADR local host name (HADR_LOCAL_HOS T) = testserver
> > HADR local service name (HADR_LOCAL_SVC ) = 56000
> > HADR remote host name (HADR_REMOTE_HO ST) = testserver
> > HADR remote service name (HADR_REMOTE_SV C) = 56001
> > HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance2
> > HADR timeout value (HADR_TIMEOUT) = 120
> > HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
> > Failover log archive path (FAILARCHPATH) =
> > /logdir1/hadr/
> > Index re-creation time and redo index build (INDEXREC) = RESTART
> > Log pages during index build (LOGINDEXBUILD) = ON
> >
> > Here are the hadr configuration of my standby db:
> >
> > HADR database role = STANDBY
> > HADR local host name (HADR_LOCAL_HOS T) = testserver
> > HADR local service name (HADR_LOCAL_SVC ) = 56001
> > HADR remote host name (HADR_REMOTE_HO ST) = testserver
> > HADR remote service name (HADR_REMOTE_SV C) = 56000
> > HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance1
> > HADR timeout value (HADR_TIMEOUT) = 120
> > HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
> > Failover log archive path (FAILARCHPATH) =
> > /logdir2/hadr/
> > Index re-creation time and redo index build (INDEXREC) = RESTART
> > Log pages during index build (LOGINDEXBUILD) = ON
> >
> > The two instances are on the same server. So firewall is not the issue.
> > Could anyone please help me to find out why?
> >
> > Thanks.
> >[/color]
>
> Make sure that the standby database is activated:
>
> db2 activate db sample
>
> If you receive a message that says that the standby database is already
> active, then activate the primary database, then start it for HADR as
> primary.[/color]

**Challenge** · Jul 4 '06, 03:45 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Please help me. Thanks.

Challenge wrote:

Can a hadr standby be started on an active db? I did what you said and
got error:
>
SQL1767N Start HADR cannot complete. Reason code = "3".
>
Thanks for replying.
>
Mark A wrote:

"Challenge" <hanna_shaw@yah oo.comwrote in message
news:1151677749 .637675.17910@7 5g2000cwc.googl egroups.com...

Hi,
>
I got error, SQL1768N Unable to start HADR. Reason code = "7", when I
tried to start hadr primary database. Here are the hadr configuration
of my primary db:
>
HADR database role = STANDARD
HADR local host name (HADR_LOCAL_HOS T) = testserver
HADR local service name (HADR_LOCAL_SVC ) = 56000
HADR remote host name (HADR_REMOTE_HO ST) = testserver
HADR remote service name (HADR_REMOTE_SV C) = 56001
HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance2
HADR timeout value (HADR_TIMEOUT) = 120
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
Failover log archive path (FAILARCHPATH) =
/logdir1/hadr/
Index re-creation time and redo index build (INDEXREC) = RESTART
Log pages during index build (LOGINDEXBUILD) = ON
>
Here are the hadr configuration of my standby db:
>
HADR database role = STANDBY
HADR local host name (HADR_LOCAL_HOS T) = testserver
HADR local service name (HADR_LOCAL_SVC ) = 56001
HADR remote host name (HADR_REMOTE_HO ST) = testserver
HADR remote service name (HADR_REMOTE_SV C) = 56000
HADR instance name of remote server (HADR_REMOTE_IN ST) = db2instance1
HADR timeout value (HADR_TIMEOUT) = 120
HADR log write synchronization mode (HADR_SYNCMODE) = NEARSYNC
Failover log archive path (FAILARCHPATH) =
/logdir2/hadr/
Index re-creation time and redo index build (INDEXREC) = RESTART
Log pages during index build (LOGINDEXBUILD) = ON
>
The two instances are on the same server. So firewall is not the issue.
Could anyone please help me to find out why?
>
Thanks.
>

Make sure that the standby database is activated:

db2 activate db sample

If you receive a message that says that the standby database is already
active, then activate the primary database, then start it for HADR as
primary.

**Steve Pearson (news only)** · Jul 6 '06, 08:35 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Can a hadr standby be started on an active db? I did what you said and
got error:
>
SQL1767N Start HADR cannot complete. Reason code = "3".

The answer can be found here:

-------

db2 =? sql1767n

SQL1767N Start HADR cannot complete. Reason code =
"<reason-code>".

Explanation:

Start HADR cannot complete. The explanation corresponding to the
reason code is:
[...]
3 START HADR AS STANDBY cannot be issued on an active
database.
[...]
User Response:

The user response corresponding to the reason code is:
[...]
3 If you intend to change a primary database to a standby
database, issue the TAKEOVER command from the current standby.
If you intend to change a standard database to a standby, the
database must be deactivated first.

-------

i.e., no, one cannot start HADR in the *standby* role on an active
database.

(However, one can start HADR in the *primary* role on an active
database.)

A thumbnail procedure to set up an HADR pair:

- create a db on intended initial primary site/instance
- back up the db
- restore the db on intended initial standby site/instance
- set HADR config params as appropriate for each copy of the db
(initial primary/standby)
- issue START HADR ON DB db AS STANDBY at initial standby
- issue START HADR ON DB db AS PRIMARY at initial primary

Note that at the time of startup in this scenario, the copy of the db
on the initial primary may or may not be active. The copy of the db on
the initial standby is definitely not active; it is (must be) marked as
rollforward pending.

Note as well that the *standby* is started first. If it is not, you
may receive the SQL1768N reason 7. To help prevent split brain, the
primary will not start unless the standby connects to it. (This can be
overridden by the BY FORCE option on the START HADR..AS PRIMARY
command. That causes the primary to start in isolation, which is all
else equal a riskier proposition.)

If the above is news to you, you may want to consult the HADR
documentation before proceeding. See for example the info center in
this area:

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/t0011725.htm

Btw, searching the Info Center is a breeze using Google search. For
example, the above URL is the top hit using the following text in
Google search:

site:ibm.com db2 initializing hadr

Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

**Challenge** · Jul 7 '06, 04:25 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Thank, Steve. But that's not my original question. Mark answered my
question by asking me to active both standby db and primary db before I
start them. That's why I doubt that standby db cannot be active.

My real problem is when I tried to start my hadr primary db, I got
error SQL1768N with reason code 7. My two instances are on the same
server. So there is no firewall issue. I cannot find anything wrong
with my configuratio(it 's in my first post.)

Any idea?

Thanks.

Steve Pearson (news only) wrote:

Can a hadr standby be started on an active db? I did what you said and
got error:

SQL1767N Start HADR cannot complete. Reason code = "3".

>
>
The answer can be found here:
>
-------
>
db2 =? sql1767n
>
SQL1767N Start HADR cannot complete. Reason code =
"<reason-code>".
>
Explanation:
>
Start HADR cannot complete. The explanation corresponding to the
reason code is:
[...]
3 START HADR AS STANDBY cannot be issued on an active
database.
[...]
User Response:
>
The user response corresponding to the reason code is:
[...]
3 If you intend to change a primary database to a standby
database, issue the TAKEOVER command from the current standby.
If you intend to change a standard database to a standby, the
database must be deactivated first.
>
-------
>
i.e., no, one cannot start HADR in the *standby* role on an active
database.
>
(However, one can start HADR in the *primary* role on an active
database.)
>
A thumbnail procedure to set up an HADR pair:
>
- create a db on intended initial primary site/instance
- back up the db
- restore the db on intended initial standby site/instance
- set HADR config params as appropriate for each copy of the db
(initial primary/standby)
- issue START HADR ON DB db AS STANDBY at initial standby
- issue START HADR ON DB db AS PRIMARY at initial primary
>
Note that at the time of startup in this scenario, the copy of the db
on the initial primary may or may not be active. The copy of the db on
the initial standby is definitely not active; it is (must be) marked as
rollforward pending.
>
Note as well that the *standby* is started first. If it is not, you
may receive the SQL1768N reason 7. To help prevent split brain, the
primary will not start unless the standby connects to it. (This can be
overridden by the BY FORCE option on the START HADR..AS PRIMARY
command. That causes the primary to start in isolation, which is all
else equal a riskier proposition.)
>
If the above is news to you, you may want to consult the HADR
documentation before proceeding. See for example the info center in
this area:

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/t0011725.htm

>
Btw, searching the Info Center is a breeze using Google search. For
example, the above URL is the top hit using the following text in
Google search:
>
site:ibm.com db2 initializing hadr
>
Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

**Steve Pearson (news only)** · Jul 7 '06, 06:15 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

My real problem is when I tried to start my hadr primary db, I got
error SQL1768N with reason code 7. My two instances are on the same
server. So there is no firewall issue. I cannot find anything wrong
with my configuratio(it 's in my first post.)
>
Any idea?

Well, did you start the standby before starting the primary?
As I said before:

A thumbnail procedure to set up an HADR pair:

- create a db on intended initial primary site/instance
- back up the db
- restore the db on intended initial standby site/instance
- set HADR config params as appropriate for each copy of the db
(initial primary/standby)
- issue START HADR ON DB db AS STANDBY at initial standby
- issue START HADR ON DB db AS PRIMARY at initial primary

[...]

Note as well that the *standby* is started first. If it is not, you
may receive the SQL1768N reason 7. To help prevent split brain, the
primary will not start unless the standby connects to it. (This can be
overridden by the BY FORCE option on the START HADR..AS PRIMARY
command. That causes the primary to start in isolation, which is all
else equal a riskier proposition.)

Some systems are also quite finicky about name resolution. Some folks
have had to get around this by using an IP address instead of server
name, though I don't think I've ever seen that for a setup using just
one host. (Of course we don't see single hosts in general, as it's not
a best practice for HA, but it is possible to set up HADR that way for
testing purposes).

The next thing I'd do is examine the diagnostic log (db2diag.log) on
each of the servers to see if there was any relevant messaging. HADR
itself might complain about name resolution (e.g., the local host needs
to resolve to a name matching that supplied in the HADR configuration).

Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

**Challenge** · Jul 12 '06, 03:45 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Thanks, Steve. It's finally solved after the server was rebooted. Some
mystery happened on the server.

Here were the parts in db2diag.log when it failed:

......
2006-06-30-10.27.02.495785-240 I12840853A579 LEVEL: Error
PID : 3272874 TID : 1 PROC : db2hadrp
(CCSTST) 0
INSTANCE: db26v8 NODE : 000 DB : CCSTST
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20390
MESSAGE : HADR primary did not establish connection with standby within
timeout
and will shut down. BY FORCE option required to start primary
without
standby. Timeout seconds =
DATA #1 : Hexdump, 4 bytes
0x0780000021C28 C64 : 0000 0078 ...x

2006-06-30-10.27.02.496289-240 I12841433A418 LEVEL: Error
PID : 3272874 TID : 1 PROC : db2hadrp
(CCSTST) 0
INSTANCE: db26v8 NODE : 000 DB : CCSTST
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20390
RETCODE : ZRC=0x8280001A=-2105540582=HDR_ ZRC_NO_STANDBY
"Comm time-out in unforced HADR primary start, to avoid
split-brain"
.......

I guess it didn't specify the reason.

Thanks again, Steve.

Steve Pearson (news only) wrote:

My real problem is when I tried to start my hadr primary db, I got
error SQL1768N with reason code 7. My two instances are on the same
server. So there is no firewall issue. I cannot find anything wrong
with my configuratio(it 's in my first post.)

Any idea?

>
>
Well, did you start the standby before starting the primary?
As I said before:
>

A thumbnail procedure to set up an HADR pair:
>
- create a db on intended initial primary site/instance
- back up the db
- restore the db on intended initial standby site/instance
- set HADR config params as appropriate for each copy of the db
(initial primary/standby)
- issue START HADR ON DB db AS STANDBY at initial standby
- issue START HADR ON DB db AS PRIMARY at initial primary
>
[...]
>
Note as well that the *standby* is started first. If it is not, you
may receive the SQL1768N reason 7. To help prevent split brain, the
primary will not start unless the standby connects to it. (This can be
overridden by the BY FORCE option on the START HADR..AS PRIMARY
command. That causes the primary to start in isolation, which is all
else equal a riskier proposition.)

>
>
Some systems are also quite finicky about name resolution. Some folks
have had to get around this by using an IP address instead of server
name, though I don't think I've ever seen that for a setup using just
one host. (Of course we don't see single hosts in general, as it's not
a best practice for HA, but it is possible to set up HADR that way for
testing purposes).
>
The next thing I'd do is examine the diagnostic log (db2diag.log) on
each of the servers to see if there was any relevant messaging. HADR
itself might complain about name resolution (e.g., the local host needs
to resolve to a name matching that supplied in the HADR configuration).
>
Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

**shenanwei@gmail.com** · Jul 13 '06, 04:25 PM

Re: Start hadr primary db failed with SQL1768N, reason code 7.

Did y do a
db2stop
db2start
after you
db2 update db cfg for databasename using hadr.....

and do
db2 update alternate server for database using hostname port
db2 terminate
then
db2 start hadr.....

Challenge wrote:

Thanks, Steve. It's finally solved after the server was rebooted. Some
mystery happened on the server.
>
Here were the parts in db2diag.log when it failed:
>
.....
2006-06-30-10.27.02.495785-240 I12840853A579 LEVEL: Error
PID : 3272874 TID : 1 PROC : db2hadrp
(CCSTST) 0
INSTANCE: db26v8 NODE : 000 DB : CCSTST
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20390
MESSAGE : HADR primary did not establish connection with standby within
timeout
and will shut down. BY FORCE option required to start primary
without
standby. Timeout seconds =
DATA #1 : Hexdump, 4 bytes
0x0780000021C28 C64 : 0000 0078 ...x
>
2006-06-30-10.27.02.496289-240 I12841433A418 LEVEL: Error
PID : 3272874 TID : 1 PROC : db2hadrp
(CCSTST) 0
INSTANCE: db26v8 NODE : 000 DB : CCSTST
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP,
probe:20390
RETCODE : ZRC=0x8280001A=-2105540582=HDR_ ZRC_NO_STANDBY
"Comm time-out in unforced HADR primary start, to avoid
split-brain"
......
>
I guess it didn't specify the reason.
>
Thanks again, Steve.
>
Steve Pearson (news only) wrote:

My real problem is when I tried to start my hadr primary db, I got
error SQL1768N with reason code 7. My two instances are on the same
server. So there is no firewall issue. I cannot find anything wrong
with my configuratio(it 's in my first post.)
>
Any idea?

Well, did you start the standby before starting the primary?
As I said before:

A thumbnail procedure to set up an HADR pair:

- create a db on intended initial primary site/instance
- back up the db
- restore the db on intended initial standby site/instance
- set HADR config params as appropriate for each copy of the db
(initial primary/standby)
- issue START HADR ON DB db AS STANDBY at initial standby
- issue START HADR ON DB db AS PRIMARY at initial primary

[...]

Note as well that the *standby* is started first. If it is not, you
may receive the SQL1768N reason 7. To help prevent split brain, the
primary will not start unless the standby connects to it. (This can be
overridden by the BY FORCE option on the START HADR..AS PRIMARY
command. That causes the primary to start in isolation, which is all
else equal a riskier proposition.)

Some systems are also quite finicky about name resolution. Some folks
have had to get around this by using an IP address instead of server
name, though I don't think I've ever seen that for a setup using just
one host. (Of course we don't see single hosts in general, as it's not
a best practice for HA, but it is possible to set up HADR that way for
testing purposes).

The next thing I'd do is examine the diagnostic log (db2diag.log) on
each of the servers to see if there was any relevant messaging. HADR
itself might complain about name resolution (e.g., the local host needs
to resolve to a name matching that supplied in the HADR configuration).

Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

Start hadr primary db failed with SQL1768N, reason code 7.

Start hadr primary db failed with SQL1768N, reason code 7.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment