HADR performance issue

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • ebusiness
    #1

    HADR performance issue

    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_SI ZE, 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.

    Tags: None
    • Mark A
      #2
      Re: HADR performance issue

      "ebusiness" <wendy_xie@hotm ail.comwrote in message
      news:1185461168 .310732.176250@ j4g2000prf.goog legroups.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_SI ZE, 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.


        Comment

        • ebusiness
          #3
          Re: HADR performance issue

          On Jul 26, 7:00 pm, "Mark A" <nob...@nowhere .comwrote:
          "ebusiness" <wendy_...@hotm ail.comwrote in message
          >
          news:1185461168 .310732.176250@ j4g2000prf.goog legroups.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_SI ZE, 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.

            Comment

            • Mark A
              #4
              Re: HADR performance issue

              "ebusiness" <wendy_xie@hotm ail.comwrote in message
              news:1185542950 .462082.148170@ j4g2000prf.goog legroups.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).




                Comment

                • ebusiness
                  #5
                  Re: HADR performance issue

                  On Jul 28, 12:45 pm, "Mark A" <nob...@nowhere .comwrote:
                  "ebusiness" <wendy_...@hotm ail.comwrote in message
                  >
                  news:1185542950 .462082.148170@ j4g2000prf.goog legroups.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.

                    Comment

                    Previous template Next
                    Working...