HADR performance issue

"ebusiness" wrote in message
news:1185461168.310732.176250@j4g2000prf.googlegroups.com...
> Hi,
>
> I have setup a HADR between two servers in different locations.
> When I compare the application response time in standard environment
> and in HADR environment,
> I find the latter is more than twice slower than the former. I have
> tried to tune some parameters
> like DB2_HADR_BUF_SIZE, log buffer size, dbheap, but not much
> improvement.
>
> Can anyone give me some suggestions of how to improve HADR
> performance? We use sync mode of HADR.
>
> Thanks.

Use near synch.

It is just as good unless both servers crash at the same time.

On Jul 26, 7:00 pm, "Mark A" wrote:
> "ebusiness" wrote in message
>
> news:1185461168.310732.176250@j4g2000prf.googlegroups.com...
>
> > Hi,
>
> > I have setup a HADR between two servers in different locations.
> > When I compare the application response time in standard environment
> > and in HADR environment,
> > I find the latter is more than twice slower than the former. I have
> > tried to tune some parameters
> > like DB2_HADR_BUF_SIZE, log buffer size, dbheap, but not much
> > improvement.
>
> > Can anyone give me some suggestions of how to improve HADR
> > performance? We use sync mode of HADR.
>
> > Thanks.
>
> Use near synch.
>
> It is just as good unless both servers crash at the same time.

The project requires no data loss, but near sync can't archive this.

Well, synchronous distant replication cannot escape the "laws of
physics", so to speak.

Is there anything you can do about your network performance,
especially latency? The primary's logger must wait for log shipping
acknowledgements from the standby in order to ensure successful log
transfer, which is required to ensure against possible transaction
loss at failover.

Alternatively, can you relax your requirements at all? In most cases
a "lesser" synch mode will still keep the standby very close to the
primary. For many folks, the risk of rarely losing a few transactions
may be a fair trade-off in order to keep the production system humming
along.

If you can't consider such a trade-off, and you need distant DR
protection, then you may want to consider a hybrid configuration where
local HA is synchronous but the DR site is asynchronous, such as
deploying traditional failover (cluster manager, spare processor(s),
and shared/multiport disk(s)) locally, and HADR (< sync) to the remote
site for DR.

Regards,
- Steve P.
--
Steve Pearson, DB2 for Linux, UNIX, and Windows, IBM Software Group
"Portland" Development Team, IBM Beaverton Lab, Beaverton, OR, USA

"ebusiness" wrote in message
news:1185542950.462082.148170@j4g2000prf.googlegroups.com...
> The project requires no data loss, but near sync can't archive this.

Perhaps you don't understand how it works.

With near synch, when the application commits, DB2 guarantees that the data
is written to the DB2 transaction log on disk on the primary server (this is
normal even without HADR), and that the log information is successfully
written to the HADR buffer on the standby server. So even if the primary
server crashes before the data is written to the log disk files on the
standby server, it is in the log buffer on the standby and will be written
to log disk on the standby within a very short amount of time (it will not
be lost). This would happen before a takeover to the standby would take
effect.

Therefore, unless the standby server crashes within a few seconds of the
primary server crashing, you will not loose any data. The odds of both
servers crashing within a few seconds of each other are astronomical.

Keep in mind that if both primary and standby server did crash within a few
seconds of each other, you would know that, and simply choose to not do a
takeover to the standby (or a takeover by automated means would not be
possible because the standby server also crashed). So in this situation the
standby would not actually loose any data, since it would never be used as
the primary.

If your primary and standby servers have a slow network interface between
them, you are not EVER going to get the same level of performance as you
would without HADR. But even if they are close, "near synch" provides much
better performance in a high transaction environment, at only a miniscule
risk (actually non-existent risk IMO).

On Jul 28, 12:45 pm, "Mark A" wrote:
> "ebusiness" wrote in message
>
> news:1185542950.462082.148170@j4g2000prf.googlegroups.com...
>
> > The project requires no data loss, but near sync can't archive this.
>
> Perhaps you don't understand how it works.
>
> With near synch, when the application commits, DB2 guarantees that the data
> is written to the DB2 transaction log on disk on the primary server (this is
> normal even without HADR), and that the log information is successfully
> written to the HADR buffer on the standby server. So even if the primary
> server crashes before the data is written to the log disk files on the
> standby server, it is in the log buffer on the standby and will be written
> to log disk on the standby within a very short amount of time (it will not
> be lost). This would happen before a takeover to the standby would take
> effect.
>
> Therefore, unless the standby server crashes within a few seconds of the
> primary server crashing, you will not loose any data. The odds of both
> servers crashing within a few seconds of each other are astronomical.
>
> Keep in mind that if both primary and standby server did crash within a few
> seconds of each other, you would know that, and simply choose to not do a
> takeover to the standby (or a takeover by automated means would not be
> possible because the standby server also crashed). So in this situation the
> standby would not actually loose any data, since it would never be used as
> the primary.
>
> If your primary and standby servers have a slow network interface between
> them, you are not EVER going to get the same level of performance as you
> would without HADR. But even if they are close, "near synch" provides much
> better performance in a high transaction environment, at only a miniscule
> risk (actually non-existent risk IMO).

Thanks guys, I'll try to persuade the management team to believe that
NEARSYNC can provide the data protection that meets the business
requirements.