MasterZiv
Блокировочники конечно. Потому что WRITER-ов они разводят
путём применения блокировок.

А версионники как разрешают конфликт, когда два юзера пытаются изменять одну и туже запись.
По времени, по приоритету?
Они же разные копии данных апдэйтят - типа версионники.
Поскольку какая никакая версионность позволяет не блокировать читателя, а два писателя одновременно, не такое честоя явление, то все еще, возможно, преждевременно относить Оракл к блокировочникам - это может сбаить с толку: блокировочник в общепринятом значении обязан блокировать читателя, т.е. припишем Ораклу то чего нет.


> Что скрывается за понятием страница данных? У Оракла в явном виде такого
> понятия вроде как нет. Есть блоки, которые хранятся на диске либо в



MasterZiv
Ну тут я имел в виду всё, что не лог.

Ну тут осттается много места для предположений, что же это на самом деле.

MasterZiv

> датафайлах, либо в сегментах отката.

Значит, в сегментах отката.


Наверное не так поняли друг друга


> При этом может быть несколько версий в момент изменения блоков.
> Изменяемый блок до коммита ну типа хранится тока в оперативной памяти,
> если не считать инфу о всех изменениях и его в частности в журналах
> повторного выполнения.

MasterZiv

Я тебе скажу, он (блок данных) и после коммита может только в
памяти остаться.

Ну это наверное в СУБД у которых данные вседа в оперативке. Оракл кстати закупли и такую. По моему IN TIME MEMORY. Но сам Оракл закомиченне вынужден сбрасывать в дата файлы.
Или я не понял о чем утверждение.

MasterZiv

Я не очень понял, что ты тут спрашиваешь. Ну да, как бы данные в логах
всегда "главнее" данных в блоках данных.

Вот это пока не расшифровал. В каком смысле "главнее"?

MasterZiv


А прикол в том, что в версионниках не было изначально лога вообще.
В IB по крайней мене. Но это, опять -таки, давало отрицательный
эффект -- изменённые страницы данных надо было по commit физически
сбрасывать на диск. Но положительный эффект -- что у БД нет recovery,
так что сервер включил -- и он уже работает.

Но время показало, что такой подход слабо оправдан, поэтому в IB логи
реализовали.

Вообще логи, если это редо логи не для версионности, а для восстановления после сбоев. А архивные и после ошибок юзеров, дропнувших что-то. Впрочем, теперь Оракл надыбался для этого сегменты отката тоже использовать прямо в SQL моно запросо увидеть шо было час назад. Однажды, в командировке в спешке удалил по ошибке не то шо надо. Но уже было девятка. На требование юзерши вернуть все как было. Я к ее удовольствию тут же вернул. А када была восьмерка у моего коллеги, у того же закачика вернуть не удалось.
Но юзера в версиях не понимают, и потому ко мне стали относиться с большим доверием.
Поди плохая версионность?
а 10 Оракл и таблы уже дропнуте возвращает. Тоже пригадилось уже - правда, не у закзачика а во время разработки, но все равно приятно. Конечно, зависит от настроек, скока он там сохраняетДля коллег выглядело по насчалу как некий фокус.