serg99
в Oracle обозван Serializable

Не только в Оракле он так обозван, но и насколько помню - это вообще стандартизованное название.

StalkerS
А при чем здесь грязное чтение и блокировки ? ... так я вам говорю о том, что версионность тоже будет включаться только когда нужна,

При том, что в Оракле они исключены. А када включится версионность в Юниконе, тада посмотрим будет или нет там появляться что-то типа ORA-01555. А нужна она скорее всего всегда. А там где не нужна, там скорее всего одна транзакция на одну таблу. Не знаю что это такое. Возможно однопользовательская БД на домашнем компе?
Кроме того, как она включится? Ведь у блокировочника журнал транзакций, а у версионника журнал повторного выполнения. Тогда у Юникона будут оба вида журналов или он будет все равно с журналом транзакций будет париться в версионном варианте?

2 Dooma

Много мучался с Вашим примером, но он выдает неизменно одну запись i = 2. Две если только Delete во второй транзакции не выполнять.

Но Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.

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


Читал внимательно. Но посмотреть никогда не вредно? Если много записей удерживать бесконечно долго, то вылезет другая более худшая ошибка или проблема.


StalkerS
Нет

Хорошо. Вам не нужна, а мне не помешает.

StalkerS
Она не нужна в тех задачах, когда число пишуших транзакции гораздо больше читающих.

Так случается, что пишушие тоже почитывают.

StalkerS
Насколько понял, это - фактически одно и то-же

А я раньше думал, что это фактически не совсем одно и то-же. Может заблуждался. Надо еще раз почитать про них. Ведь если одно и тоже, то как они обходились до сих пор (пока не перешли из блокировочников в версионники) без сегментов отката? Ведь одних только журналов повторного выполнения не дростаточно для восстановления? Не до конца ясно.

2 Alex.Czech
Но я про то и говорю: transaction log - журнал транзакций. Это для блокировочника. Там все про транзакции завершенные и не завершенные - то что ему нужно для восстановления. У версионника Оракла redo.log - журнал повторного выполнения. Там тока инфа про завершенные транзакции, которые он повторно выполнит, если точно не известно что изменения зафиксированы в БД на диске (т.е. изменения после контрольной точки, а undo он возьмет просто из сегментов отката или табл пространств отката просто блоки до изменений). Значит разница есть между журналами транзакций и журналами повторного выполнения?

2 serg99

>Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?

На практике однозначно задумываются и прменяют либо оптимистические блокировки либо писсемистические.

Мне кажется, что в Вашем примере возникает, та ситуация про которую говорил www.fun4me.narod.ru. И я считаю, что тразакция 2 (правда я read1 мысленно подвинул к start) должна быть отменена. Т.е. юзер должен получить любимое - "запись изменена другим пользователем" (оптимистическая блокировка) или он должен был заблокировать транзакцию после чтения. Иначе мы доиграимся. Все-таки второй юзер хотел увеличить только на 1, то что прочитал, а оно вдруг изменилось на 2?! Опять уточняю, что read1 мысленно подвинул к start у второй транзакции для типичности. Или Вы намерено сделали между ними разрыв, чтобы непонятней было какую из них нужно все-таки отменить?

2 Alex.Czech
Ну про журнал транзакций для блокировочников Вы пишите то, что я про них и думал. Я читал про них в общей литре по БД, где описывается упрощенная архитектура СУБД на примере блокировочника.
Что до оракла ту него только журнал повторного выполнения, хотя и реализован в виде нескольких файлов. Как минимум двух, но типично из трех. Ну, еще могут быть включены архивные журналы повторного выполнения. Ими защищены и undo сегменты. Но это не журналы, а копии блоков данных до начала изменения. Отсюда собственно и термин многоверсионность - несколько версий данных. Эти андо используются не только для чтенеия на уровне READ COMMITED, но и для отмены незавершенных транзакций при восстановлении после сбоев. Об этом кстати есть тоже в общей литре по БД.

2 serg99
Я воспроизвел Ваш пример. При попытке добавленя 1 в транзакции 2 получили сообщение об ошибке ORA-08177 can't serialize access for this transaction
А в литре по БД пояснение, что в этом случае в приложеннии должно быть предусмотрено повторное выполнение этой транзакции. Т.е. получается последовательный график транзакций. Т.е. не всегда надо в ручную вначале транзакции блокировать никакой ресурс. Достаточно установить ISOLATION_LEVEL = SERIALIZABLE. Я использовал update. А тут видно, что нюансы начинаются с инсертами. Поскольку до инсетра в пустой БД еще ничего не было, наверное. Буду смотреть этот вопрос дальше.

2 Dooma
Я извиняюсь, вчера не заметил, что девелопер настроен коммитить любую операцию, поэтому и не получалось.



StalkerS
Это уже является проблемой правильного проектирования базы, а никак не проблем в работе сервера.

Вы идtализируете проектирование базы. Ну хорошо ORA-01555 - результат того, что система не до конца правильно спроетирована. Не учли ситуации, не все просчитали, наделали ошибок в ХП. Ну их наделают и в Юконе. Или нет?

StalkerS

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

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


StalkerS
Странный ответ. Вы базы что, для личного пользования делаете ?


Исключительно не для личного, потому так и говорю - если есть версионность ее предпочту однозначно? и не буду замарачиваться. Потому что нужны слишком серьезные доводы, чтобы ее не применять, а пока я знаю только один - СУБД в принципе не поддерживает версионности. Ну, может быть система для одного пользователя, тогда тоже не имеет особого значения.

StalkerS
Так я говорю о процентном отношении пишуших и читающих

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



StalkerS
Принципиальная разница Оракла в том

Так я Вам и говорил именно про эту разницу. Т.е. про разницу между журналами тразакций и повторного выполнения. А Вы, вроде, говорили, что нет разницы. Добавлю, что использует эти данные сегментов отката не только для воостановления, но для обеспечения уровня изоляции READ COMMITED. Т.е. собственно для своей многоверсионности. Т.е. для двух целей использует сегменты отката. Потому и спарашивал Вас, что SQL-Server будет по прежнему пользоваться журналами транзакций в многоверсионном режиме? Не будет использовать эти блоки старой версии? Вроде, на первый взгляд, как-то не оптимально получается тогда.