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

Откуда: loopback
Сообщений: 52917
Ребят не обижайтесь но вы в Оракле полные профаны. Энтерпрайзовые ораклы стоят
поверх ASM а это решение работает минуя ReadFileScatter() и тем более Windows.

По поводу SSD(flash based devices). Оракл умеет работать с ними по "другому" и для "других"
целей. Детальнее обзор можно почитать тут:

http://www.oracle.com/technetwork/articles/systems-hardware-architecture/oracle-db-smart-flash-cache-175588.pdf
25 фев 16, 18:44    [18864238]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
тролил ЧАЛа
Guest
Сергей Арсеньев
Хотя Oracle реально более тяговитый грузовик и сопровождать его легче, хотя и дороже.


Ога ,

мощьно тягает через дисковый ввод вывод темп то,
что у других спокойно помещается в оперативной памяти.

_PGA_MAX_SIZE
_SMM_PX_MAX_SIZE
_SMM_MAX_SIZE
25 фев 16, 19:06    [18864294]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Yo.!
Guest
Сергей Арсеньев
Что в случае SSD - деньги на ветер. А при наличии кеша ФС и переопределения порядка операций, даже у обычного винта вообще не сильно различается, что уж говорить про большой контроллер.
Да Oracle велик. Но и у него есть свои слабости. Это и УРА мы, наконец, сделали строки 32Kb!!!!

эх Сережа, именно эти архитектурные "слабости" и делают оракл #1. оракл ставят в банк, а постгрес с его строками в банк не поставят, потому что оракл с его строками вытянет нагрузку любого банка, а постгрес фиг. если ораклу нужно хранить строковые сочинения - есть CLOB, который от варчара не отличить.
полагаться на кеш ФС могут аутсайдеры, с примитивным оптимизатором. а вот оракловый оптимизатор учитывает сотни параметров, в том числе кол-во блоков таблицы в кеше. и никакой SSD долбеж одноблочным чтением не выправит, лишь несколько сократит отставание. даже на SSD один IOPs на 128 блоков будет в разы быстрее 128 IOPs по одному блоку.
25 фев 16, 20:15    [18864520]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Yo.!
Guest
mayton
Ребят не обижайтесь но вы в Оракле полные профаны. Энтерпрайзовые ораклы стоят
поверх ASM а это решение работает минуя ReadFileScatter() и тем более Windows.

в конце концов контроллер получит все тот же многоблочный запрос. которое API его сформирует совершенно не важно.
25 фев 16, 20:24    [18864567]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Ivan Durak
Alexander Ryndin
пропущено...
Если это OLTP, то там используются bind. т.е. полный парсинг исчезающе редкая операция. Если bind не используются, то разработчика на кол.

почитай чтоли - как раз бинд и не используется из-за приложения. А переписывать его лень.
Уха-хахаха
То что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARING
25 фев 16, 21:01    [18864667]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7669
Alexander Ryndin
То что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARING
Этот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет?
25 фев 16, 21:14    [18864710]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5944
Relic Hunter
Alexander Ryndin
То что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARING
Этот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет?
8i....
25 фев 16, 21:24    [18864758]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Relic Hunter
Alexander Ryndin
То что кто-то не использует bind ведь не делает парсер тормознутым. Ну и на крайняк есть CURSOR_SHARING
Этот костыль был придуман не сразу. в 10-ке кажется? Ну и решением быстрого парса не является, и опять отправляет запрос в кеш. А если его там нет?
При втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема?
25 фев 16, 21:31    [18864781]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Подпольщег
Guest
Аффтар, поверь, дешевле переписать прикладухи на бинд, нежели
сменить SQL, что есть нереальный геморрой, архитектура разная, многих фич нет в pg, но
есть в ora и наоборот, многие фичи не так как в ora работают, подводные камни в pg есть
не хуже оракловых и так далее. Обе базы сопоставимы, но у ora оптимизатор более
вылизан. Начните писать новую версию клиентов с биндов.
26 фев 16, 11:13    [18866232]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
PG может выиграть у Оракля. И MySQL с Firebird'ом могут выиграть у Оракля. И даже FoxPro с MS Access'ом могут.

В некоторых частных случаях.

Быть может, у топикстартера как раз такой частный случай. К примеру, приложение настолько кривое или администрование СУБД поставлено настолько убого, что даже переход на PG даст выигрыш по сравнению с текущей ситуацией. А мы об этом понятия не имеем.

