irbis_al,

Вот, можете поанализировать, что есть и чего не хватает: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.plsql.doc/doc/c0053607.html. Да, у Oracle моря стандартных пакетов, в DB2 перенесено чуть-чуть. Не все возможности PL/SQL поддерживаются.

Полагаю ещё, что опытный ораклист будет от многого плеваться, потому что это пойдёт против его привычек, надо будет прилагать усилия и терпение. Только большое желание халявы может быть стимулом.

Кроме того, хотя очень многий SQL-ный и PL/SQL-ный код, по-видимому, пойдёт без переделок, PL/SQL-ный, возможно, будет сильно медленнее.

Мой опыт переноса невелик, я выдрал из HammerDB - пакет-заполнялку таблиц для TPC-C. Запустилось без переделок... но... мда... Впрочем, я мог что-то не учесть, и я ещё не раз вернусь к этой теме. Пока что...

Начать с того, что в коде интенсивное использование типа number - почти единственный ораклячий цифровой тип, и он во многих случаях будет мапиться на DB2-шный decfloat или decimal, операции с которыми (почему-то) не очень быстры. Желательно по возможности явно использовать integer-типы, иногда double (double не для денег, разумеется, а для тестов вроде HammerDB, где используется random), а decfloat/decimal только там, где записываются деньги.

При этом замена числовых типов (в коде из HammerDB) помогла только частично.

Вот после переписывания на DB2-шный синтаксис функция, которую я переписал, наоборот, стала выполняться много быстрее, чем в Oracle (благодаря тому, что стал возможен inline).

Но правка и переписывания - это именно то, что хотелось бы избежать? (Но, боюсь, переход куда-то ещё будет ещё сложнее).

С другой стороны, тот пресловутый пакет - это типичный продукт типичного ораклиста-клиппериста, который мыслит процедурами, а не операциями над множествами. По-хорошему, там могло быть просто несколько insert'ов с минимумом или вообще отсутствием PL/SQL-кода.

mad_nazgulВозможно. Я с DB2 работал мало, с Oracle и того меньше.
И их не сравнивал.
Но если был выбор, то всегда выбираю PostgreSQL, с ним проблем меньше (как минимум у меня). :-)

Я мельком посмотрел на pg и удивился их претензиям на наличие cost based optimizer - таким претензиям, что они даже против хинтов. Для OLTP-нагрузки оно, может, даже и сойдёт, а для OLAP/DWH как-то под большим сомнением. Авторы TPC-H-подобного бенчмарка HammerDB тоже сильно сомневаются.

А ещё на DB2 меня сильно разбаловал index advisor (ныне design advisor), который в комплекте даже бесплатной Express-C. Перейти на что-то без него - это ой-ой-ой какая проблема.

Я ничего не исследовал, просто почитал популярную книжку и посмотрел, как там задаётся стоимость чтения диска.

Для диска нормально задавать два параметра - OVERHEAD (грубо говоря, время, когда головки перемещаются к нужному сектору) и TRANSFERRATE (когда перемещение состоялось и идёт передача - скорость передачи в каких-то единицах). Это очень важно при подсчёте разницы между полным сканированием таблицы или индекса и случайным доступом. Это есть у DB2 и Oracle в тех или иных формах.

У PG в настройках я увидел всего один параметр. Да, кстати, про мощность CPU там что-нибудь есть?

А у HammerDB PG не справился с их версией TPC-H. Учитывая, что это широко известный (в узких кругах) бенчмарк, это о чём-то говорит.

Короче, всё под большим вопросом, требует расследования - у меня сейчас нет большой мотивации этим заниматься.

Index advisor - какой-то запрос тормозит? скормил его advisor'у, тот насоветовал индексов, скорость повысилась в дикое количество раз.

Теперь зовётся design advisor, потому что может советовать MDC и MQT.

Аналог у Oracle стоит безумных бабок (первым делом, надо EE прикупать, а к ней две опции).

Ivan DurakVictor MetelitsaУ PG в настройках я увидел всего один параметр.
плохо искал
seq_page_cost (floating point)
random_page_cost (floating point)
Спасибо, а про мощь CPU?

вот оно

PostgreSQL Up and Running (second edition)Another setting that influences the planner is the random_page_cost (RPC) ratio, which
is the relative cost of the disk in retrieving a record using a sequential read versus using random access. Generally, the faster (and more expensive) the physical disk, the lower the ratio. The default value for RPC is 4, which works well for most mechanical hard drives on the market today. The use of solid-state drives (SSDs), high-end storage area networks (SANs), or cloud storage makes it worth tweaking this value.

и ссылка на http://www.databasesoup.com/2012/05/random-page-cost-revisited.html

поэтому я ошибочно запомнил про один параметр (а всё равно второй "обычно равен единице"). Но всё равно видно, что люди себя измерением миллисекунд не утруждают, хотя pg-шный explain их из чего-то высасывает; всё это подозрительно.