|
|
|
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?fid=35&msg=34807020&tid=1553247]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 13ms |
| total: | 147ms |

| 0 / 0 |
