hi all

сабж.
Вопрос родился в другой теме, по результатам несложного теста . Переношу его в отдельный топег.

Запускаем "большой DML", затем:
var-1: срубаем его, не дождавшись завершения. Причём, неважно, как срубать: через delete from mon$statements или просто грохнуть окно.
var-2: дожидаемся завершения, затем также срубаем коннект без commit'a.

Так вот: var-1 вызовет выполнение откатов, длительность их будет пропорциональна тому, сколько успел натворить этот срубленный DML. Мониторинг, к примеру, покажет в течение всего этого времени возрастающие значения счетчика backouts для коннекта, который только что срубили (якобы!).
А при var-2 ничего этого не произойдёт, мониторинг покажет сразу, что коннект исчез, никаких backout'ов не будет.

В чём причина этого ?

dimitrперечитывай статью про сейвпойнты, потом возвращайсяПеречитал.
dimitrКогда инициируется откат транзакции, то все изменения, выполненные в ее контексте, откатываются с помощью глобальной ТС транзакции , после чего данная транзакция подтверждается (!) в TIP (Transaction Inventory Page). Но если количество изменений, выполненных в контексте транзакции, становится слишком велико (порядка 10 ⁴ – 10 ⁶ записей), то хранение списков отката получается дорогостоящим и сервер удаляет глобальную ТС транзакции , переходя к стандартному механизму TIP для пометки транзакции как отмененной"Синий вариант" выполняется при срубании живого (выполняющегося сейчас ) стейтмента. Сколько там было выполнено изменений - по барабану, откатывать будет ВСЕ, хоть 100500 млрд. Даже gfix -shut full -force 0 не поможет.

"Малиновый вариант" выполнится при срубании " idle -коннекта", когда в нём bulk DML уже выполнен, но транзакция никак не завершена.
Статью перечитал дважды, объяснений вышеприведенному НЕ вижу.

ЗЫ. Единственный известный мне вариант избежать "синюшного варианта" - нехороший: тупо останавливать ФБ-демон и получить после рестарта тучу orphan backout'ов.

Нашёл. Просветление хоть и есть, но небольшое.dimitrОчевидно, что штатное удаление подмножества ТС, расположенных "глубже" глобальной, приведет к переносу всех изменений с их контекста на контекст глобальной ТС транзакции. Как будет показано ниже, каждый клиентский DSQL-запрос и представляет собой такое подмножество ТС. Таким образом, совокупность всех изменений, успешно выполненных в контексте транзакции, хранится в ее журнале отмены, обеспечивая этим упомянутую выше возможность замены состояния dead транзакции в TIP на committed. При указании параметра isc_tpb_no_auto_undo при старте транзакции глобальная ТС не создается и в случае штатного удаления текущего стека ТС совокупный журнал отмены просто удаляется. Важно понимать, что данный параметр не отключает механизм ТС как таковой, это невозможно с точки зрения гарантии атомарности SQL-операторов. Он отключает только ведение журнала отмены транзакции как единого целого.

Системные точки сохранения и обработка исключений

Существует несколько событий, которые приводят к созданию сервером системных (то есть неуправляемых пользователем) ТС:

1. Выполнение любого клиентского SQL-запроса. Как уже было сказано выше, это делается для обеспечения атомарности данного запроса, то есть при возниковении любого исключения во время выполнения запроса, изменения, внесенные им в БД, всегда будут отменены. По окончании выполнения запроса ТС автоматически удаляется .

ВОПРОС-1. При указании параметра isc_tpb_no_auto_undo при старте транзакции глобальная ТС не создается и вот эти слова ( отсюда ): Данная кляуза всего лишь отключает копирование изменений оператора на уровень транзакции (для последующей отмены всего сразу при rollback-е)- не противоречат ли друг другу ?

ВОПРОС-2. Что значит штатное удаление текущего стека ТС ?


И еще (возникло после прочтения фразы: "По окончании выполнения запроса ТС автоматически удаляется").

Есть несколько вариантов состояния базы, когда отменяются внесённые в рамках транзакции изменения:
Вариант-1. Если выполняющийся DML (например, 16-й по счету с начала транзакции) напарывается на исключение, либо снимается по delete from mon$ statements where ..., - то откатывается только он один. Изменения остальных 15 - держатся, как раз потому, что каждый из DML-предшественников имел такую же возможность откатить "только себя".
Вариант-2. Если же после успешного завершения последнего DML будет отдана команда rollback, то будут отменены изменения как этого DML, так и всех предыдущих.
Вариант-3. Весь коннект срубается командой delete from mon$ attachments , либо вообще вся база тушится по gfix -shut. Короче - форсированное завершение всего коннекта, и неважно, по каким причинам.

Эмпирически легко устанавливается, что варианте-3 будет происходить сценарий варианта-1: сначала отмотка назад изменений последнего DML, и только после - "досвидос".

Так вот,

ВОПРОС-3. Почему при форсированном завершении коннекта было решено идти по варианту-1, а не -2 ?