SergSuper пишет:

> т.е. это разные технологии реализации, не влияющие на функционал?

В общем, да. Есть незначительные нюансы, типа того, что указал
mikron в начале топика -- одни лезут за ЛЮБЫМИ версиями
в страницы данных только чтобы понять, что версии устарели,
другие -- нет, в одних есть проблема "Snapshot is too old", а в других --
нет. Но в общем, цель достигается одна и та же --- обеспечить
уровень изоляции snapshot isolation (2).


> т.е. правильно было бы сказать /что Оракл имеет функционал версионника,
> но реализован не по технологии, изначально разработанной для версионников/
> с такой формулировкой и Вы и Yo согласны?

Нет, я не согласен. С "технологии, изначально разработанной для версионников"
не согласен. Просто это два разных подхода к реализации версионности.
При этом кажется даже ORACLE-овский похдод был придуман раньше, чем
"чистый версионный", но не уверен, надо знать историю IB и ORACLE хорошо,
а я не знаю.
Posted via ActualForum NNTP Server 1.4

mikron пишет:

> >> разные версии записей реально присутствуют на страницах данных
> получается по его-же определению т.к.
> у оракла разные версии находятся на страница данных (в логе)
> он - версионник :)

Страницы данных и лог -- разные вещи.
Posted via ActualForum NNTP Server 1.4

Apex пишет:

> Чем snapshot too old по своей природе, отличается от какой-нибудь "no
> free disk space" когда "настоящим" версионникаам уже писать эти версии
> некуда?

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

Но я скажу сразу, я не являюсь сторонником идеи, что одна реализация
лучше другой (я вообще люблю блокировочники ).
Posted via ActualForum NNTP Server 1.4

Yo.! пишет:

> в том то и дело, что разница огромна - "no free disk space" вырубит ВЕСЬ
> сервер, версионник с UNDO откатит только одну транзакцию, причем на
> длинные транзакции можно выделить отдельный UNDO.

UNDO надо видимо выделять не на длинные транзакции (они обычно
вообще читающие, потому что snapshot isolation только на чтении
даёт выгоду), а на все остальные транзакции, кроме длинных.

Разве нет ?

Posted via ActualForum NNTP Server 1.4

Di_LIne пишет:

> За циклическую перезапись логов в Винде Мелкомягких в свое время
> распустили на грелки...

Это -- общая практика в большинстве СУБД. И это -- логично.
А чем вам это не нравится ?
Posted via ActualForum NNTP Server 1.4

vadiminfo пишет:

> А на самом деле при ближайшем рассмотрении блокировочники?
> Или типа ни то ни се?

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

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

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

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

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

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

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

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

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

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

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

Игорь Горбонос пишет:

> А какая разница, что сбрасывать на диск, сами данные или лог для
> возможной recovery в любом случае диск затрагивается?

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

Страница данных же может содержать как изменённые, так и неизменённые
данные, а сбрасывать надо всю страницу целиком. Например, если
есть таблица из 100 страниц, и UPDATE, который меняет 10 записей,
но так, что на каждую из 100 страниц таблицы попадает по одной записи,
то по COMMIT-у в СУБД без журналирования придётся сбросить все
страницы таблицы, т.е. всю таблицу. Это очень плохо. Если записывать
только изменения в лог, и сбрасывать только лог, то скорее всего
это будет 1-2 страницы лога. Итого экономия порядка в 100 раз.
Posted via ActualForum NNTP Server 1.4