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,tabl espaces 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]

Re: backup/restore nTs data

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

"Hardy" <WelcomeNoSpam@ ibm.com> дÈëÓʼþ news:cfalso$170 c$1@mail.cn99.c om...[color=blue]
> hi gurus, now I have to backup and restore a 8 T size db2 database. from[/color]
two[color=blue]
> s85 to two 670. the partitions,tabl espaces 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:)
>
>[/color]

[Fan Ruo Xin]

Re: backup/restore nTs data


"Hardy" <WelcomeNoSpam@ ibm.com> wrote in message
news:cfalso$170 c$1@mail.cn99.c om...[color=blue]
> hi gurus, now I have to backup and restore a 8 T size db2 database. from[/color]
two[color=blue]
> s85 to two 670. the partitions,tabl espaces 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:)
>
>[/color]

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]

Re: backup/restore nTs data


"Fan Ruo Xin" <fanruox@sbcglo bal.net> дÈëÓʼþ
news:58gSc.2827 $FV3.1685@newss vr17.news.prodi gy.com...[color=blue]
>
> "Hardy" <WelcomeNoSpam@ ibm.com> wrote in message
> news:cfalso$170 c$1@mail.cn99.c om...[color=green]
> > hi gurus, now I have to backup and restore a 8 T size db2 database. from[/color]
> two[color=green]
> > s85 to two 670. the partitions,tabl espaces of the db should be[/color][/color]
redesigned[color=blue][color=green]
> > then I plan to use redirected restore.
> >
> > but my concern is, such big size db, I'm afraid something unexpected[/color][/color]
will[color=blue][color=green]
> > destory all the effort. Who have related experience? Can you give some
> > advice? Thanks in advance:)
> >
> >[/color]
>
> 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[/color]
partitions[color=blue]
> (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.[/color]

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.


[color=blue]
> 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,[/color]
then[color=blue]
> which approach you will use to redistribute the data?[/color]

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.



[color=blue]
> Third, how far are the source and target? Will you plan to backup to TSM,
> and restore from TSM? Or others?
>
>[/color]

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]

Re: backup/restore nTs data


"Hardy" <WelcomeNoSpam@ ibm.com> wrote in message
news:cfclrs$23u j$1@mail.cn99.c om...[color=blue]
>
> "Fan Ruo Xin" <fanruox@sbcglo bal.net> дÈëÓʼþ
> news:58gSc.2827 $FV3.1685@newss vr17.news.prodi gy.com...[color=green]
> >
> > "Hardy" <WelcomeNoSpam@ ibm.com> wrote in message
> > news:cfalso$170 c$1@mail.cn99.c om...[color=darkred]
> > > hi gurus, now I have to backup and restore a 8 T size db2 database.[/color][/color][/color]
from[color=blue][color=green]
> > two[color=darkred]
> > > s85 to two 670. the partitions,tabl espaces of the db should be[/color][/color]
> redesigned[color=green][color=darkred]
> > > then I plan to use redirected restore.
> > >
> > > but my concern is, such big size db, I'm afraid something unexpected[/color][/color]
> will[color=green][color=darkred]
> > > destory all the effort. Who have related experience? Can you give some
> > > advice? Thanks in advance:)
> > >
> > >[/color]
> >
> > First you need to guarantee if the approach can be workable. If the[/color][/color]
number[color=blue][color=green]
> > of target db partitions is different than the number of source db[/color]
> partitions[color=green]
> > (you didn't tell us if you build multiple logical db partitions on each
> > physical node), redirected restore will not cover redirecting to[/color][/color]
different[color=blue][color=green]
> > db partition.[/color]
>
> 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.
>
>[/color]

(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.

[color=blue]
>[color=green]
> > 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,[/color]
> then[color=green]
> > which approach you will use to redistribute the data?[/color]
>
> en, maybe the 'redesign' is a exaggerated word here. I just want to let[/color]
the[color=blue]
> existing tablespaces distrubute
> more reasonably on the new servers, ie. span on different partitions.
>[/color]

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, ...)



[color=blue]
>
>
>[color=green]
> > Third, how far are the source and target? Will you plan to backup to[/color][/color]
TSM,[color=blue][color=green]
> > and restore from TSM? Or others?
> >
> >[/color]
>
> 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[/color]
for[color=blue]
> 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?)
>[/color]

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(especial ly 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 ... -:(



[color=blue]
>
>
> very thankful to Ruxin:)
>
>
>
>[/color]