DB2 and File Replication

[Tony Hinkle]

I am working on an application note to provide instructions on how to
use a real-time file replication application to provide disaster
recovery for DB2.

I basically need to know how to identify what files need to be
replicated for the default databases and others that are mounted. I
would greatly appreciate any offered assistance.

Thanks!

[Almund Sebi]

Re: DB2 and File Replication

> I basically need to know how to identify what files need to be[color=blue]
> replicated for the default databases and others that are mounted. I
> would greatly appreciate any offered assistance.[/color]

I think you should go the online backup & log files way. The
administration manual covers this topic. You can't expect to get a
working database recovery by copying the database files itself.

[Tony Hinkle]

Re: DB2 and File Replication

nyook@gmx.net (Almund Sebi) wrote in message news:<947ecaa1. 0401300026.f1dd 12f@posting.goo gle.com>...[color=blue][color=green]
> > I basically need to know how to identify what files need to be
> > replicated for the default databases and others that are mounted. I
> > would greatly appreciate any offered assistance.[/color]
>
> I think you should go the online backup & log files way. The
> administration manual covers this topic. You can't expect to get a
> working database recovery by copying the database files itself.[/color]

Thanks for your input, but I still need the requested information.
File replication software allows you to have a real-time (almost) copy
on one or more targets, control bandwidth usage, etc., and setup is
easier and failover is much quicker since you don't have replay logs.
I realize that the files may sometimes be in a state that the database
is not recoverable, but they should be recoverable most of the time.
Microsoft Exchange, for example, has a 1:1000 rate of failare to
recover on files when the database is not cleanly shut down.

Anyway, I don't want to get into a discussion of which way is best in
what situations. The bottom line is that our customers are asking for
it.

Thanks.

[Erik Hendrix]

Re: DB2 and File Replication

If your customers are asking for it then you should give them another option
which is better.
File replication will have the possibility that your database is corrupt
without you knowing it.
Do you really want to run that chance?

Much better to do restore and then just keeping on replaying the log files.
Depending on the
software/hardware you have, you can use some type of snapshot of the
database.
You would then use SUSPEND and RESUME to have the database stop writing to
the
tablespaces etc.., in between the SUSPEND/RESUME you take your copy.
Depending on the software/hardware, this would be then that eveyrthing is
already in sync
and in between the SUSPEND/RESUME you just do a split, or it stores any
changes
after the SUSPEND/RESUME somewhere else allowing it to copy over the data as
it
was in between the SUSPEND/RESUME.



"Tony Hinkle" <tonyhinkle@yah oo.com> wrote in message
news:b6d753d0.0 402020606.20a01 a7d@posting.goo gle.com...[color=blue]
> nyook@gmx.net (Almund Sebi) wrote in message[/color]
news:<947ecaa1. 0401300026.f1dd 12f@posting.goo gle.com>...[color=blue][color=green][color=darkred]
> > > I basically need to know how to identify what files need to be
> > > replicated for the default databases and others that are mounted. I
> > > would greatly appreciate any offered assistance.[/color]
> >
> > I think you should go the online backup & log files way. The
> > administration manual covers this topic. You can't expect to get a
> > working database recovery by copying the database files itself.[/color]
>
> Thanks for your input, but I still need the requested information.
> File replication software allows you to have a real-time (almost) copy
> on one or more targets, control bandwidth usage, etc., and setup is
> easier and failover is much quicker since you don't have replay logs.
> I realize that the files may sometimes be in a state that the database
> is not recoverable, but they should be recoverable most of the time.
> Microsoft Exchange, for example, has a 1:1000 rate of failare to
> recover on files when the database is not cleanly shut down.
>
> Anyway, I don't want to get into a discussion of which way is best in
> what situations. The bottom line is that our customers are asking for
> it.
>
> Thanks.[/color]

[Ian]

Re: DB2 and File Replication

Tony Hinkle wrote:
[color=blue]
> nyook@gmx.net (Almund Sebi) wrote in message news:<947ecaa1. 0401300026.f1dd 12f@posting.goo gle.com>...
>[color=green][color=darkred]
>>>I basically need to know how to identify what files need to be
>>>replicated for the default databases and others that are mounted. I
>>>would greatly appreciate any offered assistance.[/color]
>>
>>I think you should go the online backup & log files way. The
>>administratio n manual covers this topic. You can't expect to get a
>>working database recovery by copying the database files itself.[/color]
>
>
> Thanks for your input, but I still need the requested information.
> File replication software allows you to have a real-time (almost) copy
> on one or more targets, control bandwidth usage, etc., and setup is
> easier and failover is much quicker since you don't have replay logs.
> I realize that the files may sometimes be in a state that the database
> is not recoverable, but they should be recoverable most of the time.
> Microsoft Exchange, for example, has a 1:1000 rate of failare to
> recover on files when the database is not cleanly shut down.
>
> Anyway, I don't want to get into a discussion of which way is best in
> what situations. The bottom line is that our customers are asking for
> it.
>[/color]

The point here is that you would be creating a situation where the database
will _not_ be supported by IBM. I can't imagine that this is what your
customers _really_ want.

IBM provides (and supports) the ability to utilize the split-mirror
or flash-copy facilities provided by disk storage vendors; this involves
suspending all I/O activity in the database while the disk subsystem
splitsits mirror. During this period (usually just a few seconds), the
database will appear to hang. If you are set on using file "replicatio n,"
then this is probably the "safest" way of accomplishing what you are
trying to do. The downside here is that you will lose transactions
(either because the replica is old, or because any transactions in
flight during the replica process will be rolled back to bring the
replica database online).

It is also possible to implement replication on a storage subsystem (EMC
SRDF) or volume level (Veritas Volume Replicator), but it does not sound
like this is what you're doing (because it's not possible to control the
bandwidth for these -- the bandwidth requirements here are dependent on
write activity on the volumes to be replicated.

If you are looking for a "poor man's HA" solution (as opposed to
implementing clustering through Sun Cluster/HACMP/MSCS), you should
really consider using log shipping (as suggested earlier). You control
the frequency at which log files are applied to the standby database,
which affects how long it takes to bring up the database after a
failure. Also, I'd argue that your bandwidth utilization could be
lower, because you are only shipping log log files (and an occaisional
full database backup) between systems, as opposed to shipping a
complete copy of the database on a regular basis. The following
article describes how to implement log shipping:

http://www-106.ibm.com/developerworks/db2/library/techarticle/0304mcinnis/0304mcinnis.html

Given all of these considerations, if you still want to do file-
replication, here's what you need:

1) Contents of the local database directory (you can get this path from
a database snapshot)

2) All of the tablespace containers (use db2look -l to see all containers)

3) The log directory (this is shown in the database configuration)

Also check the command reference for the SUSPEND WRITE / RESUME WRITE
commands.


Good luck,






-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[David Penney]

Re: DB2 and File Replication

Unless the database has been shutdown you should not copy the database
files,even then you should ask for adviice about if those files can be used
on another computer & what the processs is for that. Dont base your
expectation on knowledge of MS-Exchange. Very different.

You should encourage your client to contact IBM & you work with them. Your
local support centre (SPC) should provide quick advice -e.g. in UK its
Hursley Labs, there is one in Chicago etc etc across the world.

Unless of course you are thinking of retiring or really dont care if you
provide a workable solution to your client. If you want to keep control
then you can take out a support contract yourself for a small amount of
money & ask your SPC for advice.

Regards,
David Penney - MetaMatrix

http://www.metamatrix.com

"Tony Hinkle" <tonyhinkle@yah oo.com> wrote in message
news:b6d753d0.0 402020606.20a01 a7d@posting.goo gle.com...[color=blue]
> nyook@gmx.net (Almund Sebi) wrote in message[/color]
news:<947ecaa1. 0401300026.f1dd 12f@posting.goo gle.com>...[color=blue][color=green][color=darkred]
> > > I basically need to know how to identify what files need to be
> > > replicated for the default databases and others that are mounted. I
> > > would greatly appreciate any offered assistance.[/color]
> >
> > I think you should go the online backup & log files way. The
> > administration manual covers this topic. You can't expect to get a
> > working database recovery by copying the database files itself.[/color]
>
> Thanks for your input, but I still need the requested information.
> File replication software allows you to have a real-time (almost) copy
> on one or more targets, control bandwidth usage, etc., and setup is
> easier and failover is much quicker since you don't have replay logs.
> I realize that the files may sometimes be in a state that the database
> is not recoverable, but they should be recoverable most of the time.
> Microsoft Exchange, for example, has a 1:1000 rate of failare to
> recover on files when the database is not cleanly shut down.
>
> Anyway, I don't want to get into a discussion of which way is best in
> what situations. The bottom line is that our customers are asking for
> it.
>
> Thanks.[/color]