А в общем случае, конечно, к переходу с Oracle (даже с SE) на PG в поисках повышения производительности и к приравниванию PG к Ораклю нельзя относиться серьёзно.
26 фев 16, 11:16    [18866250]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Подпольщег
Guest
И самое главное .
1)прикладухи под пж всё равно потом придётся переписывать.
2)Выигрыша в скорострельности это может и не дать.
3)Под pg нужно затачивать железо - требование к дискам и к памяти особые.
4)Под pg понадобится ОЧЕНЬ хороший linux сисадмин и железячник
26 фев 16, 11:18    [18866261]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Подпольщег
Guest
Victor Metelitsa
А в общем случае, конечно, к переходу с Oracle (даже с SE) на PG в поисках повышения производительности и к приравниванию PG к Ораклю нельзя относиться серьёзно.

Я могу гарантировать, что тупое перекладывание запросов на другой SQL совершенно точно
положит производительность в нуль. Неважно откуда куда идёт миграция.
Посмотрите на 1С
26 фев 16, 11:23    [18866302]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
тролил ЧАЛа
Guest
Подпольщег
4)Под pg понадобится ОЧЕНЬ хороший linux сисадмин и железячник



Если в бюджете сумму из строки
лицензионные платежи переместить в
строку ФОТ , то думаю,
что толпы хороших сисадминов
и железячников будут стоять в очереди в ОК.

.
26 фев 16, 11:46    [18866454]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 52917
Victor Metelitsa, автор также пишет
......Основной упор идет на то, что кривой оптимизатор запарывает всю производительность, приходится использовать кучи хинтов в запросах, а на постгресе этой проблемы быть не должно из-за более умного оптимизатора....


Помню я где-то читал что PG использует генетические алгоритмы для отбора наилучших планов.
Возможно это и есть так козырная карта о которой пишет т.н. "руководство".

Но даже в этом случае нужно какое-то моделирование. Ребят! В этой области (миграция с одной БД
на другую) практически нет экспертов которые скажут что тут будет +25% бенефита к примеру.
Это всё от очень-очень многого зависит. Всё надо пробовать. Макеты создавать. У оракла 5 видов партишионинга. Как это
замапить на PG без деградации перформанса? Никто не знает.

Как портировать PLSQL код? ХЗ. Ну вот тут что-то пишут http://www.postgresql.org/docs/7.3/static/plpgsql-porting.html
26 фев 16, 12:46    [18866878]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Yo.!
эх Сережа, именно эти архитектурные "слабости" и делают оракл #1. оракл ставят в банк, а постгрес с его строками в банк не поставят, потому что оракл с его строками вытянет нагрузку любого банка, а постгрес фиг.

Как показал пример Сбербанка - хороший банк и Oracle озадачить сможет. :)

Yo.!
если ораклу нужно хранить строковые сочинения - есть CLOB, который от варчара не отличить.

Увы и ах - отличить. Недавно разбирался с ошибкой, когда склеивание varchar с CLOB порой приводило к NULL в результате.

Yo.!
в том числе кол-во блоков таблицы в кеше. и никакой SSD долбеж одноблочным чтением не выправит,

Ну 128 запросов к контролеру пришедших за время позиционирования головки отработают не сильно медленнее 1 на всу дорожку.
С точки зрения SSD - прочитать 64 сектора в разнобой может в теории быть эффективнее, чем 128 махом. Но впрочем и чтобы добиться того, чтобы чтение лишнего нагрузило чрезмерно надо постараться.
26 фев 16, 13:01    [18866966]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Сергей Арсеньев
Member

Откуда:
Сообщений: 4118
Alexander Ryndin
При втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема?

В том, что на третьем бинде может оказаться, что план не оптимальный. :)
Статистика по сегодняшней партиции еще не собрана. И т.д. и т.п.
И в конце концов окажется что для высоконагруженного приложения с полным использованием железа все одно придем к необходимости ручной оптимизации высококлассным специалистом, а при небольшой нагрузке не видно разницы.

Но продвинутый оптимизатор - это шаг навстречу прогресса. Тут не поспоришь.
26 фев 16, 13:09    [18866996]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
Автор вбросил и скрылся :)
26 фев 16, 13:32    [18867136]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2112
Q.Tarantino
Автор вбросил и скрылся :)


Наверно поменял cursor_sharing на force и все взлетело.
26 фев 16, 14:15    [18867478]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Melkomyagkii_newbi
Member

Откуда: из прошлого
Сообщений: 2112
Сергей Арсеньев
Alexander Ryndin
При втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема?

В том, что на третьем бинде может оказаться, что план не оптимальный. :)


Тогда включатся в игру всякие adaptive cursor sharing, cardinality feedback и прочее. И может самопофиксится.
26 фев 16, 14:18    [18867498]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2496
Сергей Арсеньев, по поводу LOB
если объём больше 200 мегабайт - в pg случаются неприятности,
а на pg_conf мне сказали, что штатная LOB, которая не bytea/text
поддерживается только для совместимости и в дальнейшем
её хотят выпилить. В oracle с этим проблем меньше. Стало быть если прикладуха
реально использует эту киллер-фичу - у разрабов будет много яркого и интересного сексу.
26 фев 16, 14:18    [18867500]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Yo.!
Guest
Сергей Арсеньев
Как показал пример Сбербанка - хороший банк и Oracle озадачить сможет. :)

один пример из десятка миллионов банков не очень показателен. тем более на фоне падений континентов у мсскл.


Сергей Арсеньев
Увы и ах - отличить. Недавно разбирался с ошибкой, когда склеивание varchar с CLOB порой приводило к NULL в результате.

руки кривые, у меня я еще в 90х применял конкотенацию и substr. больше всего меня впечатлило тогда, что пхп как с варчаром работал, без всяких танцев с LOB объектами.

Сергей Арсеньев
Ну 128 запросов к контролеру пришедших за время позиционирования головки отработают не сильно медленнее 1 на всу дорожку.
С точки зрения SSD - прочитать 64 сектора в разнобой может в теории быть эффективнее, чем 128 махом. Но впрочем и чтобы добиться того, чтобы чтение лишнего нагрузило чрезмерно надо постараться.

к чему теоризировать, поставь DB_FILE_MULTIBLOCK_READ_COUNT=1 и посмотри сам.
26 фев 16, 14:21    [18867535]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
mayton
Member

Откуда: loopback
Сообщений: 52917
По поводу падений процессинга в Сбербанке.

Тема интересная. Я какое-то время за ней следил а потом каюсь... забил и дела были.
Разумеется Оракл тогда не ругал разве что ленивый. Но КМК причины подобных
аварий не простые. И одной инструкцией тут не отпишешся. Вобщем читаем
и вспоминаем как было.

Это-ли последняя ссылка на скруле? Прошу подтвердить кто вкурсе дел.

https://www.sql.ru/forum/953904/orakle-okazyvaetsya-vinovat
26 фев 16, 14:53    [18867745]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
Alexander Ryndin
Member

Откуда:
Сообщений: 4919
Блог
Сергей Арсеньев
Alexander Ryndin
При втором запуске запроса в shared pool уже будет дерево разбора и план запуска. В чем проблема?

В том, что на третьем бинде может оказаться, что план не оптимальный. :)
Статистика по сегодняшней партиции еще не собрана. И т.д. и т.п.
Мы про OLTP говорим. Там такого быть не может. Для OLAP-нагрузки, естественно, этого делать не надо, но для DWH время парсинга стремится к нулю по сравнению со временем выполнения запроса.
26 фев 16, 17:04    [18868717]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
daunito
Member

Откуда:
Сообщений: 645
Melkomyagkii_newbi
Q.Tarantino
Автор вбросил и скрылся :)


Наверно поменял cursor_sharing на force и все взлетело.

Да не, читаю по вечерам )
Все у них нормально с bind переменными. Все запросы хранятся в xml файлах. Все что может меняться в запросах оформлено параметрами, работает через JDBC. Чтобы разбираться, нужно получить одобрение. Пока пишем планы и чиним мелкие баги. После переписывания нескольких запросов сложилось впечатление, что вся проблема в кривом проектировании таблиц. Связи избыточны и неочевидны, нормализация местами сильно хромает. Администрирование насколько понял, тоже из разряда дать права пользователю, посмотреть кто заблокировал сессию. Еще слишком много запросов выполняется лишних. Там где можно было передать один ID и запросом вытащить всю необходимую инфу, выполняется 30 маленьких запросов, где каждый вытаскивает кусочек информации. Например, методы getUserLastName, getUserFirstName, getUserBirthDate, getUserDocID, getDocSerialNumberById... чтобы собрать информацию о пользователе. В общем, нужно получить одобрение, доступ и тогда уже разбираться. Мне было интересно услышать мнение о целесообразности миграции вообще. Я услышал и убедился что большинство согласно с тем, что сама идея плохая. А то вдруг все переходят счастливо на постгрес и у всех производительность резко возрастает, а я буду отговаривать людей ))
26 фев 16, 18:52    [18869131]     Ответить | Цитировать Сообщить модератору
 Re: Миграция с Oracle на Postgres  [new]
booby
Member

Откуда:
Сообщений: 2644
Dimitry Sibiryakov
...Ню-ню...

прошу прощения. Вам тут просветления и открытия век никто не обещал.
Но и Вам, вполне разумно, стоило бы оставить свое "ню" ровно там, откуда Вы его вытащили.

Это может сберечь Вас от сопротивление отвечать человеку, который дает основания для сомнения в понимании смысла букв, которые он использует.
26 фев 16, 19:59    [18869381]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить