|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Ребят не обижайтесь но вы в Оракле полные профаны. Энтерпрайзовые ораклы стоят поверх ASM а это решение работает минуя ReadFileScatter() и тем более Windows. По поводу SSD(flash based devices). Оракл умеет работать с ними по "другому" и для "других" целей. Детальнее обзор можно почитать тут: http://www.oracle.com/technetwork/articles/systems-hardware-architecture/oracle-db-smart-flash-cache-175588.pdf ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 18:44 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей АрсеньевХотя Oracle реально более тяговитый грузовик и сопровождать его легче, хотя и дороже. Ога , мощьно тягает через дисковый ввод вывод темп то, что у других спокойно помещается в оперативной памяти. _PGA_MAX_SIZE _SMM_PX_MAX_SIZE _SMM_MAX_SIZE ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 19:06 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей АрсеньевЧто в случае SSD - деньги на ветер. А при наличии кеша ФС и переопределения порядка операций, даже у обычного винта вообще не сильно различается, что уж говорить про большой контроллер. Да Oracle велик. Но и у него есть свои слабости. Это и УРА мы, наконец, сделали строки 32Kb!!!! эх Сережа, именно эти архитектурные "слабости" и делают оракл #1. оракл ставят в банк, а постгрес с его строками в банк не поставят, потому что оракл с его строками вытянет нагрузку любого банка, а постгрес фиг. если ораклу нужно хранить строковые сочинения - есть CLOB, который от варчара не отличить. полагаться на кеш ФС могут аутсайдеры, с примитивным оптимизатором. а вот оракловый оптимизатор учитывает сотни параметров, в том числе кол-во блоков таблицы в кеше. и никакой SSD долбеж одноблочным чтением не выправит, лишь несколько сократит отставание. даже на SSD один IOPs на 128 блоков будет в разы быстрее 128 IOPs по одному блоку. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 20:15 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
maytonРебят не обижайтесь но вы в Оракле полные профаны. Энтерпрайзовые ораклы стоят поверх ASM а это решение работает минуя ReadFileScatter() и тем более Windows. в конце концов контроллер получит все тот же многоблочный запрос. которое API его сформирует совершенно не важно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 20:24 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Ivan DurakAlexander Ryndinпропущено... Если это OLTP, то там используются bind. т.е. полный парсинг исчезающе редкая операция. Если bind не используются, то разработчика на кол. почитай чтоли - как раз бинд и не используется из-за приложения. А переписывать его лень. Уха-хахахаТо что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARING ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 21:01 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Alexander RyndinТо что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARINGЭтот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 21:14 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Relic HunterAlexander RyndinТо что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARINGЭтот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет?8i.... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 21:24 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Relic HunterAlexander RyndinТо что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARINGЭтот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет?При втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.02.2016, 21:31 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Аффтар, поверь, дешевле переписать прикладухи на бинд, нежели сменить SQL, что есть нереальный геморрой, архитектура разная, многих фич нет в pg, но есть в ora и наоборот, многие фичи не так как в ora работают, подводные камни в pg есть не хуже оракловых и так далее. Обе базы сопоставимы, но у ora оптимизатор более вылизан. Начните писать новую версию клиентов с биндов. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 11:13 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
PG может выиграть у Оракля. И MySQL с Firebird'ом могут выиграть у Оракля. И даже FoxPro с MS Access'ом могут. В некоторых частных случаях. Быть может, у топикстартера как раз такой частный случай. К примеру, приложение настолько кривое или администрование СУБД поставлено настолько убого, что даже переход на PG даст выигрыш по сравнению с текущей ситуацией. А мы об этом понятия не имеем. А в общем случае, конечно, к переходу с Oracle (даже с SE) на PG в поисках повышения производительности и к приравниванию PG к Ораклю нельзя относиться серьёзно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 11:16 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
И самое главное . 1)прикладухи под пж всё равно потом придётся переписывать. 2)Выигрыша в скорострельности это может и не дать. 3)Под pg нужно затачивать железо - требование к дискам и к памяти особые. 4)Под pg понадобится ОЧЕНЬ хороший linux сисадмин и железячник ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 11:18 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Victor MetelitsaА в общем случае, конечно, к переходу с Oracle (даже с SE) на PG в поисках повышения производительности и к приравниванию PG к Ораклю нельзя относиться серьёзно. Я могу гарантировать, что тупое перекладывание запросов на другой SQL совершенно точно положит производительность в нуль. Неважно откуда куда идёт миграция. Посмотрите на 1С ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 11:23 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Подпольщег4)Под pg понадобится ОЧЕНЬ хороший linux сисадмин и железячник Если в бюджете сумму из строки лицензионные платежи переместить в строку ФОТ , то думаю, что толпы хороших сисадминов и железячников будут стоять в очереди в ОК. . ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 11:46 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Victor Metelitsa, автор также пишет ......Основной упор идет на то, что кривой оптимизатор запарывает всю производительность, приходится использовать кучи хинтов в запросах, а на постгресе этой проблемы быть не должно из-за более умного оптимизатора.... Помню я где-то читал что PG использует генетические алгоритмы для отбора наилучших планов. Возможно это и есть так козырная карта о которой пишет т.н. "руководство". Но даже в этом случае нужно какое-то моделирование. Ребят! В этой области (миграция с одной БД на другую) практически нет экспертов которые скажут что тут будет +25% бенефита к примеру. Это всё от очень-очень многого зависит. Всё надо пробовать. Макеты создавать. У оракла 5 видов партишионинга. Как это замапить на PG без деградации перформанса? Никто не знает. Как портировать PLSQL код? ХЗ. Ну вот тут что-то пишут http://www.postgresql.org/docs/7.3/static/plpgsql-porting.html ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 12:46 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Yo.!эх Сережа, именно эти архитектурные "слабости" и делают оракл #1. оракл ставят в банк, а постгрес с его строками в банк не поставят, потому что оракл с его строками вытянет нагрузку любого банка, а постгрес фиг. Как показал пример Сбербанка - хороший банк и Oracle озадачить сможет. :) Yo.!если ораклу нужно хранить строковые сочинения - есть CLOB, который от варчара не отличить. Увы и ах - отличить. Недавно разбирался с ошибкой, когда склеивание varchar с CLOB порой приводило к NULL в результате. Yo.!в том числе кол-во блоков таблицы в кеше. и никакой SSD долбеж одноблочным чтением не выправит, Ну 128 запросов к контролеру пришедших за время позиционирования головки отработают не сильно медленнее 1 на всу дорожку. С точки зрения SSD - прочитать 64 сектора в разнобой может в теории быть эффективнее, чем 128 махом. Но впрочем и чтобы добиться того, чтобы чтение лишнего нагрузило чрезмерно надо постараться. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 13:01 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Alexander RyndinПри втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема? В том, что на третьем бинде может оказаться, что план не оптимальный. :) Статистика по сегодняшней партиции еще не собрана. И т.д. и т.п. И в конце концов окажется что для высоконагруженного приложения с полным использованием железа все одно придем к необходимости ручной оптимизации высококлассным специалистом, а при небольшой нагрузке не видно разницы. Но продвинутый оптимизатор - это шаг навстречу прогресса. Тут не поспоришь. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 13:09 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Автор вбросил и скрылся :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 13:32 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Q.TarantinoАвтор вбросил и скрылся :) Наверно поменял cursor_sharing на force и все взлетело. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 14:15 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей АрсеньевAlexander RyndinПри втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема? В том, что на третьем бинде может оказаться, что план не оптимальный. :) Тогда включатся в игру всякие adaptive cursor sharing, cardinality feedback и прочее. И может самопофиксится. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 14:18 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей Арсеньев, по поводу LOB если объём больше 200 мегабайт - в pg случаются неприятности, а на pg_conf мне сказали, что штатная LOB, которая не bytea/text поддерживается только для совместимости и в дальнейшем её хотят выпилить. В oracle с этим проблем меньше. Стало быть если прикладуха реально использует эту киллер-фичу - у разрабов будет много яркого и интересного сексу. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 14:18 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей АрсеньевКак показал пример Сбербанка - хороший банк и Oracle озадачить сможет. :) один пример из десятка миллионов банков не очень показателен. тем более на фоне падений континентов у мсскл. Сергей АрсеньевУвы и ах - отличить. Недавно разбирался с ошибкой, когда склеивание varchar с CLOB порой приводило к NULL в результате. руки кривые, у меня я еще в 90х применял конкотенацию и substr. больше всего меня впечатлило тогда, что пхп как с варчаром работал, без всяких танцев с LOB объектами. Сергей АрсеньевНу 128 запросов к контролеру пришедших за время позиционирования головки отработают не сильно медленнее 1 на всу дорожку. С точки зрения SSD - прочитать 64 сектора в разнобой может в теории быть эффективнее, чем 128 махом. Но впрочем и чтобы добиться того, чтобы чтение лишнего нагрузило чрезмерно надо постараться. к чему теоризировать, поставь DB_FILE_MULTIBLOCK_READ_COUNT=1 и посмотри сам. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 14:21 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
По поводу падений процессинга в Сбербанке. Тема интересная. Я какое-то время за ней следил а потом каюсь... забил и дела были. Разумеется Оракл тогда не ругал разве что ленивый. Но КМК причины подобных аварий не простые. И одной инструкцией тут не отпишешся. Вобщем читаем и вспоминаем как было. Это-ли последняя ссылка на скруле? Прошу подтвердить кто вкурсе дел. http://www.sql.ru/forum/953904/orakle-okazyvaetsya-vinovat ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 14:53 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Сергей АрсеньевAlexander RyndinПри втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема? В том, что на третьем бинде может оказаться, что план не оптимальный. :) Статистика по сегодняшней партиции еще не собрана. И т.д. и т.п.Мы про OLTP говорим. Там такого быть не может. Для OLAP-нагрузки, естественно, этого делать не надо, но для DWH время парсинга стремится к нулю по сравнению со временем выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 17:04 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Melkomyagkii_newbiQ.TarantinoАвтор вбросил и скрылся :) Наверно поменял cursor_sharing на force и все взлетело. Да не, читаю по вечерам ) Все у них нормально с bind переменными. Все запросы хранятся в xml файлах. Все что может меняться в запросах оформлено параметрами, работает через JDBC. Чтобы разбираться, нужно получить одобрение. Пока пишем планы и чиним мелкие баги. После переписывания нескольких запросов сложилось впечатление, что вся проблема в кривом проектировании таблиц. Связи избыточны и неочевидны, нормализация местами сильно хромает. Администрирование насколько понял, тоже из разряда дать права пользователю, посмотреть кто заблокировал сессию. Еще слишком много запросов выполняется лишних. Там где можно было передать один ID и запросом вытащить всю необходимую инфу, выполняется 30 маленьких запросов, где каждый вытаскивает кусочек информации. Например, методы getUserLastName, getUserFirstName, getUserBirthDate, getUserDocID, getDocSerialNumberById... чтобы собрать информацию о пользователе. В общем, нужно получить одобрение, доступ и тогда уже разбираться. Мне было интересно услышать мнение о целесообразности миграции вообще. Я услышал и убедился что большинство согласно с тем, что сама идея плохая. А то вдруг все переходят счастливо на постгрес и у всех производительность резко возрастает, а я буду отговаривать людей )) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 18:52 |
|
Миграция с Oracle на Postgres
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov...Ню-ню... прошу прощения. Вам тут просветления и открытия век никто не обещал. Но и Вам, вполне разумно, стоило бы оставить свое "ню" ровно там, откуда Вы его вытащили. Это может сберечь Вас от сопротивление отвечать человеку, который дает основания для сомнения в понимании смысла букв, которые он использует. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2016, 19:59 |
|
|
start [/forum/topic.php?fid=35&msg=39179261&tid=1552283]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
186ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 307ms |
0 / 0 |