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

On Jun 24, 2:25*am, Gladiator <vkamalnath1... (AT) gmail (DOT) com> wrote:

I assume you are talking about ONLINE backup. The GENERATE command
won't extract the info after the backup...you have to manually key in
for that tablespace.
(at least that is what my tests are showing)

As a matter of fact...why don't u try that...with sample table

1. Create a sample database
db2sampl

2. Take a backup

3. Create a tabelspace

4. db2 "restore db sample from /XXX taken at 20100624120142 redirect
generate script test.clp"

Cheers
Shashi Mannepalli

On Jun 23, 11:25*pm, Gladiator <vkamalnath1... (AT) gmail (DOT) com> wrote:
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

On Jun 24, 9:15*pm, whatever <audheya2... (AT) gmail (DOT) com> wrote:
HI Shasi ,

I am sure the tablespaces gets created and will be loaded with data
during the rollforward if it is on the same server with the same
filesystem layout. The question is if have to do this on a different
system with a different filesystem layout.. Unfortunately i dont have
2 servers to test this .

Kamal.

On Jun 25, 5:20*am, Gladiator <vkamalnath1... (AT) gmail (DOT) com> wrote:
Kamal

Your Original Question...whether GENERATE option in the RESTORE will
create the SET CONTAINERS option for the newly added tablespace .which
was created after the Backup was taken.

I think the answer is NO.

As far as restoring into the same machine ..is concerned....u don't do
a REDIRECTE RESTORE...as u are restoring to the same containers/
fs ..etc.

if you want to Restore into a different machine ..which has different
containers/fs..then u have to use REDIRECTED RESTORE ...and then u
have to define the containers using SET CONTAINERS....

Hope this clarifies....

Cheers...

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

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

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

"Helmut Tessarek" <tessarek (AT) evermeet (DOT) cx> wrote

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.

Yes, this will work.


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

/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/

On Jun 26, 5:25*am, Helmut Tessarek <tessa... (AT) evermeet (DOT) cx> wrote:
Hi Helmut ,

Thanks for the reply and confirming this.

Thanks,
Kamal.