By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,017 Members | 979 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,017 IT Pros & Developers. It's quick & easy.

HADR performance issue

P: n/a
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.

Jul 26 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
"ebusiness" <we*******@hotmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.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.
Jul 26 '07 #2

P: n/a
On Jul 26, 7:00 pm, "Mark A" <nob...@nowhere.comwrote:
"ebusiness" <wendy_...@hotmail.comwrote in message

news:11**********************@j4g2000prf.googlegro ups.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.

Jul 27 '07 #3

P: n/a
"ebusiness" <we*******@hotmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.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).


Jul 28 '07 #4

P: n/a
On Jul 28, 12:45 pm, "Mark A" <nob...@nowhere.comwrote:
"ebusiness" <wendy_...@hotmail.comwrote in message

news:11**********************@j4g2000prf.googlegro ups.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.

Jul 30 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.