Gluk (Kazan)hvlad
Gluk (Kazan)Я говорил, что ее можно применить, для решения этих нежданчиков (что собственно Oracle и делает)
Как он это делает, объяснять надеюсь не надо ???А объясни убогому, может америку откроем.

PS Решение этой проблемы в разработке, оно обкатывается. И конкретно для insert версионность не нужна. Вот для update\delete - да, помогает.

А чоб не объяснить Особенно если юродствовать перестанешь.Я и не начинал :)

Gluk (Kazan)Применяется просто. В момент начала SQL-запроса, фиксируется SCN и все данные для выполнения этого запроса берутся из блоков согласованными на момент этого SCN. insert (и update тоже) просто не видят то что они наизменяли физически. Многовато-же блоков приходится ему запоминать...

Gluk (Kazan)Есть правда толстый нюанс с миниоткатами, но кто-ж сказал, что надо делать именно как в Oracle??? Именно так в Firebird не сделано, причём сознательно. Считается, что прикладной разработчик сам в состоянии обработать конфликт обновления и решить - повторять ему запрос или нет.


Firebird (думаю как и все остальные транзакционные СУБД) имеет (в основном в памяти) лог изменений, сделанных каждым запросом (undo-log).
Конкретно для insert'ов это разреженный битмап с номерами вставленных записей. Использовать его для корректной работы insert from select не просто, а очень просто.
Для отслеживания изменений, произведенных update\delete, используется всё тот же undo-log. Иногда бекверсия хранится прямо в нём, иногда приходится доставать её с диска (в основном из кеша, конечно). Расписывать подробности пока не хочу.

Так что для insert from select версионность никак не нужна :)

SiemarglИнтересно, а памяти как хватает при массовых операциях, см.как у Оракла?Промежуточные бекверсии переливаются на диск, после превышения некоторого порога в памяти.