backup/restore nTs data

[Hardy]

hi gurus, now I have to backup and restore a 8 T size db2 database. from two
s85 to two 670. the partitions,tablespaces of the db should be redesigned
then I plan to use redirected restore.

but my concern is, such big size db, I'm afraid something unexpected will
destory all the effort. Who have related experience? Can you give some
advice? Thanks in advance:)

[Hardy]

oh, why no one reply to me? 55~~

"Hardy" <We***********@ibm.com> дÈëÓʼþ news:cf***********@mail.cn99.com...

hi gurus, now I have to backup and restore a 8 T size db2 database. from two s85 to two 670. the partitions,tablespaces of the db should be redesigned
then I plan to use redirected restore.

but my concern is, such big size db, I'm afraid something unexpected will
destory all the effort. Who have related experience? Can you give some
advice? Thanks in advance:)

[Fan Ruo Xin]

"Hardy" <We***********@ibm.com> wrote in message
news:cf***********@mail.cn99.com...

hi gurus, now I have to backup and restore a 8 T size db2 database. from two s85 to two 670. the partitions,tablespaces of the db should be redesigned
then I plan to use redirected restore.

but my concern is, such big size db, I'm afraid something unexpected will
destory all the effort. Who have related experience? Can you give some
advice? Thanks in advance:)

First you need to guarantee if the approach can be workable. If the number
of target db partitions is different than the number of source db partitions
(you didn't tell us if you build multiple logical db partitions on each
physical node), redirected restore will not cover redirecting to different
db partition.
Second even you have the same number of db partitions on both source and
target site. Since you mentioned you need to redesign the tablespaces, then
which approach you will use to redistribute the data?
Third, how far are the source and target? Will you plan to backup to TSM,
and restore from TSM? Or others?

[Hardy]

"Fan Ruo Xin" <fa*****@sbcglobal.net> дÈëÓʼþ
news:58*****************@newssvr17.news.prodigy.co m...

"Hardy" <We***********@ibm.com> wrote in message
news:cf***********@mail.cn99.com...

hi gurus, now I have to backup and restore a 8 T size db2 database. from two

s85 to two 670. the partitions,tablespaces of the db should be redesigned then I plan to use redirected restore.

but my concern is, such big size db, I'm afraid something unexpected will destory all the effort. Who have related experience? Can you give some
advice? Thanks in advance:)

First you need to guarantee if the approach can be workable. If the number
of target db partitions is different than the number of source db

partitions (you didn't tell us if you build multiple logical db partitions on each
physical node), redirected restore will not cover redirecting to different
db partition.
the number of partitions will remain the same as before, in a safe
consideration.
but I really want to double the partitions(from 4 on each server to 8
on each server). I don't familar with things about partition, but I wonder
if I can
redirect a tablespace originally span on 4 partitions to new tablespace
which span on 8, then the data will be
redistributed in the 8 partitions. can it work? I'm very very new to do
database related things,
so maybe I had initiated a very foundamental question but only don't know
the key.
Second even you have the same number of db partitions on both source and
target site. Since you mentioned you need to redesign the tablespaces, then which approach you will use to redistribute the data?
en, maybe the 'redesign' is a exaggerated word here. I just want to let the
existing tablespaces distrubute
more reasonably on the new servers, ie. span on different partitions.

Third, how far are the source and target? Will you plan to backup to TSM,
and restore from TSM? Or others?

on the same location.
there's no TSM. still not decided.maybe EMC.
en, if we copy the full db directory to the new server, the what can I do?
Is there a convenient way to help me
distribute the data in the new environment?

the backup/restore seem to be a very long period. I'm not very confident for
I cann't find
any reference case to deal with such large dbs. one senior engineer said
they had ever tried back/restore nTBs db(informix)
several times but no success. is there any safe way?
(db2look,export,load...maybe work and easy to control, but the time...
how long can it be?)

very thankful to Ruxin:)

[Fan Ruo Xin]

"Hardy" <We***********@ibm.com> wrote in message
news:cf***********@mail.cn99.com...

