Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Glory
Сергей Васкецов

Да, для расчета производственной себестоимости

Хм. Наверное я уже чего-то не понимаю в этой жизни.

killed

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

И все это в рамках одной базы и одного sql сервера ??? OLTP и OLAP в одном флаконе ??? Извините меня, но вы меня никогда не убедите что должны "жить" вместе. Никакое задание приоритетов не сделает так что olap запрос не будет мешать oltp запросу. Имхо.
А гибридные решения - это желание съэкономить деньги. В таких системах запросто можно заменить встроенную приоритезацию запросов административными методами. Вроде
"с 10.00 до 16.00 работают только операторы ввода данных"
"с 16.00 до 10.00 работают генераторы отчетов"


Ну я убеждать целью не ставлю. Статистика в той системе далеко не OLAP. Просто пользователь может ворошить свои звонки за несколько прошлых месяцев. Теперь "должны/не должны" определяется бюджетом в каждом конкретном случае с учетом еще кучи причин. Реалии - они как бы сильно оторваны от учебников. Кстати гибридных систем в мире подавляющее большинство. Приоритезацию с помощью административных методов я не буду комментировать. Это примерно тоже, что форматирование дискетки в Виндовс 98.
30 июл 04, 12:43    [848840]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
Glory
Сергей Васкецов

Да, для расчета производственной себестоимости

OLTP и OLAP в одном флаконе ???

Понимаете, расчет себестоимости - не обязательно отчет, то есть, это не OLAP в чистом виде, например, по результатам расчета может осуществляться ввод документов прихода ГП, резервирования, планирования, генерация проводок или ее аналоги. Это уже вовсе никакой не OLAP.
30 июл 04, 13:43    [849114]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
locky
давайте попробуем оптимизировать запрос вида
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
где мощность таблицы DocDebet ~2*10^8, под условие отбора попадает ~12*10^6 строк
Проще паренной репы ;-) Материализованные виды рулят в данном случае...
Теперь далее: если у вас запрос не укладывается в 600 секунд, значит:
1. Плохо спроектирована БД (таблицы, индексы, расположение на дисках и т.д.) - тут понятно, куда смотреть надо ;-).
2. Плохой алгоритм (если это не 1 запрос) - говорить о том, что ситуацию надо менять установкой приоритетов потоков ОС - пошло. Какой же вы программист, если не можете переработать алгоритм...
3. Недостаточно системных ресурсов. Ну извините - планируйте ваши тяжелые запросы на peak-off hours.
4. Используйте OLAP. Даже в случае бедности и использования одного сервера вы получите значительный эффект. Кубы вы ведь не будете процессить во время пиковой нагрузки на сервере, если нет - то это к врачу...
5. Используйте "очередь сообщений". В MSSQL 2000 ее можно делать своими руками, в Yukon`е будет уже встроенная (кстати, а как там у Оракла в этом смысле?).
6. В MSSQL есть такие параметры, как cost threshold for parallelism и max degree of parallelism - очень действенный способ не отдавать вес ресурс одному запросу. А работать с приоритетами для задач - не, ИМХО фигня это. Решать за СУБД, как ей потоки распределять - дело неблагодарное...

Теперь по поводу бедности. В большинстве случаев на самом деле речь идет о том, что руководство не понимает того, во сколько выльются простои, связанные с недоступностью КИС: в данном случае это и тормоза при работе юзеров, и падение серверов / баз, и т.д. Вы просто предложите руководству посчитать, во сколько обойдется пол-дня простоя сервера БД. Когда вы учтете затраты на работу персонала, неудовлетворенность клиентов, недополученную прибыль и т.д., вы поймете, что нормальное аппаратное обеспечение - это норма жизни. А читать про то, что блок питания не потянет еще плюс 1 HDD - просто смешно...
30 июл 04, 23:35    [850720]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Проще паренной репы ;-) Материализованные виды рулят в данном случае...
угу.. токо на поддержку материадизованных вьюшек ресурсы тратяться постоянно, а запрос так, от времени к времени...
>Теперь далее: если у вас запрос не укладывается в 600 секунд, значит:
>1. Плохо спроектирована БД (таблицы, индексы, расположение на дисках и т.д.) - тут понятно, куда смотреть надо ;-).
дык в запросе таблица одна, ограничение одное, кластерный индекс по дату - куда проще.
Тем более Вы мыслите как программист - если что-то плохо - я это переделаю! А я мыслю как DBA - у меня есть купленная система, которую я НЕ ИМЕЮ ПРАВА (да и желания - это не моя работа) переделывать. А вот настройку сервера - могу, аднака....
>2. Плохой алгоритм (если это не 1 запрос) - говорить о том, что ситуацию надо менять установкой приоритетов потоков ОС - пошло. Какой же вы программист, если не можете переработать алгоритм...
Алгоритм - вроде как бы нормальный, конечно, несколько сложнее - там есть еще один джойн, но индексы нужные есть.
>3. Недостаточно системных ресурсов. Ну извините - планируйте ваши тяжелые запросы на peak-off hours.
да, ресурсов недостаточно. а планирование - я уже просил рассказать мне, как DBA можеть порекомендовать начальнику, когда он должен работать с системой :-)
>4. Используйте OLAP. Даже в случае бедности и использования одного сервера вы получите значительный эффект. Кубы вы ведь не будете процессить во время пиковой нагрузки на сервере, если нет - то это к врачу...
Вот тут - не скажу, не пробовал, хотя и думал. однако использование OLAP тут-же предполагает его изучение. будут за это платить - вопрос еще тот.
>5. Используйте "очередь сообщений". В MSSQL 2000 ее можно делать своими руками, в Yukon`е будет уже встроенная (кстати, а как там у Оракла в этом смысле?).
Не в курсе, что это такое, надо посмотреть. Ссылочку предложите?
>6. В MSSQL есть такие параметры, как cost threshold for parallelism и max degree of parallelism - очень действенный способ не отдавать вес ресурс одному запросу.
Угу, и maxdop стоит в 1 - из за некого глюка, при котором SQL неправильно считает суммы :-( однако наибольшая нагрузка ложится не на камни, а на ДПС, так шта...
>А работать с приоритетами для задач - не, ИМХО фигня это. Решать за СУБД, как ей потоки распределять - дело неблагодарное...
Однако, я могу решать, сколько камней использовать для запроса (option maxdop), какие индексы юзать(with index=) и в каком порядке связывать(option force order) таблицы, да и каким образом (loop|merge|hash join). я могу сказать приоритет для deadlock'а (SET DEADLOCK_PRIORITY), в какой-то мере управлять перекомпиляцией (keep plan, keepfixed plan, exec with recompile).... могу еще коем-чем управлять...
почему вызывает такое удивление, когда я хочу управлять еще одним параметром системы? В конце концов, ораклоиды то тоже не дураки были, когда ввели приоритеты... да, теоретически неправильно их использовать, а вот на практике....
Давайте чуток вспомним: SQL - декларативный язык, он определяет ЧТО делать. а КАК делать - решает оптмизатор и иже с ними. С этой точки зрения все наши указания индексов, порядка соединений и т.д. - глупости чистой воды, но мы их используем и как-то не особо по этому поводу напрягаемся.
автор

Теперь по поводу бедности. В большинстве случаев на самом деле речь идет о том, что руководство не понимает того, во сколько выльются простои, связанные с недоступностью КИС: в данном случае это и тормоза при работе юзеров, и падение серверов / баз, и т.д. Вы просто предложите руководству посчитать, во сколько обойдется пол-дня простоя сервера БД. Когда вы учтете затраты на работу персонала, неудовлетворенность клиентов, недополученную прибыль и т.д., вы поймете, что нормальное аппаратное обеспечение - это норма жизни.

А ни во сколько простой в один день не обойдется. прибыль не зависит от того, будет КИС в этот день работать или не будет. И удовлетворенность клиентов зависит по большому счету от работы канализационной сети, а не от того, смогли они сегодня справку получить, или нет. Тем более, что справку они получат, правда, за чуть большее время. вместо 3-х минут будет 5, но для одного чела это несущественно.
>А читать про то, что блок питания не потянет еще плюс 1 HDD - просто
смешно...
аха, давайте посмеемся вместе.... БП уже работает с перегрузкой, потому как тянет на 2 винта больше, чем полагалось по расчету, и напруга в нем проседает с завилным постоянством. бум продолжать спорить?
Да, так о чем это мы?
А о том, что еще одна настройка сервера - вещь очень нужная и полезная. И не надо кричать: "Вы ЭТИМ можете поранится, мы Вам ЭТО не дадим!" Мы взрослые умные (:-) ) люди, мы можем поранится чем угодно! Но мы постараемся этого не сделать. Так шта, хде наш инстрУмент?
31 июл 04, 16:54    [850979]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
Напомню с чего по сути все собственно и началось.
Locky
2Guest_2
>Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
давайте попробуем оптимизировать запрос вида
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dtgroup by Date
где мощность таблицы DocDebet ~2*10^8, под условие отбора попадает ~12*10^6 строк.

