ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О консистентности отчетов на OLTP-сервере
70 сообщений из 70, показаны все 3 страниц
  все  
О консистентности отчетов на OLTP-сервере
    #37232487
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
Народ,

какие есть в принципе концептуальные решения для построения консистентных отчетов.

Идеальано получать отчеты по snap-shot'у данных, однако при условии активного изменения данных пользователями, генерация отчета происходит по изменяющемуся во времени extent'у. Соответственно вне зависимости от скорости работы генератора отчета существует вероятность изменения данных подлежащих включению в отчет, в итоге генерация отчета по состоянию "на сегодня" дает неверный результат при любом раскладе.

Варианты решений которые видятся навскидку
1) Выполнять отчеты в ночное время - не подходит т.к. отчеты могут выполняться дольше ночного времени, к тому же ночью происходят другие регламентные задачи включая full backup. К тому же теоретически ночью пользователи могут работать.

2) Лочить данные на запись и выполнять очередь отчетов - также неприемлем, ввиду длительного подвешивания системы на локе

3) Делать что-то похожее на snap-shot путем организации зеркала - тоже малопрактичен, т.к. для каждой операции построения отчета необходимо отключать апдейты с источника на весь период выполнения очереди отчетов. Соответственно частота обновления данных определяется временем требуемым на выполнение всей очереди отчетов. К тому же требует доп. сервера для зеркала

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

Вопрос как вы выходите из ситуации в своих системах? Есть ли решения на системном уровне СУБД?
...
Рейтинг: 0 / 0
25.04.2011, 17:49
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232551
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Rus000Вопрос как вы выходите из ситуации в своих системах? Есть ли решения на системном уровне СУБД?

Уровень изоляции Repeatable Read (snapshot на MS SQL, Read Only на Oracle, concurrency на
IB/FB) гарантирует, что любой запрос в пределах транзакции видит данные такими, какими они
были на момент старта транзакции. У версионников нет проблем с блокировками и изменением
данных другими пользователями.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
25.04.2011, 18:26
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232578
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
Dimitry Sibiryakov,

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

Можете пояснить каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения.

Вот здесь приведен пример где в двух сессия коммитят данные на уровне READ_COMMITED и данные закоммиченные второй сессией попадают в первую.
...
Рейтинг: 0 / 0
25.04.2011, 18:48
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232598
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
Dimitry SibiryakovУровень изоляции Repeatable Read (snapshot на MS SQL, Read Only на Oracle, concurrency на
IB/FB) гарантирует, что любой запрос в пределах транзакции видит данные такими, какими они
были на момент старта транзакции.

как долго хранятся версии данных? наверняка есть ограничения физической реализации ... например если отчет идет 10+ часов, при активных апдейтах сотен пользователей может ли субд действительно гарантировать извлечение нужной версии данных на 10 часов назад?
...
Рейтинг: 0 / 0
25.04.2011, 19:15
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232601
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Rus000хм ... возможно я ошибаюсь но с ораклом тоже не все красиво насколько я понял - в рамках одно транзакции нужные версии данных берутся из сегментов отката, однако размер их имеет ограничение и эти сегменты при активных апдейтах могут быть перезаписаны новыми данными.

это могло быть проблемой 10 лет назад, сегодня во времена терабайтных винтов места под версии может нехватить только по недосмотру DBA. поставь ретеншен тайм = неделя и спи спокойно.

Rus000Можете пояснить каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения.

Вот здесь приведен пример где в двух сессия коммитят данные на уровне READ_COMMITED и данные закоммиченные второй сессией попадают в первую.
на RC так и должно быть, на RC консистентность обеспечивается только на один стайтмент. если тебе нужно на момент старта транзакции использую serializable. read only кажется тоже на всю транзакцию распространялось, но точно не помню.

в общем у версионных субд с читающими транзакциями вообще никаких проблем. у блокировочника обычно писателей и читателей разводят через финт "закрытый период" и табу на update, ночью закрывают день, вычисляют агрегаты. когда в час пик клиент запускает отчет вычитываются агригаты и к ним прибавляются транзакции прошедшие задень. допустим для банковского счета берут баланс с которым он был закрыт ночью + все платежи прошедшие за этот день.
...
Рейтинг: 0 / 0
25.04.2011, 19:16
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232602
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Rus000как долго хранятся версии данных? наверняка есть ограничения физической реализации ... например если отчет идет 10+ часов, при активных апдейтах сотен пользователей может ли субд действительно гарантировать извлечение нужной версии данных на 10 часов назад?
в оракле так и выставляется UNDO_RETENTION в минутах. поставь 24 часа с запасом, ну будет у тебя UNDO в пару десятков гиг, время бэкапа увеличиться на 5 минут ...
...
Рейтинг: 0 / 0
25.04.2011, 19:20
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232617
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Rus000Можете пояснить каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при
условии что данные выбираются более чем одной транзакцией чтения.

