Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 О консистентности отчетов на OLTP-сервере  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Народ,

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

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

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

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

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

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

Вопрос как вы выходите из ситуации в своих системах? Есть ли решения на системном уровне СУБД?
25 апр 11, 17:49    [10564254]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Dimitry Sibiryakov
Member

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

Rus000
Вопрос как вы выходите из ситуации в своих системах? Есть ли решения на системном уровне СУБД?

Уровень изоляции Repeatable Read (snapshot на MS SQL, Read Only на Oracle, concurrency на
IB/FB) гарантирует, что любой запрос в пределах транзакции видит данные такими, какими они
были на момент старта транзакции. У версионников нет проблем с блокировками и изменением
данных другими пользователями.

Posted via ActualForum NNTP Server 1.4

25 апр 11, 18:26    [10564407]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Dimitry Sibiryakov,

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

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

Вот здесь приведен пример где в двух сессия коммитят данные на уровне READ_COMMITED и данные закоммиченные второй сессией попадают в первую.
25 апр 11, 18:48    [10564497]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Dimitry Sibiryakov
Уровень изоляции Repeatable Read (snapshot на MS SQL, Read Only на Oracle, concurrency на
IB/FB) гарантирует, что любой запрос в пределах транзакции видит данные такими, какими они
были на момент старта транзакции.


как долго хранятся версии данных? наверняка есть ограничения физической реализации ... например если отчет идет 10+ часов, при активных апдейтах сотен пользователей может ли субд действительно гарантировать извлечение нужной версии данных на 10 часов назад?
25 апр 11, 19:15    [10564563]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Yo.!
Guest
Rus000
хм ... возможно я ошибаюсь но с ораклом тоже не все красиво насколько я понял - в рамках одно транзакции нужные версии данных берутся из сегментов отката, однако размер их имеет ограничение и эти сегменты при активных апдейтах могут быть перезаписаны новыми данными.

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

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

Вот здесь приведен пример где в двух сессия коммитят данные на уровне READ_COMMITED и данные закоммиченные второй сессией попадают в первую.

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

в общем у версионных субд с читающими транзакциями вообще никаких проблем. у блокировочника обычно писателей и читателей разводят через финт "закрытый период" и табу на update, ночью закрывают день, вычисляют агрегаты. когда в час пик клиент запускает отчет вычитываются агригаты и к ним прибавляются транзакции прошедшие задень. допустим для банковского счета берут баланс с которым он был закрыт ночью + все платежи прошедшие за этот день.
25 апр 11, 19:16    [10564569]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Yo.!
Guest
Rus000
как долго хранятся версии данных? наверняка есть ограничения физической реализации ... например если отчет идет 10+ часов, при активных апдейтах сотен пользователей может ли субд действительно гарантировать извлечение нужной версии данных на 10 часов назад?

в оракле так и выставляется UNDO_RETENTION в минутах. поставь 24 часа с запасом, ну будет у тебя UNDO в пару десятков гиг, время бэкапа увеличиться на 5 минут ...
25 апр 11, 19:20    [10564572]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Dimitry Sibiryakov
Member

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

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

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

Posted via ActualForum NNTP Server 1.4

25 апр 11, 19:33    [10564607]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Консистентность
Guest
Rus000
Можете пояснить каким образом обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения.

Кстати такой же вопрос, есть ли возможность в MS SQL/Oracle/Firebird/PostgreSQL "обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения."?
25 апр 11, 19:37    [10564613]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Консистентность
Guest
Dimitry Sibiryakov, понятно что и кому отрывать, но чисто теоретически такая возможность есть? :)
25 апр 11, 19:39    [10564615]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Dimitry Sibiryakov
Member

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

Для извращенцев есть flashback queries.

Posted via ActualForum NNTP Server 1.4

25 апр 11, 19:54    [10564651]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Yo.!
Guest
Консистентность
Кстати такой же вопрос, есть ли возможность в MS SQL/Oracle/Firebird/PostgreSQL "обеспечить непротиворечивое чтения для ВСЕГО ОТЧЕТА при условии что данные выбираются более чем одной транзакцией чтения."?


oracle docs
Read-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
25 апр 11, 19:59    [10564662]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
для оракла все более-менее понятно, спасибо Yo! и Dmitry S.

приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?
25 апр 11, 20:07    [10564688]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Dimitry Sibiryakov
Member

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

По-моему, блокировочник проще выкинуть, чем чинить.

Posted via ActualForum NNTP Server 1.4

25 апр 11, 20:11    [10564702]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Yo.!
Guest
Rus000
приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?

тады только одно - выносить весь репортинг на отдельный сервер и туда или реплицировать или log shiping с oltp. но там тьма нюансов в зависимости от вендора и характера вашего oltp.
25 апр 11, 20:12    [10564703]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Редкий случай, когда Дмитрий пишет так много и так правильно :)

Для блокировочника понятие констистентности отчёта настолько виртуально, что большинство известных мне разработчиков не очень понимали, что это такое :) Имхо нормальных решений кроме "блокировки периода" для него таки нет.
25 апр 11, 20:21    [10564726]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
АнатоЛой
Member

Откуда: Киев, Украина
Сообщений: 2897
Блог
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 не очень большое - блокировка не должна оказаться длительной и критичной. Ожидать будут вынуждены только те сесии, которые попытаются во время работы отчёта писать "документы" с "меткой" в этом временном промежутке. Естественно, после окончания отчёта, отчёт снимает "временное закрытие".

Вот такой вот геморрой для архитектора системы. Поэтому обычно для существующей системы на блокировочнике при требовании "нужен консистентный отчёт" разработчики будут тщательно выпытывать у заказчика: "в чём именно консистентный, насколько большой объём период может быть запрошен" и т.д. и т.п. ...
26 апр 11, 05:31    [10565341]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
АнатоЛой
И это будет выглядеть просто, когда вы сможете перед запуском отчёта без проблем приостановить реплику-шиппинг, а после окончания формирования отчёта - без проблем продолжить...


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

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


именно то что это нужно предусматривать в стадии проектирования системы и смущает. Получается в унаследованных системах на блокировочниках архитектура которых не предусматривала исторических данных можно строить отчеты только на снап-шотах
26 апр 11, 06:17    [10565381]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
ScareCrow
Member

Откуда: Белый город
Сообщений: 17472
softwarer
Для блокировочника понятие констистентности отчёта настолько виртуально, что большинство известных мне разработчиков не очень понимали, что это такое :) Имхо нормальных решений кроме "блокировки периода" для него таки нет.

а в наше время еще остались таки блокировочники?
26 апр 11, 10:59    [10566315]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
MasterZiv
Member

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

On 25.04.2011 20:33, Dimitry Sibiryakov wrote:

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

А как же фантомы ?

Posted via ActualForum NNTP Server 1.4

26 апр 11, 11:46    [10566669]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
MasterZiv
А как же фантомы ?

это у стандартного RepeatableRead допускаются фантомы. а у Snapshot никаких фантомов нет в принципе, и быть не может.
26 апр 11, 11:58    [10566810]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
MasterZiv
Member

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

On 26.04.2011 12:58, kdv wrote:
> А как же фантомы ?
> это у стандартного RepeatableRead допускаются фантомы. а у Snapshot никаких
> фантомов нет в принципе, и быть не может.

Так вы уж определитесь. RepeatableRead и Snapshot -- не одно и то же.

Posted via ActualForum NNTP Server 1.4

26 апр 11, 12:13    [10566931]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
MasterZiv
Так вы уж определитесь. RepeatableRead и Snapshot -- не одно и то же.

у "нас", то есть в IB/FB, есть snapshot, RepeatableRead нет. Собственно, "настоящий" RepeatableRead мало где есть, наверное только в DB2? Кому он нафиг нужен, с фантомами-то?
Да и тут про это давно написано
http://emanual.ru/download/www.eManual.ru_538.html
26 апр 11, 13:10    [10567443]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
это я к тому, что упоминая RepeatableRead уже никто не вспоминает ни про какие фантомы, и обычно подразумевает, что RepeatableRead=Snapshot.
26 апр 11, 13:15    [10567499]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
ScareCrow
а в наше время еще остались таки блокировочники?

Штуки три я назову сходу.
26 апр 11, 13:21    [10567566]     Ответить | Цитировать Сообщить модератору
 Re: О консистентности отчетов на OLTP-сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kdv
это я к тому, что упоминая RepeatableRead уже никто не вспоминает ни про какие фантомы, и обычно подразумевает, что RepeatableRead=Snapshot.


А как же стандрат?
26 апр 11, 13:28    [10567636]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить