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
"Joachim Klassen" <Jo*******@email.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
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