473,242 Members | 1,479 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,242 software developers and data experts.

start hadr as standby fails with SQL1767N rc=1

db2 8.1 fix pack 12 on AIX 5.3

This is a newly configured HADR machine. The HADR was up and running.
I was 'playing' around some on the standby and did a db2 deactivate and
things sort of went down hill from there.

Though the Standby machine seemed to know it was a standby it would not
connect to the primary. I could not even do a db2 get snapshot to view
the hadr status on the machine. I was wanting to do a few HADR tests
before I did a rolling code update but since the machine seemed to be
in this strange state I did the code update and rebooted the machine.
Due to the content in the code updated I had to perform a "rollforward
to end of logs and stop" otherwise some necessary commands failed.

When the machine came up from the reboot I did a 'db2start' then 'db2
start hadr as standby'. I am now getting the SQL1767N rc=1 stating
"The database was not in roll forward-pending or roll
forward-in-progress state when the START HADR AS STANDBY command was
issued. "

I believe it got into the situation because I did not properly stop
hadr but is there a way to get the standby going without doing a
database restore? Can I manually put the database in a roll-forward
pending state? I tried using db2rfpen but get an error:

____ D B 2 R F P E N ____

E R R O R L O G
__________________________________________________ ___________________

The following error has been encountered:
>>Unable to open the log file header control file. Return Code: -2029060074
Any help would be appreciated.

Nov 28 '06 #1
6 21663
"shorti" <lb******@juno.comwrote in message
news:11*********************@l39g2000cwd.googlegro ups.com...
db2 8.1 fix pack 12 on AIX 5.3

This is a newly configured HADR machine. The HADR was up and running.
I was 'playing' around some on the standby and did a db2 deactivate and
things sort of went down hill from there.

Though the Standby machine seemed to know it was a standby it would not
connect to the primary. I could not even do a db2 get snapshot to view
the hadr status on the machine. I was wanting to do a few HADR tests
before I did a rolling code update but since the machine seemed to be
in this strange state I did the code update and rebooted the machine.
Due to the content in the code updated I had to perform a "rollforward
to end of logs and stop" otherwise some necessary commands failed.

When the machine came up from the reboot I did a 'db2start' then 'db2
start hadr as standby'. I am now getting the SQL1767N rc=1 stating
"The database was not in roll forward-pending or roll
forward-in-progress state when the START HADR AS STANDBY command was
issued. "

I believe it got into the situation because I did not properly stop
hadr but is there a way to get the standby going without doing a
database restore? Can I manually put the database in a roll-forward
pending state? I tried using db2rfpen but get an error:

____ D B 2 R F P E N ____

E R R O R L O G
__________________________________________________ ___________________

The following error has been encountered:
>>>Unable to open the log file header control file. Return
Code: -2029060074

Any help would be appreciated.
Do not do a rollforward on a HADR standby database, as it must be in
rollforward pending state at all times. The original problem may have been
that you needed to activate the standby database.

To resolve the problem, I believe that you will need to backup the primary
and do the restore to standby, and start hadr as standby.
Nov 28 '06 #2

Mark A wrote:
>
Do not do a rollforward on a HADR standby database, as it must be in
rollforward pending state at all times. The original problem may have been
that you needed to activate the standby database.

To resolve the problem, I believe that you will need to backup the primary
and do the restore to standby, and start hadr as standby.
Thanks for the response. I did try to do an activate...and it errored
stating I could not do an activate on a standby. Then I stopped hadr
on the standby and did an activate and it seemed to not have a problem
with that but when I started hadr as standby again it stated it was
successful but still would not connect to the primary. I couldnt do a
db2pd or a db2 get snapshot to see what state the standby thought it
was in. When I issued a db2 get snapshot it stated I could not perform
that action unless the db was activated. This was confusing because I
had already tried to 'activate' previously.

Basically, I was in a state where I couldnt get an active standby and I
couldnt do anything as an active standard. I finally had to do the
rollforward so I was able to get it to an active standard mode.

I was thinking the rollforward pending state was the problem...but it
sounds like it was not.

The question now is...how do you activate a standby? I must be missing
something that is key here.

Nov 28 '06 #3
Not sure what you're trying to do here. You shouldn't activate the
standby at all; like Mark said, it needs to be sitting there in
rollforward pending state. It becomes active, as in a usable database,
when it does a takeover to become the primary database.

There are ways to make the standby available, but then it won't be a
standby anymore, from a HADR standpoint.

/T

shorti wrote:
Mark A wrote:

Do not do a rollforward on a HADR standby database, as it must be in
rollforward pending state at all times. The original problem may have been
that you needed to activate the standby database.

To resolve the problem, I believe that you will need to backup the primary
and do the restore to standby, and start hadr as standby.

Thanks for the response. I did try to do an activate...and it errored
stating I could not do an activate on a standby. Then I stopped hadr
on the standby and did an activate and it seemed to not have a problem
with that but when I started hadr as standby again it stated it was
successful but still would not connect to the primary. I couldnt do a
db2pd or a db2 get snapshot to see what state the standby thought it
was in. When I issued a db2 get snapshot it stated I could not perform
that action unless the db was activated. This was confusing because I
had already tried to 'activate' previously.

Basically, I was in a state where I couldnt get an active standby and I
couldnt do anything as an active standard. I finally had to do the
rollforward so I was able to get it to an active standard mode.

I was thinking the rollforward pending state was the problem...but it
sounds like it was not.

The question now is...how do you activate a standby? I must be missing
something that is key here.
Nov 28 '06 #4
I can't say for sure why the db refused to activate, but presumably
something happened prior to that to put it in a state where it could
not. I'm not familiar with what that may have been, as the "activate
db" command is supposed to be supported on an HADR standby.

- if the standby is not active, it should cause activation
- if the standby is already active, it will return a warning saying as
much

Note that activation of a standby does not mean normal user connections
can be made. Rather, it means that the db server is running and, if it
can connect to its partner, performing as an HADR standby.

If you examing the diagnostic log for the database (db2diag.log in your
db2dump directory), you may be able to find something about the sequece
of events leading to this and the other error messages you received.
Then I stopped hadr
on the standby and did an activate and it seemed to not have a problem
with that but when I started hadr as standby again it stated it was
successful but still would not connect to the primary.
There may have been some other steps in there. When a standby is
stopped, the db goes into an inactive rollforward-pending mode. In
this mode, the "activate db" command should return an error like this:

SQL1117N A connection to or activation of database "MYDB" cannot be
made
because of ROLL-FORWARD PENDING. SQLSTATE=57019

In any case, once you got the ex-standby started as a non-HADR
database, it most likely would be impossible for it to reconnect
successfully as a standby again except by reinitialization from scratch
(new db restore). To bring the ex-standby out of rollforward-pending
requires the rollforward to be completed there. That generally puts
that database on what we refer to as a "new log chain". In other
words, from the perspective of the db's history, as reflected in the db
log, that db has diverged and is on a different path from the primary
now.
I couldnt do a
db2pd or a db2 get snapshot to see what state the standby thought it
was in. When I issued a db2 get snapshot it stated I could not perform
that action unless the db was activated.
If you looked in the db2diag.log files for both primary and standby you
would likely find messages indicating that the standby had attempted to
connect with the primary but failed in the handshake validations. When
this is rejected, the standby deactivates. (No sense it trying again
and again as this is not a transient error.)

Without the db being active, there's no shared memory for db2pd to
attach to, nor can the get snapshot be performed.
Basically, I was in a state where I couldnt get an active standby and I
couldnt do anything as an active standard. I finally had to do the
rollforward so I was able to get it to an active standard mode.
My guess is a previously issued rollforward on the standby helped it
get into that state.

If you are concerned that HADR is behaving incorrectly, please open a
case with IBM service and provide your understanding of what happened
along with the db2diag.log files from both primary and standby covering
the entirety of the relevant time period.

Regards,
- Steve P.
--
Steve Pearson, IBM DB2 for Linux, UNIX, and Windows, IBM Software Group

DB2 "Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

Nov 28 '06 #5

Steve Pearson (news only) wrote:
I can't say for sure why the db refused to activate, but presumably
something happened prior to that to put it in a state where it could
not.
Note that activation of a standby does not mean normal user connections
can be made. Rather, it means that the db server is running and, if it
can connect to its partner, performing as an HADR standby.
Yes..this is what I am trying to determine. It seems that the standby
was in an inactive standby mode and I could not reach active standby.

After reading some more, I found the proper procedure was for me to
make the Primary HADR into a Standard non-HADR....then db2 deactivate
the Standby and stop hadr.

I did not change the Primary HADR to Standard....Instead, the first
thing I did was the db2 deactivate. After that I was not able to get
the Standby to communicate with the Primary so I assumed that the
standby remained in some sort of Inactive Standby mode. I tried
stopping and starting HADR etc...but it would not connect with the
Primary.
>
If you examing the diagnostic log for the database (db2diag.log in your
db2dump directory), you may be able to find something about the sequece
of events leading to this and the other error messages you received.
With your suggestion I did find it had a problem with a log:

FUNCTION: DB2 UDB, data protection, sqlpgArchiveLogFile, probe:3160
MESSAGE : Failed to archive log file S0005791.LOG to
/db2/backups/archive_0/xxxxxxx/THEDB/NODE0000/C0000010/ from
/db2/logs/active_0/NODE0000/ with rc = -2045837302.

So now I wonder what I should have done to recover. Evidently, the
rollforward was the wrong thing to do unless that was the last resort
to get it to Standard.
In any case, once you got the ex-standby started as a non-HADR
database, it most likely would be impossible for it to reconnect
successfully as a standby again except by reinitialization from scratch
(new db restore). To bring the ex-standby out of rollforward-pending
requires the rollforward to be completed there. That generally puts
that database on what we refer to as a "new log chain". In other
words, from the perspective of the db's history, as reflected in the db
log, that db has diverged and is on a different path from the primary
now.

If you are concerned that HADR is behaving incorrectly, please open a
case with IBM service and provide your understanding of what happened
along with the db2diag.log files from both primary and standby covering
the entirety of the relevant time period.
No...I dont feel that DB2 is the problem...and never have. Now that I
see that it looks like I corrupted the logging by not following
procedure I would like to know how this could be corrected. For
instance, what if the Standby has a power failure. A few minutes later
it is back up and has this issue...can I copy the logs to the Standby
and have it replay starting with the 'bad' log? Or am I stuck just
doing a database restore?

Thanks for the great info Steve!

Nov 29 '06 #6
Well... I'm not sure exactly what the sequence of events was, so it's
hard to propose a response. A thorough examination of the db2diag.log
files might reveal some additional information. But we can discuss a
bit more here about the initial concern you mentioned.

Assuming nothing else goes on, it should be possible to issue
"deactivate db" followed by "activate db" on a db configured as HADR
standby, and on the activate that db server should start up and resume
the activities of the standby role. That is, no special recovery
procedure should be needed after deactivation of an HADR standby
database.

Some things that could prevent the standby from properly activating:

- change in HADR config on primary or standby leading to mismatch
= if comms connects but handshake fails, standby deactivates
= if comms connection can't be made, standby stays active and retries
in a loop

- primary and standby pair validation mismatch (e.g., mismatching log
chains or standby ahead of primary); standby deactivates

- missing or corrupt log files/data on standby; standby panics or
deactivates

- missing needed log files on primary (e.g., primary got ahead while
standby was away, and archives of intervening log files are no for some
reason not retrievable on the primary); when a needed log file is not
available from primary, standby deactivates

- comms port collision/conflict with another db or other application
= standby may have its connection dropped
= primary may report comms related errors or config mismatch

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

Nov 29 '06 #7

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Mark A | last post by:
If server 01 running HADR in the primary role crashes, and the DBA does a HADR takeover by force on the 02 server to switch roles, then the 02 server is now the primary. What happens when the...
16
by: gumby | last post by:
I'm having trouble getting HADR to work with the sample databases on two HS20 xSeries blades, Red Hat ES4 up3, DB2 8.2.4, getting the following error. SQL1768N Unable to start HADR. Reason code...
8
by: Challenge | last post by:
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 ...
1
by: adpucci | last post by:
Hello list, I have 2 servers with HADR - it was supposedly working fine until last week, when I was told to do a restore DB and restart HADR following some incident in which I took no part. I...
4
by: Mark A | last post by:
I would like to make a split mirror copy of a HADR standby database. Please note that I do not want to create a standby with a split mirror of the primary, but I want to make a split mirror of the...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
Git
by: egorbl4 | last post by:
Скачал я git, хотел начать настройку, а там вылезло вот это Что это? Что мне с этим делать? ...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.