Вот судя по этому
Locky
А я мыслю как DBA - у меня есть купленная система, которую я НЕ ИМЕЮ ПРАВА (да и желания - это не моя работа) переделывать.

Вы есть АДМИНИСТРАТОР.
С точки зрения разработчика - действительно этот запрос на указанном Вами множестве будет работать плохо и ничего с ним не поделаешь. Устранить проблему - значит переписать запрос. Этого запроса в вашей системе быть не должно. Уже давались советы по рефакторингу кода системы. Устраивают они вас или нет это другое дело.

Давайте перейдем на точку зрения Администратора.

Вообще-то купленной ИС глубоко все равно, когда вашему Начальнику приспичит запустить отчет для выполнения которого необходимо выполнения приведенного выше запроса. Вообще-то должен быть регламент использования эксплуатируемой ИС. Он либо у Вас в банке есть, либо его нет. И именно в этом документе прописываются все правила и ограничения связанные с получением отчетности. И как мне кажется, Вы как Администратор системы можете и должны поддерживать данный документ в актуальном состоянии.

По поводу техники, на которой крутится база.
ИС опять же глубоко все равно на то, есть ли деньги на замену оборудования или нет. Если для нормальной работы требуются большие аппаратные мощности - они должны быть приобретены. Ваша задача, как Администратора, не дать Начальникам забывать о том, что решение проблемы находится исключительно в их компетенции, а не в Вашей.

Поймите администрирование ИС не заключается только в настройке программно-аппаратного комплекса. Это прежде всего выработка регламента использования ИС и контроль за исполнением этого регламента со стороны пользователей. И тут перед Администратором все пользователи равны, как в бане перед баньщиком все её посетители.

PS. Если у вас Orace и вы используете приоритеты запросов и это Вам помогает в работе, то и слава богу. В любом случа, как мне кажется, это не самый большой плюс по сравнению с MSSQL.
1 авг 04, 07:52    [851151]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Поддерживаю Guest_2 в плане регламентов и необходимого оборудования.
Теперь далее:
locky
>угу.. токо на поддержку материадизованных вьюшек ресурсы тратяться постоянно, а запрос так, от времени к времени...
Ну, у вас же не ежедневно эти 10*8 записей добавляются/удаляются/меняются... Вы на самом деле наверняка не пробовали ;-) У MSSQL достаточно хорошие алгоритмы в этом смысле... Ваши юзеры, скорее всего, и не почуствуют, что сервер еще что-то там поддерживает. Начальное построение вьюса - ДА - отнимет много времени.
locky
Вот тут - не скажу, не пробовал, хотя и думал. однако использование OLAP тут-же предполагает его изучение. будут за это платить - вопрос еще тот.
А вам самому-то неинтересно разобраться с сабжем? Ради любви к искусству? Вы все ради денег делаете?
locky
Не в курсе, что это такое, надо посмотреть. Ссылочку предложите?
Предложу. Поищите по ключевым словам SQL Service Broker инфо...
locky
Давайте чуток вспомним: SQL - декларативный язык, он определяет ЧТО делать. а КАК делать - решает оптмизатор и иже с ними. С этой точки зрения все наши указания индексов, порядка соединений и т.д. - глупости чистой воды, но мы их используем и как-то не особо по этому поводу напрягаемся.
Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).
locky
А ни во сколько простой в один день не обойдется. прибыль не зависит от того, будет КИС в этот день работать или не будет. И удовлетворенность клиентов зависит по большому счету от работы канализационной сети, а не от того, смогли они сегодня справку получить, или нет.
Ага, так нафига оно вам надо, головная боль эта - выкиньте КИС на помойку и забудьте о ней, как о страшном сне. Представьте, как прийдете к боссу и расскажете ему, сколько бабла можно сэкономимь, если работать по старинке без ИС... Гы-гы...
locky
аха, давайте посмеемся вместе.... БП уже работает с перегрузкой, потому как тянет на 2 винта больше, чем полагалось по расчету, и напруга в нем проседает с завилным постоянством. бум продолжать спорить?
Ой, я уже так насмеялся, аж за живот держусь ;-)) ... См. пост Guest_2 об аппаратном обеспечении...
1 авг 04, 19:17    [851315]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Сергей Тихонов
>А вам самому-то неинтересно разобраться с сабжем? Ради любви к искусству? Вы все ради денег делаете?
Очень интересно. Но - только в свободное от основной работы время, изыскав для этого свободное железо. Про литературу, которую надо покупать - не говорю, большую часть инфы можно взять из сети.
автор

Ага, так нафига оно вам надо, головная боль эта - выкиньте КИС на помойку и забудьте о ней, как о страшном сне. Представьте, как прийдете к боссу и расскажете ему, сколько бабла можно сэкономимь, если работать по старинке без ИС... Гы-гы...

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

Ой, я уже так насмеялся, аж за живот держусь ;-)) ... См. пост Guest_2 об аппаратном обеспечении...

Давайте посмеемся вместе: некоторые проблемы (еще раз повторю, не все) можно было бы решить БЕСПЛАТНО, имей сервер некоторые настройки. А покупка железа - это всегда деньги.
P.S. Как то тут всё уходит на 2-й круг... Начали с того, что фича то-ли полезна, то ли нет, нашли пути, как можно было бы обойтись без неё, упёрлись в то, что для этого необходимо реорганизовывать КИС/железо (что стоит денег), сказали - что да, иногда такая фича полезна, но можно обойтись без неё, но для этого...
Прям как-то заскучал... :-)
2 авг 04, 11:43    [852003]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Сергей Тихонов

Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).

Блажен кто верует... Вы случаем MS SQL не продаете? :)
2 авг 04, 12:02    [852088]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
funikovyuri
Сергей Тихонов

Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).

Блажен кто верует... Вы случаем MS SQL не продаете? :)

Я не верую, я знаю :-). Знаю, сколько запросов в день проходит на моем сервере БД, какие из них отнимают у сервера больше всего ресурсов, знаю динамику изменения нагрузки за период и т.д.
Нет, случаем, MSSQL НЕ продаю, точно так же, как и Oracle и многое другое (SAP, Documentum, SAS...). Для этого у нас есть туча продавцов-консультантов в компании :-) ...
2 авг 04, 12:20    [852142]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Сергей Тихонов

Знаю, сколько запросов в день проходит на моем сервере БД, какие из них отнимают у сервера больше всего ресурсов, знаю динамику изменения нагрузки за период и т.д.

Вы сказали что оптимизатор у MS SQL позволяет обходится без хинтов в 98-99% случаев, выбирая оптимальный план выполнения. К сожалению, такие фразы в большинстве случаев не отражают реальное положение вещей и больше похожи на заявления различного рода продавцов. Про динамику нагрузки я не спрашивал...
2 авг 04, 13:56    [852473]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
funikovyuri
Вы сказали что оптимизатор у MS SQL позволяет обходится без хинтов в 98-99% случаев, выбирая оптимальный план выполнения. К сожалению, такие фразы в большинстве случаев не отражают реальное положение вещей и больше похожи на заявления различного рода продавцов. Про динамику нагрузки я не спрашивал...
Да, так оно и есть, если правильно БД проектировать, правильные индексы строить... Хинты действительно используются очень редко, так что моя фраза - реальное положение вещей... Так что - низкий поклон разработчикам MSSQL 2000 за их оптимизатор ;-) .
2 авг 04, 15:05    [852792]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
автор

Да, так оно и есть, если правильно БД проектировать, правильные индексы строить... Хинты действительно используются очень редко, так что моя фраза - реальное положение вещей... Так что - низкий поклон разработчикам MSSQL 2000 за их оптимизатор ;-) .

Действительно, уже в 7-ке оптимизатор был - о-го-го! Я переходил на 7-ку с 6.5, сразу отметил, что 7-ка влегкую разгребает те запросы, которые на 6.5 долго приходилось тюнить.
и действительно, в 95% случаев оптимизатор лучше тебя знает, как чего делать. Остается еще 5%, которые надо гонять вручную. К примеру, вручную заданый план запроса может быть в 20-25 раз быстрее чем тот, который выбрал оптимизатор.
у меня из всех запросов только для 10-12 штук явно указаны порядок соединения и индексы. но это - базовые запросы нижнего уровня, используются в 50% отчетов. И тут я оказываюсь умнее, чем оптимизатор, хотя и частично умнее. Потому как мои планы не всегда работают самым наилучшим образом. зато они никогда не работают наихудшим образом.
2 авг 04, 17:02    [853183]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
wellx
Guest
Судя по постам ваша проблема может быть решена ТОЛЬКО покупкой второго сервера , причем можно их самых дешевых. На него ставите второй MSSQL , и настраиваете репликацию по ночам на второй сервер. НА него переводите всех кому нужны длинные и долгие отчеты , пусть ждут их хоть до ночи, а оперативные данные вгоняют в основную базу. Лицензия потребуется только на сервер и SQL без юзеров . Заодно всегда будет копия базы на вчера вечером. Вторую базу можно
сделать read-only для ускорения работы , но это уж как вам виднее...

А экономить при таких проблемах - как минимум путь к увольнению/банкротству.
17 сен 04, 18:58    [969850]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
По поводу плюсов Оракла, не могу не высказаться - родная СУБД все-таки :)

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

В СУБД-блокировщиках способ обеспечения согласованного чтения один - при чтении устанавливается блокировка, предотвращающая изменение данных, которая снимается только по окончании операции чтения. В противном случае имеем "грязное" (несогласованное) чтение. Соответственно как только "читатель" заблокировал данные для генерации отчетов, то "писатели" курят бамбук, пока не будет снята блокировка. Поскольку блокировка "писателей" однозначно недопустима, то нам остается разрешать грязное (неблокирующее) чтение и ошибки в отчетах. Здесь я для простоты не рассматриваю "внешние" по отношению к СУБД способы обработки транзакций. Они как правило позволяют бороться с проблемами типа писатели-писатели, а для проблемы писатели-читатели их полезность ограничена. причина проста - как только мы выносим данные в некий "кэш" внешний по отношению к СУБД, про согласованность данных можно смело забыть.

В СУБД имеющих MVCC (версионниках) таких как Oracle, есть неблокирующее согласованное чтение. Поскольку оно неблокирующее, то писателям оно никак не мешает. Если интересно как оно работает - при изменении данных старая версия сохраняется. Допустим при "долгоиграющей" читающей транзакции мы наткнулись на запись которая была изменена "писателями" после начала читающей транзакции. В этом случае "читатель" получит данные существовавие в базе на момент начала читающей транзакции (или сообщение об ошибке ORA-01555). Поскольку дисковые массивы и контроллеры нынче недороги, проблема читателей-писателей, относительно легко решается выделением достаточного места (и пропускной способности дисковой подсистемы) под "старые версии данных". Называется это хозяйство rollback (undo) segment.

В случе если объем читающих-пишущих транзакций таков, что система просто с ними не справляется, в Оракле делается вот какой трюк:

Заводим hot standby database, это такая база куда наша основная БД будет логи присылать. Потом открываем этот standby в режиме "только чтение". И гоняем наши отчеты на этом standby. Задержка будет, но небольшая (полчасика, или минут 15) и регулируемая администратором.

В мелкософте, насколько мне известно, возможности иметь hot standby database открытую на чтение нет. Но я не великий спец по MSSQL, так что поправьте меня, если что.
17 сен 04, 20:33    [969936]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
В СУБД-блокировщиках способ обеспечения согласованного чтения один - при чтении устанавливается блокировка, предотвращающая изменение данных, которая снимается только по окончании операции чтения. В противном случае имеем "грязное" (несогласованное) чтение. Соответственно как только "читатель" заблокировал данные для генерации отчетов, то "писатели" курят бамбук, пока не будет снята блокировка. Поскольку блокировка "писателей" однозначно недопустима, то нам остается разрешать грязное (неблокирующее) чтение и ошибки в отчетах.

Вы уж меня извините, но познания о блокировочниках у Вас мягко говоря слабоватые. Вообще то основным источником блокировок как раз являются писатели, а не читатели, писатели удерживают измененные записи в блокированном состоянии до подтверждения транзакции, а читатели, если эти записи попадают под условия запроса, просто стоят и ждут, пока писатели с них снимут блокировки. То что оказывается по Вашему мнению читатели вот так вот "притесняют" бедных писателей для меня честно говоря было полной неожиданностью. Что я могу сказать на примере ASA по поводу блокировок читателями:
1. Блокировки читателями ставяться только на время выполнения запроса, далее до COMMIT висит только SHARE-блокировка, запрещающая изменение метаструктуры задействованных в запросе таблиц.
2. СУБД для читателей полностью блокирует все записи до окончания выполнении запроса только для уровня изоляции SERIALIZABLE или же когда жестко в запросе указан хинт XLOCK. Для READ COMMITED (которого обычно вполне достаточно для отчетов) блокируется только текущая обрабатываемая запись при выполнении запроса, с которой тут же снимается блокировка, как только СУБД переходит сканом на следующую обрабатываемую запись.
3. В случаях использования индекса на таблицу при подходящих условиях (то есть когда чтения индекса достаточно и чтение таблицы не требуется) оптимизатор вполне может не накладывать блокировку на таблицу, обойдясь блокировкой анти-вставки на текущую запись индекса, таким образом блокируя только момент вставки между текущей и следующей записью новой на время чтения позиции индекса.
4. Если оптимизатор видит, что эффективнее построить хэш или рабочую таблицу, то он вообще может обойтись без блокировок.
5. Стоит упомянуть многочисленные опциях, регулирующие поведение СУБД в различных ситуациях и для различных уровней изоляций, с помощью которых можно довольно много - от игнорирования в READ COMMITED удаленных, но еще незавершенных транзакцией данных, до переноса до COMMIT проведения всех проверок целостности данных, что например, позволяет эффективно в таблицы грузить и изменять деревья, а главное не блокировать во время проведения транзакции ключи родительских таблиц при добавлении записей в дочерние и делать это потом одной операцией, таким образом сведя время блокировок к минимуму. Плюс разные виды накладываемых блокировок - оптимистические и пессиместические, которыми тоже можно много чего разрулить.
6. Ну и наконец, никто нам не мешает ручками разруливать ситуации с блокировками, граммотно писать запросы, не делать длинные по времени транзакции, переносить и рассчитывать данные во временные таблицы, которые никого и никогда не блокируют, по назначению использовать уровни изоляции и различные виды курсоров.

P.S. В общем мне кажется было бы довольно необоснованно говорить, что Оракл круче MSSQL или ASA именно тем, что они блокировочники, а он версионник. У каждого продукта свои достоинства и недостатки, у каждого свои превосходные и удобные плюсы и свой геммор, за который бы хотелось поубивать их разработчиков.
17 сен 04, 23:33    [970135]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Заводим hot standby database, это такая база куда наша основная БД будет логи присылать. Потом открываем этот standby в режиме "только чтение". И гоняем наши отчеты на этом standby. Задержка будет, но небольшая (полчасика, или минут 15) и регулируемая администратором.

Маленькое дополнение.
9i and upward - можно до нуля свести. Правда если на это идут то по другим причинам
18 сен 04, 00:01    [970148]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Когда я говорил о том, что читатели блокируют писателей, естественно речь шла об уровне изоляции транзакций Serializable. Ясен пень, что при Read Commited читатели писателей не блокируют (изменения структуры таблицы я не рассматриваю) а писатели блокируют читателей на время выполнения пишущей транзакции. Какие неприятности бывают при уровне изоляции Read Commited хорошо известно. Хрестоматийтый пример разбирался на sql.ru неоднократно. Грубо - у клиента 2 счета, чековый и сберегательный. Мы считаем баланс по группе клиентов. Мы начали читать таблицу, прочитали баланс на сберегательном счете в 1000 рублей. Затем прошла транзакция переводящая со сберегательного счета на чековый 500 рублей. Затем мы прочитали баланс чекового счета в 500 рублей. Таким образом эти злополучные 500 рублей мы посчитали дважды. И вся любовь. Поэтому с фразой "обычно достаточно Read Commited" я весь несогласный.

Что до блокировки индекса, не суть важно что мы блокируем индекс или таблицу. Важно что в данном случае, если читатель serializable то "писатели" отдыхают пока читатели не отпустят блокировку. Что недопустимо по условию задачи. Не должен клиент у POS-терминала с кредитной карточкой стоять и ждать пока мы свои отчеты закончим.

Вот поэтому MSSQL/Sybase/Informix/DB2/Teradata не любят долгоиграющие транзакции, особенно на уровне изоляции serializable. Что до транзакций-писателей, то все инструменты для СУБД-блокировщиках по умолчанию работают в режиме autocommit. И в книжках по СУБД-блокировщикам рекомендуется транзакции делать коротенькие, и commit делать почаще. Все это - не от хорошей жизни. В Оракле commit делается тогда когда этого требует логика приложения, а не когда этого хочет СУБД. И это правильно.

Уважаемый ASCRUS привел целый ряд способов которыми можно выкрутиться если СУБД-блокировщик. Как правило приходится либо жертвовать согласованностью данных (использовать Read commited вместо serializable) либо соглашаться на то что пишущая транзакция может завершиться с ошибкой. То есть она итак может звершиться с ошибкой, мы лишь увеличиваем вероятность такого завершения.

Поэтому, ИМХО СУБД-блокировщики имеют ряд ограничений, и плохо подходят для решения определенного класса задач, типа изложенной выше. СУБД-версионник лучше подходит для этих задач. Я просто сторонник той теории что суп удобнее хлебать ложкой, а салат есть - вилкой, а не наоборот. Возможно в природе есть задачи которые лучше решаются блокировщиком чем версионником. Я их пока не встречал. Приводите такую задачу - буду признателен. Хотя нет, вру. Teradata - злобный блокировщик, рулит в больших хранилищах данных. Там конкуренции между читателями и писателями обычно нет. И Teradata превосходит Оракл она не потому что она "блокировщик" а потому что помогает звериная мощь MPP-архитектуры.
18 сен 04, 03:51    [970235]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Зл0й
Хрестоматийтый пример разбирался на sql.ru неоднократно. Грубо - у клиента 2 счета, чековый и сберегательный. Мы считаем баланс по группе клиентов. Мы начали читать таблицу, прочитали баланс на сберегательном счете в 1000 рублей. Затем прошла транзакция переводящая со сберегательного счета на чековый 500 рублей. Затем мы прочитали баланс чекового счета в 500 рублей. Таким образом эти злополучные 500 рублей мы посчитали дважды. И вся любовь. Поэтому с фразой "обычно достаточно Read Commited" я весь несогласный.

