Изпечатай

[romeo_ninov]

....
2.Това което ползва Оракъл ДБА е expdp CONTENT=METADATA_ONLY  и след това impdp SQLFILE.

DP изисква достъп до host-а ...
Освен това, с metadata_only, разбира се, няма да може да импортира данните.

Не, не иска, последния sqldeveloper (бетата) го може от работна станция. И предлага доста богат избор от опции само схема, само данни, и двете, избрани обекти и т.н.

[radoulov]

Мисля, че dump file-а се създава само на database server-а ...
Знам, че DP може да се конфигурира и стартира от SQL Developer.

Може да има и нови възможности, които не познавам.

[victim70]

impdb/expdb Го няма като част от Instantclient basic. Пробвах да кача оракъл като инсталация, обаче сменя променливи на обкръжението, и когато го имам качен и работещ не ми дава да се свържа към мрежата и активните директории или LDAP вече незнам от къде взема всички права и достъпи ме реже. В този случай мога да дъмпа но не ме допуска до услугата, не мога да се логна никъде.
sqldeveloper работи частично заради несъвместимост със java. Дразнещото е че на малки експорти на малките схеми работи, парсват се и се импортват без проблеми на постгре-то. На големият експорт запълва паметта суапа и се троши с грешки в java след 2-3 часа работа. Описанието го има и то е стара версия на Java. А като опитам да подновя java пак ми реже достъпа до фирмените услуги. Иначе за моят случай е супер тулче като да пробвам дадено нещо дали работи. Но е по-бавен от директният селект от метадатата.

Точно DDL-a ми трябва на всички записани функции и процедури, изгледи, тригери, таблици и данните в тях, броячи, линкове към други инстанции (това май не ми трябваше, но не съм сигурен).
Като ги селектна прави дъмп от 12-15 гигабайта, обаче парсера след това не харесва нещо към 60000 ред, а с vim редакторa немога да го отворя в разумно време за да видя какво не му харесва. Опитах и след 2 часа го прекъснах. Определено това е за сега един от начините, стига да разбера какво става и какво не харесва транслатора.

Утре ще пробвам да пусна нат на единят сървер, и на моят компютър да сложа оръкъл, дано се излъже домейн контролера.

Друг вариянт е ако някой знае как се лъже домейн контролер че всичко е такова каквото трябва да е. Или да крадна нет от входната оптика и да си влезна през VPN-a само тогава не се проверява компютъра и има достъп.

Цялата тази гимнастика стана за 4 часа преди 2 месеца с прост expdp или беше exp и парсване на изхода му през мигриращият скрипт.

И за 12к евро тези дето осигуряват миграцията можеха да си напънат з...... да напишат и източвачката на сорса. И без това миграциите са ограничени от оръкал само към постгре, а от другите бази имат поне по 3-5 алтернативи.

[radoulov]

Това, което се опитваш да направиш, не е банално - миграция от Oracle към PostgreSQL.
Можеш да опиташ на части:

1. Първо export само на мета-данни: ddl за PL/SQL (packages, procedures, functions ...), tables, indexes, triggers, sequences - без данни!
    Така няма да имаш проблеми с размера на export file-а.
2. Подреди по големина таблиците и започни да ги export-ваш една по една (първо най-големите, после по-малките заедно).
    Имай предвид, че ако имаш големи таблици (> 1G) , може да се наложи да използваш друг tool (ne SQL Developer).

[radoulov]

По-важният въпрос е: защо трябва да използвате различни бази данни?
Не можете ли само Oracle или само PG да използвате?

[victim70]

Това, което се опитваш да направиш, не е банално - миграция от Oracle към PostgreSQL.
Можеш да опиташ на части:

1. Първо export само на мета-данни: ddl за PL/SQL (packages, procedures, functions ...), tables, indexes, triggers, sequences - без данни!
    Така няма да имаш проблеми с размера на export file-а.
2. Подреди по големина таблиците и започни да ги export-ваш една по една (първо най-големите, после по-малките заедно).
    Имай предвид, че ако имаш много големи таблици (> 1G) , може да се наложи да използваш друг tool (ne SQL Developer).

Мислих го но са над 100 само таблици а времето в което мога да го извърша е събота, неделя или между 22 и 6 часа през ноща, за да няма ъпдейти по време на миграцията. Тригери и изгледи и броячи са още толкова.
Дори да хвана подчинените ми, създаването трябва да е в последователност от релациите иначе няма начин да се транслира и експортне. А релациите при много таблици трудно се проследяват нищо че има детайлна документация. В смисъл последователността на създаване и пълнене на таблиците.
Таблиците са наистина огромни. Схемата е пусната преди 12 години на оракъл 7 сега сме на 11 с клъстър. В някои от таблиците на всяка секунда влизат по 2-3 записа. Включително престоя в тоалетната се записва в една от схемите, освен кой какво, колко, къде, кога, с коя доставка, с кой компонент точно от доставката е работил и т.н.т. Освен това има ЛОБ-ове с картинки на всеки изходящ продукт.
Колкото и да е голяма на сървера се експортва за 2-4 часа схемата (тя е без лоб-ове). А ресурса на сървера ми е неизвестен с VmWare е и работят на него 30-40 виртуални машини. Размера е на трикрилен гардероб с надстройка и UPS 30 kW трифазен каквото и да значи това.

Различни бази се използват заради лиценза. Едната е само подържаща (постгре) и се ползва в моментите когато на доставчика му спре тока или се прекъсне връзката между производство и офис. Спре ли проследимостта спира производството. Тука е моят дял от сговняването, защото синхронизацията обратната и превключването между оракъл и постгре и последващата синхронизация на броячи и записи съм ги правил на C. В програмата за синхронизация всички проячи съм ги наслагал INT вместо long long при което някой е превъртял и посстгрето не е с актуални стойности и не се знае кое е синхронизирано и кое не. Зависимостите вече са строшени и най лесният вариант е да се реимпортне

[romeo_ninov]

Мисля, че dump file-а се създава само на database server-а ...
Знам, че DP може да се конфигурира и стартира от SQL Developer.

Може да има и нови възможности, които не познавам.

Прав си, явно съм спал като съм писал горното, активира се от девелопера, но се записва на диска на сървъра

[victim70]

Стана със оракъл инсталиран + нат от един съвсем легално настроен сървер.
Експортна се за около 14 часа със exp. Преди това се наложи да дублирам схемата локално със sqldeveloper. exp expdp не искаха да тръгнат за отдалечената машина.
Всичко се конвертира без грешки за около 1 час, след това се предъвка от postgre за 5-6 часа.
Всичко тръгна с две думи.
Само ми е интересно защо експорта отне повече време отколкото импорта в някаква по 'несериозна' база данни.

[romeo_ninov]

Стана със оракъл инсталиран + нат от един съвсем легално настроен сървер.
Експортна се за около 14 часа със exp. Преди това се наложи да дублирам схемата локално със sqldeveloper. exp expdp не искаха да тръгнат за отдалечената машина.
Всичко се конвертира без грешки за около 1 час, след това се предъвка от postgre за 5-6 часа.
Всичко тръгна с две думи.
Само ми е интересно защо експорта отне повече време отколкото импорта в някаква по 'несериозна' база данни.

Констрейни, статистики, проверка за консистентност

[victim70]

Няколко таблици проверих всичко е наред. Тригерите броячите и функциите са ОК. Успява да синхронизира. Процедурите и функциите са 70% проверки и 30% работа.
Доверявам се на разработчика на схемата. До момента ако нещо не е наред - нищо не тръгва.