Prev: DB2 UDB V9.1.3, Database crash, crash recovery fail, no backup.
Next: db2 install questions
From: Gladiator on 24 Jun 2010 02:25
Hello ,

I have a scenario .
consider we have a database for which we have taken a Full backup on
monday.
We have added tablespaces say on tuesday. Consider we want to do a
redirect restore onto a different box which has compeltely different
filesystems with different mount points Using the backup taken on
monday .

When we generate the script we dont get the new tablespaces which
were added on tuesday. So even the restore was successfull , how does
the rollforward continue as the containers were not set for the newly
added tablespaces ? Rollforward should be trying to add containers
considering the source filesystems. but we dont have the same
filesystem layout in the target .

Thanks,
Kamalnath.V





From: Tomas on 24 Jun 2010 19:03
On Jun 23, 11:25 pm, Gladiator <vkamalnath1...(a)gmail.com> wrote:
> Hello ,
>
> I have a scenario .
> consider we have a database for which we have taken a Full backup on
> monday.
> We have added tablespaces say on tuesday. Consider we want to do a
> redirect restore onto a different box which has compeltely different
> filesystems with different mount points Using the backup taken on
> monday .
>
> When we generate the script we dont get the new tablespaces  which
> were added on tuesday. So even the restore was successfull , how does
> the rollforward continue as the containers were not set for the newly
> added tablespaces  ? Rollforward should be trying to add containers
> considering the source filesystems. but we dont have the same
> filesystem layout in the target .
>
> Thanks,
> Kamalnath.V

I encountered a variation of this, once. Not with a create
tablespace, but an alter (adding space). The problem is that it's
just a SQL statement, and so it will get executed during the
rollforward just as it was executed when it first happened. As I
recall, we temporarily created a file system with that name, let the
rollforward continue until it completed, then moved that container
over to one of the new file systems and droppped the temporary file
system. A bit of a kludge, but it worked.

/T
From: Helmut Tessarek on 25 Jun 2010 19:17
Hi Kamalnath,

I asked our master of backup and recovery (:-)) and he says the following:

-----
If the tablespace is not in the backup then we will simply replay the add
tablespace / add container operations as they appear in the log stream. If
they fail then those tablespaces will be taken off line.

We recommend that you create a backup after adding table spaces.
-----

Cheers,
Helmut

> I have a scenario .
> consider we have a database for which we have taken a Full backup on
> monday.
> We have added tablespaces say on tuesday. Consider we want to do a
> redirect restore onto a different box which has compeltely different
> filesystems with different mount points Using the backup taken on
> monday .
>
> When we generate the script we dont get the new tablespaces which
> were added on tuesday. So even the restore was successfull , how does
> the rollforward continue as the containers were not set for the newly
> added tablespaces ? Rollforward should be trying to add containers
> considering the source filesystems. but we dont have the same
> filesystem layout in the target .

--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
From: Mark A on 25 Jun 2010 20:23
"Helmut Tessarek" <tessarek(a)evermeet.cx> wrote in message
news:i03de6$97k$1(a)news.albasani.net...
> Hi Kamalnath,
>
> I asked our master of backup and recovery (:-)) and he says the following:
>
> -----
> If the tablespace is not in the backup then we will simply replay the add
> tablespace / add container operations as they appear in the log stream.
> If
> they fail then those tablespaces will be taken off line.
>
> We recommend that you create a backup after adding table spaces.
> -----
>
> Cheers,
> Helmut

Or temporarily create a path that matches the path of the new tablespaces
from the source server after the backup. You might be able to use a symbolic
link on the target server with the path name you need. You can move the
tables later to another tablespace.


From: Helmut Tessarek on 25 Jun 2010 20:25
Yes, this will work.

> Or temporarily create a path that matches the path of the new tablespaces
> from the source server after the backup. You might be able to use a symbolic
> link on the target server with the path name you need. You can move the
> tables later to another tablespace.


--
Helmut K. C. Tessarek
DB2 Performance and Development

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
 |  Next  |  Last
Pages: 1 2
Prev: DB2 UDB V9.1.3, Database crash, crash recovery fail, no backup.
Next: db2 install questions