А зачем "затем, затем, затем" ? Почему бы не "сразу". Читаем одним запросом по группе клиентов баланс для сберегательного и чекового счета, соотвествующе при переборе клиентов записи в счетах блокируется по одной на текущего обрабатываемого клиента, далее разблокируются и писатели уже могут спокойно изменять тех клиентов, которые уже прошли в запросе. Далее результат запроса выкидываем клиентскому приложению или во времянку для дальнейшей обработки - это уже как по логике нужно.

Зл0й
Что до блокировки индекса, не суть важно что мы блокируем индекс или таблицу. Важно что в данном случае, если читатель serializable то "писатели" отдыхают пока читатели не отпустят блокировку. Что недопустимо по условию задачи. Не должен клиент у POS-терминала с кредитной карточкой стоять и ждать пока мы свои отчеты закончим.

С учетом вышесказанного и избавляясь от serializable, мы получаем, что клиент и не будет ждать - данные то он там новые вводит, а значит по логике они не должны на этот момент входить на обрабатываемые читателями данные (например в условие входит, что на записи, занесенные ранее текущего времени), так что читатели могут блокировать то, что существует на момент выполнения запроса, а писатели продолжать добавлять записи.

автор
Уважаемый ASCRUS привел целый ряд способов которыми можно выкрутиться если СУБД-блокировщик. Как правило приходится либо жертвовать согласованностью данных (использовать Read commited вместо serializable) либо соглашаться на то что пишущая транзакция может завершиться с ошибкой. То есть она итак может звершиться с ошибкой, мы лишь увеличиваем вероятность такого завершения.

Да нет же, я привел целый ряд моментов, которые изначально нужно учитывать при проектировании БД и тогда не будет возникать различных проблем, которые Вы тут привели. То есть, если человек привык проектировать БД на Оракле и начнет делать ее на том же MSSQL, то сделает он все так как привык делать, а потом будет долго возмущаться - вот какие блокировочники плохие, блокировками достали. Однако я более чем уверен, что если человек, прекрасно знающий MSSQL впервой сделает БД на Оракле, то ругани в сторону версионников и Оракла конкретно будет не меньше.

автор
Поэтому, ИМХО СУБД-блокировщики имеют ряд ограничений, и плохо подходят для решения определенного класса задач, типа изложенной выше. СУБД-версионник лучше подходит для этих задач. Я просто сторонник той теории что суп удобнее хлебать ложкой, а салат есть - вилкой, а не наоборот. Возможно в природе есть задачи которые лучше решаются блокировщиком чем версионником. Я их пока не встречал. Приводите такую задачу - буду признателен.

Поэтому IMHO любая задача будет решена лучше на блокировочнике, чем на версионнике, если на блокировочнике ее будет решать специалист, у которого уровень знаний и опыт больше, чем у специалиста, делающего это на версионнике. То же самое можно сказать наоборот. И все - никаких филосовских рассуждений о достоинствах и недостатках разных СУБД, такой вот я прагматик :)
18 сен 04, 11:06    [970301]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
-------------
Guest
Зл0й
В мелкософте, насколько мне известно, возможности иметь hot standby database открытую на чтение нет. Но я не великий спец по MSSQL, так что поправьте меня, если что.
Поправляю - есть и реально используются
20 сен 04, 10:05    [971410]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Так, так, насчет избавились от serializable поподробнее.

Дано таблица accounts(acct_number, acct_type, balance) причем большая - много счетов. Имеются две сессии S0 читающая таблицу с уровнем изоляции read commited и S1 изменяющая эту таблицу.

В таблице имеются слкдующие записи
...
12345, Сhecking, 1000.00 -- Чековый счет
...
12345, Savings, 0.00 -- Сберегательный счет
...

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

Момент времени: сессия: событие
----------------------------------------
T0: S0: началась "долгоиграющая" читающая транзакция. Заблокирована запись с acct_number = 12345 acct_type='Сhecking' затем запись прочитана balance=1000 и блокировка снята - Read commited так работает или нет?
----------------------------------------
T1: S0: Таблица большая, сессия S0 пока читает записи для других клиентов. Предположем что сейчас заблокирован acct_number = 78901

Т1: S1: Запись "12345, Сhecking" уже разблокирована. Запись "12345, Savings" еще не заблокирована. Перебрасываем с чекового счета на сберегательный 500.00 и прибиваем это изменение коммитом.
----------------------------------------
T2: S0: Читаем 12345, Savings, 500.00 Вот оно, "грязное" (несогласованное) чтение.

Таким образом для acct_number = 12345 сумма чекового и сберегательного счетов посчитана 1500.00 а не 1000.00 как должно быть. Все очень просто. Или мы блокируем ВСЕ счета по которым мы считаем суммы, или мы имеем грязное чтение. Третьего не дано.

Возражения?

ЗЫ я не только с Ораклом работал, приходилось работать с Информиксом. Сейчас помимо Оракла работаю с DB2 и Teradata. Так что просьба не рассказывать про достоинства СУБД-блокировщиков, которых на самом деле нет. У них одно преимущество перед Ораклом - меньше i/o жрут, так как при оптимальной реализации им надо меньше undo писАть. Достоинство это ИМХО мало полезное. Чем так страдать, ИМХО проще железяку нормальную поставить.
21 сен 04, 21:01    [976933]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Так что уровень изоляции транзакций serializable был не просто так придуман, а чтобы не было аномалий типа вышеприведенной. Некоторые авторы называют ее phantom read, я же просто обозвал ее diry read. По мне все что не consistent, то dirty.
21 сен 04, 21:51    [976970]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
А ЗлОй во многом прав. А ASCRUS не догонят немного. (без обид ?)
Только одного не понимаю, с какой радости Oracle версионником стал.
Я, конечно, не сильно в курсе, но на сколько я знаю, данные для "старых" транзакций он берет из т.н. сегмента отката , а он у него не резиновый, хоть может быть и большим. А вот если там уже данных нет тогда КААК ....

Я прав или нет ?
Да, и насчет ПО СРАВНЕНИЮ С MSSQL - ну сделают и в MS такую ж фичу в Yukonе - ну и ?
21 сен 04, 21:54    [976973]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Oracle версионник, хотя и весьма своеобразный. Данные действительно берутся из сегментов отката (rollback segment он же undo segment). СУБД сама по себе не гарантирует что они там будут. Если данных в оном сегменте нетути, вылезает ошибка ORA-01555 "Snapshot too old". Борются с этим вот как путем создания сегментов отката адекватных решаемой задаче. И еще commit стараются без нужды не делать, так как он помечает старые данные в сегменте отката как "свободное место куда можно писАть".

Есть другие способы хранить старые версии данных, например можно при update писать данные в новую страницу как в PostGreSql. Тогда возникает проблема сборки мусора. Да и производительность получается так себе. Можно писАть старые версии в лог, потом их оттуда читать. Проблема в том, что лог обычно имеет структуру оптимизированную под запись. Восстановление по логам происходит не очень часто, так что они не оптимизированы на чтение. Если механизм версий будет читать данные из логов, сдается мне что производительность будет весьма паршивая. ИМХО Оракловое решение с сегментами отката - разумный компромисс.

Из коммерческих СУБД версионники Оракл и Интэрбэйс. Как MVCC сделано в Интербэйсе я не знаю, надо спросить в профильной конфе. Из оупенсорсных СУБД MySQL пытается идти по стопам Оракла, пока без особого успеха. В PostGreSql ИМХО механизм версий сделан ИМХО крайне неудачно.

Соответсвенно вопрос, если Оракл - не версионник, тогда кто тогда версионник? А что будет в Юконе - мы поглядим когда его сделают. Помнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.

По поводу hot backup. А разве в MSSQL можно в онлайне логи присылать на standby базу которая открыта на чтение? Не знал.
22 сен 04, 01:48    [977073]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ну не все так плохо :) Буду немножко врать, так как не работал в банковских технологиях, но постараюсь суть передать верно :)

Итак ситуация первая
Есть таблица "движения денег по счетам". Любая операция перевода денег со счета на счет фиксируется новой записью в этой таблице, тут насколько я понимаю операций удаления и изменения записей практически нет. А значит, мы можем прекрасно организовать работу с этой таблицой как читателей, так и писателей, просто добавив в нее колонку TIMESTAMP и учитывая в запросах условие TIMESTAMP <= Now() . Тогда любой запрос в READ COMMITED по этой таблице будет учитывать только те данные, которые существовали на момент его выполнения и таким образом движения по счетам, возникающие после выполнения запроса будут добавляться уже как записи с более поздним временем и писатели, вставляя новые записи не будут мешать читателям, а те не будут лезть на даже закоммиченные, но более поздние данные. Здесь я думаю все понятно и особо спорить не о чем.

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

Что же - идея здравая, ни кому не хочется поднимать многолетний архив, чтобы быстро получить баланс клиента, так что делаем табличку "баланс". Если бы счета хранились как колонки в записи, конечно бы проблем не возникало при построении аналитических запросов и на READ COMMITED - СУБД блокировало бы текущую запись вместе со всеми счетами, разблокировала ее и дальше продолжала обработку, а писатель, т.е. в данном случае триггер с таблицы движения денег по счетам, ждал бы микроскопическое время, если уж ему приспичело именно в этот момент изменить состояние счета. Однако такое решение естественно не подходит, так как счетов может быть сколько душе угодно. Как итог - в таблице множество записей по балансу клиента на каждый счет и как было правильно замечено READ COMMITED тут не прокатывает, без уровня изоляции SERIALIZABLE, который фактически сначала блокирует все обрабатываемые записи в таблице баланса и только потом начинает выполнение запроса не обойтись.

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

Немножко пофантазируем
Например, сделаем в табличке баланса еще поле TIMESTAMP, чтобы мы знали, когда последний раз был посчитан баланс (это всегда пригодиться).

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

Теперь осталось навести красоту - все таки пересчитать баланс, благо кого считать и зачем мы уже знаем. Делаем EVENT (событие), ставим ему тип SCHEDULE (по времени) и назначаем выполняться через каждое, оптимальное с нашей точки зрения время (например с частотой раз в минуту). В тело события пишем скрипт, который фиксирует в переменной текущее время и уже по ней выполняет перерасчет баланса для всех записей, имеющих меньшее или равное значению переменной время. Далее после выполнения операции нам остается честно удалить с буфера опять же по времени обработанные записи и сделать COMMIT. Ну и естественно в случае возникновения каких либо ошибок произведенный ROLLBACK вернет на место как и старые значения баланса, так и в состояние необработанных записи в табличке "перерасчет".

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

Проверка
Итак схема готова, давайте ее проверим на приведенном примере достоинства Оракла перед блокировочниками.
Зл0й

Момент времени: сессия: событие
----------------------------------------
T0: S0: началась "долгоиграющая" читающая транзакция. Заблокирована запись с acct_number = 12345 acct_type='Сhecking' затем запись прочитана balance=1000 и блокировка снята - Read commited так работает или нет?
----------------------------------------
T1: S0: Таблица большая, сессия S0 пока читает записи для других клиентов. Предположем что сейчас заблокирован acct_number = 78901

Т1: S1: Запись "12345, Сhecking" уже разблокирована. Запись "12345, Savings" еще не заблокирована. Перебрасываем с чекового счета на сберегательный 500.00 и прибиваем это изменение коммитом.
----------------------------------------
T2: S0: Читаем 12345, Savings, 500.00 Вот оно, "грязное" (несогласованное) чтение.

Таким образом для acct_number = 12345 сумма чекового и сберегательного счетов посчитана 1500.00 а не 1000.00 как должно быть. Все очень просто. Или мы блокируем ВСЕ счета по которым мы считаем суммы, или мы имеем грязное чтение. Третьего не дано.

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

Итак ход событий:

1. началась "долгоиграющая" читающая транзакция по таблице "баланс". Заблокированы все обрабатываемые данные для любых писателей.

2. во время обработки этой транзакции писатели продолжают писать данные в таблицу "движение по счетам". Это приводит к следующим действиям:
2.1 вызывается триггер
2.2 из него добавленные записи добавляются в таблицу "перерасчет"
2.3 заканчивается действие триггера
2.4 писатели делают COMMIT и заканчивают транзакцию добавления записей

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

4. читающая транзакция завершает работу и делает COMMIT

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

P.S. Таким образом используя таблицу-буфер, TIMESTAMP и механизм событий в ASA мы получаем не сложный в реализации, надежный, простой и не занимающий лишних ресурсов механизм разруливания ситуаций с высоким уровнем блокировок. Соответствующе я еще раз хочу подчеркнуть, что тут все зависит как от возможностей СУБД, так и от знаний специалиста и на любую поставленную задачу можно найти адекватное и красивое решение.

автор
Возражения?

ЗЫ я не только с Ораклом работал, приходилось работать с Информиксом. Сейчас помимо Оракла работаю с DB2 и Teradata. Так что просьба не рассказывать про достоинства СУБД-блокировщиков, которых на самом деле нет. У них одно преимущество перед Ораклом - меньше i/o жрут, так как при оптимальной реализации им надо меньше undo писАть. Достоинство это ИМХО мало полезное. Чем так страдать, ИМХО проще железяку нормальную поставить.

Все вышесказанное - это и есть мои возражения. Причем пример я давал на Sybase ASA, но почти такой же механизм будет работать и на MSSQL. Мне лично легче еще одну табличку влепить, чем мотивировать клиенту покупку "нормальной" железяки, содержания штата админов и других "тяжелых" расходов. А блокировочники действительно к ресурсам не падкие и со скоростью у них все в порядке, так что это и есть их сильные и конкурентноспособные качества, главное помнить о палке о 2-х концах и уметь пользоваться достоинствами и обходить недостатки.

Будут ли у Вас возражения по вышеизложенному тексту ?
22 сен 04, 02:27    [977105]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Уважаемый ASCRUS, то что вы расписали есть по сути попытка реализации чего-то подобного механизму версий, но на СУБД-блокировщике. Грубо говоря, попытка сделать то же что и Оракл, только "ручками". Возражения такие:
- пример был приведен очень сильно упрощенный, чтобы проиллюстрировать проблему. Ито, решение на блокировщике вышло громоздкое. Реальная задача гораздо сложнее. Будем городить или ну его нафиг?
- Зачем городить доморощенный механизм-версионник когда есть готовый? Я конечно понимаю, что изобретение велосипеда это наш российский национальный вид спорта.

В общем, на уровне идеи, ваше предложение выглядит так: временно хранить часть данных в какой-то структуре независимой от механизма управления транзакциями СУБД. Управлять транзакциями "вручную" или в обход "родных" для СУБД механизмов.

Я видел немало разных механизмов позволяющих "обходить" механизм управления транзакциями. Например в оракле можно хранить данные в очередях сообщений, пайпах и в структурах данных в пакетах хранимых процедур. Фундаментальный недостаток всех этих решений - управление транзациями "вручную". Даже самая простенькая задачка превращается в сущий кошмар, как только мы храним состояние где-то, где оно может "пережить" rollback. Где-нибудь, что-нибудь да поломается. Например что будет с данными в случае аварии сервера? События теряются? Будем собственные логи писать?

Трудозатраты на корректную реализацию таких решений многократно превыщают стоимость железа. Ибо задача которую мы беремся решать в данном случае - написание "poor man's Tuxedo" или "poor man's Oracle", как угодно. По сути мы пишем примитивный доморощенный монитор транзакций, так ведь? Причем делаем это из-за того что обработчик транзакций встроенный в СУБД нас не устраивает. Может проще взять другую СУБД, особенно если речь о новой разработке?
22 сен 04, 03:47    [977113]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить