... т.е. с таким TIL, который отличается от "текущей" транзакции ? Ибо надо :-)

dimitrсомневаюсь. А аргументация у тебя зачетная, это да.Если основная трн стартовала как SNAPSHOT, то никаких новых результатов в базе она не видит. И когда она делает некую длительную обработку, то при попытке обновления изменённых другими транзакциями данных получит облом. Было бы разумнее сразу делать периодически проверку (в течение этой тягомотной обработки): не поменялись ли некоторые строки. Но для снапшота они всегда "нет, не поменялись".
А вот если бы такую проверку делать в автономке, стартующей из-под снапшота, но с TIL = RC, с выбросом исключения при обнаружении "измены", то было бы шоколадно.

dimitrа если был холостой апдейт / селект с локомНичто не мешает выполнить сначала:

- а затем уже лочить эту строку холостым апдейтом. И такое изменение уже будет видно в RC.

Гаджимурадов РустамНичто не мешает работать с транзакциями по уму."по уму" - это ты что именно имеешь в виду ? "короткие пишущие да длинные читающие", что ле ?

Гаджимурадов РустамP.S. Приведённый им пример - далеко не единственный,
там фантомов и и подводных камней хватает.Каких именно "фантомов", приведи пример, плз.

dimitrОн уже дошел до dummy-поля для ручного контроля лок-конфликтов.А что плохого в этом ? Транзакция Т1 стартовала некую обработка ("проведение инвойса номер 123", например; может несколько минут идти). Какой смысл её продолжать, если некий другой документ, который не должен меняться на протяжении всей этой обработки, вдруг поменялся, причём сразу после старта Т1 - лучше сразу обломаться, чем узнать про это через 5 минут.

Симонов Денислогирование статистики влияет на саму статистику. Причём КМК иногда это может быть существенно.Из DDL таблицы perf_log надо давно уже выкинуть все индексы, кроме ПК и вот этого:
(он позволяет быстро вытащить записи, которые добавились "вот прямо только что").
С ПК+одним индексом по таймштампу никаких особых тормозов быть не должно, тем паче что в таблицу эту пишутся только моменты "входа" и "выхода" из ХП, но не итерации внутри циклов и проч.

Симонов Денисupdate perf_log может давать блокировки и копить мусор.Не может он давать блокировки. Ибо апдейт идёт только на вызове для "выхода" из ХП, по ID'шнику, который был сгенерён вызовом "входа". Конфликтов там нет.

ЗЫ. Львиная доля лок-конфликтов - при попытках списать товара больше, чем возможно. На втором месте - сторнирование оплат по документам, там заголовки надо лочить. Но есть идейка, как это обойти.

dimitrА проведением инвойса за 5 минут ты меня вообще убиваешь, у нас явно разные понятия об OLTP...я и сам тут "убитый" сижу, второй день уже... когда конкурентных аттачей нет (или их мало), то всё пучком, как только подкидываю дров - капут, вчера еще говорил :-)

0xFF.

Симонов ДенисНо мусор update будет генерировать в любом случае. Если это запускается на классике, то он там вообще никогда не собирается. А если на супере собирается фоновым сборщиком мусора, а это должно влиять на статистику.Отрубить-то сбор статистики недолго, всё же на одну ХП запитано (sp_add_to_perf_log). Добавить туда условие "если запрещено настройками - пшловон", и всего делов :-)
Но:
1) я туда пишу не только время вып-я, но и gdscode при аварийном завершении к-л ХП; это позволило увидеть процент аварийных завершений и причины их (т.е. на чём: user_exc, lock_conflict или что-то еще). А значит, можно сделать вывод о том, какой "КПД" у всего теста, т.е. сколько вообще полезной инфы пишется, а сколько обламывается.
2) при апдейте:
- в мусор попадает не так уж много: поля dts_end, elapsed_xx, fb_gdscode всегда перед этим пустые, а info почти всегда тоже пустое.
Да и вообще: какая свадьба без баяна, а база без мусора ? ;-)

Симонов ДенисА чего работу с логом как package не оформил?я глядел на твои мессаги в подфоруме ИБЭ, про пакеты которые... и как-то стрёмно стало еще и с этим упереться в какую-нить граблю... :-)