12.10.FC15W1AWE Blocked in LONGTX

Hello everyone. How is it possible that 12.10.FC15W1AWE gets Blocked on LONGTX? DYNAMIC_LOGS is set to 2 but the engine was not adding any new logs (although there was more than enough space in ROOTDBS.) onmode -ky was impossible (it just hung) so rebooting the server was the only option. Thankfully Informix went into fast recovery and started normally. This is the first time in decades I see this. This was a major problem back in the days (does anyone recall tbzero?) Best regards, -Snorri ------------------------------ Snorri Bergmann ------------------------------

HI Snorri, tbzero existed in the past when the engine blocked and it did not have enough log space to rollback the long transactions. It was a tool that technical support used and was not provided to customers. It does not exist anymore since DYNAMIC_LOGS was introduced. Here is what you can do to avoid long transactions: Adjust the long-transaction high-watermark setting (LTXHWM ) Adjust the exclusive access, long-transaction high-watermark setting ( LTXEHWM) Adjust the size of log files If the log files are too small, the database server might run out of log space while rolling back a long transaction. In this case, the database server cannot block fast enough to add a log file before the last one fills. If the last log file fills, the system hangs. To fix the problem, shut down and restart the database server. Hope that this helps. Cordialement, Regards, Khaled Bentebal Directeur Général - ConsultiX Tél: 33 (0) 1 39 12 18 00 Mobile: 33 (0) 6 07 78 41 97 Email: khaled.bentebal@consult-ix.fr Site Web: www.consult-ix.fr Le 08/10/2024 à 16:43, Snorri Bergmann via IBM TechXchange Community a écrit : 010001926c95793e-34010821-cc9a-4d8f-90b1-96ba42f3db2d-000000@email.amazonses.com"> Hello everyone. How is it possible that 12.10.FC15W1AWE gets Blocked on LONGTX? DYNAMIC_LOGS is set to 2 but the engine was not adding any new... -posted to the "Informix" group

Could it be that the rollback was still going, but had hit the LTXEHWM threshold? onstat -x would have shown some movement if that was the case. If the logs had got to the point where the next log had an open transaction, you could have tried adding logs manually with onparams -a -i giving a few extra logs in the hope that the transaction would finish the rollback. If that was the case, then you may want to revisit the LTXHWM/LTXEHWM settings. There can also be issues with this and distributed transactions. ------------------------------ Mike Walker xDB Systems, Inc www.xdbsystems.com ------------------------------

Hi Snorri. When I taught the Admin classes I used to preach an extreme LTX setting, something like: LTXHWM 40 LTXEHWM 45Although I could not think of a way to prove it, I believe it should now be mathematically provable for a LTX block to happen. I reasoned that, should a LTX-rollback start and bleed into the exclusive LTX-rollback at 45% of log space, there is still at least as much available log space left for the rollback as you spanned getting into that mess in the first place. And the space you spanned getting to that 40% is shared my myriad other transactions so you were not really hogging all of that 40% in the first place. And once you are past that LTXEHWM mark no other transactions will get in the way of the rollback. Make sense to y'all? ------------------------------ Jacob Salomon --- Nobody goes there anymore, it's too crowded. --Attr: Yogi Berra ------------------------------

The way automatic DYNAMIC_LOGS works is: a flag is being set when it looks like the system might be running out of usable log space, then the so called periodic thread will submit a task to the db scheduler to get a log added. All this, as you might guess, doesn't work instantaneously, so if your system's filling the logs faster than what it will take these components to act, you can still end up in a situation where you don't have any space left for logging the addition of a new log file. -> any sign log files were filling very fast, say one or even multiple logs per second? Whether that log filling came from your long transaction or a different operation, and whether this happened during normal operation or during rollback of a (long?) transaction, is a separate question and probably not particularly material to your question. HTH, Andreas ------------------------------ Andreas Legner Dev Engineer HCL Software ------------------------------