HADR and failed tablespace creation

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Joachim Klassen - 11 Apr 2006 11:21 GMT

DB2 V8.2 FP10 on Windows

I tested the following HADR scenario:
- a new tablespace on a new filesytem is created on the primary System
- the replay on standby fails because of lacking permissions
- the tablespace is backed up on the primary system
- tables are created in the new tablespace and data is inserted (and a
couple of logs are archived)

- Takeover is done by the standby
- the new tablespace is not available (as expected)
- HADR is stopped and the tablespace is restored from the latest backup
- a rollforward to end of logs is started and it succeeded to my
surprise

I would have expected that it complains about missing log files (the
ones which have been archived by the former primary - the standby
system is not able to see the primary's archive destination)
it seems that all the necessary log files for the rollforward are still
local to the new primary system

My question now is:
Will the standby hold all logs following a transaction he could not
replay or am I just lucky that the logs
have still been there ?

Any comments ?
TIA
Joachim

Reply to this Message

Paul Peters - 12 Apr 2006 10:45 GMT

Recently I had created a PMR with the following complaint, I think it's
about the same as your case :

- after doing a load on a HADR database and if the load file is not
available on the standby server the tablespace becomes in the 'restore
pending' state. The only thing you can do now is a) a full database restore
or b) a tablespace restore. First, only a. was supported and advised. But
after giving my procedure I received the following message :

<begin>
ACTION PLAN: We finished the review of customers procedure to do
tablespace restore within his HADR environment.
---
on (primary)

db2 backup database hadrtest tablespace "(TEST)" online include logs

on (standby)

ftp file from <primary> to <standby>
db2 deactivate database hadrtest
db2 stop hadr on db hadrtest
db2 restore database hadrtest tablespace "(test)"
db2 start hadr on db hadrtest as standby
db2 takeover hadr on db hadrtest
db2 rollforward database hadrtest to end of logs tablespace "(test)"
online
---

These are the remarks to the above mentioned procedure used by customer:

- the steps outlined are correct
- essentially it is a standalone restore which is why it is working and we
should not have any issues.
- the key over here is the stop hadr which is req and you are no longer in
an HADR env.
- the trick is to make the system move into a standard mode away from a
prim / sec mode
- after doing tablespace restore you are fine to start hadr again.

So this is a supported procedure to do tablespace restore in hadr
environment without the need to do complete rebuild of hadr.

<end of message>

If you are using the userexit program. You should copy these files manually
to the standby server. (be carefull with that). Also place them in the
mirrorlogpath or another directory which can be used by the rollforward
statement.

Kind regards,
Paul

> DB2 V8.2 FP10 on Windows
>
[quoted text clipped - 25 lines]
> TIA
> Joachim

Reply to this Message

Mark A - 12 Apr 2006 23:58 GMT

> Recently I had created a PMR with the following complaint, I think it's
> about the same as your case :
[quoted text clipped - 48 lines]
> Kind regards,
> Paul

I assume that this is not a problem with an import? I have done some imports
(with the input file on only the primary server), and have not noticed a
problem.

Reply to this Message

Paul Peters - 13 Apr 2006 08:54 GMT

> I assume that this is not a problem with an import? I have done some
> imports (with the input file on only the primary server), and have not
> noticed a problem.

No this is not a problem with an import, because data which is inserted with
an import will go through the logfiles. No this problem can occur if you're
doing things like

db2 load from file.ixf of ixf insert into db2inst1.test copy yes to
/dbbackup/load/TEST/NODE0000

You can have problems with HADR if there are network connections problems.
If they resolve the log files are earlier back than the mounting to the
/dbbackup directory. Thus the load will fail because the mounting does not
exist. It's a pitty that there is no load files shipping in db2 between the
primary and the secundary server.

Reply to this Message

Steve Pearson (news only) - 12 Apr 2006 18:30 GMT

More or less good luck.

The standby may recycle log files a bit slower than the primary, but in
general it will not hold onto log files over time (if it did, that
could cause a space problem in the active log path). Because
performing a ROLLFORWARD at the secondary site some time after a
failover makes it Primary should be an anticipated recovery scenario,
it is important that the secondary site has some means to get at any
log files archived at the primary site.

Regards,
-Steve P.
--
Steve Pearson, IBM DB2 UDB for LUW Development, IBM Software Group
DB2 "Portland" Team, IBM Beaverton Lab, Beaverton, OR, USA

Reply to this Message