Oracle: statement-level write consistency question.

tengiz · Post by **tengiz** » 07 Nov 2003 18:56

vc wrote:Please check you personal messages. I've sent you one about how to get more information on the stuff we've been discussing.

Thanks, I will definitely check it as soon as it arrives. For some bloody reason sometimes it takes many hours for the the private message engine to deliver one.

tengiz · Post by **tengiz** » 07 Nov 2003 19:12

Dmitry67 wrote:Why not implement a AWARD_WINNING_CRITICAL_BENCHMARK_MODE=ON/OFF ?

Да ладно, Дима, не издевайтесь. Сами знаете - техническая публика в таких случаях обычно не причём. Наверняка решение об этой "оптимизации" было продавлено руководством с подачи продавцов/маркетологов. Вполне допускаю, что именно по таким причинам из разработчиков ядра уходят хорошие специалисты. А ядро Oracle делала отличная команда. Чем больше я с ним осваиваюсь, тем больше проникаюсь уважением к этим незнакомым мне людям. Как я уже говорил, для разработки которой уже 10 лет ядро Oracle - выше всяких похвал за продуманность и целостность концепции, за элегантный минималисткий и сбалансированный дизайн. Не хватает только одного - корректно написанной документации, со всеми необходимыми оговорками и граничными условиями. Хотя бы в таких вопиющих случаях, как те что мы разбирали.

zVlad · Post by **zVlad** » 08 Nov 2003 00:54

Tengiz, тут такая мысль созрела, типа рацпредложения - а что Вам поставить на Ваш компьютер DB2 (можно скачать с ИБМ-а за так), погонять её по полной программе и поделиться с народом своим мнением - уверен будет исключительно интересно.

tengiz · Post by **tengiz** » 08 Nov 2003 22:38

zVlad wrote:Tengiz, тут такая мысль созрела, типа рацпредложения - а что Вам поставить на Ваш компьютер DB2 (можно скачать с ИБМ-а за так), погонять её по полной программе и поделиться с народом своим мнением - уверен будет исключительно интересно.

Да с DB2 всё намного проще - стандартный блокировочкик сделанный по хорошо известным алгоритмам безо всяких хитростей. Вот что намного любопытнее - устройство Interbase, который сильно отличается от других версионников. А потом, IBM-у чуть ли не автобиоргафию нужно предоставить, чтобы зарегистрироваться и скачать trial версию DB2. Не говоря уже о времени - мы тут скоро должны вторую бету Yukon выкатить. На это раз публичую. Так что будем все заняты по самые ушки.

Merle · Post by **Merle** » 09 Nov 2003 00:33

Действительно... Давайте лучше, Тенгиз, мы вас по Юкону при случае немного по терзаем, если Вы не против, конечно... Ну и по Ораклу, чуть-чуть..

)
Кстати, если все-таки надумаете об этом.. ээ.. эффекте... по дискутировать с Томом, то киньте сюда ссылочку пожалуйста, очень любопытно будет почитать..

Big Cheese · Post by **Big Cheese** » 09 Nov 2003 07:44

tengiz wrote:
zVlad wrote:Tengiz, тут такая мысль созрела, типа рацпредложения - а что Вам поставить на Ваш компьютер DB2 (можно скачать с ИБМ-а за так), погонять её по полной программе и поделиться с народом своим мнением - уверен будет исключительно интересно.

Да с DB2 всё намного проще - стандартный блокировочкик сделанный по хорошо известным алгоритмам безо всяких хитростей. Вот что намного любопытнее - устройство Interbase, который сильно отличается от других версионников.

Tengiz, не могли бы Вы рассказать об отличительных чертах Interbase?

Прошу прощения за оффтопик (можно будет открыть отдельный топик, если тема получит продолжение). Мне бы было очень интересно услышать мнение(я) уважаемого сообщества об этом самом Interbase, как с точки зрения архитектуры, так и впечатления от использования в проектах - стабильность, масштабируемость, concurrency, производительность и все такое. Особый интерес для меня представляет [ опыт | впечатления от | возможность ] использования Interbase как embedded database engine, т.е. как ядро некоего серверного продукта, обеспечивающее, кроме, собственно, RDBMS functionality, еще и реюзание более "высокоуровневыми" подсистемами внутренних сервисов ядра Interbase- memory management, concurrency control, security/access right control, syncronization/locking, threading, network/disk I/O.

Заранее благодарен всем ответившим.

vc · Post by vc » 09 Nov 2003 22:41

tengiz wrote:... Вот что намного любопытнее - устройство Interbase, который сильно отличается от других версионников. ...

We considered briefly Interbase/Firebird for one of our projects.

Interbase is a multiversioning engine with the following pecularities:

1. Isolation levels:
SNAPSHOT
READ COMMITTED

a. Under the SIL, IB behaves in the manner identical to Oracle's SERIALIZABLE:

reads: w0[x0] c0 w1[x1] r2[x0] c1 r2[x0] c2 r2[x1]
writes: w0[x0] c0 w1[x1] c1 w[x2]* => transaction aborted.

When the younger transaction aborts, IB's error message is somewhat misleading : "deadlock-update conflicts with concurrent update" (Oracle's error message would be "cannot serialize").

The SIL is the default IL.

b. READ COMMITTED. It appears that originally IB had only SIL and the RCIL was added later on. There are two varieties of the RCIL:
b1: "read committed no record_version" that behaves so:

reads: w0[x0] c0 w1[x1] r2[x0] c1 r2[x1] c2 r2[x1]
writes: w0[x0] c0 w1[x1] c1 w2[x2]* => transaction aborted.

Quite similar to the SIL, but read consistensy is maintained only at the statement level (as opposed to the whole transaction level for the SIL).

b2. "read committed record_version". This is more interesting and resembles the locking scheduler behaviour:

reads: w0[x0] c0 w1[x1] c1 r2[x1]
writes: w0[x0] c0 w1[x1] c1 w2[x2]

In other words, both reads and writes are _blocked_ by the older write transaction until the time such transaction commits.

Both RCIL varieties have the 'NOWAIT' option whereby, upon detecting a conflict, the younger transaction returns immediately with an error code.

2. IB appears to have a locking manager similar to SQL Server/DB2 and no row level lock bytes (as Oracle does).

3. IB does not have a construct similar to Oracle's "SELECT FOR UPDATE", and the usual trick to lock a specific row is to use an actual update statement. Firebird 1.6 (not yet released as of the time we ran our tests) promises to implement something similar ("SELECT FOR UPDATE WITH LOCK"), though.

4. IB uses garbage collection ("sweep") to get rid of old dversions as opposed to Oracle's circular buffer (undo tablespace).

5. Surprisingly enough, Oracle's READ COMMITTED augmented with "SELECT FOR UPDATE" turned out to be more flexible, at least for our applications, than either of IB's RCILs.

Rgds.

tengiz · Post by **tengiz** » 10 Nov 2003 04:46

Big Cheese,

С точки зрения внутреннего устройства подсистемы хранения и обработки транзакций, Interbase отличает наличие поддержки многих незафиксированных версий. В отличие от Oracle или Postgress. Каждая транзакция, которая хочет изменить строку, просто создаёт новую версию, невидимую никому, пока транзакция не зафиксирована (на самом деле записывает изменение - то, что они называют дельтой) поэтому одну и ту же строку при необходимости может одновременно обновлять любое количество транзакций. Конфликты при этом разрешаются во время фиксации.

Interbase фактически не имеет журнала транзакций. Откат делается элементарно - новые версии просто объявляются мусором, так как предыдущая версия строки никуда не девается, пока обновление не зафиксировано. Фиксации как таковой тоже нет - в системе ведётся список транзакций с их состоянием. Поэтому для чтения (или восстановления путём "наложения" нужного количества нужных дельт) правильной версии строки, достаточно просто свериться с текущим состоянием транзакций, которые изменяли эту строку (создали дельты).

Подсистема обработки запросов у Interbase, как говорят те, кто с ней работал, довольно посредственная, чуть ли не до самого последнего времени там, например, не было "Halloween protection", т.е., скажем, запрос "insert into tab select * from tab" мог приводить к бесконечному циклу. Оптимизатор очень средний.

С точки зрения администрирования: отсутствуют критические для надёжных СУБД свойства - начиная от нормального backup и кончая удобными административным инструментами.

Но всё это - по впечатлениям либо 10-летней давности, либо с чужих слов, либо по информации из всяческих обзоров.

Merle · Post by **Merle** » 10 Nov 2003 19:22

tengiz wrote:С точки зрения внутреннего устройства подсистемы хранения и обработки транзакций, Interbase отличает наличие поддержки многих незафиксированных версий. В отличие от Oracle или Postgress. Каждая транзакция, которая хочет изменить строку, просто создаёт новую версию, невидимую никому, пока транзакция не зафиксирована (на самом деле записывает изменение - то, что они называют дельтой) поэтому одну и ту же строку при необходимости может одновременно обновлять любое количество транзакций. Конфликты при этом разрешаются во время фиксации.

Ну, все немного не так, tengiz. Я тоже так думал, но IB'сники меня поправили. IB возможно наличие только одной незафиксированной версии. Разборки происходят не при фиксации, вместо этого, в случае конфликта версий происходит откат опоздпвшей транзакции.
Тоесть поздавшая транзакция не порождает новую версию в надежде на неуспех более ранней транзакции, а откатывается.
Вот, более-менее подробное описание методики разрешения конфликтов в IB: http://www.ibase.ru/devinfo/versions.htm

SkyWalker · Post by **SkyWalker** » 10 Nov 2003 20:23

Merle wrote:Действительно... Давайте лучше, Тенгиз, мы вас по Юкону при случае немного по терзаем, если Вы не против, конечно...

Поддерживаю. Было бы очень интересно немногo потерзать первоисточник.

tengiz · Post by **tengiz** » 10 Nov 2003 21:38

Merle wrote:...Разборки происходят не при фиксации, вместо этого, в случае конфликта версий происходит откат опоздпвшей транзакции. Тоесть поздавшая транзакция не порождает новую версию в надежде на неуспех более ранней транзакции, а откатывается.

Спасибо за ссылку - я внимательно всё прочитал. А Вы не знаете, как IB делает восстановление после краха? Описанные алгоритмы аккуратно обходят этот вопрос. Если бы IB работал так как я полагал (каждая транзакция создаёт свою версию, проверка конфликтов и сброс страниц делается при фиксации,) то с восстановлением всё было бы более-менее понятно - версии созданные незавершёнными транзакциями просто чистились бы при перезапуске сервера. Однако, если старая версия строки реально меняется непосредственно при обновлении, то всё повисает в воздухе начиная с этого момента и до момента фиксации, когда делается сброс на диск. И вообще, остутствие журнала делает высокопроизводительную и одновременно надёжную работу довольно проблематичной, на первый взгляд.

В общем, у Вас нет под рукой никаких ссылок с приличным описанием процедуры восстановления в IB?

Merle · Post by **Merle** » 10 Nov 2003 22:06

tengiz wrote: А Вы не знаете, как IB делает восстановление после краха? Описанные алгоритмы аккуратно обходят этот вопрос.

Увы...

tengiz wrote:Однако, если старая версия строки реально меняется непосредственно при обновлении, то всё повисает в воздухе начиная с этого момента и до момента фиксации, когда делается сброс на диск.

На сколько мне известно, реально она не меняется. Как я понял актуальное состояние базы считается на момент самой старшей незафиксированной транзакции.
Впрочем, давайте не будем гадать, я лучше попытаюсь по спрашивать про ссылки на первоисточники...

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

Да вот самому любопытно, что там с журналом.. Вроде он как бы там есть, но явно его как бы нет. Непонятно вообщем.
А в руках я IB не держал..

tengiz wrote:В общем, у Вас нет под рукой никаких ссылок с приличным описанием процедуры восстановления в IB?

Alas.

Но зато кажется есть у кого спросить...

Big Cheese · Post by **Big Cheese** » 11 Nov 2003 08:50

Tengiz, Merle - спасибо за инфу. После прочтения мне тоже (хотя я и не специалист) кажется, что с восстановлением после сбоя у Interbase не все так гладко, как это описано в агитках

- во всяком случае (как совершенно справедливо отметил Тенгиз) отсутствие такого достаточно очевидного решения, как журнализирование наводит на нехорошие подозрения. Услуги по ремонту баз данных Interbase, Firebird, Yaffil - тоже как-то неуютно становится... Вобщем, еще раз спасибо - будет о чем поговорить с interbase team - посмотрим, что они скажут...

tengiz · Post by **tengiz** » 11 Nov 2003 21:32

Big Cheese,

На всякий случай во избежание недоразумений хочу почётче сказать, что я имел в виду: даже при остутствии журналирования несомненно можно обеспечить надёжное восстановление, но плата за это - производительность. То есть без журнала будет одно из двух - либо быстрые обновления, но остутствие автоматического восстановления; либо гарантия целостности при авариях даже в самые неудобные моменты, но медленные обновления (или, что почти то же самое - быстрые обновления при медленной фиксации).

Big Cheese · Post by **Big Cheese** » 12 Nov 2003 00:06

tengiz wrote:На всякий случай во избежание недоразумений хочу почётче сказать, что я имел в виду: даже при остутствии журналирования несомненно можно обеспечить надёжное восстановление, но плата за это - производительность. То есть без журнала будет одно из двух - либо быстрые обновления, но остутствие автоматического восстановления; либо гарантия целостности при авариях даже в самые неудобные моменты, но медленные обновления (или, что почти то же самое - быстрые обновления при медленной фиксации).

Tengiz,

Спасибо за уточнение, хотя в Вашем постинге на мой взгляд и так все достаточно однозначно; это скорее я несколько неопределенно высказался, из-за того, что из технологий crash recovery я кроме журналирования ничего не знаю, навскидку тоже на ум ничего не приходит. Не могли бы Вы порекомендовать что-нибудь из литературы на эту тему (организация систем хранения, восстановление после сбоя)?

Merle · Post by **Merle** » 12 Nov 2003 00:24

Вот, что удалось найти:
http://ibase.ru/devinfo/inplupd.htm
http://ibase.ru/devinfo/oitoat.htm
И вот еще любопытный FAQ.
http://ibase.ru/devinfo/db_repair.htm#corrupt
Вообщем похоже полноценного журнала все-таки нет... Но с другой стороны все изменения порождают новою версию и до их фиксации актуальной считается старое состояние базы. Таким образом в случае сбоя база находится в согласованом состоянии, проблемы возникают лишь в том случае, если сбой произошел во время сборки мусора (устаревших зафиксированных версий) и вот здесь бы журнал не помешал.

Big Cheese · Post by **Big Cheese** » 12 Nov 2003 01:29

Merle wrote:Вообщем похоже полноценного журнала все-таки нет... Но с другой стороны все изменения порождают новою версию и до их фиксации актуальной считается старое состояние базы. Таким образом в случае сбоя база находится в согласованом состоянии, проблемы возникают лишь в том случае, если сбой произошел во время сборки мусора (устаревших зафиксированных версий) и вот здесь бы журнал не помешал.

Может, я не прав, но если операция по сборке мусора происходит на одной странице данных, и если запись страницы считать атомарной операцией, тогда проблем тоже быть не должно - не получилось стереть старую запись сейчас, сотрем в следующий раз. А вот как при отсутствии журнала безопасно оперировать с индексными страницами B-Tree (вставлять, удалять страницы) - мне непонятно... Вообще, насколько я понимаю, любая операция, которая переводит образ базы на диске из одного согласованного состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) - должна быть сначала прописана в журнале, иначе восстановление после сбоя в общем случае невозможно. Оговорюсь еще раз - я в этом вопросе дилетант, хотелось бы узнать, что об этом думают специалисты...

Merle · Post by **Merle** » 12 Nov 2003 20:46

Я вот здесь вот http://www.rsdn.ru/?forum/?mid=438892
Развел наших IB краеведов на обсуждение восстановления и вообще IB'ной версионности.
Много любопытных вещей рассказали...
Вообщем если интерес остался, то вот, велкам.
Меня, правда, боюсь на много не хватит, до меня юкон с PDC доехал и я в него погружаюсь...

tengiz · Post by **tengiz** » 13 Nov 2003 02:29

Big Cheese wrote:А вот как при отсутствии журнала безопасно оперировать с индексными страницами B-Tree (вставлять, удалять страницы) - мне непонятно...

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

Вообще, насколько я понимаю, любая операция, которая переводит образ базы на диске из одного согласованного состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) - должна быть сначала прописана в журнале, иначе восстановление после сбоя в общем случае невозможно. Оговорюсь еще раз - я в этом вопросе дилетант, хотелось бы узнать, что об этом думают специалисты...

Для обеспечения восстанавливаемости по алгоритму WAL необходима инфомация undo и redo, информация о том, как завершились транзакции (commit, abort), а также информация о том, какая часть базы уже не требует актуализации, так как recovery для неё уже успешно закончился. В IB, судя по по ссылкам от Merle, информации undo и redo находятся прямо в страницах данных; никакой дополнительной информация о том, до какой точки дошёл recovery не нужна, так как транзакция ни будет зафиксирована, пока страницы данных не окажутся сброшенными на диск; а информация о завершении транзакций хранится отдельно.

B итоге, так как страницы данных самодостаточны для успешого undo и redo, в том числе и для recovery, то этот самый transaction inventory table или как она там в IB называется, фактически и является журналом. В каком-то смысле это как журнал координатора распределённой транзакции, а каждая отдельная странице со своим набором изменений - это как самодостаточный участник распределённой транзакции, при условии, что координатор всегда может всем сообщить общий итог.

Поэтому если информация об итоге всех транзакций всегда идёт сначала в отдельный transaction inventory, то восстанавливаемость гарантируется. Но при условии атомарности отдельной операции со страницей (что на самом деле не может быть 100% обеспечено с существующей технологией дисков, для защиты от таких проблем в том же SQL Server имеется torn page detection). Но слабое место у IB здесь, как уже было сказано, производительность - ввиду необходимости перед подтверждением commit сбросить на диск все грязные страницы, тронутые транзакцией.

Big Cheese · Post by **Big Cheese** » 13 Nov 2003 03:34

Tengiz,

Спасибо большое за ответ! Если позволите, у меня еще пара вопросов
WAL - это Write Ahead Logic?

tengiz wrote:
Big Cheese wrote:А вот как при отсутствии журнала безопасно оперировать с индексными страницами B-Tree (вставлять, удалять страницы) - мне непонятно...

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

Вот тут я честно признаться, не понял. Т.е. опять же, при наличии журнала все более-менее понятно (надеюсь, что хоть здесь я не ошибаюсь): сначала пишется log entry, потом пишутся затронутые страницы (если не рассматривать performance improvements типа checkpointing). Для data pages в Interbase тоже (теперь) понятно - они сами себе log entries, но тогда для обеспечения recoverability нужно и non-leaf pages делать версионными, что на первый взгляд выглядит как-то дико...

tengiz · Post by **tengiz** » 13 Nov 2003 05:29

Big Cheese,

WAL - это Write Ahead Logging. Страницы b-tree индекса, как внутренние (non-leaf), так и внешние (leaf) обычно имеют такую же или почти такую же структуру как и нормальные страницы со строками данных. В случае leaf pages в этих строках содержатся пары колонок (key, rowid строки данных), в случае внутренних страниц - пары (key, pageid страницы следующего уровня). Так что любые трюки, применяемые для страниц с данными, вполне могут работать для индексов тоже.

Big Cheese · Post by **Big Cheese** » 13 Nov 2003 08:33

tengiz wrote:Big Cheese,

WAL - это Write Ahead Logging. Страницы b-tree индекса, как внутренние (non-leaf), так и внешние (leaf) обычно имеют такую же или почти такую же структуру как и нормальные страницы со строками данных. В случае leaf pages в этих строках содержатся пары колонок (key, rowid строки данных), в случае внутренних страниц - пары (key, pageid страницы следующего уровня). Так что любые трюки, применяемые для страниц с данными, вполне могут работать для индексов тоже.

Tengiz, еще раз спасибо. Если в Interbase действительно все реализовано подобным образом (мультиверсионность всех структур вплоть до non-leaf B-Tree pages), то мне это представляется весьма странным архитектурным решением, т.к. недостатки здесь, я полагаю, очевидны, а вот преимущества мне лично совершенно неочевидны. Впрочем, при всем богатстве выбора, другой альтернативы нет (с). Может, не так все и плохо окажется

Еще раз спасибо всем!

tengiz · Post by **tengiz** » 18 Nov 2003 00:35

Продолжения истории пока нет. Каждый раз, когда у меня было время на попытку запостить на AskTom.oracle.com, там висел статус с backlog, поэтому мне до сих пор никак не удалось найти окно, когда они принимают вопросы. Даже с учётом всех рекомендаций о правильных периодах времени, как с самого сайта, так и от vc (спасибо ему за информацию). Хотя на самом деле, судя по датам, некоторые настойчивые люди умудряются-таки впихнуть туда свои сообщения.

vc · Post by vc » 18 Nov 2003 15:09

tengiz wrote:Продолжения истории пока нет. Каждый раз, когда у меня было время на попытку запостить на AskTom.oracle.com, там висел статус с backlog, поэтому мне до сих пор никак не удалось найти окно, когда они принимают вопросы. Даже с учётом всех рекомендаций о правильных периодах времени, как с самого сайта, так и от vc (спасибо ему за информацию). Хотя на самом деле, судя по датам, некоторые настойчивые люди умудряются-таки впихнуть туда свои сообщения.

Just a gentle reminder... I am pretty sure you can post a follow-up to the original thread since your question would be entirely relevant. If you post a follow-up, you do not need to wait in line. It never hurts to try ;)

Rgds.

Dmitry67 · Post by **Dmitry67** » 18 Nov 2003 15:14

Два вопроса на AskToM.Oracle.com

1. Почему исчез вопрос о баге в Oracle ?
2. Куда делся tengiz ?