Путём отрывания рук тому идиоту, который для одного отчёта выбирает данные в нескольких
транзакциях. Повторяю ещё раз медленно: для Repeatable Read ВСЕ данные консистентны на ВСЁ
время транзакции. Одной транзакции. И да, если отчёт составляется 10 часов, все эти 10
часов данная транзакция будет активна. Если Ваш SQL сервер имеет с этим проблемы - время
подумать о миграции.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
25.04.2011, 19:33
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232620
Консистентность
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Консистентность
Гость
Rus000Можете пояснить каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения.

Кстати такой же вопрос, есть ли возможность в MS SQL/Oracle/Firebird/PostgreSQL "обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения."?
...
Рейтинг: 0 / 0
25.04.2011, 19:37
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232621
Консистентность
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Консистентность
Гость
Dimitry Sibiryakov, понятно что и кому отрывать, но чисто теоретически такая возможность есть? :)
...
Рейтинг: 0 / 0
25.04.2011, 19:39
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232640
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Для извращенцев есть flashback queries.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
25.04.2011, 19:54
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232645
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
КонсистентностьКстати такой же вопрос, есть ли возможность в MS SQL/Oracle/Firebird/PostgreSQL "обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения."?

oracle docsRead-Only Transactions

By default, the consistency model for Oracle guarantees statement-level read consistency, but does not guarantee transaction-level read consistency (repeatable reads). If you want transaction-level read consistency, and if your transaction does not require updates, then you can specify a read-only transaction. After indicating that your transaction is read-only, you can execute as many queries as you like against any database table, knowing that the results of each query in the read-only transaction are consistent with respect to a single point in time.
http://download.oracle.com/docs/cd/F49540_01/DOC/server.815/a68003/01_08pro.htm#2194
...
Рейтинг: 0 / 0
25.04.2011, 19:59
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232653
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
для оракла все более-менее понятно, спасибо Yo! и Dmitry S.

приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?
...
Рейтинг: 0 / 0
25.04.2011, 20:07
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232658
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
По-моему, блокировочник проще выкинуть, чем чинить.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
25.04.2011, 20:11
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232659
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Rus000приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?
тады только одно - выносить весь репортинг на отдельный сервер и туда или реплицировать или log shiping с oltp. но там тьма нюансов в зависимости от вендора и характера вашего oltp.
...
Рейтинг: 0 / 0
25.04.2011, 20:12
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232670
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Редкий случай, когда Дмитрий пишет так много и так правильно :)

Для блокировочника понятие констистентности отчёта настолько виртуально, что большинство известных мне разработчиков не очень понимали, что это такое :) Имхо нормальных решений кроме "блокировки периода" для него таки нет.
...
Рейтинг: 0 / 0
25.04.2011, 20:21
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232874
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Yo.!Rus000приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?
тады только одно - выносить весь репортинг на отдельный сервер и туда или реплицировать или log shiping с oltp. но там тьма нюансов в зависимости от вендора и характера вашего oltp.
И это будет выглядеть просто, когда вы сможете перед запуском отчёта без проблем приостановить реплику-шиппинг, а после окончания формирования отчёта - без проблем продолжить...

А про закрытие периода, Рус000, Вы похоже, не поняли... Периоды можно закрывать "по частям": "постоянное закрытие" - например, на 22.04.2011 00:00:00.000 - закрыт банковский день и мы не ожидаем что кто-то попытается "писать в закрытый период", и "временное закрытие" - например, на текущий момент 26.04.2011 04:15:00.000 (на момент формирования отчёта минус небольшая задержка). Отчёт выставляет "временное закрытие" как можно позже - перед непосредственным чтением данных за период с 22.04.2011 00:00 по 26.04.2011 04:15:00.000. Причём сессиям в режиме 24х7 никто не запрещает вносить "документы" с "метками" времени ПОСЛЕ 26.04.2011 04:15:00.000. При этом, поскольку чтение данных за период 22.04.2011 00:00:00.000 - 26.04.2011 04:15:00.000 не очень большое - блокировка не должна оказаться длительной и критичной. Ожидать будут вынуждены только те сесии, которые попытаются во время работы отчёта писать "документы" с "меткой" в этом временном промежутке. Естественно, после окончания отчёта, отчёт снимает "временное закрытие".

Вот такой вот геморрой для архитектора системы. Поэтому обычно для существующей системы на блокировочнике при требовании "нужен консистентный отчёт" разработчики будут тщательно выпытывать у заказчика: "в чём именно консистентный, насколько большой объём период может быть запрошен" и т.д. и т.п. ...
...
Рейтинг: 0 / 0
26.04.2011, 05:31
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37232883
Rus000
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Rus000
Гость
АнатоЛойИ это будет выглядеть просто, когда вы сможете перед запуском отчёта без проблем приостановить реплику-шиппинг, а после окончания формирования отчёта - без проблем продолжить...


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

АнатоЛойВот такой вот геморрой для архитектора системы. Поэтому обычно для существующей системы на блокировочнике при требовании "нужен консистентный отчёт" разработчики будут тщательно выпытывать у заказчика: "в чём именно консистентный, насколько большой объём период может быть запрошен" и т.д. и т.п. ...

именно то что это нужно предусматривать в стадии проектирования системы и смущает. Получается в унаследованных системах на блокировочниках архитектура которых не предусматривала исторических данных можно строить отчеты только на снап-шотах
...
Рейтинг: 0 / 0
26.04.2011, 06:17
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233202
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
softwarerДля блокировочника понятие констистентности отчёта настолько виртуально, что большинство известных мне разработчиков не очень понимали, что это такое :) Имхо нормальных решений кроме "блокировки периода" для него таки нет.
а в наше время еще остались таки блокировочники?
...
Рейтинг: 0 / 0
26.04.2011, 10:59
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233331
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 25.04.2011 20:33, Dimitry Sibiryakov wrote:

> Путём отрывания рук тому идиоту, который для одного отчёта выбирает данные в
> нескольких
> транзакциях. Повторяю ещё раз медленно: для Repeatable Read ВСЕ данные
> консистентны на ВСЁ
> время транзакции. Одной транзакции.

А как же фантомы ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 11:46
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233372
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
MasterZivА как же фантомы ?
это у стандартного RepeatableRead допускаются фантомы. а у Snapshot никаких фантомов нет в принципе, и быть не может.
...
Рейтинг: 0 / 0
26.04.2011, 11:58
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233415
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 12:58, kdv wrote:
> А как же фантомы ?
> это у стандартного RepeatableRead допускаются фантомы. а у Snapshot никаких
> фантомов нет в принципе, и быть не может.

Так вы уж определитесь. RepeatableRead и Snapshot -- не одно и то же.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 12:13
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233598
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
MasterZivТак вы уж определитесь. RepeatableRead и Snapshot -- не одно и то же.
у "нас", то есть в IB/FB, есть snapshot, RepeatableRead нет. Собственно, "настоящий" RepeatableRead мало где есть, наверное только в DB2? Кому он нафиг нужен, с фантомами-то?
Да и тут про это давно написано
http://emanual.ru/download/www.eManual.ru_538.html
...
Рейтинг: 0 / 0
26.04.2011, 13:10
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233606
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
это я к тому, что упоминая RepeatableRead уже никто не вспоминает ни про какие фантомы, и обычно подразумевает, что RepeatableRead=Snapshot.
...
Рейтинг: 0 / 0
26.04.2011, 13:15
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233630
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ScareCrowа в наше время еще остались таки блокировочники?
Штуки три я назову сходу.
...
Рейтинг: 0 / 0
26.04.2011, 13:21
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233647
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
kdvэто я к тому, что упоминая RepeatableRead уже никто не вспоминает ни про какие фантомы, и обычно подразумевает, что RepeatableRead=Snapshot.

А как же стандрат?
...
Рейтинг: 0 / 0
26.04.2011, 13:28
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233701
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
pkarklinА как же стандрат?
А кому он нафиг сдался?
...
Рейтинг: 0 / 0
26.04.2011, 13:48
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233722
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
pkarklinА как же стандрат?
стандарт писался под блокировочников, в современном мире он в таком виде мягко говоря не нужен.
...
Рейтинг: 0 / 0
26.04.2011, 13:54
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233734
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 14:10, kdv wrote:

> у "нас", то есть в IB/FB, есть snapshot, RepeatableRead нет. Собственно,
> "настоящий" RepeatableRead мало где есть, наверное только в DB2?

Он есть в стандарте ANSI/ISO SQL.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 13:57
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233739
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 14:15, kdv wrote:

> это я к тому, что упоминая RepeatableRead уже никто не вспоминает ни про какие
> фантомы, и обычно подразумевает, что RepeatableRead=Snapshot.

Интересно, вот если тебе говорят "Он купил машину ВАЗ-21110" ты тоже
сразу же подразумеваешь, что он купил AUDI 6, потому что ВАЗ-ы всё
равно уже никто почти не покупает ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 13:59
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233760
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Ну, не знаю, раз стандарты создают, значит это кому-то нужно. Другой вопрос, что есть СУБД, в которых действительно RR приравнивается к SNAPSHOT.
...
Рейтинг: 0 / 0
26.04.2011, 14:07
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233762
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
MasterZivА как же фантомы ?
В природе не существуют.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 14:07
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233776
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
softwarerScareCrowа в наше время еще остались таки блокировочники?
Штуки три я назову сходу.
я только сабейз Асе.
...
Рейтинг: 0 / 0
26.04.2011, 14:13
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233778
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ScareCrowШтуки три я назову сходу.
я только сабейз Асе.[/quot]

MS SQL без включенной версионности.
...
Рейтинг: 0 / 0
26.04.2011, 14:14
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233784
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinраз стандарты создают, значит это кому-то нужно.

Стандарт допускает появление фантомов на уровне RR, но отнюдь не предписывает их иметь.
Поэтому их и нет ни у кого - гораздо проще реализовать RR без фантомов, чем с ними.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 14:17
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233808
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ScareCrowsoftwarerШтуки три я назову сходу.
я только сабейз Асе.
Вот чёрт, про неё-то я и забыл
...
Рейтинг: 0 / 0
26.04.2011, 14:26
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233826
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
softwarerВот чёрт, про неё-то я и забыл
Держу пари, ты и про FVMAS забыл...
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 14:32
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233831
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ScareCrow
Участник
авторВот чёрт, про неё-то я и забыл
а что еще?
...
Рейтинг: 0 / 0
26.04.2011, 14:34
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233846
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Dimitry Sibiryakov,

Сам стандарт описывает IL посредством введения феноменов. Есть, конечно, и критики такого подхода.
...
Рейтинг: 0 / 0
26.04.2011, 14:40
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233865
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinСам стандарт описывает IL посредством введения феноменов.

Это старый стандарт. Создатели новых уже не так скоррумпированы некрософтом.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 14:52
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233912
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
pkarklinScareCrowШтуки три я назову сходу.
я только сабейз Асе.

MS SQL без включенной версионности.[/quot]
Кстати можно как-то включить на конкретную БД версионность "наглухо".
Чтобы следующие инструкции не могли ее опять отключить.
...
Рейтинг: 0 / 0
26.04.2011, 15:05
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233926
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dbaКстати можно как-то включить на конкретную БД версионность "наглухо".
Чтобы следующие инструкции не могли ее опять отключить.

Для выполнения ALTER DATABASE нужны определенные (высокого уровня) полномочия.
...
Рейтинг: 0 / 0
26.04.2011, 15:10
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37233974
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
MasterZivИнтересно, вот если тебе говорят "Он купил машину ВАЗ-21110" ты тоже
сразу же подразумеваешь, что он купил AUDI 6, потому что ВАЗ-ы всё
равно уже никто почти не покупает ?
не понимаю, откуда такая агрессия и гиперболы.
Shapshot это фактически Repeatable Read без фантомов. Стандартом фантомы в RR ДОПУСКАЮТСЯ.
Поэтому ВАЗ-21110 не превращается в Ауди, как и наоборот. Просто более качественная отделка салона, только и всего.

И поэтому я еще раз задам вопрос - кто вообще живьем видел стандартный RepeatableRead с фантомами, кроме как в DB2 (якобы там оно соответствует, но возможно у меня склероз)?
...
Рейтинг: 0 / 0
26.04.2011, 15:23
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234041
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
kdvИ поэтому я еще раз задам вопрос - кто вообще живьем видел стандартный RepeatableRead с фантомами

В MS SQL RR полностью соответствует стандарту.
...
Рейтинг: 0 / 0
26.04.2011, 15:44
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234045
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
pkarklinbeginner_dbaКстати можно как-то включить на конкретную БД версионность "наглухо".
Чтобы следующие инструкции не могли ее опять отключить.

Для выполнения ALTER DATABASE нужны определенные (высокого уровня) полномочия.

Да но если кто-то напишет
Код: plaintext
 set isolation level read uncommited
перед инструкцией это "перекроет"
Код: plaintext
alter database set isolation level snapshot...
даже не обладая полномочиями, а будучи обычным пользователем, имеющим права на вставку, чтение, удаление таблицы?
...
Рейтинг: 0 / 0
26.04.2011, 15:45
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234056
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dba,

Что значит "перекроет"?! Изменения TIL никак не влияет на то, создаются версии или нет, если включена версионность. Явное изменение TIL сказывается только для той сессии, в которой он изменен.
...
Рейтинг: 0 / 0
26.04.2011, 15:50
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234064
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dba,

И, потом, вторая инструкция - это полная чушь. Нет такого:

Код: plaintext
alter database set isolation level snapshot

есть

Код: plaintext
ALTER DATABASE database_name SET READ_COMMITTED_SNAPSHOT ON

и

Код: plaintext
ALTER DATABASE database_name SET ALLOW_SNAPSHOT_ISOLATION ON

т.е. опции, которые позволяют:

1. Использовать RC с поддержкой версионности;
2. Использовать новый TIL SNAPSHOT.

Эти инструкции ни есть установка TIL для сессии, который по дефолту RC и может быть изменен по желанию разработчика.
...
Рейтинг: 0 / 0
26.04.2011, 15:55
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234095
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinВ MS SQL RR полностью соответствует стандарту.

Ты слова местами перепутал. Следует читать "стандарт полностью соответствует RR MS SQL".
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 16:04
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234098
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
pkarklinВ MS SQL RR полностью соответствует стандарту.
для меня до сих пор является загадкой, как воспроизводимое (!) чтение может порождать какие-то фантомы.
Фантом по определению это характеристика ReadCommitted, то есть когда очередным перечитыванием мы видим данные, которые успели измениться и быть committed с момента предыдущего чтения.
Грубо говоря, определение Repeatable Read не стыкуется с фантомами никак. Да и вообще, определение феноменов P2 (fuzzy read) и P3 (phantom) отличаются только тем, что P2 читает данные "без условий", а P3 - с условиями.
Насколько я понимаю, когда-то подразумевалось, что phantom - это видимость части данных, измененных и committed другой транзакцией. То есть, как бы, одна транзакция изменяет некую совокупность данных, и мы эту совокупность должны видеть либо целиком, либо не видеть вообще. А если видим только часть - то это фантом.

И исходя из определения того же стандарта, если RR допускает фантомы, то это уже не RR, а RC. Потому что не является воспроизводимым чтением. Извиняюсь, если начал пересказ уже упоминаемого http://citforum.ru/database/classics/SQL_critiques/.

Возвращаясь к цитате - раз RR в MS SQL соответствует стандарту, значит он реально является RC?
...
Рейтинг: 0 / 0
26.04.2011, 16:04
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234108
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
kdv,

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

RR не допускает МОДИФИКАЦИИ прочитанных данных, но допускает ВСТАВКУ новых данных. Т.е. сколько бы раз не перечитывали данные, то то, что мы прочитали в первый раз будет неизменным и далее пока транзакция не закомиттится. В MS SQL это (RR) реализуется накладыванием шаред локов на ПРОЧИТАННЫЕ данные до конца транзакции, в отличии от RC, при котором локи удерживаются на короткий промежуток, необходимый для чтения данных. Но вот при следующих чтениях могут как раз появляться НОВЫЕ записи, которых не было при предыдущих чтениях.
...
Рейтинг: 0 / 0
26.04.2011, 16:11
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234119
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
pkarklinbeginner_dba,

И, потом, вторая инструкция - это полная чушь. Нет такого:

Код: plaintext
alter database set isolation level snapshot

есть

Код: plaintext
ALTER DATABASE database_name SET READ_COMMITTED_SNAPSHOT ON

и

Код: plaintext
ALTER DATABASE database_name SET ALLOW_SNAPSHOT_ISOLATION ON

т.е. опции, которые позволяют:

1. Использовать RC с поддержкой версионности;
2. Использовать новый TIL SNAPSHOT.

Эти инструкции ни есть установка TIL для сессии, который по дефолту RC и может быть изменен по желанию разработчика.
Дело в том, что например 1С 8.1 при старте каждой сесии на сервер посылает вот такое

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language русский
set dateformat dmy
set datefirst  1 
set transaction isolation level read committed
А я хочу, чтобы была версионность (неблокирующее чтение (и неблокирующая вставка данных в ту же таблицу в рамках другой транзакции) больше нужно) независимо, от того, что посылает 1с для своего spid
...
Рейтинг: 0 / 0
26.04.2011, 16:14
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234130
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
kdvдля меня до сих пор является загадкой, как воспроизводимое (!) чтение может порождать какие-то фантомы.
Претензии к RR в MSSQL в общем-то те же, что и к Serializable в Oracle. А называть ли их фантомами или ещё какими глюками - дело десятое.
...
Рейтинг: 0 / 0
26.04.2011, 16:17
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234136
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 16:23, kdv wrote:
> не понимаю, откуда такая агрессия и гиперболы.
> Shapshot это фактически Repeatable Read без фантомов.

Да нет, это абсолютно разные вещи.
Агрессии нет. Есть непонимание, зачем на клетке с верблюдом
писать "Лев".
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 16:19
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234141
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
pkarklinпри следующих чтениях могут как раз появляться НОВЫЕ записи, которых не было при
предыдущих чтениях.

Т.е. имеет место неповторяемое чтение. Прелестно...

Впрочем, как я уже сказал, свежий стандарт уже не описывает изоляцию через глюки.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 16:20
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234150
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 17:04, kdv wrote:

> Фантом по определению это характеристика ReadCommitted, то есть когда очередным
> перечитыванием мы видим данные, которые успели измениться и быть committed с
> момента предыдущего чтения.

Феномен фантома может наблюдаться на ReadCommitted.
Но придуман он для описания уровней Repeatable Read и Serializable.

> Насколько я понимаю, когда-то подразумевалось,...

Ты понимаешь неправильно.

> И исходя из определения того же стандарта, если RR допускает фантомы, то это уже
> не RR, а RC.

Ты не понимаешь, что такое фантом в стандарте.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 16:22
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234152
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 26.04.2011 17:11, pkarklin wrote:

> RR не допускает МОДИФИКАЦИИ прочитанных данных,

К модификации данных RR не имеет почти никакого отношения.
RR описывается феноменами, возникающими при ЧТЕНИИ данных.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
26.04.2011, 16:23
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234165
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dba,

Перечитайте в документации, что делают две указанные опции.
...
Рейтинг: 0 / 0
26.04.2011, 16:28
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234176
Консистентность
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Консистентность
Гость
Yo.!КонсистентностьКстати такой же вопрос, есть ли возможность в MS SQL/Oracle/Firebird/PostgreSQL "обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения."?

oracle docsRead-Only Transactions

By default, the consistency model for Oracle guarantees statement-level read consistency, but does not guarantee transaction-level read consistency (repeatable reads). If you want transaction-level read consistency, and if your transaction does not require updates, then you can specify a read-only transaction. After indicating that your transaction is read-only, you can execute as many queries as you like against any database table, knowing that the results of each query in the read-only transaction are consistent with respect to a single point in time.
http://download.oracle.com/docs/cd/F49540_01/DOC/server.815/a68003/01_08pro.htm#2194
Насколько я понял здесь идет речь о statement-level read consistency и transaction-level read consistency. А интересует существуют ли в каких-либо СУБД механизмы консистентности межтранзакционного уровня. Слышал вроде есть привязки транзакций друг к другу?
...
Рейтинг: 0 / 0
26.04.2011, 16:33
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234214
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
КонсистентностьНасколько я понял здесь идет речь о statement-level read consistency и transaction-level read consistency. А интересует существуют ли в каких-либо СУБД механизмы консистентности межтранзакционного уровня. Слышал вроде есть привязки транзакций друг к другу?
ах транзакций. нет, такое только в оракле можно. взять timestamp (или SCN) и во всех транзациях через flashback query на этот timestamp (SCN) получать.
...
Рейтинг: 0 / 0
26.04.2011, 16:42
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234215
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
pkarklinbeginner_dba,

Перечитайте в документации, что делают две указанные опции.

ALLOW_SNAPSHOT_ISOLATION { ON | OFF }
ON
Enables Snapshot option at the database level. When it is enabled, DML statements start generating row versions even when no transaction uses Snapshot Isolation . Once this option is enabled, transactions can specify the SNAPSHOT transaction isolation level. When a transaction runs at the SNAPSHOT isolation level, all statements see a snapshot of data as it exists at the start of the transaction. If a transaction running at the SNAPSHOT isolation level accesses data in multiple databases, either ALLOW_SNAPSHOT_ISOLATION must be set to ON in all the databases, or each statement in the transaction must use locking hints on any reference in a FROM clause to a table in a database where ALLOW_SNAPSHOT_ISOLATION is OFF.
Это просто включает режим версионности по умолчанию? То есть если явно не указать TIL у сессии, то берем версионность?


READ_COMMITTED_SNAPSHOT { ON | OFF }
ON
Enables Read-Committed Snapshot option at the database level. When it is enabled, DML statements start generating row versions even when no transaction uses Snapshot Isolation . Once this option is enabled, the transactions specifying the read committed isolation level use row versioning instead of locking. When a transaction runs at the read committed isolation level, all statements see a snapshot of data as it exists at the start of the statement.
А это нахрапом, невзирая на личности, верно?
...
Рейтинг: 0 / 0
26.04.2011, 16:42
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234241
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dba,

Мдя...

Опция READ_COMMITTED_SNAPSHOT вводит версионный режим для дефолтного RC, когда читатели не мешают писателям и наоброт. Данные режим обеспечивает statement-level read consistency.

Опция ALLOW_SNAPSHOT_ISOLATION позволяет использовать (для этого его надо задать явно) TIL SNAPSHOT, который обесечивает transaction-level read consistency.
...
Рейтинг: 0 / 0
26.04.2011, 16:47
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234262
Консистентность
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Консистентность
Гость
beginner_dbapkarklinbeginner_dba,

И, потом, вторая инструкция - это полная чушь. Нет такого:

Код: plaintext
alter database set isolation level snapshot

есть

Код: plaintext
ALTER DATABASE database_name SET READ_COMMITTED_SNAPSHOT ON

и

Код: plaintext
ALTER DATABASE database_name SET ALLOW_SNAPSHOT_ISOLATION ON

т.е. опции, которые позволяют:

1. Использовать RC с поддержкой версионности;
2. Использовать новый TIL SNAPSHOT.

Эти инструкции ни есть установка TIL для сессии, который по дефолту RC и может быть изменен по желанию разработчика.
Дело в том, что например 1С 8.1 при старте каждой сесии на сервер посылает вот такое

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language русский
set dateformat dmy
set datefirst  1 
set transaction isolation level read committed
А я хочу, чтобы была версионность (неблокирующее чтение (и неблокирующая вставка данных в ту же таблицу в рамках другой транзакции) больше нужно) независимо, от того, что посылает 1с для своего spid
Делает именно то что вы написали
Код: plaintext
ALTER DATABASE database_name SET READ_COMMITTED_SNAPSHOT ON
Если документация не понятна, попробуйте её на русском прочитать.
...
Рейтинг: 0 / 0
26.04.2011, 16:53
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234319
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
pkarklinbeginner_dba,

Мдя...

Опция READ_COMMITTED_SNAPSHOT вводит версионный режим для дефолтного RC, когда читатели не мешают писателям и наоброт. Данные режим обеспечивает statement-level read consistency.

Опция ALLOW_SNAPSHOT_ISOLATION позволяет использовать (для этого его надо задать явно) TIL SNAPSHOT, который обесечивает transaction-level read consistency.

Т.о. при включенных обоих опциях, одна которая позволяет в принципе использовать версионность для всей транзакции (с обязательным явным указанием TIL Snapshot), а другая использовать версионность для инструкции "по умолчанию" не отработают версионным механизмом, если при старте сессии будет инструкция read commited. Потому что дефолта нет, так как явно указан read commited и также не указан явно snapshot.Правильно?
...
Рейтинг: 0 / 0
26.04.2011, 17:11
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234335
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
beginner_dbaТ.о. при включенных обоих опциях, одна которая позволяет в принципе использовать версионность для всей транзакции (с обязательным явным указанием TIL Snapshot), а другая использовать версионность для инструкции "по умолчанию" не отработают версионным механизмом, если при старте сессии будет инструкция read commited. Потому что дефолта нет, так как явно указан read commited и также не указан явно snapshot.Правильно?

