Здравствуйте, Gt_, Вы писали:

КДВ>>оба случая — уровень изолированности snapshot.

Gt_>и какое отношение к спору имеет snapshot ? речь шла о READ COMMITTED. я не пойму — вы тоже утверждаете, что с помощью неких параметров Read committed транзакции можно получать консистентный набор ?? (в том топике эфект неконсистентного набора вы упорно называете "неатомарным" )

snapshot конечно никакого отношения к делу не имеет. да, неконсистентный набор я называю неатомарным, что в принципе
одно и то же. Насчет возможности атомарного, или консистентного набора в RC, я не утверждаю, потому
что в IB/FB это невозможно. Вернее, возможно, с оговорками, и в случае когда в плане запроса
есть конструкция SORT.

Gt_>аргументация чАго ? что RC в IB/FB способен получить консистентный набор ? что RC в oracle на это не способен ? я не понимаю что вы своей аргументацией хотите сказать ...

типичное передергивание
а) я про Оракл ничего не хочу сказать. у него запросы консистентные в RC, и пусть
б) аргументацию я последовательно изложил в упомянутом топике на sql.ru
могу повторить еще раз. в IB/FB в уровне изолированности RC можно получить консистентный набор для Select
только если на время select перевести уровень изолированности в snapshot.
Надеюсь, понятно, почему? Если нет, отвечу — в IB/FB нет блокировок по чтению. есть версионность.
Также, сам по себе read committed предполагает нестабильность результатов отдельных select.
это стандартно. Следовательно, если разные select относительно друг друга нестабильны, то это
нормально. А если сам select нестабилен в RC — это ненормально? Так вот, ненормальность можно
исправить выполнением запроса в "микро-snapshot", если позволите такой термин.
Отсюда я делаю вывод, что подобная функциональность хоть и возможна, но не нужна.
Потому что RC не предназначен для "стабильности" как уровень изолированности non-repeatable read.

Gt_>не понял при чем тут cursor stability, но сразу вопрос — что на IL snapshot "insert into table1 select * from table1" не зациклится !?

понятно. то есть Вы, это еще один маньяк, который приколебался к этому пресловутому insert into select,
который в свою очередь к уровню изолированности никакого отношения не имеет, потому что выполняется
в одной транзакции, т.е. видит свои же данные. Как бороться с ЭТИМ — давно известно.
Фатальным это не является. считайте это implementation defined. И еще раз подчеркну — это
не относится к уровням изолированности транзакций вообще никаким боком.

КДВ>>тут непонятно, почему база осталась corrupted, если бэкап был восстановлен.

Gt_>бэкап делался до прогона теста, т.е. на него еще нужно накатить лог.

ну если так... А если выдернуть диск с логом? Впрочем, это уже обсуждали в "сравнении СУБД",
в отношении Оракла и MS SQL.
Относительно IB/FB могу сказать, что в них восстановить базу можно либо до уровня
последнего бэкапа, либо до уровня последнего инкрементного бэкапа в FB 2 или до уровня
последнего архивированного журнала в IB 2007. Что в принципе одно и то же.
И конечно, так как из лога журналов, здесь состояние базы не восстановить, ни в IB ни в FB.