|
Problem IC96902
|
Status: Closed |
PERFORMANCE DEGRADATION OF HADR PRIMARY MAY OCCUR AFTER UPGRADING THE STANDBY TO V9.7 FP6 OR LATER FIXPAK. |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
After upgraded the HADR Standby to v9.7 FP6 or later fixpak, a
performance degradation of HADR Primary may occur.
From db2pd -hadr on Standby side, one problem can be observed
that Standby is using almost 0% of receive buffer,
2013-10-09-15.52.21.000999
PrimaryFile PrimaryPg PrimaryLSN
S0467575.LOG 26092 0x00004758AE52CC46
StandByFile StandByPg StandByLSN StandByRcvBufUsed
S0467575.LOG 26091 0x00004758AE52BFAA 0%
And from trace collection of EDU db2hadrs on Standby side, the
hdrAddLogFiles function will take more time to complete the log
initialization and specially opening log file is direct i/o -If
logging disks are slow, then in this direct i/o case, the
performance will be impacted.
581182 exit DB2 UDB oper system services sqloopenp cei
(2.3.15.825.2)
pid 5636136 tid 200465 cpid 4850536 node 0 sec 14 nsec
105142410
codepath = 2:11:15:16:20:46:48:49
rc = 0
bytes 16
Data1 (PD_TYPE_SQO_FILE_HDL,8) File handle:
File Handle = 518
File System Block Size = 0 bytes
File System Type = UNKNOWN
File Handle Flags :
Require Sector Align = No
DIO/CIO Mode = Yes
Raw Block Device = No
Reserved Handle = No
Flush On Close = Yes
Thread-Level Lock = No
Write-through Mode = No
File Not Tracked = No
Slower disk operation will adds up to a case that db2hadrs on
Standby is busy with I/O manipulation for log initialization,
during this time db2hadrs will not response any request from
HADR Primary, therefore, HADR Primary may see performance
degradation if db2hadrs spent longer time to initialize the log. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL USERS *
****************************************************************
* PROBLEM DESCRIPTION: *
* See Error Description *
****************************************************************
* RECOMMENDATION: *
* Upgrade to v9.7 FP9 or use the local fix as workaround. *
**************************************************************** |
| Local Fix: |
Set a registry variable DB2_LOGGER_NON_BUFFERED_IO=OFF on HADR
Standby to get back the file system cache performance, however
the side effect of DB2_LOGGER_NON_BUFFERED_IO=OFF is that it
will enable all normal log operations to use File System Cache
as well, this will incur overhead of File System Cache
Management and side performance effect, specially after takeover
the new primary will be impacted. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
This problem has been fixed in v9.7 FP9 |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 14.10.2013
17.12.2013
17.12.2013 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP9
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.9
|
 |
| 9.7.0.9
|
|
