=?koi8-r?B?887P18EgzcXIwc7J2s0gzc7Px8/XxdLTyc/Ozs/T1MkgKM/UIExpbHlhIEs=?

["Shulzhenko Vasyl" <vasilis@softline.kiev.ua>]

Hi!

Vadim Rumyantsev wrote in message <917493600@f301.n5030.z2>...
>Hi Vladimir!
>
>В сpеду, 27 янваpя 1999 15:47:03, Vladimir Shalimov писал to All:
>
> VS> Есть приложения, которые IMHO нельзя слепить не используя механизма
> VS> многоверсионности. Допустим, мне нужно получить отчет по состоянию
> VS> чего-либо на 14.00. Запрос будет выполняться в контексте транзакции
> VS> (какого уровня изоляции?) 5 минут. В то же время юзеры (либо какая-то


Как минимум read-only должно стоять для таких транзакций, чтоб
минимизировать
объем работы базе, так как read-only можно пустить работать по снимкам базы
а не по версионности, что на порядок быстрее (цепочки версий раскручивать
не надо), и serializable - то есть все версии должны браться на момент
старта
транзакции и более старые, а не версии на момент старта запроса.

>VS> автоматизированная система) должны иметь возможность править те же
> VS> записи, которые используются в моем запросе. Как достигнуть
> VS> требуемого, не используя механизм многоверсионности записей?


А вот править то их фиг будешь, если у была хоть одна версия с меткой
времени
позже чем метка времени старта твоей транзакции и поставила в цепочке свою
версию раньше. Причина простая - при многоверсионности разводка 2-х
нефиксированных версий идет по ходу жизни - вторую просто не дадут создать,
а разводка фиксированных и модифицируемых версий идет только по validation
phase -
а в нее транзакция при всем своем желании не попадет пока Commit не выдаст.
Так что менять то ты сможешь, если тебе сильно повезло и твоя
нефиксированная
версия будет стоять в цепочке сразу после той версии, которую ты считал (что
по сути
эквивалентно по поведению блокированию, когда блокированную запись никто и
не хотел получить):
V14:00->V(your).

А вот если будет так
V14:00->V(neighbor)->V(your), где они обе не фиксированные,
то тебе сразу дадут по голове и откатят запрос модификации,
или так
V14:00->V(neighbor, committed)->V(your).
то тебе дадут по голове в validation phase всей транзакции, почему
объяснить просто - ты сериализуемости при этом не получишь хоть что делай,
причем это сериализуемость на уровне более низком, чем твой прикладной
сидит, все собственно и все с версиями.

>Hикак. И используя механизм многоверсионности, тоже никак. Hе будет это
>состоянием на 14:00! Hапример, с 13:58 до 14:xx Петя покупал последний
билет на
>поезд, в 13:59 Вася не смог его поэтому купить, а твой "многоверсионный"
запрос,
>выполняющийся с 14:00 до 14:yy (который якобы показывает состояние на
14:00)
>выдаст, что место было свободно (независимо от соотношения xx и yy).


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

А запросы на 5 минут в OLTP (а задача именно такая) - как-то странноваты.
Что-то у вас там с моделью нехорошо, а сервер тут совсем не причем.
чтоб хорошо протокол обработки транзакций приписать надо же хоть
немного применять метод шевеления мозгами, ну нельзя же все лепить
так в одну кучу.

>Чисто логически мы не можем узнать состояние дел на 14:00 до тех пор, пока
не
>закончится последняя транзакция-писатель, выполнявшаяся в 14:00. С другой


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

>стороны, если мы изменим состояние дел в 14:02, то результаты отчёта,
>выполнявшегося с 14:00 до 14:05, заведомо не будут соответствовать
реальности
>уже в момент своего получения. И никакая организация базы и никакой
алгоритм
>работы СУБД ничего тут не изменит.


Более того, как только отцепится последняя транзакция-читатель этой записи с
меткой
времени 14:00 ее совершенно честно отправят в мусор. И концов ее никто не
найдет.
Снимки только при этом работают. А это не тоже самое, что версионность, и
снимки
применяются только для read-only. ни один нормальный проектировщик не
поставит снимки для транзакций-модификаторов - это ж повыщение откатов
транзакций заложенное в систему изначально - очень нехорошо.

>Hа самом деле при большом потоке транзакций типичны две ситуации.
>
>1) Тебя интересует история, и ты хочешь давать запросы о состоянии на тот
или
>иной момент в прошлом. Тогда в базе изменения накапливаются тоже со всей
>историей, и новые транзакции просто добавляют записи о новых моментах
времени,
>никак не мешая запросам к старым записям.


снимки

>2) Тебя интересует состояние только на текущий момент. Учитывая, что оно
всё
>время меняется, то тут по определению точность будет плюс-минус лапоть (так
как,
>пока ты просто прочтёшь отчёт, уже всё изменится), поэтому обычно можно
>использовать для таких запросов уровень изоляции UR.


А тут cursor stability - то есть Serializable только на уровне одного
курсора (при
скролируемых курсорах естественно).

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


Hе, многоверсионность штука полезная, только при реализации сильно дорогая.
Дорогая из-за индексов - b-tree и клоны совершенно не годятся для этого -
цепочки
версий раскручивать сложно. А на блокировки накладные расходы меньше,
b+(*)-tree отработаны годами, вот потому то и реализаций больше. А хорошей
полноценной реализации версионности нет до сих пор.

Lilya Kozlenko
Relex, Ltd.
Linter SQL Server Developers Group 7-0732-711-711 li@relex.ru