"Fan Ruo Xin" <fa*****@sbcglobal.net> дÈëÓʼþ
news:58*****************@newssvr17.news.prodigy.co m...

"Hardy" <We***********@ibm.com> wrote in message
news:cf***********@mail.cn99.com...

hi gurus, now I have to backup and restore a 8 T size db2 database.

from

two

s85 to two 670. the partitions,tablespaces of the db should be redesigned then I plan to use redirected restore.

but my concern is, such big size db, I'm afraid something unexpected will destory all the effort. Who have related experience? Can you give some
advice? Thanks in advance:)
First you need to guarantee if the approach can be workable. If the

number of target db partitions is different than the number of source db

partitions

(you didn't tell us if you build multiple logical db partitions on each
physical node), redirected restore will not cover redirecting to different db partition.

the number of partitions will remain the same as before, in a safe
consideration.
but I really want to double the partitions(from 4 on each server to 8
on each server). I don't familar with things about partition, but I wonder
if I can
redirect a tablespace originally span on 4 partitions to new tablespace
which span on 8, then the data will be
redistributed in the 8 partitions. can it work? I'm very very new to do
database related things,
so maybe I had initiated a very foundamental question but only don't know
the key.

(1) You CAN NOT backup a 8 db partitions database, and restore (even with
redirect) into a 16 db partitions database -:(
(2) You have to consider which way you need to go - build 8 db partitions on
each new box or build 4 db partitions on each new boxe first and then add
additional 4 db partitions later. This also determine the possible solution
about how to move the data from the old boxes to the new boxes.

Second even you have the same number of db partitions on both source and
target site. Since you mentioned you need to redesign the tablespaces, then

which approach you will use to redistribute the data?

en, maybe the 'redesign' is a exaggerated word here. I just want to let

the existing tablespaces distrubute
more reasonably on the new servers, ie. span on different partitions.

No, REDESIGN is a rather MAKE SENSE word. When the db systems need to be
upgraded to the new hardware environment, it is absolutely necessary for us
to consider REDESIGN, better use the new hardware power. The configuration
for the old hardware environment will not totally match the new environment.
And you also need to consider to take care of the data growing for the
following years (2, 3, 5, ...)

Third, how far are the source and target? Will you plan to backup to TSM, and restore from TSM? Or others?
on the same location.
there's no TSM. still not decided.maybe EMC.
en, if we copy the full db directory to the new server, the what can I do?
Is there a convenient way to help me
distribute the data in the new environment?

the backup/restore seem to be a very long period. I'm not very confident

for I cann't find
any reference case to deal with such large dbs. one senior engineer said
they had ever tried back/restore nTBs db(informix)
several times but no success. is there any safe way?
(db2look,export,load...maybe work and easy to control, but the time...
how long can it be?)

Which backup/restore policy are you using today? How long will take you to
do the full db backup today?
DB2 UDB EEE has no problem to deal with backup/restore nTBs database size.
And you can also backup 32bit database, and restore into a 64bit database,
if they both use DB2 UDB version8.1. I never got a chance to use Informix
XPS, but I believe it can handle the db size like this scenario.

It is possible that Backup/Restore might take you days. But ...
- DB2 UDB EEE can backup each db partitions in parallel. Only during the
offline full db backup, you need to backup catalog db partition first. But I
don't know if your catalog db partition contains a lot of user data.
- From what you tell us here, if your catalog also contain the user
tablespace, like all the other non-catalog nodes, then each db partition
size is about 1 TB. Is this the size of each db partition backup image?
- Again, if you want to use this way - backup/restore, do you want to use
TSM (Tape), fs, EMC, ...? The performance is totally different. Do you use
EMC for your current system?
Unload(especially if you use HPU) and load approach is a very good choice.
You need to be serious to think this. By using this way, you can dump the
data from a 8 db partitions database and load into a 16 db partitions
database. You don't need to worry about the data redistribution.
But there are always some tradeoff, advantage/disadvantage for each way.

I am afraid no one can give you the answer - how long will it be?
Any one if he/she wants to give you the answer, he/she need to do a batch of
research about your current environment, and need to know more detail
information about the new environment ... -:(



very thankful to Ruxin:)