Oracle Data Pump – przygotowanie środowiska developerskiego – przykład


Ave 🙂

Jak większość osób wie baza danych Oracle ma świetnie narzędzie do eksportu i importu danych – Data Pump (expdp oraz impdp), które zastąpiło stare narzędzia exp i imp. Umożliwia ono w szybki i stosunkowo łatwy sposób przenoszenie struktur oraz danych pomiędzy instancjami. Postaram się podać krótki przykład zastosowania tego tool’a.

Załóżmy, że mamy środowisko testów oprogramowania na „górkach programowych”, które służy do ostatecznych testów developerskich – zatem zawiera mnóstwo danych – oczywiście w zależności jak wytrwale programiści testowali to co wyszło spod ich palców. Oprogramowanie w najwyższych wersjach determinuje również najwyższą strukturę obiektów w bazie danych. Przypuśćmy, że programista ma do przetestowania moduł, którego oprogramowanie zahacza o podstawy testowanego systemu zatem najlepiej aby kompilacja i testy były przeprowadzone na własnym środowisku zanim trafią na środowisko testów ostatecznych – najnormalniej w świecie jak coś pójdzie nie tak to nie będzie przestoju w pracy środowiska. Wiadomo również, że nie zawsze środowiska developerskie są aktualne – programiści mają tendencje do aktualizowania tylko swoich obiektów, na których pracują.

W każdym razie  jeżeli mamy nieaktualną strukturę bazy danych, a nie chcemy kopiować w całości środowiska wraz ze wszystkimi danymi, które nie są potrzebne – chociażby ze względu na zasoby jakie by zajmowało – zatem niezbędne będą następujące komponenty:

  • Struktury wszystkich obiektów naszego schematu
  •  Tabele parametryczne dla naszej aplikacji

Teraz pokrótce jak wygląda struktura naszej bazy. Mamy użytkownika o nazwie user i dane, które znajdują się w schemacie o takiej samej nazwie jak nazwa użytkownika. Nasza aplikacja składa się z 2 modułów.  Tabele do modułów mają prefiksy MOD1 oraz MOD2. Podstawowe tabele parametryczne aplikacji nie mają prefiksu np. PARAMETRY, PRACOWNICY, nazwy tabel parametrycznych dotyczących poszczególnych modułów mają prefiksy zgodne z nazwami modułów + _PA_ np. MOD1_PA_% dla modułu o nazwie MOD1. Gdy następują zmiany w tabelach parametrycznych modułów wykonywany jest zapis w tabeli historycznej o tej samej nazwie z sufiksem _HP.

W  tym przypadku baza danych (w wersji 11g dla ścisłości) przechowuje datafile’e na filesystemie ale gdyby to był ASM zasada działania będzie podobna. Instancje startowane są z użytkownika oracle. Posiadamy 2 instancje o nazwach stefan1 i stefan2 znajdujące się na tym samym serwerze. Instancja stefan1 jest instancją wzorcową, stefan2 jest instancją z której będzie korzystał nasz developer, i właśnie tą będziemy aktualizować. Każda z nich ma takie same tablespace’y (w przypadku gdyby brakowało jakiegoś tablespace’u na stefan2 należy taki założyć, a te które istnieją najlepiej byłoby zmniejszyć). Na instancji stefan2 wycięliśmy wszystkie dane kasując kaskadowo użytkownika user i zakładając go ponownie, Zatem przystępujemy do przenoszenia danych:

  1. Musimy utworzyć katalog na obu instancjach wskazujący na ten sam katalog (katalog w systemie musi istnieć i mieć odpowiednie uprawnienia tak aby użytkownik oracle miał do niego dostęp i mógł tam zapisywać. Poniżej przykład utworzenia katalogu:

    create directory BACKUP as ‚/home/oracle/BACKUP’;

  2. Nadajemy uprawnienia do odczytu i zapisu dla użytkownika user:

    grant read, write on directory BACKUP to user;

  3. Eksportujemy obiekty schematu user z opcją content=metadata_only czyli bez danych

    expdp user/user@stefan1 directory=BACKUP schemas=user \
    dumpfile=metadata_only.dmp logfile=metadata_only.txt \
    content=metadata_only

  4. Eksportujemy tabele parametryczne wraz z danymi dla modułów z wyłączeniem tabel historycznych z zapisem zmian o sufiksie _HP czyli dla przykładu pominie tabele MOD1_PA%_HP oraz MOD2_PA%_HP

    expdp user/user@stefan1 directory=BACKUP \
    tables=MOD1_PA%,MOD2_PA% exclude=TABLE:\”LIKE \’%_HP\’\” \
    dumpfile=par_mod.dmp logfile=par_mod.txt

  5. Eksportujemy pozostałe tabele parametryczne wraz z danymi ale wyłączamy z eksportu wszystkie tabele użytkownika user, których nazwy zawierają prefiksy modułów aplikacji MOD1 i MOD2

    expdp user/user@stefan1 directory=BACKUP \
    tables=% exclude=TABLE:\” in \(select table_name from all_tables where owner=\’USER\’ and \(table_name LIKE \’MOD1%\’ or table_name LIKE \’MOD2%\’\)\)\” \
    dumpfile=parametry.dmp logfile=parametry.txt

  6. Importujemy dane zawierające metadata. Używamy dyrektywy transform=storage:n, która determinuje, że w czasie tworzenia obiektu pomijana jest klauzula storage czyli nie alokuje zasobów zgodnie z tym co zostało wyeksportowane ze stefan1:

    impdp user/user@stefan2 directory=BACKUP dumpfile=metadata_only.dmp \
    logfile=metadata_in_only.txt transform=storage:n

  7. Następnie importujemy tabele parametryczne tym razem używając dyrektywy table_exists_action=REPLACE – ze względu na to, że tabele istnieją ponieważ zostały założone przy imporcie danych w punkcie 6:

    impdp user/user@stefan2 directory=BACKUP dumpfile=par_in_mod.dmp \
    logfile=par_in_mod.txt transform=storage:n table_exists_action=REPLACE

    impdp user/user@stefan2 directory=BACKUP dumpfile=parametry_in.dmp \
    logfile=parametry_in.txt transform=storage:n table_exists_action=REPLACE

Dane są gotowe. To jest przykład wykorzystania Data Pump. Oczywiście narzędzie jest bardziej rozbudowane i najlepiej sięgnąć do manuala aby poznać więcej opcji, być może jak znajdę jeszcze chwilę to poprowadzę bardziej szczegółowy wywód a propos narzędzia wgłębiając się bardziej w poszczególne parametry 🙂

 

 

 

 

 

 

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *