Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Apex пишет:


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

В реальном мире IB был известен своей тормознутостью на ровном месте.
Это в классическом варианте, естественно, не в современном.
Впрочем, я не большой знаток IB. Но вроде бы никто из СУБД больше
так не делал после них, и сами они отказались.

Posted via ActualForum NNTP Server 1.4

17 июл 09, 13:48    [7429103]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
MasterZiv

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

Хм... Или лог презаписывается последовательными блоками, что неизменно приведет к потере нужного, или есть еще и управление перезаписью блоков в логе.
Ну и каким местом второе лучше FB-шного?
Да и первое - бу-га-га.
17 июл 09, 14:24    [7429361]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
MasterZiv
А прикол в том, что в версионниках не было изначально лога вообще. В IB по крайней мене.

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

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

а тут вообще неверно.

Логи в IB НЕ реализовали. В IB 2007 сделали "журналирование", но оно опять же страничное, и вообще это просто "предварительная" запись не в базу, с переносом изменений в базу периодически по checkpoint.

И потом, где Вы услышали что "такой подход слабо оправдан"?

MasterZiv
В реальном мире IB был известен своей тормознутостью на ровном месте.

если тормознутость и была, то она обусловлена криворукостью разработчиков, т.е. неумением управлять транзакциями в версионнике. Если Вы на любом версионнике начнете держать snapshot-транзакции часами, то при большом числе обновлений Вы получите тучу версий в базе - хоть в логах, хоть где, что и приведет к замедлению работы.
Но опять же, про "тормознутость" в основном мифы, как про "ИБ тормозит на базах больше 200мб" во времена Win98.

В апреле мне удалось увидеть промышленную базу данных на Firebird 1.5, у которой из-а застрявшей на 5 суток транзакции snapshot в одной таблице образовалось примерно полтора миллиона версий для одной (!) записи. Как бы, эксплуататор был не в восторге от производительности, но база работала.
17 июл 09, 14:29    [7429409]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Yo.!
hvlad
Есс-но. В Firebird, при нехватке места на диске, тр-ция (тр-ции), которые создают версии, получат ошибку и спокойно продолжат работу. С какой стати что-то должно останавливаться ? Особенно читатели...

вот так и продолжат получая ошибку
в отличие от оракла стопорнут все пишущие транзакции, т.к. даже модифицирующим некуда будет версии строк сложить.
С какой стати все пишушие тр-ции непременно пишут в новые страницы ?
И, ещё раз, сам сервер ничего не "стопорнёт". Текущий оператор в тр-ции обломится с ошибкой, но тр-ция останется жить пока клиент не решит что с ней делать. Кстати, при откате оператора, место тоже освободится.
Не всё так просто, как кажется.
17 июл 09, 14:30    [7429418]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
MasterZiv
Впрочем, я не большой знаток IB. Но вроде бы никто из СУБД больше так не делал после них, и сами они отказались.

опять же, чудовищные фантазии.
1. "журналирование" было введено в InterBase 2007
2. в Firebird журналирования нет, пока не планируется
3. в IB2007 возможность журналирования является опцией, НЕ по умолчанию. Реально ее используют редко. То есть ~99% баз на IB 2007/2009 используются без журналирования.
4. если база IB 2007/2009, у которой включено журналирование, находится на внешних дисках (SAN), то производительность падает (относительно базы без включенного журналирования)

ну и наконец, журналирование в IB 2007 было введено в основном для защиты от сбоев.
17 июл 09, 14:39    [7429479]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
hvlad
Member

Откуда:
Сообщений: 11555
Игорь Горбонос
А какая разница, что сбрасывать на диск, сами данные или лог для
возможной recovery в любом случае диск затрагивается?
Последовательная запись намного быстрее случайной. Не на SSD, кстати.

MasterZiv
Лог тупо короче. И компактнее.
Типичное заблуждение. Это не правда.

MasterZiv
Лог содержить только данные
о изменении данных и они все лежать где-то в конце лога обычно.
И этих данных об изменениях может быть намного больше, чем самих данных. Кроме того, для восстановления нужны ещё и старые данные.

MasterZiv
Страница данных же может содержать как изменённые, так и неизменённые
данные, а сбрасывать надо всю страницу целиком. Например, если
есть таблица из 100 страниц, и UPDATE, который меняет 10 записей,
но так, что на каждую из 100 страниц таблицы попадает по одной записи,
то по COMMIT-у в СУБД без журналирования придётся сбросить все
страницы таблицы, т.е. всю таблицу. Это очень плохо. Если записывать
только изменения в лог, и сбрасывать только лог, то скорее всего
это будет 1-2 страницы лога. Итого экономия порядка в 100 раз.
Во-первых, в логе будет таки побольше данных.
Во-вторых, время записи 10 байт и 4КБ из одной страницы есть величина одинаковая.
В третьих, можно рассмотреть и обратный пример, когда одна и таже запись менялась многкратно - в лог уйдёт куча инф-ции, а в данные - одна страница.

Ну и совсем непонятно мне как 10 записей попадают на 100 страниц.
Пересчитаем "экономию" ?

Я это уже здесь кому-то объяснял...
17 июл 09, 14:39    [7429480]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
пгуые123
Guest
MasterZiv
Лог тупо короче.

Хороший у вас план тов. Жюков (С)
поробуйте из одной крупной табли в другу insert select сделать и засеките насколько изменится размер лога, а насколько у файла данных. ;)

а еще вспомните, что наличие лога означет необходимость записывать одни и те же данные 2 раза. чистому версионику этого делать не надо, данные сразу помещаются в датафайл.
17 июл 09, 14:51    [7429583]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Давно я в этот форум не заглядывал, а тут все то же и все те же. Yo рассказывает неприятные вещи про FB, оппоненты дружно его опровергают

Кстати, любопытно, а за это время в FB хоть одна "больная мозоль" рассосалась? Из тех, на которые и я, бывало, наступал. Вот у IB, как оказалось, уже даже лог есть.
17 июл 09, 14:57    [7429635]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
АГ
Yo рассказывает неприятные вещи про FB, оппоненты дружно его опровергают

нет, тут еще интереснее - зарождение новых мифов про ИБ.

АГ
Кстати, любопытно, а за это время в FB хоть одна "больная мозоль" рассосалась? Из тех, на которые и я, бывало, наступал.


какие-такие "больные мозоли"...

АГ
Вот у IB, как оказалось, уже даже лог есть.


нет у него лога. это миф.
17 июл 09, 15:08    [7429722]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
oracle forever
Guest
пгуые123

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

+APPEND

:P
17 июл 09, 16:12    [7430145]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
kdv

какие-такие "больные мозоли"...

да я уж и не вспомню сходу все, но навскидку:
- невосстановимый бэкап
- распараллеливание запросов в супер-сервере
- update tablename set a=b, b=a -- ну или что-то типа того на ту же тему
- статистика в индексах и планы зависящие от распределения данных
Что-нибудь из этого в FB с тех пор улучшилось?
kdv

АГ
Вот у IB, как оказалось, уже даже лог есть.


нет у него лога. это миф.

Т.е. лога, который можно представить в виде последовательности DML и DDL запросов там нет? Интересно, а кроме IB/FB есть еще "безлоговые" серверы? Просто любопытно. В PostgreSQL знаю точно есть WAL.
17 июл 09, 16:45    [7430365]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Di_LIne пишет:


> Хм... Или лог презаписывается последовательными блоками, что неизменно
> приведет к потере нужного, или есть еще и управление перезаписью блоков
> в логе.

Стираются из лога естетственно только старые блоки, содержащие
транзакции, уже прошедшие через checkpoint.

Posted via ActualForum NNTP Server 1.4

17 июл 09, 16:50    [7430400]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
MasterZiv

Стираются из лога естетственно только старые блоки, содержащие
транзакции, уже прошедшие через checkpoint.
А не прошедщие?
Хотя, как сказали выше, хватит и двойной записи на диск, что бы закрыть этот аспект для дискусси.
Намертво.
17 июл 09, 16:57    [7430457]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

kdv пишет:

Логи в IB НЕ реализовали. В IB 2007 сделали "журналирование", но оно опять же
страничное, и вообще это просто "предварительная" запись не в базу, с переносом
изменений в базу периодически по checkpoint.

А чем логи от журналирования отличаются ? Два разных слова на русском,
суть одна. Я вот пробежался по приведённой ссылке, там ровно то,
о чём я тут писал, и написано. И очевиден выигрыш от применения
журнала.

> И потом, где Вы услышали что "такой подход слабо оправдан"?

Это я нигде не слышал. Это я сам знаю, что такой подход
не оправдан.

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

> Вы на любом версионнике начнете держать snapshot-транзакции часами, то
> при большом числе обновлений Вы получите тучу версий в базе - хоть в

А зачем тогда нужна версионность вообще ? Без долгоживущих
транзакций я и на блокировочнике проживу замечательно.

> логах, хоть где, что и приведет к замедлению работы.
> Но опять же, про "тормознутость" в основном мифы, как про "ИБ тормозит
> на базах больше 200мб" во времена Win98.

Что такое базы больше 200 мб я вот лично слабо представляю.

> В апреле мне удалось увидеть промышленную базу данных на Firebird 1.5, у
> которой из-а застрявшей на 5 суток транзакции snapshot в одной таблице
> образовалось примерно полтора миллиона версий для одной (!) записи. Как
> бы, эксплуататор был не в восторге от производительности, но база работала.

Ну и слава Богу, сейчас-то IB всё же как никак похорошел. В основном
от того, что его в опенсоурс выложили и хорошие люди к разработке подключились.

Posted via ActualForum NNTP Server 1.4

17 июл 09, 16:57    [7430461]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

hvlad пишет:

> MasterZiv
> Лог тупо короче. И компактнее.
>
> Типичное заблуждение. Это не правда.

Естественно, это неправда. Это вообще зависит
от ваших транзакций. Но как правило транзакции маленькие,
а базы -- большие.

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

Ну я же специально придумал пример, чтобы показать, когда это плохо.

> Ну и совсем непонятно мне как 10 записей попадают на 100 страниц.
> Пересчитаем "экономию" ?

Ну, сложилось так. Например, хочу каждую 10 запись по возрастающему
PK поменять.

Posted via ActualForum NNTP Server 1.4

17 июл 09, 17:02    [7430490]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

пгуые123 пишет:

> поробуйте из одной крупной табли в другу insert select сделать и
> засеките насколько изменится размер лога, а насколько у файла данных. ;)

Ребята, не надо меня за советскую власть.

Понятно, что транзакции разные, и нагрузку на лог дают
разнюу. Но логи тоже не дураки придумали. Так что в среднем
в приложениях выгоднее писать на диск логи.

Posted via ActualForum NNTP Server 1.4

17 июл 09, 17:04    [7430504]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

kdv пишет:

> АГ
> Вот у IB, как оказалось, уже даже лог есть.
>
>
>
> нет у него лога. это миф.

Не, у него не лог, у него -- "журнал".

Posted via ActualForum NNTP Server 1.4

17 июл 09, 17:05    [7430515]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
MasterZiv
А чем логи от журналирования отличаются ? Два разных слова на русском,
суть одна. Я вот пробежался по приведённой ссылке, там ровно то, о чём я тут писал, и написано. И очевиден выигрыш от применения журнала.

логи может ничем от жураналирования и не отличаются. Только журналирование у IB 2007 служит только для "защиты" базы от сбоев. Т.е. если поместить базу в архив с логами, то можно восстановить из архива база + логи на некоторый момент, который точно выбрать нельзя, только по имеющемуся логу.

В упрощенном виде журнал IB 2007 представляет собой следующее:
1. пишем страницы не в базу а в "лог"
2. лог имеет фиксированный размер, по заполнению создается новый лог
3. логи циклические
4. по checkpoint информация из лога переносится в базу.
все.

Кажется что это похоже на логи СУБД с transaction/undo log, но здесь откатить или "накатить" лог нельзя, посмотреть лог нельзя, и т.п.

И никакого особенного выигрыша от применения журнала НЕТ.

MasterZiv
А зачем тогда нужна версионность вообще ? Без долгоживущих транзакций я и на блокировочнике проживу замечательно.

болезнь блокировочника - блокировки.
болезнь версионника - накопление версий.
нет в жизни счастья.

MasterZiv
Что такое базы больше 200 мб я вот лично слабо представляю.

сейчас я слабо представляю себе базы на IB/FB меньге гига, причем на десктопах.
Про промышленные 10-20-50-100-400 гиг я даже не говорю.

MasterZiv
Ну и слава Богу, сейчас-то IB всё же как никак похорошел. В основном
от того, что его в опенсоурс выложили и хорошие люди к разработке подключились

то есть, последний раз Вы что-то такое читали про ИБ-ФБ лет 8-9 назад. Потому что у IB нет открытых исходников, они у Firebird.
17 июл 09, 17:37    [7430757]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Yo.!
Guest
hvlad
С какой стати все пишушие тр-ции непременно пишут в новые страницы ?

например потому что датфайл и страницы не резиновые.

hvlad
И, ещё раз, сам сервер ничего не "стопорнёт". Текущий оператор в тр-ции обломится с ошибкой, но тр-ция останется жить пока клиент не решит что с ней делать. Кстати, при откате оператора, место тоже освободится.
Не всё так просто, как кажется.

помоему уже все поняли. вариантов у транзакции не так уж много - откатываться или ждать пока админ протрезвеет и пойдет искать "виновника". подозреваю, что в наше время терабайтных дисков - FB захлебнется в и/о гораздо раньше, чем уткнется в нехватку диска. фуллскан таблицы как я понимаю заставит читать все страницы таблицы, включая все накопившиеся версии строк всех записей таблицы.

что по тому примеру где 10 измененных записей на 100 страницах, то это скорее из DHW. но 100 записей на 100 разных страницах, которые чудно уместятся в одну страницу лога вполне реально на OLTP. т.е. лог потребует в 100 раз меньшее кол-во иопсов и при этом лог пишется последовательно, а не юлозить по всему диску расскладывая 100 страниц. ораклу тоже когда нибудь нужно будет разложить эти 100 страниц по датафайлам, но он уже не завязан на транзакцию - т.е. блокировки сняты, транзакция закоммичена - можно не спешить.

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

ну разве, что если это одна сумашедшая транзакция длбит несчастную запись. если запись долбят разные транзакции, то записей ФБ сделает не менее кол-ва коммитов.

>Кажется что это похоже на логи СУБД с transaction/undo log

лог транзакций это REDO, в UNDO версии строк.

>по checkpoint информация из лога переносится в базу.

дык, тогда это в полне полноценный WAL, чего его народ до "журнала" понизил ?
17 июл 09, 18:54    [7431215]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Yo.!,
В Postgre если есть старые версии(помеченные как убитые), то они со временем затираются новыми данными.
Это даёт некоторую фрагментацию, но tablespace так не растёт, как вы говорите.
17 июл 09, 18:57    [7431237]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
Yo.!
Guest
ОКТОГЕН
Yo.!,
В Postgre если есть старые версии(помеченные как убитые), то они со временем затираются новыми данными.
Это даёт некоторую фрагментацию, но tablespace так не растёт, как вы говорите.

пока жив "виновник" никто не позволит их пометить как "убитые".
17 июл 09, 19:28    [7431364]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30257
Yo!
дык, тогда это в полне полноценный WAL, чего его народ до "журнала" понизил ?

ок, пусть WAL, но после конкретного checkpoint в базе все будет так же, как и без WAL - версии, мусор, и т.п. Т.е. между checkpoint физически база от обычной (без WAL) не отличается.

В Firebird 2.x примерно то же самое можно получить время от времени вручную переводя базу в состояние lock/unlock (nbackup).
т.е. сделали lock - изменения пишутся в delta, чтение идет из базы и из delta.
сделали unlock - delta залилась в базу, имитировали checkpoint.
Если процесс автоматизировать, то получится почти тот же WAL что и в IB 2007/2009.

Грубо говоря, это дополнительный "write-cache", и все.
17 июл 09, 21:14    [7431608]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Yo.!

пока жив "виновник" никто не позволит их пометить как "убитые".

Yo.!, в 8.4 админ спокойно прибивает виновника штатными средствами.
17 июл 09, 23:40    [7431793]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MasterZiv

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

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


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



MasterZiv

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

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

MasterZiv


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

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


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


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

MasterZiv


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

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

MasterZiv


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

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

MasterZiv



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

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

Вообще логи, если это редо логи не для версионности, а для восстановления после сбоев. А архивные и после ошибок юзеров, дропнувших что-то. Впрочем, теперь Оракл надыбался для этого сегменты отката тоже использовать прямо в SQL моно запросо увидеть шо было час назад. Однажды, в командировке в спешке удалил по ошибке не то шо надо. Но уже было девятка. На требование юзерши вернуть все как было. Я к ее удовольствию тут же вернул. А када была восьмерка у моего коллеги, у того же закачика вернуть не удалось.
Но юзера в версиях не понимают, и потому ко мне стали относиться с большим доверием.
Поди плохая версионность?
а 10 Оракл и таблы уже дропнуте возвращает. Тоже пригадилось уже - правда, не у закзачика а во время разработки, но все равно приятно. Конечно, зависит от настроек, скока он там сохраняетДля коллег выглядело по насчалу как некий фокус.
17 июл 09, 23:52    [7431815]     Ответить | Цитировать Сообщить модератору
 Re: Выбор бюджетной базы для замены Postgres.  [new]
kdv
Member

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


никак они "разные копии данных" апдейтить не могут.
если одна транзакция обновила запись и не сделала commit, то никакая другая транзакция не может обновить эту же запись (!), потому что существует не-committed версия. в IB/FB это и есть единственный "признак блокировки".
И обновлять можно только самую последнюю committed-версию записи. Если в соответствии с уровнем изолированности транзакции ей такая версия не видна, то при попытке обновить предыдущие версии транзакция также получит облом. Нельзя обновить то, чего не знаешь.

Возможно, какие-то другие версионники, типа Lotus Notes или MS Exchange и создают одновременно два варианта результата, но в РСУБД невозможно одновременно существование двух разных committed версий одной и той же записи. Просто потому, что это нарушит целостность, и непонятно как другие транзакции будут это читать.
18 июл 09, 01:40    [7431927]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить