Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Oracle vs DB2  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Apex
На проекте, где я сейчас работаю у нас 72-х нодный кластер на DB2. И я скажу так, различия весьма и весьма существеные, что бы там не говорил гражданин Метелица.

А что он такого говорил? Возможно, у вас сложилось неверное впечатление.

Я полагаю, что перевестись с Oracle на DB2 будет легче, чем на другую СУБД, потому что IBM-еры постарались перенести PL/SQL и кучу других вещей - но это совсем не значит, что будет легко.
19 окт 13, 11:42    [15001857]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Yo.!
ну и второй большой косяк - отсутствие версионности, в 21 веке, где даже mysql выдает консистентный набор на момент старта запроса биться будет проблематично. изврат в виде хинтов аля skip_locked, last_committed девелоперы в своей массе не оценят, когда есть выбор

Сферическим девелоперам в вакууме при решении задач о сферических конях в вакууме невозможно обойтись без ораклиной консистентности, ага.
19 окт 13, 11:53    [15001869]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Yo.!
db2 до сих пор динозавр, повторяет то что прошел оракл 15-20 лет назад. 15-20 лет назад у оракла тоже был статический SQL который внедрялся в известные языки, типа C, но если на смену этому порно в оракле достаточно быстро пришел 4GL язык

Кстати, по мне, (в сравнении с "4GL") статический SQL в DB2 как был великолепен в DB2 2.1 for OS/2, так и сейчас великолепен (разве что, могли бы добавить поддержку большего количества типов данных). Всякого рода PL/SQL-и нужны были для попытки переманивания с Oracle, но не сами по себе.
19 окт 13, 12:02    [15001888]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Yo.!
мериться отмершими в мире оракла прекомпиляторами не готов, а вот по 4GL запросто. нука напишите мне аналог на любом вашем языке
create procedure myproc (p_ref IN sys_refcursor, p_row IN tabl1.col1%type)


http://tkyte.blogspot.ru/2006/10/slow-by-slow.html
Вот то, чем вы и сотни тысяч таких же, как вы, занимаетесь. Clipper умер, а клипперисты живее всех живых.
предлагаете на каждый чих реавалидировать сотни мб кода всего проекта ?

В нынешних версиях DB2 Oracle-подобное поведение.
19 окт 13, 12:09    [15001903]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Victor Metelitsa
Не сочиняю. Undo tablespace у DB2 нет. В старые времена при попытке посмотреть на изменённую запись происходила блокировка (если не использовать уровень изоляции UR), теперь может заглянуть в лог ( http://www.ibm.com/developerworks/data/library/techarticle/dm-0907oracleappsondb2/index.html ).

ну и где там двунаправленный лог ? я рад за db2, что он научился вместо грязного блока выдавать last committed. я понимаю, что это огромный шаг для db2, но к консистентному набору выдаваемому версионными субд этот костыль db2 не приближает. никому не нинтересен последняя закомиченная версия, всех интересует та, что была в момент старта запроса/транзакции.

Victor Metelitsa
C поры "IBM DB2 UDB 8.2" ситуация могла сильно поменяться.

это не важно, важно, что есть пример, где хорошо видно, что оракл на одинаковом железе может писать в undo+redo быстрее чем db2 или mssql в один transaction log.
19 окт 13, 12:18    [15001914]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Victor Metelitsa
http://tkyte.blogspot.ru/2006/10/slow-by-slow.html
Вот то, чем вы и сотни тысяч таких же, как вы, занимаетесь. Clipper умер, а клипперисты живее всех живых.

анекдот
- Сивка Бурка вещая каурка, встань передо мной как лист перед травой.
- Иван, вы бы поконкретнее выражались как вставать, а то у нас у лошадей короткий ассоциативный ряд.

интересно, это у вас под влиянием db2 декларация процедуры ассоцируется с клипером ?

Victor Metelitsa
В нынешних версиях DB2 Oracle-подобное поведение.

это вам мерещется, ничего похожего на зависимости в db2 нет.
19 окт 13, 12:30    [15001926]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

Yo.!
ничего похожего на зависимости в db2 нет.

А зачем они нужны, если всё равно не используются? Какая принципиальная разница между
последовательностями "изменение объекта - инвалидация зависимых - попытка использования
зависимого объекта - попытка компиляции - ошибка пользователю" и "изменение объекта -
попытка использования зависимого объекта - ошибка - попытка компиляции - ошибка пользователю"?

Posted via ActualForum NNTP Server 1.5

19 окт 13, 12:40    [15001939]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
нука напишите мне аналог на любом вашем языке
create procedure myproc (p_ref IN sys_refcursor, p_row IN tabl1.col1%type)

нуканаписал:
create procedure myproc (IN p_ref cursor, IN p_row ANCHOR tabl1.col1)
В режиме совместимоси с Ораклом - вообще без изменений.
Yo.!
или выдайте права на процедуры связанные с фин подсистемой (с пакаджем)
Не уверен, что понял, что вы хотите.
В db2 права на процедуры выдаются так же как и в Оракле - грантом на выполнение процедуры, а не на пакет.
На пакет выдаются гранты, если вы написали программу на C, JAVA, например, с использованием статического SQL.
Можно выдавать грант на выполнение модуля (пакета по-вашему), что даёт право на выполнение любой опубликованной процедуры.

Вопрос: чего здесь не хватает по сравнению с Ораклом?
Yo.!
... если я снес таблицу, у меня процедуры обращающиеся к этой таблице должны пометиться как invalid и должен быть запрет на запуск заведомо не валидного кода. в db2 до сих пор даже этого базиса нет.
...
это вам мерещется, ничего похожего на зависимости в db2 нет.
Мне тоже что-то мерещится.
Давайте на примере.

В системном каталоге есть несколько представлений с именем DEP в конце.
+ Вот их список

CONSTDEP
DATATYPEDEP
FUNCDEP
INDEXDEP
INDEXEXTENSIONDEP
PACKAGEDEP
ROUTINEDEP
TABDEP
TABDETACHEDDEP
TRIGDEP
VARIABLEDEP
VIEWDEP
XSROBJECTDEP

Во всех представлениях есть поля для описания объектов от которых есть зависимость:
BTYPE, BSCHEMA, BNAME
При DDL эти таблицы ведутся автоматически, и я могу проверить любые зависимости.
+ Вот пример
create table dep_t(i int)/

create or replace procedure dep_p(out prows int)
specific dep_p
begin
  set prows = (select count(1) from dep_t);
end/

select r.valid, d.btype, varchar(d.bname, 20) bname
from syscat.routines r
join syscat.routinedep d 
on d.routineschema=r.routineschema and d.specificname=r.specificname
where r.routineschema=user and r.specificname='DEP_P'/

VALID BTYPE BNAME               
----- ----- --------------------
Y     T     DEP_T               
Y     K     P2101101175         

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

-- после drop
drop table dep_t/
-- запрос возвращает:
VALID BTYPE BNAME               
----- ----- --------------------
N     T     DEP_T               
N     K     P2101101175         

-- и вызов возвращает ошибку
call dep_p(?)/

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

-- после пересоздания таблицы я вызываю ревалидацию процедуры явно, и моя процедура начинает работать
CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS('procedure', user, 'DEP_P')/
-- я могу выставить параметр базы так, чтобы оно в рантайме само автоматически пыталось ревалидировать все инвалидные объекты при обращении к ним, если мне это надо.
Вопрос: что в этой схеме ведения зависимостей не так, и чем Оракл лучше в этом смысле?
19 окт 13, 14:44    [15002154]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
db2 до сих пор динозавр, повторяет то что прошел оракл 15-20 лет назад. 15-20 лет назад у оракла тоже был статический SQL который внедрялся в известные языки, типа C, но если на смену этому порно в оракле достаточно быстро пришел 4GL язык, то в db2 sqlpl до сих слишком куцый и глючной.
Вы путаете SQL статический (db2: static), которого у Оракла никогда не было, и "встраиваемый" (db2: embedded).
Про куцый и глючный: ОБС-news или на примере можете?
19 окт 13, 14:54    [15002181]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
нуканаписал:
create procedure myproc (IN p_ref cursor, IN p_row ANCHOR tabl1.col1)
В режиме совместимоси с Ораклом - вообще без изменений.

блин, если уж встреваете в спор, ну проследите нить разговора:
CawaSPb
Это потому что у Оракла никогда не было нормального статического SQL с нормальным менеджментом пакетов (bind, rebind и т.п.). А этот 4GL язык - один фиг бейсик для работы с датасетами толком не предназначенный. Да он стал популярен, но строго потому, что писать на нём идут люди недалеко ушедшие от VB.


к чему тут пример на SQLPL, покажите аналог этой процедуры на прекомпиляторе + static SQL ! та же фигня с грантами.
19 окт 13, 16:46    [15002378]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
Вы путаете SQL статический (db2: static), которого у Оракла никогда не было, и "встраиваемый" (db2: embedded).

и там и там прекомпилятор, разница лишь в деталях. на мой взгляд статик SQL ублюдочен в своей концепции. план запроса должен меняться вместе с ростом и изменениями объектов субд, а не зашиваться вместе с процедурой. запрос в любых условиях должен исполняться с оптимальным планом, а не с тем, что был когда-то оптимальным.
19 окт 13, 16:55    [15002394]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
к чему тут пример на SQLPL, покажите аналог этой процедуры на прекомпиляторе + static SQL ! та же фигня с грантами.
А какой смысл показывать, как на мотоцикле пару мешков картошки возить? Это на машине удобнее делать, примерно такой же, как и ваша.
Yo.!
и там и там прекомпилятор, разница лишь в деталях. на мой взгляд статик SQL ублюдочен в своей концепции. план запроса должен меняться вместе с ростом и изменениями объектов субд, а не зашиваться вместе с процедурой. запрос в любых условиях должен исполняться с оптимальным планом, а не с тем, что был когда-то оптимальным.
Никому не интересно как мы код компилируем - с пре-, пост- или вместо-компилятором. Главное отличие в результате.

Попробуйте расширить своё сознание (только без веществ, пожалуйста :), чтобы понять эту концепцию. Идея там примерно в следующем:
Часто вы знаете, что план запроса не будет меняться с изменением статистики. Такие запросы характерны для OLTP систем - они простые, но их много.
Для того, чтобы выполнить динамический запрос вы должны сделать:
- распарсить запрос, проверить, есть ли он в кэше запросов
- проверить права на каждую таблицу запроса
- построить план и сохранить его в кеше запросов
Понятно, что все шаги вы не делаете постоянно, если не закрываете стейтмент сразу после использования. Но накладные расходы есть, и они могут стать довольно значительными, особенно если запросов действительно много.
В случае статических запросов вы только провеояете права на выполнение пакета, который управляет всеми запросами программы.
У IBM есть даже такой продукт, как pureQuery, который может превращать динамические запросы вашей программы в статические без перепрограммирования. Говорят, что на некоторых нагрузках можно получить только из этого довольно неплохие результаты.

В общем, это инструмент для своих нужд, его не надо пытаться использовать для решения всех задач.
Если вы не хотите, то можете его не использовать.
Но в Оракле этого просто нет.
19 окт 13, 20:15    [15002925]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
А какой смысл показывать, как на мотоцикле пару мешков картошки возить? Это на машине удобнее делать, примерно такой же, как и ваша.

прекомпилер это не мотоцикл - это динозовр, на большинстве задач давно вымерший по объективным причинам.

Mark Barinstein
Часто вы знаете, что план запроса не будет меняться с изменением статистики.

очнитесь, на дворе 21 век, cost based оптимизаторы. да наши предки грелись у костров, охотились на мамонтов и использовали прекомпиллеры, но сейчас то оптимизатор может посмотреть в буферный кеш и изменить план уже исходя из этого. прекомпиллер физически не может построить оптимальный план не имея даже базовой информации, какая часть таблицы в буферном кеше. опять же план может сильно зависеть от переменных, я не понимаю как прекомпилятор мог бы построить оптимальный план на каждый вариант. на все варианты не зашьешь ...
19 окт 13, 20:46    [15003000]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
прекомпиллер физически не может построить оптимальный план не имея даже базовой информации, какая часть таблицы в буферном кеше. опять же план может сильно зависеть от переменных, я не понимаю как прекомпилятор мог бы построить оптимальный план на каждый вариант. на все варианты не зашьешь ...
Вы, похоже, так и не поняли, о чём я написал.
Для построения плана запроса типа:
select ... from mytable where pk=:par
не надо знать ни статистики, ни значения параметра, ни то, какая там часть таблицы в кэше сидит. Какие тут могут быть варианты? Вариант плана здесь всегда будет один, и он же будет оптимальным.
А главная идея в том, чтобы для такого запроса (которых, повторюсь, может быть очень много) убрать накладные расходы, которые в сумме вообще могут превысить расходы на выполнение этого запроса.

А для 21-го века у DB2 есть тоже хитрый оптимизатор и т.п.

P.S.:
1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас?
2. Про куцый и глючный DB2 SQL/PL (или PL/SQL) будут примеры?
19 окт 13, 21:16    [15003073]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
select ... from mytable where pk=:par

[/src]не надо знать ни статистики, ни значения параметра, ни то, какая там часть таблицы в кэше сидит. Какие тут могут быть варианты? Вариант плана здесь всегда будет один, и он же будет оптимальным.

если колонка pk не уникальна, даже на столь примитивном запросе будет полно вариантов.

Mark Barinstein
А главная идея в том, чтобы для такого запроса (которых, повторюсь, может быть очень много) убрать накладные расходы, которые в сумме вообще могут превысить расходы на выполнение этого запроса.

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

Mark Barinstein
А для 21-го века у DB2 есть тоже хитрый оптимизатор и т.п.

поэтому db2 и бросила все силы на копирование фич oracle, а не выносит мозг протухшими прекомпиляторами.

Mark Barinstein
1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас?
2. Про куцый и глючный DB2 SQL/PL (или PL/SQL) будут примеры?


1. далеко не все, такие зависимости и в мсскл есть, а может db2 отследить если изменилась колонка с варчар на инт ?
2. попозжей будут
19 окт 13, 21:33    [15003132]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
поэтому db2 и бросила все силы на копирование фич oracle, а не выносит мозг протухшими прекомпиляторами.
Вы зациклились на прекомпиляторах. Считайте, что его нет в db2. В SQL процедуре статический код появляется без всяких прекомпиляторов, например.
Yo.!
Mark Barinstein
1. Всё ли понятно теперь про зависимости в db2? Они все-таки есть, или их по-прежнему нет для вас?
1. далеко не все, такие зависимости и в мсскл есть, а может db2 отследить если изменилась колонка с варчар на инт ?

Каких зависимостей не хватает? И при чём здесь MSSQL?

Что значит "отслеживать"?
Инвалидировать зависящие от объекты?
+ Пример
create table test_v(v varchar(10))/
insert into test_v values '1', '2', '3'/
alter table test_v alter v set data type int/
describe select * from test_v/

 Column Information

 Number of columns: 1

 SQL type              Type length  Column name                     Name length
 --------------------  -----------  ------------------------------  -----------
 497   INTEGER                   4  V                                         1


insert into test_v values '1', '2', '3'/

DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0668N  Operation not allowed for reason code "7" on table "MARK_B.TEST_V".  
SQLSTATE=57016

Explanation: 
...
7        

         The table is in the reorg pending state. This can occur after
         an ALTER TABLE statement containing a REORG-recommended
         operation.

select * from test_v/

V          
-----------
          1
          2
          3

Т.е. оно переводит таблицу в read-only режим после изменения типа до тех пор, пока я не сделаю реорганизацию таблицы.
Процедура типа этой не инвалидируется.
create or replace procedure test_v(pi varchar(10), out po varchar(10))
specific test_v
begin
  set po = (select v from test_v where v=pi);
end/
Это нормально или нет?
19 окт 13, 22:13    [15003247]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
выносит мозг протухшими прекомпиляторами
Спасибо, поржал. И про вынос мозга очень к месту.
Yo.!, любезный, "прекомпилятор" - это совсем не то, что Вы думаете :)
Прекомпилятор - это тулза, запускаемая до компиляции/интерпретации, а не вместо :)
И никакие исполняемые коды (планы исполнения для SQL) прекомпилятор генерить не может в принципе. Его задача - только подготовить исходный текст.

В DB2 "прекомпилятором" можно назвать те фазы, которые запрос объединяют в один длинный текст, inline подставляя view и специально обученные UDF (нет такого в Oracle), парсят его, переформулируют (sql rewriting - есть ли он в Oracle?), объединяют группу запросов в пакет, проверяют права. Т.е. делают всю работу, для которой статистика и прочие cost based совсем не нужна.
Получется полуфабрикат - пакет по-DB2'шному.
Собственно "компиляция", при которой строятся планы выполнения, грубо говоря называется bind/rebind. И уже она может происходить в момент вызова, в момент первого обращения или постоянно при необходимости (как в интерпретаторах, но без подготовительных фаз "прекомпилятора") - как укажешь.
И что лучше - интерпретатор, работающий только одним способом, или компиляция с возможностью выбора ее времени с экономией времени на предобработку?
19 окт 13, 23:07    [15003387]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
Вы зациклились на прекомпиляторах. Считайте, что его нет в db2. В SQL процедуре статический код появляется без всяких прекомпиляторов, например.

в SQLPL процедуре ? забавно, а там то такое на кой ?
в оракле если уж так хочется зафиксировать план - есть отдельные инструменты, которые зафиксировать могут не только SQL из процедур но и то, что приходит от клиента или генерится на лету.

Mark Barinstein
Что значит "отслеживать"?
Инвалидировать зависящие от объекты?

да, инвалидировать код, заведомо не выполнимый.

Mark Barinstein
Это нормально или нет?


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

зы. так на счет того, что оптимальность плана может измениться не только из-за изменений статистики я убедил ?
19 окт 13, 23:11    [15003401]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

Yo.!
po у вас объявлено как варчар, а таблица вернет инт, значит ваша процедура
превратилась в инвалидную.

А что, implicit cast числа в строку кто-то предал анафеме?..

Posted via ActualForum NNTP Server 1.5

19 окт 13, 23:15    [15003414]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
CawaSPb
2 Apex, а что с ним не так??? Интересно. И ещё раз, в Oracle его попросту нет, так что в контексте темы это просто таки жирный плюс DB2. При этом технология более чем зрелая. На моей памяти (>15 лет) ей вовсю (в том числе в мире VLDB) пользуютя "и не жужжат" ;)

Согласен, по сравнению с Ораклом - все прекрасно, тут у меня претензий никаких.

На счет не жужжат - я бы так не сказал. Тут вот какое дело, как и Оракл РАК, так и DB2 DPF (ранее PE) они, что называется, кластерны не от природы, обе СУБД уходят корнями в некластерные СУБД для OLTP. Отсюда лишние сложности в администрировании: надо создавать какие-то партинш группы, партишн тейблспейсы, думать о том, в каком тейблспейсе у тебя таблица - в партиционированном или нет? и пр. Т.е. прозрачность для приложений вроде есть, а вот для администрирования как-то не очень.

Теперь что касается функционала, в DB2 варехаузный ИМХО слабоват: набор аналитических функций куций по сравнению с тем же Ораклом, партиционирование только двухуровневое (хотелось бы еще минимум одного), truncate конкретной партиции просто так не сделаешь - надо сначала detach сделать, переливка данных из таблицы в таблицу а-ля INSERT /*+APPEND*/ INTO - это вообще песня, где простая операция превращаетя в серию каких-то приседаний и подпрыгиваний с курсорами и вызовами консольной утилиты LOAD через процедуру ADMIN_CMD. CTAS опять же ущербный...

В общем, я конечно понимаю, что по сравнению с мировой революцией - это все мелочи и дело привычки, но сложно все как-то, не удобно и работать с DB2 в будущем у меня никакого желания нет.
20 окт 13, 05:33    [15003882]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
Mark Barinstein
Что значит "отслеживать"?
Инвалидировать зависящие от объекты?
да, инвалидировать код, заведомо не выполнимый.
Mark Barinstein
Это нормально или нет?
на мой взгляд нет. po у вас объявлено как варчар, а таблица вернет инт, значит ваша процедура превратилась в инвалидную.
Нет, процедура как работала, так и работает. Там будет делаться неявное преобразование типов.

Еще есть претензии/вопросы к зависимостям в db2?
20 окт 13, 09:27    [15003920]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
зы. так на счет того, что оптимальность плана может измениться не только из-за изменений статистики я убедил ?
Вы даже не начали. Если это продолжение:
Yo.!
select ... from mytable where pk=:par
если колонка pk не уникальна, даже на столь примитивном запросе будет полно вариантов.
то давайте обсудим.
Дано: "большая" таблица, поля в предикате проиндексированы, запрос возвращяет несколько записей (ну, не больше 20-30). Кардинальность индекса высокая. В общем, довольно часто встречающийся вариант в OLTP системе.

Расскажите про "полно вариантов", кроме обычного IXSCAN-FETCH.
Мы каждый обсудим и решим, много ли от перебора всех возможных вариантов мы выиграем.
И много ли потеряем, если для такого случая оптимизатор при каждом из огромного потока таких запросов будет проявлять интеллект и решать, а надо ли поменять план.
20 окт 13, 09:42    [15003929]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Apex
партиционирование только двухуровневое (хотелось бы еще минимум одного), truncate конкретной партиции просто так не сделаешь - надо сначала detach сделать, переливка данных из таблицы в таблицу а-ля INSERT /*+APPEND*/ INTO - это вообще песня, где простая операция превращаетя в серию каких-то приседаний и подпрыгиваний с курсорами и вызовами консольной утилиты LOAD через процедуру ADMIN_CMD. CTAS опять же ущербный...

- партиционирование
Вы можете использовать MDC для "субпартиционирования" (возможно указать несколько полей в ORGANIZE) типа такого:
CREATE TABLE MYTABLE
DISTRIBUTE BY (...)
PARTITION BY (...)
ORGANIZE BY (...)
Вы не используете такой вариант? Если нет, то почему?

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

- CTAS
В DB2 есть процедура ADMIN_MOVE_TABLE, которая похожие вещи делает, если я правильно понял аббревиатуру CTAS.
К ней надо привыкнуть, конечно, но с ней проблемы или неудобства какие-то?
20 окт 13, 10:11    [15003943]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Yo.!
Guest
Mark Barinstein
Нет, процедура как работала, так и работает. Там будет делаться неявное преобразование типов.

Еще есть претензии/вопросы к зависимостям в db2?

да, про неявную сглупил, но вы поняли в чем мой вопрос. в обратной ситуации - переменная инт, а в таблице на чар сменили

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

по вашему олтп это лишь вытягивания по индексу ? я например столь примитивные запросы в реальных системах не встречал. если хотите совсем конкретики давайте возьмем TPC-E - реальная задача, реальные запросы. там, например, такого примитива нет.
но даже на таком примитивном запросе если по значению 'shit' возвращается 99.9% записей, то вместо индекса эффективней фулскан применить. т.е. уже не один вариант.
20 окт 13, 12:36    [15004165]     Ответить | Цитировать Сообщить модератору
 Re: Oracle vs DB2  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 5032
Yo.!
да, про неявную сглупил, но вы поняли в чем мой вопрос. в обратной ситуации - переменная инт, а в таблице на чар сменили
Нет, я не понял разницы.

DB2 мне не запрещает на
create table test_v(v varchar(10))
пытаться делать арифметические операции над v.
Т.е. я могу в процедуре делать v + 1, например, и процедура создастся.
То же самое будет, если я поменяю int на varchar в таблице, т.е. процедура использующая арифметику не будет инвалидироваться.
Она в рантайме будет отваливаться, если неявное преобразование varchar -> int не пройдёт.

А как это в Оракле происходит?
Создастся ли на таблице выше процедура, где есть обращение v + 1 к полю?
Будет ли процедура инвалидироваться при изменении varchar -> int?
Yo.!
по вашему олтп это лишь вытягивания по индексу ? я например столь примитивные запросы в реальных системах не встречал. если хотите совсем конкретики давайте возьмем TPC-E - реальная задача, реальные запросы. там, например, такого примитива нет.
но даже на таком примитивном запросе если по значению 'shit' возвращается 99.9% записей, то вместо индекса эффективней фулскан применить. т.е. уже не один вариант.
Да, по-моему OLTP - это преимущественно вытягивание по индексу.
Я не говорю, что все, но значительная часть запросов - да.
Давайте смотреть TPC-E, если хотите.
Можете показать, где там будут фуллсканы встречаться, неравномерное распределение данных и т.п.
Я уверен, что и там мы с вами найдем запросы, для которых не надо знать статистику и всё остальное, а можно будет только по существующим индексам сказать, какой будет оптимальный план запроса.
20 окт 13, 15:53    [15004560]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить