Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Yo.!!
https://www.sql.ru/forum/actualthread.aspx?bid=1&tid=172639&pg=-1
Судя по комментарию, Вы не совсем поняли смысл той дискуссии.
softwarer
MSSQL на уровне RC не обеспечивает read consistency.
Это было лишь мое предположение, достаточно гипотетическое и ничем, кроме той дискуссии, не подтвержденное. Подозрение возникает на основании той самой оптимизации, которую, по словам Merle, выполняет сервер, т.е., в некоторых случаях он может не накладывать shared блокировку при чтении. Собственно, он там же, но чуть раньше, писал о том же самом. Сам лично специально не проверял, так как это поведение легко изменяется в желаемую сторону добавлением хинта HOLDLOCK для соответствующей таблицы. IMHO, подобное поведение формально не противоречит описанию READ COMMITTED, так как чтение происходит только данных из подтвержденных транзакций. Хотя, в целом, это, конечно, было несколько неожиданно. И хотя вероятность подобных несогласованностей на практике, опять же, IMHO, не велика, тем не менее неприятно, так как о такой "оптимизации" узнать практически невозможно, пока не натолкнешься на сам факт.
Насколько знаю, в 2005 read consistency на уровне оператора обеспечивается способом аналогичным Oracle при использовании механизма SNAPSHOT-ов. Впрочем, это на уровне знакомства с отдельными источниками, ничего более внятного предложить не могу, не имел дела.
27 сен 06, 21:31    [3193490]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ChA
Судя по комментарию, Вы не совсем поняли смысл той дискуссии.

вполне вероятно, я имел ввиду вот эту фичу:
GreenSunrise
Итак, в первом коннекте есть эксклюзивный лок на оба индекса - и кластерный и некластерный. Эксклюзивная блокировка означает, что все другие типы блокировок с ней несовместимы. Несмотря на это утверждение, второй коннект читает данные, опираясь на кластерный индекс. Для чтения необходимо наложить как минимум shared блокировку, поскольку хинта nolock нет.


ну и ваш вопрос о целостности на уровне одного запроса тоже очень интересует, может кто другой знает точный ответ ?

ChA

Насколько знаю, в 2005 read consistency на уровне оператора обеспечивается способом аналогичным Oracle при использовании механизма SNAPSHOT-ов. Впрочем, это на уровне знакомства с отдельными источниками, ничего более внятного предложить не могу, не имел дела.

угу, как говорится верной дорогой идете товарищи, говорят вот и Sybase (ASA) тоже MVCC добавила, даешь оракловый MVCC стандарт ! :)
27 сен 06, 22:28    [3193610]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Не понимаю, чего тут такую кашу развели с несчастным READ COMMITED - ведь написанно же, читаем закомиченные данные. Хотим второй раз те же данные считать, ставим REPEATABLEREAD, боимсе при повторном чтении новые записи схлопотать - ставим SERIALIZABLE. Все как написано в стандарте, работать в любом сервере должно одинаково по смыслу. Не понятно к чему здесь можно спорить ... а то вон Yo! вообще уже по индексам незакомиченные данные читать начал прямо на RC, кошмар да и только
--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
27 сен 06, 22:48    [3193664]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Yo.!!
вполне вероятно, я имел ввиду вот эту фичу:
[quot GreenSunrise ]Итак, в первом коннекте есть эксклюзивный лок на оба индекса - и кластерный и некластерный. Эксклюзивная блокировка означает, что все другие типы блокировок с ней несовместимы. Несмотря на это утверждение, второй коннект читает данные, опираясь на кластерный индекс. Для чтения необходимо наложить как минимум shared блокировку, поскольку хинта nolock нет.
Ну, пожалуйста, прочитай внимательнее дискуссию, не придумывай ничего своего. Повторяю, это не имеет ничего общего с твоим комментарием о возможности чтения незакомиченных данных на уровне RC.
Yo.!!
ну и ваш вопрос о целостности на уровне одного запроса тоже очень интересует, может кто другой знает точный ответ ?
Не может, а наверняка знает кто-либо из разработчиков или лиц, к ним приближенных, одним из которых, насколько понимаю, является вышеупомянутый Merle, достаточно известная личность на RSDN. Многим его утверждениям вполне можно доверять, IMHO. Хотя возможно некоторые стоит и перепроверить...
Yo.!!
говорят вот и Sybase (ASA) тоже MVCC добавила, даешь оракловый MVCC стандарт !
Возможно неправ, но, по некоторым отрывочным сведениям, Oracle просто не имеет RC, он у него фактически эквивалентен RR. Другое дело, что существует критика существующих на сегодняшний день уровней изоляции в ANSI, но это уже совсем другоя тема.
27 сен 06, 23:53    [3193770]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ChA
Ну, пожалуйста, прочитай внимательнее дискуссию, не придумывай ничего своего. Повторяю, это не имеет ничего общего с твоим комментарием о возможности чтения незакомиченных данных на уровне RC.

блин еще один, непойму где вы (и остальные) увидели "чтения незакомиченных данных", я упомянул "прочитать старое значение записи котрую уже проапдейтили "

ChA
Многим его утверждениям вполне можно доверять, IMHO. Хотя возможно некоторые стоит и перепроверить...

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

ChA

Возможно неправ, но, по некоторым отрывочным сведениям, Oracle просто не имеет RC, он у него фактически эквивалентен RR. Другое дело, что существует критика существующих на сегодняшний день уровней изоляции в ANSI, но это уже совсем другоя тема.

все проще, в оракле просто другие уровни изолированости. стандарт писался под блокировочник и ораклу просто пришлось называть свои уровни так, чтоб удолетворять требованиям стандарта.
28 сен 06, 00:19    [3193808]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Yo.!!
блин еще один, непойму где вы (и остальные) увидели "чтения незакомиченных данных", я упомянул "прочитать старое значение записи котрую уже проапдейтили "
Да, sorry, был неправ. Было
Yo.!!
или прочитать старое значение записи котрую уже проапдейтили но еще не закомитили (из индекса)
Где пример или ссылка ? Та которая давали ранее никак не относится к этому утверждению...

Yo.!!
честно говоря он тут произвел неизгладимое впечатление обнаружив блокировки в читающих транзакциях оракла , может найдутся другие кандидатуры ?
А шо, таки нету ? :)
Для меня, например, "читающая транзакция" есть нонсенс, хотя в понятиях работы версионного механизма Oracle, насколько понимаю, это вполне корректный термин.

P.S. Вообще говоря, можно было бы провести соответствующий тест, но, если честно, не вижу смысла, хотя методику, пожалуй, представляю.
28 сен 06, 01:30    [3193893]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
ChA
Для меня, например, "читающая транзакция" есть нонсенс, хотя в понятиях работы версионного механизма Oracle, насколько понимаю, это вполне корректный термин.
А если добавить "блокирующая", то будет понятнее?
Получится "блокирующая читающая транзакция" (та, что не даст в MSSQL другой транзакции обновить эти же строки)
28 сен 06, 01:39    [3193897]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Anton Demidov
А если добавить "блокирующая", то будет понятнее?
Получится "блокирующая читающая транзакция" (та, что не даст в MSSQL другой транзакции обновить эти же строки)
Если не вдаваясь в определения, коим полон Инет, то для меня транзакция - это последовательность изменений БД из одного целостного состояния в другое. Соответственно, чтение, само по себе, транзакцией не считается. В блокировочниках, как правило, при любом чтении используемые данные блокируются, за исключением разве, особых условий, когда это не делается, наподобие упомянутых здесь ранее. Отсюда, нет необходимости изобретать эвфемизмов типа "читающая транзакция". Так что, возможно, надо было быть проще и прямо так и писать "блокирующее чтение", так как к транзакциям в прямом("классическом") смысле эта процедура никакого отношения не имеет, IMHO.
28 сен 06, 02:41    [3193931]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
ChA
Anton Demidov
А если добавить "блокирующая", то будет понятнее?
Получится "блокирующая читающая транзакция" (та, что не даст в MSSQL другой транзакции обновить эти же строки)
Если не вдаваясь в определения, коим полон Инет, то для меня транзакция - это последовательность изменений БД из одного целостного состояния в другое. Соответственно, чтение, само по себе, транзакцией не считается. В блокировочниках, как правило, при любом чтении используемые данные блокируются, за исключением разве, особых условий, когда это не делается, наподобие упомянутых здесь ранее. Отсюда, нет необходимости изобретать эвфемизмов типа "читающая транзакция". Так что, возможно, надо было быть проще и прямо так и писать "блокирующее чтение", так как к транзакциям в прямом("классическом") смысле эта процедура никакого отношения не имеет, IMHO.

Мне кажется, что для того чтобы произвести целостное состояние из одного в другое в первую очередь требуется чтение данных, а уж потом их изменение (даже на вставку таблиц с FK будут читаться родительские таблицы). Соответственно чтение должно обеспечить доступ к целостной информации, а значит так же включается в понятие транзакции. По стандарту допустимое качество целостности информации определяется уровнями изоляции, на практической реализации это разруливается shared-блокировками или работой с версиями записей для различных СУБД. Хотя конечно вопрос спорный.

Еще хотелось бы задать немного ламерский вопрос тем, кто работает с версионниками (так сказать для ликбеза) - как на версионнике обеспечить уровень изоляции SERIALIZABLE для гарантированного отсутствия фантомов.
К примеру мне нужно по условию задачи вставить в Таблицу1 запись и если это первая вставленная запись, то вставить запись в Таблицу2. Никаких уникальных индексов/ограничений на обеих таблицах нет. Для блокировочника даже на уровне RC этот вариант замечательно отработает. Что нужно сделать на версионнике, чтобы 2 сессии при одновременной вставке первой записи в Таблицу1 получили на выходе только 1 запись в Таблице2 ? (естественно без блокировки таблицы в эклюзивном режиме).
28 сен 06, 07:46    [3194080]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
ЛП
транзакция рушится на коммите.


Специально для УМНЫХ аксессников - ТРАНЗАКЦИЯ не рушиться. Конкретный DML ловит Exception, вполне штатная ситуация (транзакции от этого не жарко и не холодно). Далее ПРИЛОЖЕНИЕ (или оператор, в случае тяжелой потологии, но опять эе через какое-то ПРИЛОЖЕНИЕ а не силой мысли) решает что делать с этой транзакцией, откатить, закомитить или попробовать что-то еще.

ЛП

что никаких сейв-поинтов может не быть установлено


Ишо раз (последний, потерпи) пабуквам:

Savepoint в Oracle выставляется АВТОМАТИЧЕСКИ, и откат к нему в случае неуспешного DML также производится АВТОМАТИЧЕСКИ

ЛП

У тебя есть документация по аксесу?


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

Хочется какта приобщиться
28 сен 06, 09:11    [3194255]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

ASCRUS

Что нужно сделать на версионнике, чтобы 2 сессии при одновременной
вставке первой записи в Таблицу1 получили на выходе только 1 запись в
Таблице2 ? (естественно без блокировки таблицы в эклюзивном режиме).

Не нужно ничего делать ибо полный облом: в таблице2 будет две записи в
силу одного из базовых принципов транзакций (не помню, правда которого
из ACID. Кажется, I): каждая транзакция работает с базой так будто
других транзакций не существует. Если блокировочники позволяют нарушать
ACID, это... их ниша.

Posted via ActualForum NNTP Server 1.3

28 сен 06, 09:40    [3194391]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67393
Блог
ChA
Судя по комментарию, Вы не совсем поняли смысл той дискуссии.

Почему-то я уверен, что если я попрошу Вас логически строго обосновать свое утверждение, мы придем к выводу, что Вы брякнули абы что.

ChA
Это было лишь мое предположение, достаточно гипотетическое и ничем, кроме той дискуссии, не подтвержденное.

То есть, если я правильно понял, Вы не производили экспериментов, не задавали вопросов и другими способами не выясняли, какой же все-таки результат запроса вернет Вам сервер.

Тогда вопрос: каким образом Вы добиваетесь того, что приложение ведет себя предсказуемым образом? Пихаете в каждый нетривиальный запрос хинт holdlock? Используете только простые запросы? Что-то другое? Оставляете на самотек, "авось не случится", наконец?

