DB 7.2 Replication And DR

[johnm]

Here is my situation.

We run a very mission critical application that uses DB2 7.2 for the data
repository. The database is hosed at a data center in Los Angeles, Ca.

Our main office is in Portland, Oregon.

For disaster recovery purposes, we have been conducting an offline backup of
the database each night, and then sending the backup file and the log files
to our Portland office over a T1 connection. We have a DR machine in
Portland that is identical to the production machine in LA. In the event of
a problem, our plan was to restore the back up and log files to the Portland
machine and then redirect all users to that database.

First Issue: Because of the increasing database size, we have reached the
point where the overnight time window is not enough to complete the backup
and file transfer process before the start of business the next day.

Second Issue: Since this is a mission critical application, we have been
instructed that in the event of a problem, the application can only be
unavailable for 1 hour. RTO = 1 hr. We also cannot stand to loose more than
1 hours worth of data. RPO = 1 hr. Therefore, our old plan, which could
cause a data loss of 24 hours, is no longer good enough.

I am toying with the notion of replicating the database in LA to the DR
machine in Portland over the T1 link. Is this possible? Can it be done?
Would it accomplish our objectives?

Given this situation, what is the best way to accomplish our DR goals? (RTO
= 1 hr. and RPO = 1 hr.)

Any help with this is greatly appreciated.

Thanks in advance,

John

[Ian]

johnm wrote:

We run a very mission critical application that uses DB2 7.2 for the data
repository. The database is hosed at a data center in Los Angeles, Ca.
I hope you mean "hosted" not "hosed". :-)

I am toying with the notion of replicating the database in LA to the DR
machine in Portland over the T1 link. Is this possible? Can it be done?
Would it accomplish our objectives?
Using replication for an HA solution is generally a bad idea. Much too
complicated.
Given this situation, what is the best way to accomplish our DR goals? (RTO = 1 hr. and RPO = 1 hr.)

With DB2 UDB V7.2 (which is out of support, as you probably know), your
options are limited.

Have you looked into log shipping (you only ship the log files you need
and an occaisional full backup). There is a good article on DB2
Developer Domain about implementing this,

http://tinyurl.com/89vwg

and it includes links to docs on other HA features and DB2 UDB.

[Larry]

I would migrate to V8.2 and use Q-Replication. But Ian is kinda right
.... you have to maintain a subscription for each table. But there are
people doing this at 1000s txns/sec and maintaining < 1 sec latency. Ask
your IBM rep.

Larry Edelstein

johnm wrote:

Here is my situation.

We run a very mission critical application that uses DB2 7.2 for the data
repository. The database is hosed at a data center in Los Angeles, Ca.

Our main office is in Portland, Oregon.

For disaster recovery purposes, we have been conducting an offline backup of
the database each night, and then sending the backup file and the log files
to our Portland office over a T1 connection. We have a DR machine in
Portland that is identical to the production machine in LA. In the event of
a problem, our plan was to restore the back up and log files to the Portland
machine and then redirect all users to that database.

First Issue: Because of the increasing database size, we have reached the
point where the overnight time window is not enough to complete the backup
and file transfer process before the start of business the next day.

Second Issue: Since this is a mission critical application, we have been
instructed that in the event of a problem, the application can only be
unavailable for 1 hour. RTO = 1 hr. We also cannot stand to loose more than
1 hours worth of data. RPO = 1 hr. Therefore, our old plan, which could
cause a data loss of 24 hours, is no longer good enough.

I am toying with the notion of replicating the database in LA to the DR
machine in Portland over the T1 link. Is this possible? Can it be done?
Would it accomplish our objectives?

Given this situation, what is the best way to accomplish our DR goals? (RTO
= 1 hr. and RPO = 1 hr.)

Any help with this is greatly appreciated.

Thanks in advance,

John

[RdR]

Hi JohnM,

If it is just the database that you need to be highly available, you can use
Data Propagator so that you can replicate a change as it happens. This will
also allow you to distribute the changes within a one day period rather than
in one batch - near real time data replication. One good thing about Data
Propagator is that you do not need to setup an MQ environment as would be
needed if you use Q Replication. Even if you already have MQ, you would
still need to make sure that you might still need to upgrade your MQ
environment especially if you are just using it for messaging - if you go Q
Replication. Having said that, Data Propagator's performance will start to
degrade once you hit the 5,000/changes per second data change rate, in which
case Q Replication may be a better option (more IT investments might be
needed though (go DB2 8.2 as per one of th esuggestions in this thread but
still cheaper than not meeting Service Level Agreements). I have seen this
in situations wherein volumes hit the 5,000 per second change.

Hope this helps,

RdR

"johnm" <jo***@matrixsg.com> wrote in message
news:11*************@corp.supernews.com...

Here is my situation.

We run a very mission critical application that uses DB2 7.2 for the data
repository. The database is hosed at a data center in Los Angeles, Ca.

Our main office is in Portland, Oregon.

For disaster recovery purposes, we have been conducting an offline backup
of
the database each night, and then sending the backup file and the log
files
to our Portland office over a T1 connection. We have a DR machine in
Portland that is identical to the production machine in LA. In the event
of
a problem, our plan was to restore the back up and log files to the
Portland
machine and then redirect all users to that database.

First Issue: Because of the increasing database size, we have reached the
point where the overnight time window is not enough to complete the backup
and file transfer process before the start of business the next day.

Second Issue: Since this is a mission critical application, we have been
instructed that in the event of a problem, the application can only be
unavailable for 1 hour. RTO = 1 hr. We also cannot stand to loose more
than
1 hours worth of data. RPO = 1 hr. Therefore, our old plan, which could
cause a data loss of 24 hours, is no longer good enough.

I am toying with the notion of replicating the database in LA to the DR
machine in Portland over the T1 link. Is this possible? Can it be done?
Would it accomplish our objectives?

Given this situation, what is the best way to accomplish our DR goals?
(RTO
= 1 hr. and RPO = 1 hr.)

Any help with this is greatly appreciated.

Thanks in advance,

John

[Steve Pearson (news only)]

If you're going to consider moving to V8.2 anyway, another solution you
should definitely look at is HADR, which is highly suited to exactly
this kind of disaster recovery scenario. HADR essentially automates
the hand-rolled log shipping solution mentioned above, while reducing
the granule of transfer to a log buffer flush (down from a full log
file). This means the standby can run very close behind the primary,
with little (ASYNC mode) or no (SYNC mode) transaction loss possible at
failover. In addition, having the standby keeping up to current work
on the primary means that failover can be accomplished very quickly
(typically from a few seconds to a few minutes), as there is little or
no additional log data to play through at the time the operation is
initiated.

HADR is also very simple to set up and manage. HADR operates on an
entire database, replicating all logged operations, as opposed to other
DB2 Replication offerings that require configuration by database
object.

Whether your existing comm facility is sufficient depends on a couple
main factors:

1. Whether it can handle the expected data rate. You can estimate the
data rate by looking at how fast your system generates DB2 log data.
With HADR, the amount of data transferred will be modestly greater than
the existing log generation rate (due some log pages being sent more
than one time as they fill up, and to occasional control messages).

2. Depending on the synchronization mode you choose, the round trip
latency on your network could also come into play. SYNC and NEARSYNC
modes require acknowledgements of log data receipt from standby to
primary, and can put backpressure on the logging rate of the primary if
they are not delivered fast enough (in context of what load the
application is driving).

http://www-306.ibm.com/software/data/db2/udb/hadr.html

http://publib.boulder.ibm.com/infoce...n/c0011267.htm

ftp://ftp.software.ibm.com/ps/produc...S/db2hae81.pdf
(Chapter 7)

Regards,
- Steve P.
IBM DB2 UDB for LUW Development
Portland, OR

[Fred Nurk]

I would go for HADR as suggested previously. I am using HADR between a
database in Sydney (AU) and Auckland (NZ), this works like a dream. The
automatic client reroute helps as well so the clients automatically switch
over to the standy when we bring the primary down.

Cheers,

"Steve Pearson (news only)" <st*******@my-deja.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

If you're going to consider moving to V8.2 anyway, another solution you
should definitely look at is HADR, which is highly suited to exactly
this kind of disaster recovery scenario. HADR essentially automates
the hand-rolled log shipping solution mentioned above, while reducing
the granule of transfer to a log buffer flush (down from a full log
file). This means the standby can run very close behind the primary,
with little (ASYNC mode) or no (SYNC mode) transaction loss possible at
failover. In addition, having the standby keeping up to current work
on the primary means that failover can be accomplished very quickly
(typically from a few seconds to a few minutes), as there is little or
no additional log data to play through at the time the operation is
initiated.

HADR is also very simple to set up and manage. HADR operates on an
entire database, replicating all logged operations, as opposed to other
DB2 Replication offerings that require configuration by database
object.

Whether your existing comm facility is sufficient depends on a couple
main factors:

1. Whether it can handle the expected data rate. You can estimate the
data rate by looking at how fast your system generates DB2 log data.
With HADR, the amount of data transferred will be modestly greater than
the existing log generation rate (due some log pages being sent more
than one time as they fill up, and to occasional control messages).

2. Depending on the synchronization mode you choose, the round trip
latency on your network could also come into play. SYNC and NEARSYNC
modes require acknowledgements of log data receipt from standby to
primary, and can put backpressure on the logging rate of the primary if
they are not delivered fast enough (in context of what load the
application is driving).

http://www-306.ibm.com/software/data/db2/udb/hadr.html

http://publib.boulder.ibm.com/infoce...n/c0011267.htm

ftp://ftp.software.ibm.com/ps/produc...S/db2hae81.pdf
(Chapter 7)

Regards,
- Steve P.
IBM DB2 UDB for LUW Development
Portland, OR