Oracle vs DB2 / Сравнение СУБД

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Oracle vs DB2

16 сообщений из 66, страница 3 из 3

все

Oracle vs DB2

#38434899

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

Mark Barinstein- партиционирование
Вы можете использовать MDC для "субпартиционирования" (возможно указать несколько полей в ORGANIZE) типа такого:

Код: sql

1.
2.
3.
4.

CREATE TABLE MYTABLE
DISTRIBUTE BY (...)
PARTITION BY (...)
ORGANIZE BY (...)

Вы не используете такой вариант? Если нет, то почему?

Гм... Про MDC я в курсе, причем давно, но вот используется он у нас и правда редко. Интересно почему. Спасибо, Марк, несмотря на всю очевидность решения, оно мне почему-то в голову не пришло, посыпаю голову пеплом.
Хотя если подумать, такой способ тоже не лишен недостатков, это все же не полноценные партиции, их нельзя дропнуть или сделать truncate, например, ровно как и нельзя за секунду сделать attach, как с партициями.
Но с другой стороны это почти тоже самое, что и партиции в Терадате (их концепция партиционирования очень похожа на MDC), если вставлять и удалять данные будет так же быстро, то detach\attach и не нужен.

Mark Barinstein- INSERT /*+APPEND*/ INTO
Будет работать и в DB2 с той разницей, что в DB2 нет APPEND хинта, и чтобы добиться такого же поведения, надо выставить это свойство на уровне таблицы.
LOAD from CURSOR же - это весьма скоростная альтернатива, позволяющая заметно быстрее, без жуналирования, вставлять в таблицу большие объёмы данных на основе другого запроса.
Типа sql loader'а в режиме direct path, только входные данные - результат запроса. Не уверен, что в Оракле есть такая возможность, поэтому трудно сравнивать.

Свойство на уровне таблицы - это alter, а на него не всегда дают права, особенно редко это позволяют делать в хранимках.
На самом деле Оракловый INSERT /*+APPEND*/ INTO есть ничто иное как direct path операция (ну ясное дело, что если триггеров нет), выполняемая в определенных случаях без генерации журналов отката\наката.

Mark Barinstein- CTAS
В DB2 есть процедура ADMIN_MOVE_TABLE, которая похожие вещи делает, если я правильно понял аббревиатуру CTAS.
К ней надо привыкнуть, конечно, но с ней проблемы или неудобства какие-то?
Не совсем, ADMIN_MOVE_TABLE все же для перемещения таблиц налету. Я же имел в виду Create Table As Select, т.е. гораздо более простую операцию, которая только в DB2 почему-то не умеет заполнять таблицу данными из запроса.

...

Рейтинг:

0 / 0

21.10.2013, 00:06

| Ответить | Цитировать | Написать

Oracle vs DB2

#38435043

Mark Barinstein

Гость

ApexХотя если подумать, такой способ тоже не лишен недостатков, это все же не полноценные партиции, их нельзя дропнуть или сделать truncate, например, ровно как и нельзя за секунду сделать attach, как с партициями.
Но с другой стороны это почти тоже самое, что и партиции в Терадате (их концепция партиционирования очень похожа на MDC), если вставлять и удалять данные будет так же быстро, то detach\attach и не нужен.Да, скорость удаления, скорее всего, не будет такая же, как при detach. При вставке данных выигрыша вы не получите. Оно, всё же, для оптимизации ввода-вывода с помощью автоматической кластеризации предназначено.
Но и удаление при определённых условиях будет идти эффективнее обычного delete.
См. Rollout deletion .

ApexMark Barinstein- CTAS
В DB2 есть процедура ADMIN_MOVE_TABLE, которая похожие вещи делает, если я правильно понял аббревиатуру CTAS.
К ней надо привыкнуть, конечно, но с ней проблемы или неудобства какие-то?Не совсем, ADMIN_MOVE_TABLE все же для перемещения таблиц налету. Я же имел в виду Create Table As Select, т.е. гораздо более простую операцию, которая только в DB2 почему-то не умеет заполнять таблицу данными из запроса.Скорее всего это сделано для того, чтобы разделить DDL и DML - в DB2, в отличие от Oracle (насколько я знаю), DDL - под транзакционным контролем, и если всю операцию сделать в одной транзакции, то на некоторые системные таблицы могут длительное время висеть строчные блокировки, что иногда нежелательно.
Но с другой стороны, всё "неудобство" заключается в том, что вы делаете 2 команды вместо 1 с тем же select_statement :

Код: plaintext

create table newtab as ( select_statement ) definition only;
insert into newtab  select_statement ;

...

Рейтинг:

0 / 0

21.10.2013, 09:28

| Ответить | Цитировать | Написать

Oracle vs DB2

#38437465

Yo.!

Гость

Mark BarinsteinА как это в Оракле происходит?
Создастся ли на таблице выше процедура, где есть обращение v + 1 к полю?
Будет ли процедура инвалидироваться при изменении varchar -> int?

в оракл 11.2 то же самое, что в дб2 произошло. вроде раньше такого не было, я ожидал, что инвалидирует процедуру. я поищу постарше оракл.

Да, по-моему OLTP - это преимущественно вытягивание по индексу.
Я не говорю, что все, но значительная часть запросов - да.
Давайте смотреть TPC-E, если хотите.
[/quot]

давайте смотреть TPC-E, вот запрос из BrokerVolume.sql

Код: plsql

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.

    SELECT  B_NAME,
            SUM(TR_QTY * TR_BID_PRICE)
    FROM    BROKER,
            TRADE_REQUEST,
            SECURITY,
            COMPANY,
            INDUSTRY,
            SECTOR
    WHERE   B_NAME      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) AND
            B_ID        = TR_B_ID   AND
            TR_S_SYMB   = S_SYMB    AND
            S_CO_ID     = CO_ID     AND
            CO_IN_ID    = IN_ID     AND
            IN_SC_ID    = SC_ID     AND
            SC_NAME     = @sector_name
    GROUP   BY B_NAME
    ORDER   BY 2 DESC
    OPTION  (FORCE ORDER, LOOP JOIN)

...

Рейтинг:

0 / 0

22.10.2013, 18:39

| Ответить | Цитировать | Написать

Oracle vs DB2

#38438465

CawaSPb

Участник

Откуда: Питер/Москва/Wroclaw

Сообщения: 787

Рейтинг: 0 / 0

Блин, всё пропустил :)

Небольшие ремарки.

Yo.!Mark Barinsteinто давайте обсудим.
Дано: "большая" таблица, поля в предикате проиндексированы, запрос возвращяет несколько записей (ну, не больше 20-30). Кардинальность индекса высокая. В общем, довольно часто встречающийся вариант в OLTP системе.

по вашему олтп это лишь вытягивания по индексу ? я например столь примитивные запросы в реальных системах не встречал. если хотите совсем конкретики давайте возьмем TPC-E - реальная задача, реальные запросы. там, например, такого примитива нет.
но даже на таком примитивном запросе если по значению 'shit' возвращается 99.9% записей, то вместо индекса эффективней фулскан применить. т.е. уже не один вариант.
На самом деле это даже неважно. Дело в том, что в DB2 это управляемо (REOPT опция команд BIND / REBIND ), а в Oracle выбора просто нет ;)
Лёгкость, с которой IBM добавило эту фичу (довольно давно, когда точно - не скажу) - следствие стройности и глубокой продуманности архитектуры системы. Так во всём. Именно за это я люблю DB2. Она не делается методом "заплаток" (ничего не могу сказать в этом отношении про Оракл).
Второй момент - IBM просто фантастически упорно старается придерживаться стандартов. И это хорошо.

Мой поинт в том, что боже упаси считать "Oracle - suxx, DB2 - rulezzz!" Оракл тоже более чем зрелая, зарекомендовавшая себя и подтвердившая свой статус широким использованием система.
Но говорить "DB2 - старьё, застрявшее где-то в прошлом веке" - или некомпетентность, или откровенное сознательное враньё.

Примером тому "старая добрая" DPF, натурально таки интегрированный в RDBMS полноценный XML движок (pureXML), pureScale, многообещающий BLU Acceleration ( http://it.toolbox.com/blogs/db2luw/ibm-db2-105-with-blu-acceleration-vs-oracle-exadata-57369 ), ну и самое главное - отличный мощный развиваемый SQL.
Можно долго спорить по каждой из этих фич, где лучше или хуже что реализовано, приводить примеры, ссылаться на benchmarketing и т.п. Всё это иррелевантно без привязки к конкретному проекту (серии проектов).

Самый большой и очень серьёзный минус DB2 - количество спецов по ней в России. Но если у компании они/внешний сервис есть или компания готова наращивать компетенции, DB2 будет отличным выбором (как и Оракл).

...

Рейтинг:

0 / 0

23.10.2013, 15:14

| Ответить | Цитировать | Написать

Oracle vs DB2

#38438640

Mark Barinstein

Гость

Yo.!в оракл 11.2 то же самое, что в дб2 произошло. вроде раньше такого не было, я ожидал, что инвалидирует процедуру. я поищу постарше оракл.Т.е. оракл чем новее, тем хуже становится? :)
Тоже даёт в ногу себе выстрелить, если очень хочется?
Yo.!давайте смотреть TPC-E, вот запрос из BrokerVolume.sqlЧто вы хотите этим примером показать?
Если то, что в OLTP системах, как в этом тесте, иногда кому-то охота BI запросы погонять, то да, я вам верю.
Для этого запроса, скорее всего, нет смысла использовать статический sql - он не для этого. Запрос этот выполняется не часть. Хотя и для этого запроса, когда накопится достаточное кол-во данных и что-то серьёзно не будет меняться, то можно перестроить план в последний раз по текущей статистике и больше этим не заниматься.

Но там же ниже чуть ли не все запросы - очень хорошие кандидаты для статики.

Начал собирать их, но потом бросил - их слишком много

Код: sql

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.

select ... from CUSTOMER where C_TAX_ID = tax_id;

select ... from CUSTOMER where C_ID = cust_id;

select ... 
from CUSTOMER_ACCOUNT 
left outer join HOLDING_SUMMARY on HS_CA_ID = CA_ID,
LAST_TRADE
where CA_C_ID   = cust_id and LT_S_SYMB = HS_S_SYMB
group by CA_ID, CA_BAL
order by 3 asc;

select ...
from
(select first 10 rows
T_ID as ID
 from
TRADE
 where
T_CA_ID = acct_id
 order by T_DTS desc) as T,
TRADE,
TRADE_HISTORY,
STATUS_TYPE
where
T_ID = ID and
TH_T_ID = T_ID and
ST_ID = TH_ST_ID
order by TH_DTS desc

update
LAST_TRADE
set
LT_PRICE = price_quote[i],
LT_VOL = LT_VOL + trade_qty[i],
LT_DTS = now_dts
where
LT_S_SYMB = symbol[i];

update TRADE
set
T_DTS   = now_dts,
T_ST_ID = status_submitted
where T_ID = req_trade_id;

delete TRADE_REQUEST
where current of request_list;

insert into TRADE_HISTORY
values (
TH_T_ID = req_trade_id,
TH_DTS = now_dts,
TH_ST_ID = status_submitted
);


select
WI_S_SYMB
from
WATCH_ITEM,
WATCH_LIST
where
WI_WL_ID = WL_ID and
WL_C_ID = cust_id;

Либо простейшие запросы по индексу, либо на несколько таблиц по стандартной схеме: IXSCAN по индексу одной таблицы + NLJOIN по всем остальным.

...

Рейтинг:

0 / 0

23.10.2013, 16:38

| Ответить | Цитировать | Написать

Oracle vs DB2

#38442283

Yo.!

Гость

CawaSPbНа самом деле это даже неважно. Дело в том, что в DB2 это управляемо (REOPT опция команд BIND / REBIND ), а в Oracle выбора просто нет ;)

а зачем в 21 веке такой выбор ? это имело смысл разве, что в 80х, сейчас потратить несколько микросекунд на постройку примитивного плана на порядок, если не два быстрее выходит, чем лезть на хдд.

CawaSPbЛёгкость, с которой IBM добавило эту фичу (довольно давно, когда точно - не скажу) - следствие стройности и глубокой продуманности архитектуры системы. Так во всём. Именно за это я люблю DB2. Она не делается методом "заплаток" (ничего не могу сказать в этом отношении про Оракл).

вы предвзяты. именно из-за косяков архитектуры ибм пришлось налепить столько заплаток в стиле skip_locked, last_commited, отдельные костыли под оптимистичную стратегию.

CawaSPbПримером тому "старая добрая" DPF, натурально таки интегрированный в RDBMS полноценный XML движок (pureXML), pureScale, многообещающий BLU Acceleration ( http://it.toolbox.com/blogs/db2luw/ibm-db2-105-with-blu-acceleration-vs-oracle-exadata-57369 ), ну и самое главное - отличный мощный развиваемый SQL.

а теперь взгляните на реальность/ много в мире реальных OLTP систем на DPF или pureScale ? а на BLU Acceleration

...

Рейтинг:

0 / 0

26.10.2013, 17:33

| Ответить | Цитировать | Написать

Oracle vs DB2

#38442335

Yo.!

Гость

Mark BarinsteinТ.е. оракл чем новее, тем хуже становится? :)
Тоже даёт в ногу себе выстрелить, если очень хочется?

пока не понял, наверно отслеживаются только SQL типы, например в INSERT INTO сразу инвалидируются, а вот при конвертации из SQL в PL/SQL ... надо почитать.

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

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

а потом на бирже появиться торговый робот, один сгенерит 20% транзакций и ваш план ...

Mark Barinstein Начал собирать их, но потом бросил - их слишком много
половина из них не так проста, как вам кажется

...

Рейтинг:

0 / 0

26.10.2013, 20:28

| Ответить | Цитировать | Написать

Oracle vs DB2

#38442620

Mark Barinstein

Гость

Yo.!Mark BarinsteinТ.е. оракл чем новее, тем хуже становится? :)
Тоже даёт в ногу себе выстрелить, если очень хочется?

пока не понял, наверно отслеживаются только SQL типы, например в INSERT INTO сразу инвалидируются, а вот при конвертации из SQL в PL/SQL ... надо почитать.Т.е. вы не зная, как оно там в оракле, и уж точно не зная, как оно в db2, начали обвинять db2 в отсутствии нормального ведения зависимостей?
Ну что же, если вы не только блестящий теоретик, то сделайте, пожалуйста, тесты у себя, а потом мы поговорим, у кого там тру ведение зависимостей.

