Migracja systemowa bazy danych

Ewa Palarczyk

Oto stało się! Kierownictwo w ramach redukcji kosztów, zwiększenia
bezpieczeństwa lub innych, nie mniej ważnych powodów, zadecydowało o
wymianie infrastruktury informatycznej w firmie, a dokładniej o zastąpieniu
istniejącego serwera Linuksem. Być może jesteśmy takimi szczęśliwcami, że
sami możemy podejmować tego typu decyzje, wtedy należy po prostu zabrać się
do rzeczy i działać… Aby cała operacja odbyła się bezboleśnie i
sprawnie, musi przede wszystkim być dokładnie zaplanowana i przemyślana. Załóżmy,
że krytycznym z punktu widzenia naszej firmowej infrastruktury informatycznej będzie
przeniesienie na serwer linuksowy bazy danych klientów, z której korzystają
wszyscy pracownicy.

Pierwsza rzecz, o jaką musimy zadbać, to odpowiedni dobór
konfiguracji sprzętowej. Wszystko oczywiście zależy od wielu czynników, w
tym: potrzeb naszej firmy, ilości użytkowników, kosztów zakupu, instalacji i
utrzymania. Przykładowo, możemy zdecydować się na serwer z procesorami
Intela, które w połączeniu z Linuksem wydają się korzystne finansowo. Nie
tylko koszty utrzymania są w dłuższym okresie niższe, ale również koszt
początkowy serwera i urządzeń peryferyjnych (kontrolera SCSI, modemów, napędów
CDROM, streamera itd.), poza tym wybór sprzętu jest bardzo szeroki.

Wprawdzie obecnie kłopoty sprzętowe w Linuksie występują
coraz rzadziej, do niedawna jednak najczęstsze problemy pojawiały się z
modemami, kartami video i kontrolerami SCSI. W chwili obecnej – mówiąc krótko,
rynek linuksowy jest zbyt atrakcyjnym kąskiem dla producentów, aby mogli sobie
pozwolić na jego ignorowanie. Tym samym znakomita większość dostępnego
obecnie na rynku sprzętu posiada sterowniki zarówno dla Windows Linuksa, a także
innych systemów operacyjnych Oczywiście może się zdarzyć, że mając nowe
sterowniki będziemy mieć kłopot w sytuacji, gdy pracujemy na
„starym” systemie operacyjnym, a mówiąc precyzyjnie, na którejś
dawnej wersji jądra – nie będzie ono obsługiwało wtedy nowych urządzeń.
Druga sytuacja, to gdy mamy w jądrze wyłączoną obsługę danego typu urządzeń.
W pierwszym przypadku zaleca się pobranie nowej wersji jądra (stabilnej) i
– to już w obu sytuacjach – kompilację. W każdym razie kupując
nowy sprzęt, warto go sprawdzić w specyfikacji, a jeszcze pewniej w
Internecie, na stronach poświęconych urządzeniom pracującym pod Linuksem
– będziemy mieć wtedy pewność, że jeżeli dane urządzenia znajduje
się na takiej liście, to na pewno pod Linuksem działa. Zdarza się niestety,
że producent niekiedy deklaruje, że dany sprzęt pod Linuksem pracuje i
dopiero przy próbie instalacji dowiadujemy się, że owszem działa, ale np.
tylko wtedy gdy mamy odpowiednią wersję jądra 2.2.x (a w Internecie innych
czy nowszych sterowników nie ma); gdy powszechnie korzysta się już z wersji
2.4.x – wtedy ręczne poprawianie kodu (do którego na szczęście mamy
wgląd) jest jedyną szansą na uruchomienie danego urządzenia. A jednak wydając
pieniądze na sprzęt nie zawsze mamy ochotę poprawiać niedopatrzenia
producenta, nie zawsze też mamy do tego niezbędną wiedzę, dlatego aby nie
tracić niepotrzebnie nerwów, lepiej najpierw na listach urządzeń linuksowych
nabrać stuprocentowej pewności.

Jednym z możliwych rozwiązań jest zakup serwera z
preinstalowanym Linuksem. Niektórzy producenci taką możliwość oferują,
biorąc tym samym na siebie odpowiedzialność, że sprzęt będzie prawidłowo
pracował z systemem operacyjnym i usługami na nim uruchomionymi. Tego rozwiązania
jednak nie polecam – Linux, aby w pełni spełniał nasze wymagania i
gwarantował odpowiadający nam poziom bezpieczeństwa – powinien być
instalowany i konfigurowany samodzielnie. Jeszcze raz zachęcam do śledzenia na
bieżąco nowych pojawiających się stabilnych wersji jądra. Trudno oczekiwać,
żeby jądro 2.2.x obsługiwało Bluetooth (linuksowy Bluez), podczas gdy wersja
2.4.21 ma już wbudowaną obsługę tego standardu (wcześniejsze kernele 2.4
wymagają nałożenia łaty). Podobnie rzecz się ma z wszystkimi nowymi
technologiami, ponadto można powiedzieć, że każda nowa wersja jądra zwiększa
bezpieczeństwo i stabilność systemu, bo zawiera w sobie zabezpieczenia na
odkryte luki i błędy (przynajmniej na jakiś czas, nim znajdą się nowe).
Jednocześnie powinniśmy pamiętać o regularnym nakładaniu łat na kernel i
wszelkie inne oprogramowanie.

Mając dobrany odpowiednio sprzęt i wiedząc dokładnie
jakie zadania ma nasz system operacyjny spełniać, możemy przystąpić do
migracji naszej bazy na serwer linuksowy. Warto w jakiś sposób usystematyzować
swoje działania, aby były one jak najbardziej efektywne i sprawne i abyśmy
nie zostali czymś przykro zaskoczeni.

Wydaje się dobrym pomysłem, aby w pierwszym etapie zapoznać
się z Linuksem jako sieciowym systemem operacyjnym. Osoby, które dobrze znają
Linuksa mogą ten element pracy pominąć, warto jednak sobie pewne wiadomości
odświeżyć. Etap ten obejmuje instalację Linuksa na stacji podłączonej do
sieci. Jeżeli nie jesteśmy linuksowym guru, to na tym etapie należałoby się
zapoznać z możliwościami konfiguracji systemu, parametrami, poleceniami.
Ponieważ nowy system nie będzie działał w środowisku odosobnionym, jest to
również dobry punkt, żeby przetestować komunikację i współdziałanie
Linuksa z już obecnymi w danej firmie aplikacjami np. finansowo-księgowymi. Tu
warto zapoznać się z zasadami pracy Linuksa w sieci, zwłaszcza pracy
bezpiecznej, opartej o odpowiednie standardy bezpieczeństwa. Można na tym
etapie, znając już zależności i procedury, które będziemy w przyszłości
wykorzystywali, pokusić się o przygotowanie skryptów i programów automatyzujących
naszą pracę. Jest to również dobry moment na wyszukanie pomocniczych
aplikacji, które mogą nam być potrzebne. Ustawiamy uruchomienie całego
systemu pod kątem, czy zamierzamy pracować domyślnie w trybie tekstowym, czy
graficznym. W tym celu, aby sprawdzić wartość domyślnego uruchomienia
systemu, należy zajrzeć do pliku /etc/inittab, gdzie powinniśmy wybrać między
trybem tekstowym (poziom uruchomienia 3), a graficznym (poziom 5).

Kolejną rzeczą, której powinniśmy się na tym etapie
przyjrzeć, są poziomy uruchomień konkretnych usług. Usługi, które nie
uruchamiają się automatycznie, należy samodzielnie dodać do skryptów
startowych, na odpowiednim poziomie, najlepiej za pomocą dowiązań
symbolicznych (tzw. symlinków). Jeżeli nie mamy odpowiednich skryptów
startowych, lub chcemy zmodyfikować nieco proces uruchamiania aplikacji (np.
poprzedzić go dodatkowym testem), należy takie skrypty napisać, najprościej
jeśli będą to skrypty powłoki. Przykładowo, napisanie skryptu, który
informował wszystkich użytkowników o pojemności ich kont, będzie wyglądało
następująco:

vi skrypt_quota
   
     #! /bin/bash
   
     for i in 'cut -d :f1 /etc/passwd' ; do quota$i |mail
-s informacja$i; done

dla tak zapisanego skryptu, należy nadać mu prawo wykonalności,
w tym wypadku dla administratora:

chmod u+x skrypt_quota

Skrypt ten można uruchomić wpisując w linii poleceń

./skrypt_quota

lub dodać go do skryptów startowych, zakładając, że
chcemy taką wiadomość wysyłać do użytkowników po każdym uruchomieniu
systemu:

ln -s /home/skrypt_quota /etc/rc.d/rc3.d/S100
ln -s /home/skrypt_quota /etc/rc.d/rc3.d/K100

w przypadku zadań, które mają być wykonywane w
odpowiednich odstępach czasu (co akurat w przypadku powyższego skryptu wydaje
się bardziej zasadne) należy również stworzyć odpowiednie skrypty i umieścić
je do cron’a. Dodawanie nowych zadań wykonuje się za pomocą polecenia

crontab -e polecenie_lub_skrypt

lub poprzez dodanie odpowiedniej linii w pliku /etc/crontab.

Na tym etapie dostosowywania zadań systemu do naszych
potrzeb, należy również pomyśleć o zapewnieniu podstaw bezpieczeństwa
systemu. Świeżo zainstalowany Linux, podobnie zresztą Oracle, jest niezwykle
łakomym kąskiem dla hakerów i doskonale nadaje się na różnego rodzaju
ataki. Tematu bezpieczeństwa Linuksa nie wyczerpie się w jednym artykule i nie
taki jest mój cel, natomiast chciałabym wyszczególnić te aspekty
architektury systemu, o których trzeba koniecznie pamiętać, myśląc o jego
bezpieczeństwie:

  • bezpieczeństwo kont i haseł użytkowników,
  • bezpieczeństwo root’a,
  • zabezpieczenie bootloader’a (program LILO
    lub GRUB),
  • bezpieczeństwo systemu plików (ustawienia umask, dostęp
    do plików, sprawdzanie integralności plików (np. poprzez oprogramowanie
    Tripwire),
  • bezpieczeństwo jądra i opcje kompilacji zwiększającego
    bezpieczeństwo,
  • bezpieczeństwo sieci: gdzie tylko możliwe, zastąpienie
    protokołów nieszyfrowanych szyfrowanymi (np. ftp przez sftp, rsh przez ssh
    itd.),
  • konfiguracja firewall’a (dla jąder 2.4.x –
    iptables, dla serii 2.2.x – ipchains),
  • zabezpieczenie używanych usług sieciowych,
  • regularne tworzenie kopii zapasowych,
  • zabezpieczenie bazy Oracle,
  • regularne śledzenie i nakładanie łat na oprogramowanie
    i jądro,
  • monitorowanie logów systemowych i logów poszczególnych
    usług (/var/log/messages i przykładowo /…/apache/log). Pomocne w
    analizie podejrzanych wpisów jest oprogramowanie typu Logcheck,
  • bezpieczeństwo portów. Tutaj wymienię dwa programy, które
    w tej materii są niezwykle pomocne – Portsentry do monitorowania portów
    i nmap do sprawdzenia bezpieczeństwa naszego systemu.

Podstawową zasadą, jaką powinniśmy się kierować, to
uruchamianie tylko i wyłącznie tych usług, które są niezbędne, wszystkie
pozostałe – nieużywane konta użytkowników i aplikacje, stają się
potencjalną luką oprogramowania, dlatego też powinny zostać zlikwidowane.

Ponieważ nasz serwer nie ma być stacją wolnostojącą,
musimy się zająć konfiguracją sieci. Zwykle konfiguracja sieci dokonuje się
podczas procesu instalacji systemu. Jesteśmy pytani wtedy o adres IP serwera,
nazwę hosta, maskę podsieci (zwykle 255.255.255.0), adres sieci (zwykle adres
IP z ostatnią pozycją 0), adres broadcast (adres IP z ostatnią pozycją 255)
i domyślną bramę (adres IP bramy używanej w naszej sieci). Jeżeli z jakichś
powodów nie skonfigurowaliśmy sieci w trakcie instalacji, możemy to zrobić w
każdej chwili za pomocą polecenia ifconfig. W dystrybucji Red Hat pomocna jest
usługa netconfig. Po podaniu adresów sieciowych i maski podsieci, musimy
zdefiniować ruch pakietów w sieci, czyli określić tablicę routingu. Służy
do tego polecenie route. Przy konfiguracji sieci warto zwrócić uwagę na pliki
konfiguracyjne /etc/hosts, /etc/hosts.deny, /etc/hosts.allow.

Kolejnym krokiem, znając już środowisko, w jakim będziemy
pracować, jest zapoznanie się z warunkami instalacji i pracy bazy
oracle’owej na Linuksie. My zakładamy, że baza na dotychczasowym
serwerze spełniała nasze wymagania i była zoptymalizowana dla naszych
potrzeb, w tym punkcie zatem możemy się ograniczyć do zapoznania się ze
specyfiką baz oracle’owych na Linuksie oraz zasadach konfigurowania środowiska
pracy. O tych zagadnieniach pisałam w poprzednich artykułach (Oracle’owe
PLOUG’tki Nr 23, 24, 25 i 26).

Mając odpowiednio przygotowane środowisko pracy, możemy
przystąpić do instalacji bazy danych, a następnie towarzyszącego
oprogramowania Oracle i innych aplikacji, które do tej pory były świadczone
przez dotychczasowy serwer. Po tym etapie możemy przystąpić do niezwykle
istotnego etapu działania, a mianowicie do testowania utworzonej konfiguracji.
Należy sprawdzić, czy nie ma konfliktów o charakterze sprzętowym, aczkolwiek
jeżeli by takie były, najprawdopodobniej wystąpiłyby już podczas
instalacji. Następnie możemy przystąpić do kluczowej części naszego
zadania, mianowicie migracji bazy danych na nasz docelowy serwer. Celowo
proponuję wcześniejsze utworzenie bliźniaczej bazy i przestrzeni tabel, aby
zminimalizować ryzyko ewentualnych błędów podczas importu.

Przed przeniesieniem danych z bazy Oracle na nowy serwer,
musimy koniecznie pamiętać, aby przed przystąpieniem do migracji bazy wykonać
kompletną kopię bezpieczeństwa. Przeniesienia bazy można dokonać za pomocą
dwóch programów, stanowiących w zasadzie jedno narzędzie, mianowicie Oracle
Export i Import. Działanie programu Export polega na tym, że zapisuje on dane
z bazy Oracle do osobnych, zewnętrznych plików, natomiast Import czyta dane z
tych plików i wstawia jest do bazy oracle’owej. Program Export posiada
cztery poziomy funkcjonalności: tryb przestrzeni tabel (Tablespace mode), tryb
użytkownika (User mode), tryb tabeli (Table mode) oraz tryb pełny (Full mode).
Narzędzie to umożliwia nam przenoszenie danych między różnymi bazami Oracle,
nawet jeśli są one postawione na różnych platformach sprzętowych czy różnych
systemach operacyjnych – a o to przecież w naszym przypadku chodzi.

Mówiąc krótko, w trybie przestrzeni tabel eksportowi
poddawane są wszystkie obiekty, które znajdują się w podanych przestrzeniach
tabel, w tym definicje indeksów związanych z tymi elementami, nawet gdy należą
do innych przestrzeni tabel.

W trybie użytkownika eksportowane są obiekty użytkownika,
jak również zawiązane z nimi dane. Eksportowane są również wszystkie
uprawnienia i indeksy utworzone przez użytkownika na obiektach użytkownika. W
trybie tym nie są natomiast eksportowane uprawnienia i indeksy utworzone przez
użytkowników nie będących właścicielami danych obiektów.

W trybie tabeli eksportowana jest określona tabela.
Zapisywana jest tutaj struktura tabeli, indeksy oraz uprawnienia razem z danymi
lub bez danych tabeli. Tryb tabeli umożliwia również eksport pełnego zestawu
tabel należących do danego użytkownika (przez określenie właściciela
schematu, ale bez podania nazw tabel). Można również określić partycje
tabeli przeznaczone do wyeksportowania.

Tryb pełny, który wykorzystamy do migracji naszej bazy,
charakteryzuje się tym, iż następuje tu wyeksportowanie wszystkich plików
bazy danych. Odczytywany jest cały słownik danych, a skrypt DLL, konieczny do
odtworzenia pełnej bazy, zapisywany jest w wynikowym pliku eksportu. Plik ten
zawiera polecenia tworzenia wszystkich przestrzeni tabel, wszystkich użytkowników
oraz wszystkich obiektów, danych i uprawnień w ich schematach.

Proces eksportu możemy uruchomić interaktywnie z poziomu
narzędzia OEM lub przez pliki poleceń. Działanie programu Export wygląda w
ten sposób, że pobiera on definicje obiektów i dane z tabeli i zapamiętuje
je w postaci binarnego pliku eksportu. Następnie pliki eksportu można już
wykorzystać do przenoszenia danych w tym samym, bądź różnych systemach. Po
uruchomieniu narzędzia Export, obiekty (np. tabele) są pobierane z bazy razem
z zależnymi od nich obiektami (takimi, jak indeksy, komentarze, uprawnienia) i
zapisywane w pliku eksportu. Plik eksportu utworzony przez Oracle Export nie może
być przeczytany przez żadne inne narzędzie poza Oracle Import. Aby eksportować
swoje dane użytkownik musi posiadać przywilej CREATE SESSION, czyli możliwość
podłączenia się do bazy. Aby móc dodatkowo – a to będzie najpewniej w
naszym przypadku niezbędne – eksportować tabele innych użytkowników,
potrzebna jest również włączona rola EXP_FULL_DATABASE. Oracle Export
pracuje w trzech trybach, nas interesuje tryb eksportu pełnej bazy, w którym
eksportowane są wszystkie obiekty w bazie poza obiektami należącymi do użytkownika
SYS. Eksport tego rodzaju może być oczywiście wykonany przez
uprzywilejowanych użytkowników. Aby móc używać programu Oracle Export, należy
uruchomić wcześniej skrypty CATEXP.SQL lub CATALOG.SQL. Do uruchomienia powyższych
skryptów można użyć następującego polecenia:

exp80 uzytkownik/haslo parfile=plik_parametrow.dat

Opcja parfile wskazuje nam plik przechowujący parametry
eksportu, do ważniejszych parametrów eksportu należą:

  • FULL=Y – określa, że wyeksportowana zostanie cała
    baza,
  • FILE=DBA.DMP – wskazuje plik eksportu,
  • GRANTS=Y – określa, że zostaną wyeksportowane
    uprawnienia nadane na eksportowanej tabeli,
  • INDEXES=Y.

Nasze polecenie eksportu całej bazy będzie wyglądało następująco:

exp system/manager parfile=params.dat

gdzie params.dat wygląda zawierał będzie poniższe wpisy:

FILE=dba.dmp

GRANTS=y

FULL=y

ROWS=y

Można również podać parametry w linii poleceń lub określić
plik parametrów eksportu z dodatkowymi parametrami w linii poleceń. Parametry
podane w linii poleceń nadpiszą wartości z pliku parametrów.

Podczas procesu zapisywania danych eksportowanej bazy do
pliku wynikowego, poszczególne tabele odczytywane są przez program Export
kolejno (pojedynczo). Oznacza to, iż tabele odczytywane są w różnym czasie,
chociaż program rozpoczął działanie w określonym momencie. Eksportowane są
te dane, które istnieją w danej tabeli w chwili rozpoczęcia pracy przez
Export. Ponieważ większość tabel jest związana z innymi tabelami,
modyfikowanie danych podczas procesu eksportu może prowadzić do eksportowania
niespójnych danych. Aby uniknąć problemu niespójności, należy zaplanować
eksporty danych w czasie, gdy nikt nie modyfikuje zawartości tabel. Jeżeli to
możliwe, można zastosować klauzulę strtup restrict, co zapewni, że tylko
administratorzy bazy będą zalogowani podczas trwania eksportu. Drugim rozwiązaniem
zapewniającym spójność danych, jest użycie parametru consistent (eksport spójny).
Oznacza to, że Oracle będzie dążył do utworzenia takiej wersji poddawanych
procesowi danych, która będzie nadawała się do odczytu i będzie zawierała
ich obraz z chwili, gdy rozpoczęto procedurę. Jeśli baza nie będzie w stanie
powtórzyć tego procesu, wygeneruje komunikat snapshot too old. Aby
takiej sytuacji zapobiegać, warto utworzyć duże segmenty, do których będzie
się odwoływał program. Oracle zapisuje dane usuwając poprzednie wpisy bez
uwzględniania ustawienia consistent=y.

Gwarancją spójności eksportowanych danych jest
przeprowadzenie eksportu, kiedy baza jest nieużywana lub ustawiona w trybie
ograniczonego eksportowania. Takie rozwiązanie wydaje się najpewniejsze w
naszym przypadku – przenoszenia danych z całej bazy. Jeżeli nie ma możliwości
takiego ustawienia, należy w trakcie przeprowadzanego eksportu ograniczyć działalność
bazy do niezbędnego minimum i przeprowadzić go z parametrem consistent=y.

Alternatywnie możemy utworzyć dwa pliki parametrów
eksportu. W jednym z nich zapamiętane zostaną nazwy większości tabel
zawierających się w bazie lub w schemacie. Plik ten może zostać wykorzystany
przy pierwszym eksporcie z parametrem consistent domyślnie ustawionym na
„n”. Drugi plik zawierający nazwy tabel, których spójność musi
zostać zachowana, zostanie wykorzystany przy eksporcie z parametrem consistent=y.
Dzięki zastosowaniu tej metody, rozmiary segmentów wycofania nie będą musiały
być szczególnie duże, a wydajność systemu nie zostanie zbytnio nadwerężona.

Mając zainstalowaną bazę oracle’ową na docelowym
serwerze i połączone oba serwery (z bazą źródłową i docelową) w taki
sposób, aby serwer linuksowy miał podmontowany dysk (partycję), na którym
znajduje się wyeksportowany plik dba.dmp, możemy przystąpić do importu.
Program Import czyta wyłącznie pliki stworzone przez Export. Wydobywa z pliku
eksportu obiekty i wstawia je do bazy. Przy imporcie tabel pobierane są
kolejno: definicje tabel, dane, indeksy oraz więzy integralności i wyzwalacze.
Oznacza to, że najpierw tworzona jest tabela, a następnie wstawiane są do
niej dane, budowane indeksy, importowane wyzwalacze i włączane więzy
integralności. Program Import pracuje w trzech trybach, przy czym nas
interesuje import pełnej bazy, gdzie pobrane zostaną wszystkie obiekty z pliku
eksportu. Aby wywołać import w tym trybie należy uprzednio włączyć rolę
IMP_FULL_DATABASE.

Aby uruchomić import musimy mieć uruchomione skrypty
CATEXP.SQL lub CATALOG.SQL. Zasada działania programu Import jest podobna do
Oracle Export. Składnia polecenia uruchamiającego Import wygląda w naszym
przypadku następująco:

imp system/manager parfile=params.dat

gdzie parfile wskazuje plik zawierający parametry importu.
Analogicznie jak w składni polecenia eksportu, alternatywnie możemy określić
parametry importu w linii poleceń lub połączyć oba rozwiązania, to jest
określić plik parametrów i dodatkowo podać parametry w linii poleceń.
Parametr w linii poleceń mają wyższą wagę od tych w pliku parametrów. Należy
pamiętać, że niektóre parametry importu są ze sobą sprzeczne, co może być
potencjalną przyczyną błędów powodowanych niespójnymi instrukcjami
importu. Rzeczą, na którą powinno się zwrócić uwagę, są ustawienia
parametrów buffer i commit. Commit wskazuje, czy proces
importu będzie zatwierdzany po przetworzeniu każdej tablicy bufora danych (jej
rozmiar ustawiany jest za pomocą parametru buffer). Ustawienie na N
(„nie”) spowoduje konieczność potwierdzania po każdorazowym
przetworzeniu tablicy bufora danych. Dla dużych tabel ustawienie commit=N
spowoduje konieczność zapewnienia segmentów wycofania o rozmiarze zapewniającym
obsługę tych tabel. Jeśli nie sprecyzujemy parametru buffer, jego
wartość będzie zależna od systemu operacyjnego. Innymi słowy, nie ustawiając
tych parametrów, domyślnie baza wydaje polecenie potwierdzenia commit
po zakończeniu importu każdej tabeli. Tym samym, jeśli mamy przykładowo w
bazie tabelę wielkości 400 MB, segmenty wycofania muszą posiadać rozmiar umożliwiający
pomieszczenie wpisów segmentu wycofania co najmniej tej wielkości. Wydaje się
to zbędnym obciążeniem segmentów wycofania. Aby zmniejszyć to obciążenie,
należy nadać parametrowi commit wartość Y („tak”) razem z
wartością buffer, np.:

imp system/manager file=dba.dmp buffer=64000 commit=y

Wielkość parametru buffer powinniśmy tak dobierać,
aby był on wystarczająco duży do obsłużenia największego importowanego
wiersza. W tabelach o zadeklarowanych typach danych LONG i LOB, parametr ten może
mieć wartość ponad 64kB. Jeśli nie znamy długości największego spośród
eksportowanych wierszy, należy oszacować jego przybliżoną wartość. Jeżeli
program Import zwróci błąd IMP-00020, będzie to oznaczało, iż badaliśmy
zbyt niską wartość parametru buffer. Wystarczy wtedy ją zwiększyć i
ponownie przeprowadzić import. W tabelach zawierających kolumny BFILE, LONG,
LOB, REF i UROWID wiersze wstawiane są indywidualnie. Wartość parametru buffer
nie musi dzięki temu uwzględniać rozmiaru wiersza z danymi typu LONG i LOB,
ponieważ Import, w przypadku takiej potrzeby, dąży do zaalokowania dla nich
dodatkowego obszaru.

Dodatkowo commit jest wykonywane dla każdej tablicy buffer,
co oznacza, że import tabeli może się nie powieść, gdy niektóre wiersze będą
już zaimportowane i potwierdzone poleceniem commit. Wtedy częściowo załadowane
dane będą wykorzystane albo usunięte przed ponownym uruchomieniem programu
Import. Jeżeli w naszej docelowej bazie chcemy dokonać modyfikacji np. w
przestrzeni tabel, możemy stworzyć tabelę z odpowiednimi parametrami jeszcze
przed importem danych. Problemy mogą pojawić się przy przenoszeniu więzów
integralności, które – jeśli nie określimy tego inaczej – są
pobierane dopiero po imporcie wszystkich tabel. Zapobiega to występowaniu błędów
spowodowanych np. błędnymi odwołaniami kluczy obcych do tabel, które nie
zostały jeszcze zaimportowane. Niestety błędy mogą wystąpić, jeżeli
utworzyliśmy wcześniej tabele i do nich ładujemy dane. Wydaje się, że
najlepszym rozwiązaniem jest wyłączenie więzów integralności przed
importem do istniejących tabel.

Oczywiście musimy pamiętać również, aby zaznaczyć
parametr rows=Y, który wskazuje, czy importowane będą wiersze danych. Jeśli
parametr ten byłby ustawiony na N („nie”), to wykonane zostałyby
jedynie polecenia DDL, dotyczące obiektów bazy. Poza tym parametr rows
umożliwia ponowne utworzenie samej struktury bazy, bez danych tabel. Jest to możliwe
nawet w sytuacji, gdy dane zostały wyeksportowane. Oprócz tego możemy
wykorzystać parametr rows w odtwarzaniu obiektów, które nie zostały
utworzone przy pierwszej próbie importu. Wielokrotne operacje importu
przeprowadza się niekiedy z powodu potrzeby zachowania określonej kolejności,
w jakiej dane obiekty są eksportowane i importowane. Podczas drugiego
importowania musimy dodać parametr ignore=y, aby proces importu nie został
zatrzymany ze względu na to, że importowane tabele już istnieją. Włączenie
opcji ignore spowoduje, że zaimportowane zostaną jedynie te obiekty, które
nie istnieją w tworzonym schemacie, natomiast obiekty poprawnie utworzone
podczas pierwszej operacji importu zostaną pominięte. Niekiedy w celu udanego
utworzenia obiektów bazy, będziemy musieli dokonać wielu operacji importu
przy ustawieniu parametru rows=n.

Ważne, abyśmy w podczas importu mieli zdefiniowany parametr
FULL=Y, aby pobrać wszystkie obiekty, w tym profile, publiczne łącza do baz,
publiczne synonimy, role, definicje segmentów wycofania, systemowe ustawienia
obserwacji, uprawnienia systemowe, definicje przestrzeni tabel, kwoty na
przestrzeniach tabel, definicje użytkowników, aliasy katalogów. Pozostałe
importowane komponenty to:

  • statystyki klastra gromadzone przez polecenie ANALYZE,
    przechowywane w katalogu danych,
  • kontekst aplikacji, który ułatwia implementację
    kontroli dostępu. Pozwala stosować zasady bezpieczeństwa z odpowiednimi
    funkcjami, a następnie powiązać je z aplikacjami. Każda aplikacja może
    posiadać swój własny kontekst. Użytkownicy nie mogą arbitralnie zmieniać
    swojego kontekstu (np. przez SQL*Plus). Kontekst aplikacji umożliwia
    elastyczną, opartą na parametrach kontrolę dostępu,
  • domyślne role – nowo utworzony użytkownik ma
    ustawioną domyślną rolę na wartość ALL, co powoduje, że wszystkie
    następnie nadawane użytkownikowi role będą rolami domyślnymi. Do zmiany
    ról domyślnych wykorzystywane jest polecenie ALTER USER,
  • alias katalogu – „DIRECTORY” jest w
    Oracle aliasem do fizycznego katalogu systemu operacyjnego. Dla kolumn typu
    BFILE Oracle nie eksportuje/replikuje zawartości BFILE. Programy Export i
    Import propagują jedynie nazwy plików i aliasy katalogu, do których
    odnoszą się kolumny BFILE. Co więcej, Oracle nie sprawdza, ani nie
    modyfikuje aliasu katalogu w oparciu o lokalizację tablicy po imporcie.
    Oznacza to, że musimy samodzielnie tak zmodyfikować odwołania do katalogu
    i plików, aby odwoływały się do ich rzeczywistego położenia.
    Najprawdopodobniej będzie to oznaczało również samodzielne skopiowanie
    pewnych plików, do których odwołują się pola BFILE,
  • historia haseł potrzebna przy zmianie hasła, aby
    kontrolować próby ponownego wykorzystania już używanego hasła. W
    przypadku Oracle8 hasła wygasają lub konta mogą zostać zablokowane po
    zbyt wielu nieudanych próbach zalogowania.

W momencie importu definicji użytkowników, użytkownicy są
tworzeni przy pomocy polecenia SQL CREATE USER i tym samym nie dostają
automatycznie przywileju CREATE SESSION. Podczas eksportu/importu powinniśmy
pamiętać o odpowiednim zdefiniowaniu zmiennej środowiskowej NLS_LANG, aby
przy przenoszeniu bazy nie wystąpiły błędy z kodowaniem znaków.

Przeniesienie bazy wymaga dokładnego przetestowania, czy
wszystko działa jak należy i czy absolutnie wszystkie elementy bazy zostały
przeniesione. Po dokładnym sprawdzeniu poprawności działania bazy, możemy
przystąpić do ostatniego kroku, mianowicie zastąpienia dotychczasowego
serwera serwerem linuksowym i dokonania ostatecznego testu w „żywym”
środowisku przez użytkowników. Teraz jeżeli wszystko działa, możemy
otworzyć butelkę szampana…

Niestety, na temat migracji tej samej bazy między różnymi
systemami operacyjnymi nie znajdziemy wiele literatury. O ile kwestia
przenoszenia danych między różnymi bazami (z bazy X do Oracle), jest omawiana
bardzo szeroko i dokładnie, o tyle na temat „podmiany” systemu
operacyjnego pod bazą nie znajdziemy w zasadzie nic wartego uwagi np. w
internetowym serwisie technicznym Oracle Technology Network. Jest to fakt o tyle
zaskakujący, że informacje na temat Linuksa pojawiają się w centralnych
miejscach oracle’owych stron internetowych i temat ten przewija się przy
każdej możliwej okazji. Sytuacja wydaje się trochę dziwna – oto jest,
można powiedzieć, sztandarowy nowy projekt Oracle, w postaci Linuksa. Produkt
zachwalany jest na wszelkie możliwe strony, zachęca się do przejścia na ten
system operacyjny popierając to różnorakimi testami porównawczymi, wydajnościowymi
i wszystko pięknie, tylko nikt nie mówi jak to zrobić. A sytuacja migracji
bazy między systemami operacyjnymi chyba nie jest aż tak oczywista, żeby
pomijać ją zupełnym milczeniem. Jak rozumiem, strategia marketingowa Oracle
sprowadza się w dużej mierze do tego, aby zachęcić użytkowników i
administratorów baz do zmiany środowiska pracy, mówiąc innymi słowy, zwiększyć
liczbę użytkowników Linuksa kosztem użytkowników innych systemów
operacyjnych. Dość mało prawdopodobna wydaje się sytuacja, że chodzi
jedynie o pozyskanie nowych użytkowników, stąd kwestia przeniesienia bazy
powinna być typowa dla tej grupy szczęśliwców, którzy postanowili zaliczyć
się do „Linux users”. Dlaczego zatem tak powszechny problem
pomijany jest milczeniem? Mam nadzieję, że jest to wynik niedopatrzenia ze
strony twórców dokumentacji oracle’owej i że luka ta zostanie szybko
zapełniona. Póki co, oby ten artykuł rzucił troszkę światła na
zagadnienie migracji bazy w układzie system źródłowy – dowolny, system
docelowy – Linux.

Literatura:

  1. zasoby Internetu
  2. dokumentacja Linuksa
  3. Proffessional Linux Deployment, G. Prasad, G. Sherlock,
    M. Boerner, M. Wilcox
  4. Oracle9i. Podręcznik administratora baz danych, K. Looney,
    M. Theriault, Helion, 2003
  5. Oracle8i. Podręcznik administratora baz danych, K. Loney,
    M. Theriault, Helion, 2002