|
|
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Помогите сравнить DB2 и Oracle. При этом нужно доказать, что последний явно лучше. Сравнить нужно по критериям: 1. максимальное количество одновременно подключенных пользователей 2. разделение прав доступа к данным 3. время выполнения запросов 4. блокировка при одновременном доступе к одним и тем же данным По oracle я еще могу хоть что-то написать, но по DB2... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 08:17 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
luchik_5Помогите сравнить DB2 и Oracle. При этом нужно доказать, что последний явно лучше. Сравнить нужно по критериям: 1. максимальное количество одновременно подключенных пользователей 2. разделение прав доступа к данным 3. время выполнения запросов 4. блокировка при одновременном доступе к одним и тем же данным По oracle я еще могу хоть что-то написать, но по DB2... :( если бы мог то давно бы и написал :) версионность там, MTS, FGAC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 10:02 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
> При этом нужно доказать, что последний явно лучше Разве что упирать на доступность спецов, что уменьшает издержки при обслуживании. А по критериям... 1. Тож на тож. 2. в DB2 имеется label-security, в чём-то помогучее оракуля. 3. тож на тож 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и тупоконечников о достоинствах того и другого пока не закончились :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 11:19 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
RomanSavelyevСпоры остроконечников и тупоконечников о достоинствах того и другого пока не закончились :) Но Microsoft свою позицию в этом споре уже выбрала :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 11:37 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
RomanSavelyev пишет: > 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и Оракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Так что они в этом сравнимы с DB2. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 11:50 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZiv RomanSavelyev пишет: > 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и Оракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Так что они в этом сравнимы с DB2. Posted via ActualForum NNTP Server 1.4 подстулом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:01 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZivОракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Вполне версионный. А сегменты отката и логи в Oracle совсем разные сущности, и не надо их путать. Какая разница, где физически хранятся старые, а где новые версии. Можно, как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, новые версии хранить в сегментах данных, а старые версии откладывать в отдельную физическую структуру. MasterZivТак что они в этом сравнимы с DB2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:03 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:05 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? конечно грязное чтение завется .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:10 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. MasterZivОракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Вполне версионный. А сегменты отката и логи в Oracle совсем разные сущности, и не надо их путать. Какая разница, где физически хранятся старые, а где новые версии. Можно, как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, новые версии хранить в сегментах данных, а старые версии откладывать в отдельную физическую структуру. MasterZivТак что они в этом сравнимы с DB2. Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache, о чем на форуме Oracle разговор периодически возникает. Просто есть одна Current-версия блока, которая будет скидываться на диск и куча версий, конструируемых на основе undo (consistent read - CR), которые служат для чтения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:23 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
tru55Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache они там не ХРАНЯТСЯ, а КЭШИРУЮТСЯ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 12:56 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) tru55Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache они там не ХРАНЯТСЯ, а КЭШИРУЮТСЯ Хех... В слова играемся? 1. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) 2. версии храняться временно по своей сути - постоянное хранение никому не нужно 3. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 13:18 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? В общем-то это зависит от указанного типа изоляции. Можно сказать, чтоб блокировали, можно сказать, что не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 13:37 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
tru553. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск У Oracle блокировки записываются на диск :) и кэшируются в памяти ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 13:50 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 13:55 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
tru553. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск Правильно полагаете. И.. есть настройка поведения СУБД при переполнении буфера (либо превышении лимита оных на процесс) - возможна эскалация блокировок до уровня таблицы. Возможно отключение блокировок записей и блокирование всей таблицы. Например: Имеем в хранилище данных небольшой справочник, миллионов этак на 50 записей, да обильно сдобренный текстовыми полями (например - адреса привлеченных сторон). Справочник имеет два состояния. Либо он актуализирован, либо он находится в процессе актуализации (частичная готовность записей никому нахрен не нужна). Ради ускорения процесса актуализации, имеет смысл выключить блокировки и/или журналирование изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 14:00 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? А какое это имеет отношение к вышесказанному? Я лишь сказал о том, что в UNDO хранятся не полноценные версии (т.е. те данные, которые можно использовать непосредственно для SELECT), а некоторые данные (вектора изменений), на основании которых можно сконструировать полноценную версию, хранимую (или кэшируемую - как угодно) именно в buffer cache ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 14:15 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
tru55 Gluk (Kazan) tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? А какое это имеет отношение к вышесказанному? Я лишь сказал о том, что в UNDO хранятся не полноценные версии (т.е. те данные, которые можно использовать непосредственно для SELECT), а некоторые данные (вектора изменений), на основании которых можно сконструировать полноценную версию, хранимую (или кэшируемую - как угодно) именно в buffer cache а я сказал, что в кэше данные не хранятся, а реконструируются и кэшируются по ере необходимости ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 14:40 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Горячие финские парни :) Какая ПО СУТИ разница, как ИМЕННО Оракуль "варит" данные? Значение имеет реакция системы на запрос, а внутренний механизЬм вполне может измениться в следующей версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 15:00 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Тогда какая разница, что в СУЩЕСТВУЮЩИХ блокировочниках таблица транзакций располагается в оперативной памяти ? ведь реализация может измениться (c) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 15:03 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Да, о птичках. В DB2 удобно реализовано горизонтальное разделение, да и MDC часто даёт хороший выигрыш. http://www.redbooks.ibm.com/abstracts/sg247467.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 15:05 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. пишет: > Вполне версионный. А сегменты отката и логи в Oracle совсем разные > сущности, и не надо их путать. Может быть. Не важно это. > Какая разница, где физически хранятся старые, а где новые версии. Можно, > как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, Разница в том, что сегмент отката может закончится. А в Interbase/Postgres версии хранятся до тех пор, пока они нужны. Ладно, я не большой поклонник версионников, мне все равно. Просто разница реально есть. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:37 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. пишет: > В DB2 тоже читатели не блокируют писателей, и писатели не блокируют > читателей на уровне записи? Это наверное нет, но я не крупный знаток DB2. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 17:40 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
А для каких задач? Немножко работал и на DB2 и на Oracle, по личному впечатлению и опыту: Задачи для баз данных делятся на два класса. В одном (финансовые приложения и т.п.) практически вся нагрузка приходится на SERIALIZABLE транзакции, там DB2 явно предпочтительнее. Во-втором (ERP, корпоративные порталы и т.п.) актуальность получаемых на чтении данных не существенна и лучше подходит Oracle. По личному опыту: DB2 побыстрее на записи данных (мне это было актуально, поэтому мерял), гораздо проще для разработчика, существенно дешевле по лицензиям. Но админа найти сложно, хотя администрирование и гораздо легче (можно научиться). Oracle - лучше в качестве строки в резюме, проще найти работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 18:43 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZiv Разница в том, что сегмент отката может закончится. А в Interbase/Postgres версии хранятся до тех пор, пока они нужны. Как в воду ..., типа в Interbase/Postgres место для хранения старых записей не нужно, в точку сжимаюся, в форме коня в известной среде. DPH для каких задач? Немножко работал и на DB2 и на Oracle, по личному впечатлению и опыту: Задачи для баз данных делятся на два класса. В одном (финансовые приложения и т.п.) практически вся нагрузка приходится на SERIALIZABLE транзакции, там DB2 явно предпочтительнее. Во-втором (ERP, корпоративные порталы и т.п.) актуальность получаемых на чтении данных не существенна и лучше подходит Oracle. Первые три слова, можно взять из предыдущего моего абзаца... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 20:47 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Блин пивка уже добряче выпил, не удержусь, DPHактуальность получаемых на чтении данных не существенна и лучше подходит Oracle. Это вообще 3.14здец ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 20:52 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
DimaR пишет: > Как в воду ..., типа в Interbase/Postgres место для хранения старых > записей не нужно, в точку сжимаюся, в форме коня в известной среде. Они хранятся в основной базе, все версии в которой равноправны. Все, какме были версии, и какие все еще нужны (есть транзакции, которые их могут потенциально использовать) - все храняться. Это и плохо может быть даже, но это не так как в оракле и иннодб работает. Там место под сегмент отката отведено фиксированно и просто эти записи могут стереться. А в Interbase база будет пухнуть от старых записей до потери пульса (места на диске). На самом деле мне немного надоело вам все это объяснять, я тут не нанятый вам адепт MVCC, поищите лучше другого кого-то. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.09.2007, 21:29 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZiv DimaR пишет: > Как в воду ..., типа в Interbase/Postgres место для хранения старых > записей не нужно, в точку сжимаюся, в форме коня в известной среде. Они хранятся в основной базе, все версии в которой равноправны. Все, какме были версии, и какие все еще нужны (есть транзакции, которые их могут потенциально использовать) - все храняться. Это и плохо может быть даже, но это не так как в оракле и иннодб работает. Там место под сегмент отката отведено фиксированно и просто эти записи могут стереться. Блин, уважаемый, ну не надо, а? Все что вы писали про IB справедливо и для Оракла. Записи в undo перетераются только в том случае, если они уже не нужны. Место в undo может быть как фиксированным, так и динамически расширяемым (никто не мешает поставить файл данных undo на авторастяжку и наблюдать как он увеличивается). MasterZiv А в Interbase база будет пухнуть от старых записей до потери пульса (места на диске). Не будет она пухнуть, читающая транзакция, выполняющая роль сборщика мусора, удалит ненужные версии. MasterZivНа самом деле мне немного надоело вам все это объяснять, я тут не нанятый вам адепт MVCC, поищите лучше другого кого-то. Вы для начала сами разберитесь в вопросе, а потом другим объяснять пытайтесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 09:58 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Yo.! Владимир П.В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? конечно грязное чтение завется .... Во! А в Оракле оно без всякой грязи, с полным соблюдением соблюдением транзакционной целостности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:10 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZivРазница в том, что сегмент отката может закончится. А в Interbase/Postgres версии хранятся до тех пор, пока они нужны. Точно так же может кончиться место на диске для файлов данных, в которых хранятся версии. Сегмент отката -- это просто специально выделенный для этих целей файл. Кончается он, когда файл не может увеличиться из-за нехватки места (или назначен предел для максимального размера файла). MasterZivПросто разница реально есть. Конечно! Но это разница на уровне реализации физики, а не логическая и не понятийная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:15 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Apex пишет: > Не будет она пухнуть, читающая транзакция, выполняющая роль сборщика > мусора, удалит ненужные версии. Вы вот все почти правильно говорите, а все спорите. Удалит сборщик мусора только те версии записей, КОТОРЫЕ ДАТИРОВАНЫ РАНЬШЕ НАЧАЛА САМОЙ СТАРОЙ АКТИВНОЙ ТРАНЗАКЦИИ. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:17 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. пишет: > Во! А в Оракле оно без всякой грязи, с полным соблюдением соблюдением > транзакционной целостности. DIRTY READ еще не значит несоблюдение транзакционной целостности. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:18 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
MasterZiv Apex пишет: > Не будет она пухнуть, читающая транзакция, выполняющая роль сборщика > мусора, удалит ненужные версии . Вы вот все почти правильно говорите, а все спорите. Удалит сборщик мусора только те версии записей, КОТОРЫЕ ДАТИРОВАНЫ РАНЬШЕ НАЧАЛА САМОЙ СТАРОЙ АКТИВНОЙ ТРАНЗАКЦИИ. Posted via ActualForum NNTP Server 1.4 Доктор, а я как сказал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 10:25 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Владимир П. Во! А в Оракле оно без всякой грязи, с полным соблюдением соблюдением транзакционной целостности. На самом деле, есть куча задач, где как раз необходимо, что бы писатели блокировали читателей и наоборот. Собственно, почти все финансовые приложения. И реализовывать подобные бизнес-требования на Oracle и неудобно и непроизводительно. А ничего, аналогичного Dirty Read в Oracle вообще нет, насколько я помню. Вообще, сравнивать схемы изоляций для oracle и db2 некорректно, в одних задачах нужно одно, в других - другое. Производительность "в среднем по больнице" они обеспечивают одинаковую. DB2 в некоторых распространенных случаях быстрее пишет, Oracle - в некоторых распространенных случаях быстрее читает, но это, в общем, не существенно. SQL в DB2, пожалуй, поудобнее и помощнее. Интеграция продуктов внутри Oracle, пожалуй, более глубокая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 13:19 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
DPH[quot Владимир П.] DB2 в некоторых распространенных случаях быстрее пишет, Oracle - в некоторых распространенных случаях быстрее читает В DB2 есть простор для деятельности с компрессией данных, да мультидоменной кластеризацией. Выигрыши можно получить очень значительные. SQL в DB2, пожалуй, поудобнее и помощнее. Интеграция продуктов внутри Oracle, пожалуй, более глубокая. Да тож на тож. Заклинания чуть разные, общая суть такая же. Какая разница, "nextval for sequencename" или "sequencename.nextval"? Но арифметика дат (например) в DB2 логичнее и удобнее. А в Оракле рекурсивный запрос с connect by удобнее, чем с дибитушным WITH. Но... это спор об относительных достоинствах португальского и испанского языка (или портвейна :) ) К тому же в 9.5, которая сейчас выходит апдейтом к девятке, можно включить ораклячий синтаксис. Из практической разницы, ораклячий "нумерик" в разработке удобнее, чем строго типизированные численные данные дибиту. Но опять же, в 9.5 есть DECFLOAT... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 13:51 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
DPH На самом деле, есть куча задач, где как раз необходимо, что бы писатели блокировали читателей и наоборот. Собственно, почти все финансовые приложения. И реализовывать подобные бизнес-требования на Oracle и неудобно и непроизводительно. брехня - берем TPC-E, эталонный тест эмулирующий вполне финансовую задачу брокерской канторы, все 3 теста доступные на сегодня выполнены в версионном режиме, при том что все три теста выполнены на mssql для которого родной блокировочный режим. Дальше открываем тест Unisys и видим, что они сначала пытались выполнить самый злобный запрос в READ COMMITED но видимо пробится через блокировки на READ COMMITED не удалось и им пришлось использовать версионный SNAPSHOT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 13:53 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Yo.! брехня - берем TPC-E И выкидываем его нафиг. Ибо в реальной жизни фронтофисная и бэкофисная системы разносятся. Более того, настраиваются по разному. И в бэкофисе (то место, где имеются тяжелые запросы), операции по актуализации данных производятся пакетно. Добро пожаловать в реальный мир :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 14:26 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
DPHНа самом деле, есть куча задач, где как раз необходимо, что бы писатели блокировали читателей и наоборот. Собственно, почти все финансовые приложения. Хм. Вот уже почти двадцать лет занимаюсь разработкой финансовых и учетных приложений и ни разу необходимости в блокировании читателей (или читателями) не возникало. DPHИ реализовывать подобные бизнес-требования на Oracle и неудобно и непроизводительно. А ничего, аналогичного Dirty Read в Oracle вообще нет, насколько я помню.Т слава богу, что нет. Несколько раз сталуивался при необходимости интеграции с приложениями на MSSQL (с использованием Dirty Read) и ни разу авторы систем не могли без плясок с бубнами обеспечить консистентность данных. Правда может быть тут дело не в инструменте, а в музыкантах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 15:37 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
RomanSavelyev Ибо в реальной жизни фронтофисная и бэкофисная системы разносятся. Добро пожаловать в реальный мир :) дык, понятно, что блокировочники вынуждены разносить принося в жертву актуальтность данных. имея MVCC это совершенно не обязательно. Я не брокер и не в курсе на сколько обязательно мэнеджеру видеть актуальный перфоменс брокеров, но подозреваю, что неспроста этот запрос оказался в спецификации ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 16:42 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
2Yo! >>> Я не брокер и не в курсе на сколько обязательно мэнеджеру видеть актуальный перфоменс брокеров Интересно, а перфоменс брокеров это что? Скорость бегания пальцев по клавишам за последние пять минут? Или количество сделок за последнюю минуту? Или сумма заключенных сделок по ИТОГАМ ОТЧЕТНОГО ПЕРИОДА(уже закрытый месяц, последняя (уже завершенная) неделя)? Растолкуйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 16:51 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
gardenman2Yo! >>> Я не брокер и не в курсе на сколько обязательно мэнеджеру видеть актуальный перфоменс брокеров Интересно, а перфоменс брокеров это что? Скорость бегания пальцев по клавишам за последние пять минут? Или количество сделок за последнюю минуту? Или сумма заключенных сделок по ИТОГАМ ОТЧЕТНОГО ПЕРИОДА(уже закрытый месяц, последняя (уже завершенная) неделя)? Растолкуйте. The Broker-Volume Transaction The Broker-Volume Transaction is designed to emulate a brokerage house‟s “up-to-the-minute” internal business processing. An example of a Broker-Volume Transaction would be a manager generating a report on the current performance potential of various brokers. Broker-Volume is invoked by EGenDriverCE. It consists of a single Frame. The Transaction searches the pending limit orders to find orders that are associated with a given list of brokers responsible for stocks of a given sector. The value of each order is calculated based upon bid price and quantity of shares and added to the running total volume for the appropriate broker. The list of brokers with their associated total volume sorted in descending volume order is returned. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 17:14 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
И что, вы утверждаете, что бизнес-логика этого отчета такова, что блокировочник точно с этим не справится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 17:48 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Интересно кто тот "умник" который так писал: IN (@broker1, @broker2, @broker3, @broker4, @broker5, @broker6, @broker7, @broker8, @broker9, @broker10, @broker11, @broker12, @broker13, @broker14, @broker15, @broker16, @broker17, @broker18, @broker19, @broker20, @broker21, @broker22, @broker23, @broker24, @broker25, @broker26, @broker27, @broker28, @broker29, @broker30, @broker31, @broker32, @broker33, @broker34, @broker35, @broker36, @broker37, @broker38, @broker39, @broker40) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 17:50 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
Yo.! RomanSavelyev Ибо в реальной жизни фронтофисная и бэкофисная системы разносятся. Добро пожаловать в реальный мир :) дык, понятно, что блокировочники вынуждены разносить Так и на Оракле разносим :) Фронтофисную систему настраиваем на "короткие" транзакции, вставку и изменение данных. Ставим архивные журналы и т.д. Бэкофисную настраиваем на OLAP, циклические журналы и т.д. Актуальность данных имеем ровно такую, какая требуется, производительность - высокую в обоих случаях. Технологических "окон" для обслуживания - столько, сколько нужно. И за последние лет 15 я не припомню ни одного случая, чтоб "версионность" или "блокировочность" имела какое-то реальное значение. Вся эта хрень актуальна только для синтетических тестов и надуманных ситуаций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 17:54 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
RomanSavelyev Так и на Оракле разносим :) Фронтофисную систему настраиваем на "короткие" транзакции, вставку и изменение данных. Ставим архивные журналы и т.д. Бэкофисную настраиваем на OLAP, циклические журналы и т.д. ну наверно у нас все же разные представления о бэкофисе - мне ради такого запросика бы в голову не пришло разворачивать целую машину ... вы там видите какие-то космические вычисления требующие выделеный сервер ? gardenman И что, вы утверждаете, что бизнес-логика этого отчета такова, что блокировочник точно с этим не справится? да справится, просто сильно хуже чем версионник. предсказыю: DB2 UDB в tpc-e окажется процентов на 10-15 хуже mssql со snapshot. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2007, 18:21 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
> мне ради такого запросика бы в голову не пришло разворачивать целую машину ... А мне и в голову не придёт разрешать на фронтофисе любые незапланированные запросы, не нужные для работы регистрационной системы. И не придёт в голову на одной системе месить транзакции C с H. В результате, дохлый и дешевый сервер отлично "варит" фронтофис, а на бэке стоит роовно такой, какой нужен. Система (в целом) получается дешевле. Добро пожаловать в реальный мир! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2007, 13:49 |
|
||
|
Oracle и DB2
|
|||
|---|---|---|---|
|
#18+
RomanSavelyev> мне ради такого запросика бы в голову не пришло разворачивать целую машину ... А мне и в голову не придёт разрешать на фронтофисе любые незапланированные запросы, не нужные для работы регистрационной системы. я так понимаю вы хорошо ориентируетесь в работе брокерских компаний раз так так уверенны, что BrokerVolume не запланированый и не нужный для работы ? может в двух словах расскажите бизнес значение этой инфо для менеджера ? RomanSavelyev И не придёт в голову на одной системе месить транзакции C с H. извиняюсь за серость, а что такое "C" и "H" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2007, 14:25 |
|
||
|
|

start [/forum/topic.php?all=1&fid=35&tid=1553247]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 374ms |

| 0 / 0 |
