G
George Potemkin
Guest
I know this bug well - we worked together with PSTS. The bug's symptoms: bi reads are (much) higher than bi writes,t he process that undoes transaction owns the MTX latch the most of the time. It's not the current case. The customer uses V10.2B0817 for main application and V10.2B0723 for the application mentioned at the beiginning of the topic. MTX latches are also used for BI log space allocation. What is "BI log space allocation"? Adding new bi cluster? Writing bi block to the disks? If MTX latch is locked during some very long operation then it's very likely that promon will catch the owner of the latch. The number of MTX/BIB/AIB latch locks used to be very close each other and close to the number of recovery notes generated by transactions. Example: Time MTX BIB AIB 18:25:41 2796.5 2580.5 2575.0 18:25:45 0 0 0 18:25:48 0 0 0 18:25:52 0 0 0 18:25:55 0 0 0 18:25:59 0 0 0 18:26:02 0 0 0 18:26:06 1086.5 1014.5 1017.0 18:26:09 0 0 0 18:26:13 0 0 0 18:26:16 0 0 0 18:26:20 0 0 0 18:26:23 0 0 0 18:26:27 0 0 0 18:26:31 2722.5 2590.0 2577.0 18:26:35 1734.5 1648.5 1641.0 18:26:38 0 0 0 18:26:42 0 0 0 18:26:45 0 0 0 18:26:49 0 0 0 18:26:52 0 0 0 18:26:56 0 0 0 18:26:59 2707.5 2562.5 2562.0 18:27:03 0 0 0 18:27:06 0 0 0 18:27:10 0 0 0 18:27:13 0 0 0 18:27:17 0 0 0 18:27:20 583.5 568.0 564.0 18:27:24 0 0 0
Continue reading...
Continue reading...