Yo.!я хочу сказать, что в типичном OLTP простетньких запросов - мизер и подавляющая часть достаточно сложные. но суть не в кол-ве, а в том, что даже несколько часто используемых запросто превратят систему в большого тормоза.
в любой современной субд запросы кешируются, если план ушел из кеша на примитивный план построится за пару микросекунд, т.е. хранить на хдд примитивные планы смысла нет никакого, они гораздо быстрее построятся, чем ибм их прочтет с хдд. с более сложными смысла еще меньше, т.к. оптимальность их плана меняется с течением жизни системы.
Я уже говорил, что скорость построения плана это не единственные накладные расходы.
С микросекундами у вас ошибка примерно на 3 (!!!) порядка. Они за миллисекунды строятся, даже самые простые.
Ну да ладно, как говорится, имеющий уши да услышит...

Похоже, что мы действительно понимаем с вами под OLTP разные вещи.
Вот ваш TPC-E. Там как раз подавляющая часть - простые запросы.
Если считаете, что нет - давайте, показывайте свою половину "непростых" запросов и разные варианты планов.

Yo.! а потом на бирже появиться торговый робот, один сгенерит 20% транзакций и ваш план ...Кто придёт?
Робот? Со своим SQL Developer'ом и ad-hoc запросами?
Как этот робот повлияет на мои планы запросов?
Кто это в свою OLTP систему пускает каких-то роботов с возможностью генерировать неизвестно что?

...

Рейтинг:

0 / 0

27.10.2013, 17:23

| Ответить | Цитировать | Написать

Oracle vs DB2

#38450268

Yo.!

Гость

Mark BarinsteinТ.е. вы не зная, как оно там в оракле, и уж точно не зная, как оно в db2, начали обвинять db2 в отсутствии нормального ведения зависимостей?
Ну что же, если вы не только блестящий теоретик, то сделайте, пожалуйста, тесты у себя, а потом мы поговорим, у кого там тру ведение зависимостей.

ну извини, даже лидер индустрии еще не довел отслеживание зависимостей до совершенства.

Mark BarinsteinЯ уже говорил, что скорость построения плана это не единственные накладные расходы.
С микросекундами у вас ошибка примерно на 3 (!!!) порядка. Они за миллисекунды строятся, даже самые простые.
Ну да ладно, как говорится, имеющий уши да услышит...

вы из 80х что-ли пишете ? за милисекунды я результат на уже клиенте имею

Mark BarinsteinКто придёт?
Робот? Со своим SQL Developer'ом и ad-hoc запросами?
Как этот робот повлияет на мои планы запросов?

вы современные предприятия совсем видели ? в TPC-E описаны транзакции, которые обрабатывает типичное агентство, у агентства могут быть клиенты люди-брокеры, а могут быть торговые автоматы, которые эти транзакции дергают через веб сервисы, например. один такой автомат может надергать больше транзакций, чем все остальные клиенты агентства вместе взятые.

Mark BarinsteinПохоже, что мы действительно понимаем с вами под OLTP разные вещи.
Вот ваш TPC-E. Там как раз подавляющая часть - простые запросы.
Если считаете, что нет - давайте, показывайте свою половину "непростых" запросов и разные варианты планов.

-- BrokerVolumeFrame1 is responsible retrieving
-- the total volume that could be potentially
-- generated by each qualifying broker.

-- MarketWatchFrame1 is responsible for retrieving
-- the current price of each symbol on the list
-- and computing the average percentage of change
-- in price over the list.

-- Trade Lookup Frame 1 is responsible for retrieving
-- information about the specified maximum of 20 trade IDs.

-- Trade Update Frame 1 is responsible for retrieving
-- information about the specified max of 20 trade IDs.
-- It also may modify up to max_updates rows of TRADE.

-- CustomerPositionFrame2 is responsible for retrieving
-- the 10-30 most recent trade events for the specified account

-- CustomerPositionFrame2 is responsible for retrieving
-- the 10-30 most recent trade events for the specified account

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

...

Рейтинг:

0 / 0

01.11.2013, 16:44

| Ответить | Цитировать | Написать

Oracle vs DB2

#38456083

Mark Barinstein

Гость

Yo.!ну извини, даже лидер индустрии еще не довел отслеживание зависимостей до совершенства.Ну извиняю.
Т.е. я правильно, понял, что вы берёте назад свои голословные обвинения DB2 в том, что по сравнению с лидером индустрии "ничего похожего на зависимости в db2 нет"?

Если да, то давайте перейдём к следующему вашему утверждению: "в db2 sqlpl до сих слишком куцый и глючной".
Раз вы решили поучаствовать в топике, где автор писал про "мнение тех, кто работал с этими двумя БД", у вас должны быть примеры об этом. Мы дождёмся их?

Yo.!вы из 80х что-ли пишете ? за милисекунды я результат на уже клиенте имеюНет, я пишу из настоящего.
А вот разработчики Оракла, по-вашему, всё ещё в 80-х находятся, судя по тому, что в Using Application Tracing Tools в выводе tkprof "parse time" в десятках миллисекунд измеряется:

вывод tkprof из доки

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

SELECT * 
FROM emp, dept 
WHERE emp.deptno = dept.deptno;

