|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
17.09.2007, 08:17
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Помогите сравнить DB2 и Oracle. При этом нужно доказать, что последний явно лучше. Сравнить нужно по критериям: 1. максимальное количество одновременно подключенных пользователей 2. разделение прав доступа к данным 3. время выполнения запросов 4. блокировка при одновременном доступе к одним и тем же данным По oracle я еще могу хоть что-то написать, но по DB2... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 10:02
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
luchik_5Помогите сравнить DB2 и Oracle. При этом нужно доказать, что последний явно лучше. Сравнить нужно по критериям: 1. максимальное количество одновременно подключенных пользователей 2. разделение прав доступа к данным 3. время выполнения запросов 4. блокировка при одновременном доступе к одним и тем же данным По oracle я еще могу хоть что-то написать, но по DB2... :( если бы мог то давно бы и написал :) версионность там, MTS, FGAC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 11:19
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
> При этом нужно доказать, что последний явно лучше Разве что упирать на доступность спецов, что уменьшает издержки при обслуживании. А по критериям... 1. Тож на тож. 2. в DB2 имеется label-security, в чём-то помогучее оракуля. 3. тож на тож 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и тупоконечников о достоинствах того и другого пока не закончились :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 11:37
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
RomanSavelyevСпоры остроконечников и тупоконечников о достоинствах того и другого пока не закончились :) Но Microsoft свою позицию в этом споре уже выбрала :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 11:50
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
RomanSavelyev пишет: > 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и Оракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Так что они в этом сравнимы с DB2. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:01
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
MasterZiv RomanSavelyev пишет: > 4. Оракуль версионный, ДБ2 - блокировочная. Споры остроконечников и Оракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Так что они в этом сравнимы с DB2. Posted via ActualForum NNTP Server 1.4 подстулом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:03
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
MasterZivОракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Вполне версионный. А сегменты отката и логи в Oracle совсем разные сущности, и не надо их путать. Какая разница, где физически хранятся старые, а где новые версии. Можно, как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, новые версии хранить в сегментах данных, а старые версии откладывать в отдельную физическую структуру. MasterZivТак что они в этом сравнимы с DB2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:05
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:10
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Владимир П. MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? конечно грязное чтение завется .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:23
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
Владимир П. MasterZivОракл не чисто версионный. Он получает старые записи из сегмента отката (лога). Вполне версионный. А сегменты отката и логи в Oracle совсем разные сущности, и не надо их путать. Какая разница, где физически хранятся старые, а где новые версии. Можно, как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, новые версии хранить в сегментах данных, а старые версии откладывать в отдельную физическую структуру. MasterZivТак что они в этом сравнимы с DB2. Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache, о чем на форуме Oracle разговор периодически возникает. Просто есть одна Current-версия блока, которая будет скидываться на диск и куча версий, конструируемых на основе undo (consistent read - CR), которые служат для чтения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 12:56
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
tru55Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache они там не ХРАНЯТСЯ, а КЭШИРУЮТСЯ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 13:18
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
Gluk (Kazan) tru55Ну если уж быть совсем точным, то в Oracle все версии храняться в buffer cache они там не ХРАНЯТСЯ, а КЭШИРУЮТСЯ Хех... В слова играемся? 1. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) 2. версии храняться временно по своей сути - постоянное хранение никому не нужно 3. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 13:37
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Владимир П. MasterZivТак что они в этом сравнимы с DB2. В DB2 тоже читатели не блокируют писателей, и писатели не блокируют читателей на уровне записи? В общем-то это зависит от указанного типа изоляции. Можно сказать, чтоб блокировали, можно сказать, что не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 13:50
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
tru553. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск У Oracle блокировки записываются на диск :) и кэшируются в памяти ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 13:55
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 14:00
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
tru553. как я полагаю, у блокировочников ихние блокировки тоже реализуются в памяти, а не записываются на диск Правильно полагаете. И.. есть настройка поведения СУБД при переполнении буфера (либо превышении лимита оных на процесс) - возможна эскалация блокировок до уровня таблицы. Возможно отключение блокировок записей и блокирование всей таблицы. Например: Имеем в хранилище данных небольшой справочник, миллионов этак на 50 записей, да обильно сдобренный текстовыми полями (например - адреса привлеченных сторон). Справочник имеет два состояния. Либо он актуализирован, либо он находится в процессе актуализации (частичная готовность записей никому нахрен не нужна). Ради ускорения процесса актуализации, имеет смысл выключить блокировки и/или журналирование изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 14:15
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
Gluk (Kazan) tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? А какое это имеет отношение к вышесказанному? Я лишь сказал о том, что в UNDO хранятся не полноценные версии (т.е. те данные, которые можно использовать непосредственно для SELECT), а некоторые данные (вектора изменений), на основании которых можно сконструировать полноценную версию, хранимую (или кэшируемую - как угодно) именно в buffer cache ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 14:40
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
tru55 Gluk (Kazan) tru551. кэширование - это тоже хранение, только временное (а к слову сказать, вечного все равно ничего не бывает) Вот уж даже и не знаю кто тут в слова играет Вечного и не надо, достаточно хранить версии ПОСТОЯННО столько сколько нужно (т.е. столько, чтобы было возможно откатить любую из незавершенных транзакций) Под постоянно в данном случае понимается, что если случится страшное, эти данные не будут потеряны, а будут успешно применены на накате/откате при автоматическом восстановлении на следующей загрузке БД. Для этого UNDO (постоянно хранимые версии) защищены REDO (журналом транзакций) Будем дальше играть в слова ??? А какое это имеет отношение к вышесказанному? Я лишь сказал о том, что в UNDO хранятся не полноценные версии (т.е. те данные, которые можно использовать непосредственно для SELECT), а некоторые данные (вектора изменений), на основании которых можно сконструировать полноценную версию, хранимую (или кэшируемую - как угодно) именно в buffer cache а я сказал, что в кэше данные не хранятся, а реконструируются и кэшируются по ере необходимости ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 15:00
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Горячие финские парни :) Какая ПО СУТИ разница, как ИМЕННО Оракуль "варит" данные? Значение имеет реакция системы на запрос, а внутренний механизЬм вполне может измениться в следующей версии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 15:03
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Тогда какая разница, что в СУЩЕСТВУЮЩИХ блокировочниках таблица транзакций располагается в оперативной памяти ? ведь реализация может измениться (c) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 15:05
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
Да, о птичках. В DB2 удобно реализовано горизонтальное разделение, да и MDC часто даёт хороший выигрыш. http://www.redbooks.ibm.com/abstracts/sg247467.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 17:37
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
Владимир П. пишет: > Вполне версионный. А сегменты отката и логи в Oracle совсем разные > сущности, и не надо их путать. Может быть. Не важно это. > Какая разница, где физически хранятся старые, а где новые версии. Можно, > как в InterBase, всё хранить в страницах данных; а можно, как в Oracle, Разница в том, что сегмент отката может закончится. А в Interbase/Postgres версии хранятся до тех пор, пока они нужны. Ладно, я не большой поклонник версионников, мне все равно. Просто разница реально есть. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 17:40
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
Владимир П. пишет: > В DB2 тоже читатели не блокируют писателей, и писатели не блокируют > читателей на уровне записи? Это наверное нет, но я не крупный знаток DB2. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 18:43
|
|||
|---|---|---|---|
|
|||
Oracle и DB2 |
|||
|
#18+
А для каких задач? Немножко работал и на DB2 и на Oracle, по личному впечатлению и опыту: Задачи для баз данных делятся на два класса. В одном (финансовые приложения и т.п.) практически вся нагрузка приходится на SERIALIZABLE транзакции, там DB2 явно предпочтительнее. Во-втором (ERP, корпоративные порталы и т.п.) актуальность получаемых на чтении данных не существенна и лучше подходит Oracle. По личному опыту: DB2 побыстрее на записи данных (мне это было актуально, поэтому мерял), гораздо проще для разработчика, существенно дешевле по лицензиям. Но админа найти сложно, хотя администрирование и гораздо легче (можно научиться). Oracle - лучше в качестве строки в резюме, проще найти работу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.09.2007, 20:47
|
|||
|---|---|---|---|
Oracle и DB2 |
|||
|
#18+
MasterZiv Разница в том, что сегмент отката может закончится. А в Interbase/Postgres версии хранятся до тех пор, пока они нужны. Как в воду ..., типа в Interbase/Postgres место для хранения старых записей не нужно, в точку сжимаюся, в форме коня в известной среде. DPH для каких задач? Немножко работал и на DB2 и на Oracle, по личному впечатлению и опыту: Задачи для баз данных делятся на два класса. В одном (финансовые приложения и т.п.) практически вся нагрузка приходится на SERIALIZABLE транзакции, там DB2 явно предпочтительнее. Во-втором (ERP, корпоративные порталы и т.п.) актуальность получаемых на чтении данных не существенна и лучше подходит Oracle. Первые три слова, можно взять из предыдущего моего абзаца... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/search_topic.php?author=%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D0%B9+%D0%9F%D0%B5%D1%80%D0%BC%D1%8F%D0%BA%D0%BE%D0%B2&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 712ms |
| total: | 890ms |
| 0 / 0 |
