Benjamin,
> Does the stack trace match what you have, even in part?
Yes, it does.
We are still experiencing occasional RSAM corruptions that are back again after some time of absence.
Does FAST CACHE have any settings? If so, cannot find such in the docs.
I have an idea to find out a culprit, please let me know if it makes any sense.
Taking into account that a culprit corrupts memory, perhaps, hours before a victim encounters it, we will dump buffer headers at regular basis to find out an owner of the corrupted area, later.
If this idea makes sense, what should we dump, `onstat -g mem`,.. ? How do we get a memory block owner?
------------------------------
Sincerely,
Dennis
------------------------------
Original Message:
Sent: Fri October 25, 2024 07:04 AM
From: Benjamin Thompson
Subject: Memory block header in pool 'rsam' corruption
Dennis,
LOW is the default mode if you just run 'UPDATE STATISTICS'. Regardless, if USTLOW_SAMPLE is not set it cannot be that bug.
Another possible candidate: IT03769: FAST CACHE PROBLEM WHEN DROPPING TABLE OR DATABASE CAN ASSERT CRASH WITH BAD BLOCK HEADER MT_SHM_FREE 1
Does the stack trace match what you have, even in part?
I am not sure I can help much more. If I remember correctly 11.70.FC5 is from around 2005. When did you drop support? Do you have any entitlement to the latest 7.31 release which I think was 11.70.UD10 or something like that?
Ben.
------------------------------
Benjamin Thompson
------------------------------
Original Message:
Sent: Fri October 25, 2024 06:35 AM
From: Dennis Melnikov
Subject: Memory block header in pool 'rsam' corruption
Ben,
Thank you for the link.
- We don't use LOW.
- USTLOW_SAMPLE is set to 0 (zero).
------------------------------
Sincerely,
Dennis
Original Message:
Sent: Fri October 25, 2024 05:26 AM
From: Benjamin Thompson
Subject: Memory block header in pool 'rsam' corruption
Hi Dennis,
I don't believe there is any difference between UPDATE STATISTICS with or without the FORCE keyword except that if FORCE is not specified the engine may decide that updating statistics is not necessary (and do nothing) based on the AUTO_STAT_MODE and STATCHANGE parameters.
This looks a lot like:
IT09609: RSAM MEMORY POOL CORRUPTION RUNNING UPDATE STATISTICS ON TABLE WITH USTLOW_SAMPLE ENABLED (SET TO 1)
https://www.ibm.com/support/pages/apar/IT09609
Are you using sampling for UPDATE STATISTICS [LOW]?
Ben.
------------------------------
Benjamin Thompson
Original Message:
Sent: Thu October 24, 2024 02:46 AM
From: Dennis Melnikov
Subject: Memory block header in pool 'rsam' corruption
Hi,
I feel like I must inform you that we managed to discover that RSAM buffer header corruption results from UPDATE STATISTICS.
The memory got corrupted and later a random session encounters the failure.
Meanwhile, UPDATE STATISTICS FORCE does not corrupt memory.
------------------------------
Sincerely,
Dennis