call   count      cpu    elapsed     disk    query current    rows
---- -------  -------  --------- -------- -------- -------  ------
Parse     11     0.08      0.18        0       0       0         0
Execute   11     0.23      0.66        0       3       6         0
Fetch     35     6.70      6.83      100   12326       2       824
------------------------------------------------------------------
total     57     7.01      7.67      100   12329       8       826

Да и Statistics Descriptions говорит о том, что parse time elapsed - Total elapsed time for parsing, in 10s of milliseconds.
Т.е. у пользователя Оракла нет шансов в большинстве случаев получить это время для OLTP запросов, т.к. там нули будут?
Можете погуглить цифры, которые у реальных пользователей получаются, если доступа к живой системе нет.
У меня сейчас нет доступа к Ораклу. Но я, например, довольно часто вижу в DB2 примерно одинаковые времена компиляции и выполнения простых запросов, и это время выражается в десятках или единицах милисекунд. Не знаю, конечно, может лидер индустрии действительно обгоняет не лидеров на порядки в этом...

Yo.!вы современные предприятия совсем видели ? в TPC-E описаны транзакции, которые обрабатывает типичное агентство, у агентства могут быть клиенты люди-брокеры, а могут быть торговые автоматы, которые эти транзакции дергают через веб сервисы, например. один такой автомат может надергать больше транзакций, чем все остальные клиенты агентства вместе взятые.Да какая разница, автомат или человек дергает транзакции? Главное то, что никто не позволит автомату дёргать неизвестно как сгенерированный код. Он из этих веб-сервисов только заранее прописанные там запросы может надёргать, и не важно, в каком количестве или комбинации.
Или что, в современных предприятиях, которые вы видели, для автоматов создаются веб-сервисы типа "дайте мне любой текст запросов, я его выполню для вас"? Мне с трудом в это верится. Это самоубийство.

По запросам могу отвечать последовательно.

-- MarketWatchFrame1

В 5% случаев для этой транзакции выполняется запрос, по которому действительно нужна статистика (по индустрии и с диапазоном в 5000 компаний). В остальных 95% случаев там простейшие запросы, которые вполне подходят для статического sql.

MarketWatchFrame1

Код: sql

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.

-- сложный
select
S_SYMB
from
INDUSTRY,
COMPANY,
SECURITY
where
IN_NAME = industry_name and
CO_IN_ID = IN_ID and 
CO_ID between (starting_co_id and ending_co_id) and
S_CO_ID = CO_ID;

-- простейшие
select
WI_S_SYMB
from
WATCH_ITEM,
WATCH_LIST
where
WI_WL_ID = WL_ID and
WL_C_ID = cust_id;

select
HS_S_SYMB
from
HOLDING_SUMMARY
where
HS_CA_ID = acct_id;

select
new_price = LT_PRICE
from
LAST_TRADE
where
LT_S_SYMB = symbol;

select
s_num_out = S_NUM_OUT
from
SECURITY
where
S_SYMB = symbol;

// Closing price for this security on the chosen day.
select
old_price = DM_CLOSE
from
DAILY_MARKET
where
DM_S_SYMB = symbol and
DM_DATE = start_date;

...

Рейтинг:

0 / 0

07.11.2013, 13:44

| Ответить | Цитировать | Написать

Oracle vs DB2

#38458573

Yo.!

Гость

Mark BarinsteinНу извиняю.
Т.е. я правильно, понял, что вы берёте назад свои голословные обвинения DB2 в том, что по сравнению с лидером индустрии "ничего похожего на зависимости в db2 нет"?

не правильно.
вот как это получилось у дб2 ?
http://dbaspot.com/ibm-db2/91190-syscat-routines-valid-column.html

вообще, если на proc2 SYSCAT.ROUTINES.VALID показывает N или X, что будет показываться на proc1, которая имеет вызов proc2 ?

Mark BarinsteinРаз вы решили поучаствовать в топике, где автор писал про "мнение тех, кто работал с этими двумя БД", у вас должны быть примеры об этом. Мы дождёмся их?

обязательно

Mark BarinsteinНет, я пишу из настоящего.
А вот разработчики Оракла, по-вашему, всё ещё в 80-х находятся, судя по тому, что в
Да и Statistics Descriptions говорит о том, что parse time elapsed - Total elapsed time for parsing, in 10s of milliseconds.

это какой-то троллинг ? эти цифры в 80х и были получены, вот они еще в доке от восьмерки:
http://docs.oracle.com/cd/A87860_01/doc/server.817/a76992/ch14_str.htm

Mark BarinsteinМожете погуглить цифры, которые у реальных пользователей получаются, если доступа к живой системе нет.

зачем гуглить, у меня оракл есть, беру реальный запрос из вьюшки, с нетривиальным планом

Код: 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.

select id
from
 secretview id = 100801


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1       0.00        0.07          0          6          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.37       0.39          1       4652          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.37       0.46          1       4658          0           1

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  NESTED LOOPS OUTER (cr=4652 pr=1 pw=0 time=240684 us)
      1   FILTER  (cr=4651 pr=1 pw=0 time=391827 us)
   1503    HASH JOIN OUTER (cr=4651 pr=1 pw=0 time=181213 us)
   1503     NESTED LOOPS  (cr=34 pr=1 pw=0 time=32315 us)
      1      NESTED LOOPS  (cr=11 pr=1 pw=0 time=29213 us)
      1       NESTED LOOPS OUTER (cr=10 pr=1 pw=0 time=29186 us)
      1        NESTED LOOPS  (cr=10 pr=1 pw=0 time=29175 us)
      1         NESTED LOOPS  (cr=6 pr=1 pw=0 time=29097 us)
      1          NESTED LOOPS  (cr=5 pr=1 pw=0 time=29064 us)
      1           TABLE ACCESS BY INDEX ROWID secrettable  (cr=3 pr=1 pw=0 time=29021 us)
      1            INDEX UNIQUE SCAN secrettable_PK (cr=2 pr=1 pw=0 time=28980 us)(object id 162392)
      1           TABLE ACCESS BY INDEX ROWID secrettable  (cr=2 pr=0 pw=0 time=39 us)
      1            INDEX UNIQUE SCAN EXCTRS_PK (cr=1 pr=0 pw=0 time=19 us)(object id 162411)
      1          INDEX UNIQUE SCAN PK_secrettable  (cr=1 pr=0 pw=0 time=24 us)(object id 162424)
      1         TABLE ACCESS BY INDEX ROWID secrettable  (cr=4 pr=0 pw=0 time=73 us)
      1          INDEX UNIQUE SCAN secrettable_PK (cr=3 pr=0 pw=0 time=53 us)(object id 162512)
      0        INDEX UNIQUE SCAN PK_LEGAL_STATUSES (cr=0 pr=0 pw=0 time=3 us)(object id 162471)
      1       INDEX UNIQUE SCAN PK_EMPLOYEES (cr=1 pr=0 pw=0 time=22 us)(object id 162426)
   1503      TABLE ACCESS FULL CLIENT_SETTINGS (cr=23 pr=0 pw=0 time=114 us)
1453316     INDEX FAST FULL SCAN secrettable_PK (cr=4617 pr=0 pw=0 time=163 us)(object id 162512)
      1   INDEX UNIQUE SCAN PK_EMPLOYEES (cr=1 pr=0 pw=0 time=20 us)(object id 162426)

********************************************************************************

не вижу милисикунд даже на сервере 2006 года.

Mark BarinsteinУ меня сейчас нет доступа к Ораклу. Но я, например, довольно часто вижу в DB2 примерно одинаковые времена компиляции и выполнения простых запросов, и это время выражается в десятках или единицах милисекунд. Не знаю, конечно, может лидер индустрии действительно обгоняет не лидеров на порядки в этом...

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

Mark BarinsteinДа какая разница, автомат или человек дергает транзакции? Главное то, что никто не позволит автомату дёргать неизвестно как сгенерированный код.
блин, ну я же русским языком разъяснил, цитата - "торговые автоматы, которые эти транзакции дергают". что за сгенеренный код ? суть в кол-ве записей, автомат за секунду может миллионы транзакций надергать, брокер-человек за жизнь столько может и не поспеть.

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.

-- простейшие
select
WI_S_SYMB
from
WATCH_ITEM,
WATCH_LIST
where
WI_WL_ID = WL_ID and
WL_C_ID = cust_id;

не факт. 10 брокеров людей имеют 100 WATCH_ITEM, один брокер-автомат 100500 WATCH_ITEMs, для брокера-автомата дешевле фулскан.

...

Рейтинг:

0 / 0

09.11.2013, 01:31

| Ответить | Цитировать | Написать

Oracle vs DB2

#38458697

Mark Barinstein

Гость

Yo.!не правильно.
вот как это получилось у дб2 ?
http://dbaspot.com/ibm-db2/91190-syscat-routines-valid-column.html

вообще, если на proc2 SYSCAT.ROUTINES.VALID показывает N или X, что будет показываться на proc1, которая имеет вызов proc2 ?Вы бы ещё про db2 v2.1 где-нибудь что-нибудь нашли.
Вероятно в то время, когда SQL процедуры неявно c-компилятором преобразовывались в нативный код и на этой 8.1.5 версии были такие странности, хотя и тогда по состоянию пакета можно было понять, что процедура не выполнится.
Сейчас катрина поменялась, пример это демонстрирует.
После удаления таблицы:
- Процедура test_dep1, обращающаяся к таблице, имеет статус N, её пакет - статус X.
- Вызывающая эту test_dep1 процедура test_dep2 имеет статус Y, её пакет - N.

Пример

Код: sql

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.

create table test_dep (i int) in userspace1/

create procedure test_dep1 (pi int, out po int)
specific test_dep1
begin
  set po = (select count(1) from test_dep where i = pi);
end/

create procedure test_dep2 (pi int, out po int)
specific test_dep2
begin
  call test_dep1(pi, po);
end/

drop table test_dep/

select r.valid rvalid, p.valid pvalid, varchar(r.specificname, 10) name
from syscat.routines r
join syscat.routinedep d 
on d.routineschema=r.routineschema and d.specificname=r.specificname and d.btype='K'
join syscat.packages p 
on p.pkgschema=d.bschema and p.pkgname=d.bname
where r.routineschema=user and r.specificname in ('TEST_DEP1', 'TEST_DEP2')/

RVALID PVALID NAME      
------ ------ ----------
N      X      TEST_DEP1 
Y      N      TEST_DEP2 

call test_dep2(1, ?)/

SQL0727N  An error occurred during implicit system action type "3". 
Information returned for the error includes SQLCODE "-204", SQLSTATE "42704" 
and message tokens "DB2INST1.TEST_DEP".  LINE NUMBER=0.  SQLSTATE=56098

Итак, по таблицам зависимостей легко можно определить, что у нас валидно и будет выполняться, а что нет.
Ещё вопросы есть? Будем слова свои назад брать?

Yo.!зачем гуглить, у меня оракл есть, беру реальный запрос из вьюшки, с нетривиальным планом

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

select id
from
 secretview id = 100801


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1       0.00        0.07          0          6          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.37       0.39          1       4652          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.37       0.46          1       4658          0           1

...
похоже мы получили ответ, почему у дб2 так держится за прекомпиляцию
Похоже, что мы получили то, что вы не очень-то разбираетесь в том, сколько времени и на что Оракл тратит.

Код: plaintext

1.
2.

Table 21-4 SQL Trace Statistics for Parses, Executes, and Fetches:
CPU    : Total CPU time in seconds for all parse, execute, or fetch calls for the statement.
ELAPSED: Total elapsed time in seconds for all parse, execute, or fetch calls for the statement.

Вы посмотрели не в ту колонку. Никому не интересно, сколько там времени именно CPU тратит на построение плана. Главное - сколько времени в сумме у системы ушло на это.
В вашем случае это 70 миллисекунд. 15% времени выполнения.
Разница между этими 2-мя показателями это "the total waiting time for parse resources". Вот в эту разницу у вас всё время и ушло.

Yo.!не факт. 10 брокеров людей имеют 100 WATCH_ITEM, один брокер-автомат 100500 WATCH_ITEMs, для брокера-автомата дешевле фулскан.А вы не отклоняйтесь от условий конкретного теста, раз сами его предложили рассмотреть. Нету тут такого распределения данных. Наверное, создатели этого теста посчитали, что вариант с сошедшими с ума роботами не очень показателен.

...

Рейтинг:

0 / 0

09.11.2013, 12:58

| Ответить | Цитировать | Написать

Oracle vs DB2

#38465870

Apex

Участник

Откуда: Made in USSR

Сообщения: 3 841

Рейтинг: 0 / 0

Mark BarinsteinYo.!зачем гуглить, у меня оракл есть, беру реальный запрос из вьюшки, с нетривиальным планом

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

select id
from
 secretview id = 100801


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1       0.00        0.07          0          6          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.37       0.39          1       4652          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.37       0.46          1       4658          0           1

Код: plaintext

1.
2.

Table 21-4 SQL Trace Statistics for Parses, Executes, and Fetches:
CPU    : Total CPU time in seconds for all parse, execute, or fetch calls for the statement.
ELAPSED: Total elapsed time in seconds for all parse, execute, or fetch calls for the statement.

...

Рейтинг:

0 / 0

15.11.2013, 02:14

| Ответить | Цитировать | Написать

Oracle vs DB2

#38467304

Yo.!

Гость

Mark BarinsteinВы бы ещё про db2 v2.1 где-нибудь что-нибудь нашли.
Вероятно в то время, когда SQL процедуры неявно c-компилятором преобразовывались в нативный код и на этой 8.1.5 версии были такие странности, хотя и тогда по состоянию пакета можно было понять, что процедура не выполнится.
Сейчас катрина поменялась, пример это демонстрирует.
После удаления таблицы:
- Процедура test_dep1, обращающаяся к таблице, имеет статус N, её пакет - статус X.
- Вызывающая эту test_dep1 процедура test_dep2 имеет статус Y, её пакет - N.
...
Ещё вопросы есть? Будем слова свои назад брать?

нашел то с чем сталкивался, к сожалению, что-то свежее на zOS не часто встретишь.
если test_dep2 имеет статус Y я верно понимаю, что test_dep3 вызывающая test_dep2 будет иметь везде Y ?

Mark BarinsteinПохоже, что мы получили то, что вы не очень-то разбираетесь в том, сколько времени и на что Оракл тратит.

я не ту табличку выложил. это единственный запрос какой (с десятком NESTED LOOPS) начинает хоть какие-то цифры показывать и для этого мне пришлось поискать раритетную технику. все, что проще оракл даже измерить не может. я не представляю какой тормозной должен быть оптимизатор, что бы на современном железе по настоящему примитивный запрос. если дб2 за миллисекунды строит простые запросы, сколько же занимает постройка плана с десятком NESTED LOOPS !?? на моем i7 я не смог увидеть миллисекунды.

Mark BarinsteinА вы не отклоняйтесь от условий конкретного теста, раз сами его предложили рассмотреть. Нету тут такого распределения данных. Наверное, создатели этого теста посчитали, что вариант с сошедшими с ума роботами не очень показателен.
я вам хотел показать, что такое OLTP задача. в принципе. повторюсь, запросы даже в синтетическом tpc-e не так просты, как вам кажется, а в реальных системах они на порядок сложнее и распределение данных на порядок забавней.

...

Рейтинг:

0 / 0

16.11.2013, 15:39

| Ответить | Цитировать | Написать

Oracle vs DB2

#38467306

Yo.!

Гость

ApexНу это потому что был hard parse.
так мы про хард и рассуждаем, тысячи планов построятся в пределах секунды, лазить за каждым из них на хдд, явно архаизм.

...

Рейтинг:

0 / 0

16.11.2013, 15:43

| Ответить | Цитировать | Написать

Oracle vs DB2

#38470397

Mark Barinstein

Гость

Yo.!нашел то с чем сталкивался, к сожалению, что-то свежее на zOS не часто встретишь.
если test_dep2 имеет статус Y я верно понимаю, что test_dep3 вызывающая test_dep2 будет иметь везде Y ?
Так здесь, вроде, речь не про DB2 for zOS идёт, а про DB2 for LUW.
Да, поведение DB2 отличается здесь от поведения Оракла: если:
- test_dep1 обращается к таблице
- test_dep2 вызывает test_dep1
и таблицу удаляют, то test_dep2 (и все, которые её вызывают) не инвалидируется.
Сделано это, скорее всего, намеренно, т.к. здесь мне достаточно создать таблицу и ревалидировать test_dep1, которая непосредственно на неё ссылается. И не пытаться ревалидировать другие поцедуры, т.к. ревалидировать там нечего.
С практической точки зрения я всегда могу по таблице зависимостей определить, какие именно процедуры не будут выполняться:

вот так

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

with t(routineschema, specificname) as (
select routineschema, specificname
from syscat.routines
where routineschema=user and valid<>'Y'
  union all
select d.routineschema, d.specificname
from syscat.routinedep d, t
where d.bschema=t.routineschema and d.bname=t.specificname and d.btype='F'
)
select distinct routineschema, specificname
from t

и ревалидировать то, что мне нужно (либо все, либо все в схеме, либо по отдельности) специальной процедурой.
Yo.!я не ту табличку выложил. это единственный запрос какой (с десятком NESTED LOOPS) начинает хоть какие-то цифры показывать и для этого мне пришлось поискать раритетную технику. все, что проще оракл даже измерить не может. я не представляю какой тормозной должен быть оптимизатор, что бы на современном железе по настоящему примитивный запрос. если дб2 за миллисекунды строит простые запросы, сколько же занимает постройка плана с десятком NESTED LOOPS !?? на моем i7 я не смог увидеть миллисекунды.Ну да, имея чувствительность в десятки миллисекунд, тяжело на современном железе поймать такие запросы. Но дело даже не в скорости построения одного плана, а в соотношении времени выполнения и потраченного времени на накладные расходы.
Я ведь не просто просил вас погуглить по, например "oracle high parse time".
Можно получить такие , или такие результаты. Запросы там очень быстро выполняются, только если parse time такое убрать, то запросов бы гораздо больше в единицу времени можно было бы выполнить.
Yo.!я вам хотел показать, что такое OLTP задача. в принципе. повторюсь, запросы даже в синтетическом tpc-e не так просты, как вам кажется, а в реальных системах они на порядок сложнее и распределение данных на порядок забавней.Спасибо, что пытаетесь открыть мне глаза!
Только я и сам принимал участие в разработке таких систем, и сейчас довольно часто приходится смотреть на то, что разные компании пишут.
И могу сказать, повторяясь, что да, не все OLTP запросы простые, есть и забавные распределения данных. Но простых запросов много в таких системах.

Но мы, действительно, слишком много времени этим статическим запросам уделили. Это как рассматривать смысл использования мотоцикла, если есть легковая машина: где-то пригодится, где-то нет.

Я к вам почему прицепился: вы в очередной раз, не имея никакого опыта работы с предметом обсуждения (DB2 for LUW), начали её обвинять в серьезных грехах.
Мы продолжим дальше обсуждение "отсутствующих зависимостей" и "куцего и глючного" языка?

...

Рейтинг:

0 / 0

19.11.2013, 19:23

| Ответить | Цитировать | Написать

16 сообщений из 66, страница 3 из 3

все

Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Oracle vs DB2

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=35&msg=38442335&tid=1552422]:	0ms
get settings:	11ms
get forum list:	13ms
check forum access:	3ms
check topic access:	3ms
track hit:	40ms
get topic data:	12ms
get forum data:	3ms
get page messages:	55ms
get tp. blocked users:	1ms
others:	15ms

total:	156ms