Вот это вот я для кого написАл?!

pkarklinОпция READ_COMMITTED_SNAPSHOT вводит версионный режим для дефолтного RC, когда читатели не мешают писателям и наоброт.

"если при старте сессии будет инструкция read commited" = "дефолтный RC".
...
Рейтинг: 0 / 0
26.04.2011, 17:16
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234447
beginner_dba
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beginner_dba
Участник
Код: plaintext
"если при старте сессии будет инструкция read commited" = "дефолтный RC"
то отработает версионный механизм. Все понятно, большое спасибо, что тупицу просвятили
...
Рейтинг: 0 / 0
26.04.2011, 18:00
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37234815
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
pkarklinScareCrowШтуки три я назову сходу.
я только сабейз Асе.

MS SQL без включенной версионности.[/quot]

IBM Informix [Dynamic Server]

что ещё?
...
Рейтинг: 0 / 0
26.04.2011, 22:50
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37239075
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ggg_old
Участник
db2,informix (вроде кажется появилась поддержка last comitted в какой-то из последних версий но деталей не знаю),sybase ase, sabase sa(с выключенной версионностью).
sybase sa, mssql, informix умеют last comitted - что не совсем версионность, т.е. есть только одна версия строки - перед ее модификацией. Если ошибаюсь - поправьте.
Еще краем уха слышал про поддержку lastconmitted а дб2 но не уверен, так как не слежу,
...
Рейтинг: 0 / 0
28.04.2011, 21:11
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37239097
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Ggg_old...mssql... умеют last comitted - что не совсем версионность, т.е. есть только одна версия строки - перед ее модификацией. Если ошибаюсь - поправьте.

Поправляю...

When either the READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION database options are ON, logical copies (versions) are maintained for all data modifications performed in the database. Every time a row is modified by a specific transaction, the instance of the Database Engine stores a version of the previously committed image of the row in tempdb. Each version is marked with the transaction sequence number of the transaction that made the change. The versions of modified rows are chained using a link list. The newest row value is always stored in the current database and chained to the versioned rows stored in tempdb.
...
Рейтинг: 0 / 0
28.04.2011, 21:30
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37239160
lastconmitted
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lastconmitted
Гость
lastconmitted это тоже что Read Commited только с одной последней версией строки или что-то другое?
...
Рейтинг: 0 / 0
28.04.2011, 22:30
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37239189
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ggg_old
Участник
насчет микрософта меня поправили а насчет сайбейс са посыпаю голову пеплом версий - строк много. Откуда в голову попал термин last comitted уже не помню, кажется из информикаса, но не уверен. прошу прощения за дезинформацию.
...
Рейтинг: 0 / 0
28.04.2011, 23:03
| Ответить | Цитировать | Написать  
О консистентности отчетов на OLTP-сервере
    #37239220
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
АнатоЛой
Участник
Ggg_oldнасчет микрософта меня поправили а насчет сайбейс са посыпаю голову пеплом версий - строк много. Откуда в голову попал термин last comitted уже не помню, кажется из информикаса, но не уверен. прошу прощения за дезинформацию.
Да, в блокировочнике Informix с версии 11.10 появился именно этот режим - LAST COMITTED.

DIRTY READ = ANSI UNCOMMITTED READ - позволяет читателям читать всё подряд. при этом можно было читать данные неподтверждённых транзакций - именно "новую" версию данных :(.

COMMITTED READ = ANSI COMMITTED READ - читаем только подтверждённые, при этом если натыкаемся на изменённые не подтверждённые - вываливаемся с ошибкой - либо ждём, пока отпустит :).

COMMITTED READ LAST COMMITTED (появился с версии 11.10 года 4 назад) - позволяет читателям читать всё подряд. при этом для данных, изменённых транзакциями читает "старую версию" данных - как в версионнике для СOMMITTED READ.
...
Рейтинг: 0 / 0
28.04.2011, 23:44
| Ответить | Цитировать | Написать  
70 сообщений из 70, показаны все 3 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / О консистентности отчетов на OLTP-сервере
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552696]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 36ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 86ms
get tp. blocked users:
 2ms
others: 13ms
total:  181ms
созд. / загр.: 181ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]