Миграция Oracle -> PostgreSQL

Дайте съвет как да го направя най-безпроблемно?

Препоръчайте и някоя хубава книга (на български) за нормализиране на база данни.

според мен прехвърлянето на данни е най лесно ако закачиш таблиците в аксес през одбс
а за правене таблици може да ползваш някои reverse engineering tool

no pain, no gain

Викаш в акцеса с копи/пейст ще ги прехвърли за нула време... Мъка!

[линк]

на теб май ти стана хоби да пишеш фантазии

къв копи/пейст ти се привижда този път?

в аксес има sql с които от една таблица прехвърля в друга с 1-2 реда и 10-20 букви, маи имаше и вариант само с 2-3 цъквания с мишката...

айде пробвай понякога поне малко да мислиш преди да пишеш

no pain, no gain

Прехвърлянето на данните ти е най-малкия проблем.
ETL тулове колкото искаш...

Можеш да погледнеш orafce и/или ora2pg

Ако базата ти е малка (имам впредвид по отношение на обекти, пакети, процедури и функции) ядовете ти ще са по-малко. Ако обаче е голяма база и особено ако имаш апликейшън/и които са вързани за нея - ще бъде доста болезнено:-)

Без тест кейзове и пренаписване на PL/SQL процедурите и функциите както и BL-a и/или Data Layer-а на приложението няма да минеш. Доколкото знам в postgreSQL няма BLOB и CLOB datatypes, там всички е varchar/text...Абе мъката ще ти е правопорпорционална на големината на базата :-)

П.П. Няма да е лошо след тази миграция да споделиш какви проблеми си имал и как си ги решил. Ще бъде интересно и полезно за всички.

Предлагам ти да почнеш да спазваш съветите си, а именно да почнеш да мислиш принципно.

Как ще вържеш таблиците през ODBC при положение че той още няма таблици в Postgres-а, м? Човекът трябва да прехвърли първо схемата на базата, а това ще е болезнено най-малкото, щото между типовете данни няма 1:1 съответствие.

Данните са му втория проблем, особено с referential integrity-то, ама за тебе всичко е някакви си INSERT ... SELECT-и. Въпросът е в каква последователност трябва да се изпълнят, предлагам да ти прати DDL-а на теб да направиш топологическото сортиране на ръка. Deal?

[линк]

пак фантазии

Как ще вържеш таблиците през ODBC при положение че той още няма таблици в Postgres-а, м?
писах по долу как може да направи таблиците: "а за правене таблици може да ползваш някои reverse engineering tool", с него може да се направят и връзките между таблиците

живееш в някъв измислен свят и пишеш просто така колко да се намираш на работа, явно целта ти е да се правиш на интересен ама опитай поне да четеш преди да пишеш

и какво толкова има да се мисли за тази последователност? пробва една последователност ако не стане лесно може да пробва друга и все ще нагласи referential integrity, например може да сложи кода за referential integrity в отделен скрипт и да го пусне накрая като е прехвърлил данните

разбира се като има някои като теб дето хем не чете за какво става дума хем пробва да се прави на интересен работата става бай ганьовска: един прави нещо 10 му пречат

no pain, no gain

Има блобове в postgre-то, само дето са имплементирани малко шантаво. Иначе пренаписване, тестване, главоболия ще има. Според мен поне месец работа, а може и повече ако някой гений се е улисал в писане на stored proc.

Именно, престани да пречиш на човека с твоята некомпетентност.

[линк]

тва ли е най новата ти фантазия

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

все пак опитай да разбереш че му писах неща които в някои случай са добър избор



no pain, no gain

Аз не съм експерт нито по Oracle, нито по PostgreSQL, но аз бих направил следното:

Ако ти си човека, който работи върху програмата, която използва тези бази данни, предполагам че имаш data access layer в твоята програма - код, който да се свързва с DB server-а и да вкарва данните в обекти. В момента част от този код е написан само за Oracle. На теб така или иначе ще ти трябва такъв код за Postgres. Напиши първо него. После напиши друг код, който да може да копира от Oracle тип обект в Postreges обект. Едва ли ще е много голям или сложен миграционния код. После го изпълняваш. Това ще е перфектния тест за новите библиотеките за Postgres. Това е за данните. А таблиците, ако са под 30-40 примерно, аз лично на ръка бих пренаписал DDL кода. Не знам дали бих се доверил на продукт, освен ако не е някакъв скъп ETL продукт. Същото е положението и със stored procs.

Ако ти нямаш достъп до програмата и примерно искаш да смениш back end-а на твоята bug tracking system, тогава дай повече детайли.

Не си дал никакви подробности ..
По принцип анализираш схемата на старата база, правиш схемата на новата, в това се включват всякаквите евентуални тригери и СП и правиш скриптове за конвертиране, като по възможност си ползваш продуктивните дб библиотеки за тях .
Обикновено се оказва, че няма лесен и безболезнен начин - много зависи от размера на базата, колко чисто е имплементирана старата система и колко пъти е еволюирала - ако са повече от 1-2 хич не ти завиждам.
На мен поне досега не ми се е случвало да видя система, която е работила повече от година и на която data integrity-то да е повече от 70% ок. Без значение всички правила и нормални форми и не знам си какво - никога не се спазват до край :) Така че предвиди си сериозно време за тази задачка

По принцип има конвертиращи тулове, които улесняват докато се оглеждаш още, но са безполезни когато наистина трябва да се свърши работа, има и хубав текст в документацията на Postgre-то за портване на СП от Oracle.

С Oracle не съм бачкал, но с postgres ако имаш някакви проблеми - пиши детайли, ще го измислим

кротък крилат крококит кърка текила, тармъчка трепетно тревата

Това според мен е доста необмислен подход...

Пъво се портва базата и тогава се пренаписва дейта леъра.
В противен случай ще се наложи да го пренаписваш 2 пъри (DL-a) не заради друго, а защото ще ти се наложи след портването на базата да правиш и database tuning.

EnterpriseDB Migration Studio - пичовете да доста навътре в нещата
За четене: Packt миналия месец издадоха 2 много добри книги аз PostgreSQL 9

Това е положението - свиквай

Аз съм опитен програмист и моите съвети не са необмислени. Като човек с опит на lead developer, аз много пъти съм давал технически съвети и вярвам че те обикновено са разумни. Нека всеки да даде съвет в тази тема как той ги вижда нещата. Който пита за съвет може да се възползва, от която си иска идея.

Отделен въпрос е, че твоя коментар е просто объркващ. Като казах пренаписването на DDL, беше ясно, че влючвам и всички индекси. Ако някой индекс не работи добре в PostgreSQL, а е работил добре в Oracle, аз не вярам че има ETL програма, която да ти оправи този проблем. След миграцията си тестваш програмата за performance и ако има проблем, го оправяш. И най-важното - аз не споря с никого тук.

Колко си опитен бе пешо... Какво не разбра на аарона?

Как ще пренапишеш ДАЛ-а преди изобщо да си портнал схемата на съхранение? Ами ако постгре-то не позволява да консумираш същите неща? Ако се наложи да махнеш всички процедури (което е доста вероятно)?

Моля, обръщайте се със съвети директно към този, който е питал. Не се каня да споря с хора, които говорят несвързано:
1) един ми хвърля термина database tuning
2) друг ми обяснява какво е искал да каже първия, а именно, че е невъзможно да се напише data access layer без да имаш теблиците създадени в Postgres. ОК. не е вярно - нито това е вярно твъдение, нито има нещо общо с твърдението на първия. но аз не съм казвал да не се създадат таблиците първо.

Сериозно хора, не бих ви наел на работа в моята компания. Започнете да говорите свързано и последователно!

То, дейта лейъра, не е ли добре така да е написан, че да не се пипа при смяната на базите? Примерно, нещо, NHibernate / Entity Framework? Аз моите АСП.НЕТ MVC неща ги пиша само с IQueryable и после само сменям LINQ provider-а, ако се наложи. Не че не се налага да се фиксне нещо, но чак преписване на целия ДАЛ, малко нанагоре ми се струва.

И като стана дума за миграция - който в 2010 още пише PL/SQL - T-SQL или каквито и да е производни на stored procedures - наказанието му е да портне база данни от MongoDB към Clipper и dBase.

--
One day it will make sense.

Абе всеки се опитва да напише "перфектния" дейта леър дето да не се бара и пренаписва при миграция от една база на друга база, ама досега не съм видял някой да е успял (е, за много-малки приложения може и да успее).

Просто невъзможно е според мен да напишеш например голям LOB application без PL/SQL, T-SQL, PL/pgSQL и т.н. колкото и кавито и Data mapping tools да използваш.
Все пак базата си е допълнителен леър с нейната си "бизнес" логика...не става някакси всичко да е в DL-а...