I must mention, that in the end of transaction (commit or abbort), logging is re-enabled automatically, so in most cases you just need to disable logging and then do nothing.Practically speaking – to disable logging to invent Sum Log TTS during inventory closing/recalculation, you need insert a call to I made this change for two installations and I had quite positive results: Inventory recalculation/closing time dropped from days to hours (about 15-20 times) and all locking between production operations and inventory closing/recalculation have been gone.
Since both installations use Weighted Average inventory model, routine inventory recalculation was causing some 2-3-5 millions of updates to Invent Trans table and, respectively, creation of the same number of records in invent Sum Log TTS table.
The worst part of it is that Invent Sum Log TTS table is locked in pessimistic mode.
It turned out that update statement in SQL (and update_recordset statement in Axapta respectively) place U-lock ON EVERY row it read. If update statement has simple logic (like ), the system either update a row (if it fits a where condition) and replace U lock with X, either it immediately release U lock (if row does not fit to the condition).
So for simple cases, U-lock is placed on a row for really short duration – from reading of a page into memory until end of the page’s in-memory scan.
But since detailed documentation on static/dynamic plan update algorithms is absent, not many people understand how Axapta actually use this table for plan updates; what are advantages and caveats of dynamic vs static plan use;how order explosion differs from regeneration planning and so on…