ChA
Насколько знаю, в 2005 read consistency на уровне оператора обеспечивается способом аналогичным Oracle при использовании механизма SNAPSHOT-ов.

Нельзя ли ссылку?
28 сен 06, 09:43    [3194410]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19905
ASCRUS
Еще хотелось бы задать немного ламерский вопрос тем, кто работает с версионниками (так сказать для ликбеза) - как на версионнике обеспечить уровень изоляции SERIALIZABLE для гарантированного отсутствия фантомов.

Но-но, попрошу без провокаций :)
Согласованое изменение данных требует синхронизации, будь ты хоть десятирежды версионником.
С другой стороны, попробуйте приветси хоть одну реальную задачу, под которую требуется контроль количества записей в таблице и которую нельзя решить без такого контроля после небольшой нормализации :)
Что же до мнимых преимуществ блокировочников в плане соответствия стандарту - то я с удовольствием променяю это соответствие на возможность запустить отчет по оперативным OLTP-таблицам в разгар рабочего дня ;)
28 сен 06, 09:45    [3194422]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Dimitry Sibiryakov

ASCRUS

Что нужно сделать на версионнике, чтобы 2 сессии при одновременной
вставке первой записи в Таблицу1 получили на выходе только 1 запись в
Таблице2 ? (естественно без блокировки таблицы в эклюзивном режиме).

Не нужно ничего делать ибо полный облом: в таблице2 будет две записи в
силу одного из базовых принципов транзакций (не помню, правда которого
из ACID. Кажется, I): каждая транзакция работает с базой так будто
других транзакций не существует. Если блокировочники позволяют нарушать
ACID, это... их ниша.
Posted via ActualForum NNTP Server 1.3

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

andrey_anonymous
Но-но, попрошу без провокаций :)
Согласованое изменение данных требует синхронизации, будь ты хоть десятирежды версионником.
С другой стороны, попробуйте приветси хоть одну реальную задачу, под которую требуется контроль количества записей в таблице и которую нельзя решить без такого контроля после небольшой нормализации :)
Что же до мнимых преимуществ блокировочников в плане соответствия стандарту - то я с удовольствием променяю это соответствие на возможность запустить отчет по оперативным OLTP-таблицам в разгар рабочего дня ;)

Это не провокация, а вопрос. Задача приведена упрощенная, однако реально существует определенный круг таких задач, тот же биллинг. Я тоже как бы запускаю отчеты по оперативным OLTP таблицам на блокировочнике в разгар рабочего дня и проблем не наблюдаю, так как есть функционал сервера, позволяющий решать проблему блокирования читателей с помощью тех же времянок. И меня интересует не стандарт, а именно фантомы в чистых версионниках - хочется понять насколько сейчас по сравнению с ними выгоднее гибриды (тот же MSSQL 2005 или ASA10), которые позволяют одновременно работать на блокировках с честным SERIALIZABLE для OLTP и через версии записей/страниц организовывать SNAPSHOP для OLAP.

P.S. Я так правильно понимаю у чистых версионников моя поставленная проблема должна решается не сервером, а проектировщиком (как я решаю такую же проблему для OLAP на блокировочнике) ?
28 сен 06, 10:08    [3194560]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

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

onstat-

Но ситуации опсанной мною в примере не нашел.
Единственной зацепкой есть
автор

all queries return information with respect to the system change number (SCN)

В качестве оффтопика прошу прокоментировать зантоков Английского эту фразу.
А эта цитата противоречит вашему правилу
автор

The return set for a SELECT... FOR UPDATE may change while the query is running; for example, if columns selected by the query are updated or rows are deleted after the query started. When this happens, SELECT... FOR UPDATE acquires locks on the rows that did not change, gets a new read-consistent snapshot of the table using these locks, and then restarts the query to acquire the remaining locks.

Может я ее неправильно понял?

Ооооо... Тут мы попадаем в царство привидений.
Вы только что открыли для себя один из самых неоднозначных и малоизвестных широкой общественности механизмов oracle, который называется statement restart.
На стандарт кивать бесполезно, это проприетарное ноу-хау :)
Смысл в том, что ежели dml-запросу (включая select for udate) не удается заблокировать консистентный набор строк, то oracle... просто откатывает statement и начинает все сначала, смещая SCN на момент повторного старта ежели дело происходит в read commited или выкидывает "Can't serialize access" в serializable.
К readonly это все не относится, поскольку dml в такой транзакции запрещен, а читаемый набор набор просто реконструируется на заданный момент времени (раздел read consistency and concurrency в oracle concepts).


Андрей,
поведение рестарта для меня логично и понятно,

Мне неясно откуда взялось правило:

AI


Команда или вся транзакция (в зависимости от уровня изолированности) должна видеть данные на момент своего старта. Это правило для транзакции.



ИХМО его практически не возможно выполнить в
любой многопользовательской(многонитевой) СУБД
при приемлимой производительности.

Я хотел найти этому подтверждение или опровержение.
28 сен 06, 10:09    [3194572]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

ASCRUS

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

"Согласованно" и "независимо" (вроде бы I это как раз Independency) это
как бы антонимы, ну да ладно...
ASCRUS

P.S. Я так правильно понимаю у чистых версионников моя поставленная
проблема должна решается не сервером, а проектировщиком (как я решаю
такую же проблему для OLAP на блокировочнике) ?

За все версионники не скажу, но для FB - да. SERIALIZABLE там в принципе
не поддерживается. Хотя... с транзакциями уровня "consistency" я не
работал. Впрочем, их не рекомендуют даже собаководы ибо ахтунг.

Posted via ActualForum NNTP Server 1.3

28 сен 06, 10:37    [3194750]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
ASCRUS

Это не провокация, а вопрос.

это провакация, у вас уже есть задача с которой вы так и не справились.

ASCRUS

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

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

ASCRUS
И меня интересует не стандарт, а именно фантомы в чистых версионниках - хочется понять насколько сейчас по сравнению с ними выгоднее гибриды (тот же MSSQL 2005 или ASA10), которые позволяют одновременно работать на блокировках с честным SERIALIZABLE для OLTP и через версии записей/страниц организовывать SNAPSHOP для OLAP.

ну и как вы это себе представляете ? OLPT задыхается в блокировок и дедлогах ставя на каждый чих локи и к тому же еще создает версии строк для MVCC режима, как вы думаете какой перфоменс будет у такого подхода ?

ASCRUS

P.S. Я так правильно понимаю у чистых версионников моя поставленная проблема должна решается не сервером, а проектировщиком (как я решаю такую же проблему для OLAP на блокировочнике) ?

еще раз, сформулируйте задачу из реальной жизни и вам все рассскажут, считать кол-во записей в таблице - это результат кривого проэктирования.
28 сен 06, 10:44    [3194792]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19905
onstat-
Андрей,
поведение рестарта для меня логично и понятно,
Мне неясно откуда взялось правило:
AI
Команда или вся транзакция (в зависимости от уровня изолированности) должна видеть данные на момент своего старта. Это правило для транзакции.

ИХМО его практически не возможно выполнить в
любой многопользовательской(многонитевой) СУБД
при приемлимой производительности.

А говорите понятно :)
Тут все просто. Запрос должен вернуть согласованный набор данный на некоторый момент времени.
Для "блокировочников" это момент окончания запроса, для "версионников" - момент начала. Просто ввиду особенностей технологии.
28 сен 06, 10:53    [3194862]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19905
ASCRUS
P.S. Я так правильно понимаю у чистых версионников моя поставленная проблема должна решается не сервером, а проектировщиком (как я решаю такую же проблему для OLAP на блокировочнике) ?

Любая проблема в конечном итоге решается человеком.
Ваш конкретный задачк - тоже.
"На вскидку" можно предложить решения:
- на функциональных индексах
- на триггерах и пользовательских блокировках
- на материализованных представлениях и uniq
- перепроектировать.

... А про биллинг - это Вы зря. Нет там таких задач, я бы знал ;)
28 сен 06, 10:56    [3194889]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
ASCRUS прав в элементарной вещи: эфективно работающий биллинг на чистом версионнике без блокировок не написать.
Ну ладно, скажем так: для всех проблем, что я увидел, блокировки были единственным мною замеченным корректно работающим решением.
28 сен 06, 10:59    [3194912]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
onstat-
Member

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

Что же до мнимых преимуществ блокировочников в плане соответствия стандарту - то я с удовольствием променяю это соответствие на возможность запустить отчет по оперативным OLTP-таблицам в разгар рабочего дня ;)


Андрей, разберемся в следующих вопросах.

1.Удобное формирование репортов.

Версионники действительно хорошо и удобно делают репорты в середине
рабочего дня на OLTP. С этим спорить трудно.

Теперь вопрос 2-й на основанни чего они его делают

Давайте рассмотрим задачу о "хлебе насущном"
Она заключается в слудующем
У нас есть гипотетических гиперрмаркет есть кассы( клиенты СУБД).
Условие задачи состоит в том что клиенты берут ~50 наименований товара и 90% клиентов супермаркетапокупают хлеб.
По другим позициям пересечений немного.
Что при этом происходит.
Если брать к примеру oracle
Все транзакции толкутся вокруг позиции хлеб(пытаясь установить
блокировку select for update) идет постоянный рестарт.
fetch по другим позициям в это время тоже зделать нельзя( курсор еще не готов), и записи по другим позиция уже заблокированы. И паралельно обрабатываться не могут.

Что при этом будет у блокировочника.
Остальные 49 позиций он будет(может) обрабатывать, когда останется только хлеб, он дождется своей очереди обработает и отпустит
(закомитит) все записы.

При этом oracle только начнет фетчить и обрабатывать, продолжая держать все записи курсора.

А что будет с версионником который не имеет рестарта я боюсь себе даже предствить.

Мое резюме по этому поводу:
Для каждой задачи можно найти свои достоинства и
недостатки в любой СУБД.
28 сен 06, 11:17    [3195077]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

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

Funny_Falcon

ASCRUS прав в элементарной вещи: эфективно работающий биллинг на чистом
версионнике без блокировок не написать.

А эффективно работающий биллинг позарез требует хранение текущих
остатков? Ну извините тады...

Posted via ActualForum NNTP Server 1.3

28 сен 06, 11:17    [3195083]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19905
Funny_Falcon
ASCRUS прав в элементарной вещи: эфективно работающий биллинг на чистом версионнике без блокировок не написать.
Ну ладно, скажем так: для всех проблем, что я увидел, блокировки были единственным мною замеченным корректно работающим решением.

Что-то мне подсказывает, что Вы более чем тенденциозны.
По крайней мере биллинги ведущих операторов сотовой связи РФ и многих (ну не всех же я знаю :) зарубежных писаны на оракеле, а не на MSSQL/DB2 ;)
28 сен 06, 11:18    [3195099]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19905
onstat-
Если брать к примеру oracle

Простите, но тут Вы пытаетесь навязать свойства какой-то очень неудачной реализации серверу БД.
Какой курсор "не готов"? Почему он "не готов"?
Если Вам интересны конкретные технические решения, которые могли бы работать в Вашей задаче - могу проконсультировать, но это уже оффтоп поэтому предпочтительно все-таки в личной переписке.
Могу даже спроектировать и сделать пилот, но уже за деньги :)
28 сен 06, 11:23    [3195143]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
Dimitry Sibiryakov
А эффективно работающий биллинг позарез требует хранение текущих
остатков? Ну извините тады...

Более - менее RealTime биллинг для телефонной связи (с задержкой меньше минуты) требует хранения информации о текущих разговоров.

andrey_anonymous
Что-то мне подсказывает, что Вы более чем тенденциозны.
По крайней мере биллинги ведущих операторов сотовой связи РФ и многих (ну не всех же я знаю :) зарубежных писаны на оракеле, а не на MSSQL/DB2 ;)

У меня тоже на PostgreSQL - а он еще больщий версионник чем Oracle :-)
На версионнике биллинг получается лучше (я и не спорю), но без блокировок по-любому не обойтись (моё мнение).
28 сен 06, 11:25    [3195168]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить