Jeśli nie przygotujesz się należycie, wykonując eksport i import bazy danych, mogą pojawić się błędy. Cały proces będzie przez to skomplikowany i czasochłonny. Jak ich uniknąć ? Przejdź przez poniższą check listę a oszczędzisz mnóstwo czasu i nerwów.
Technika eksportu i importu bazy danych może być bardzo efektywnym sposobem do migracji bazy danych na inną platformę. Data Pump może działać zadziwiająco szybko i jest efektywnym narzędziem do przenoszenia danych pomiędzy platformami. W szczególność kiedy platformy różnią się w formacie zapisu danych – BigEndin, LitleEndian.
Przygotowanie do eksportu bazy danych.
- Przygotowując bazę danych do eksportu sprawdź takie rzeczy jak ilość obiektów INVALID, rozmiar danych, rozmiar plików redo, strona kodowa.
- Utwórz docelową bazę danych. Optymalnym sposobem tworzenia bazy danych jest wybór opcji “custom”. Tylko wtedy utworzysz bazę danych ze skryptów, w innych przypadkach jest to kopia wcześniej utworzonej bazy danych. Baza danych zawiera wtedy zbędne schematy oraz niepotrzebne opcje. Nowa baza powinna zawierać jak najmniej zbędnych komponentów.
- Pamiętaj o stronie kodowej. Jeśli migrujesz bazę danych bez zamiany strony kodowej, ustaw ją taką jak na źródle. Dzięki temu unikniesz wielu kłopotów po uruchomieniu aplikacji. Strona kodowa jest jedną z niewielu ustawień bazy danych, których nie można zmienić (przynajmniej w prosty i supportowany sposób). Zmiana strony kodowej wymaga również przygotowania aplikacji do jej obsługi.
- Przygotuj przestrzenie tabel. Import nie utworzy brakujących przestrzeni tabel, trzeba zadbać o to we własnym zakresie. Uwaga – sprawdź czy są wszystkie domyślne przestrzenie tabel użytkowników.
- Sprawdź, czy nie masz obiektów aplikacji w schemacie SYS lub SYSTEM. Te konta nie się eksportują i zdarza się, że znajdują się tam obiekty wykorzystywane przez aplikację. Nie powinno się tego robić, ale zdarzają się takie przypadki
- Sprawdź, czy działają linki bazodanowe. DB linki są przenoszone przez eksport/import, ale często wykorzystują definicję innych baz danych zapisanych w pliku tnsnames.ora. Przed importem warto sprawdzić, czy aliasy do innych baz danych zostały przeniesione i czy działają. Być może potrzebujesz dodatkowo otwarcie portów na firewallu. Niedziałający db_link może spowodować, że dużo obiektów będzie ze statusem INVALID oraz czas importu znacznie się wydłuży.
Właściwy proces – eksport i import.
- Po imporcie pamiętaj o przeniesieniu jobów. Masz w bazie joby bazodanowe zdefiniowane w schematach sys i system ? To po imporcie sprawdź, czy wszystkie ostały prawidłowo przeniesione.
- Przenieś zadania związane z backupem bazy danych. Jeśli baza jest objęta polityką kopii zapasowych, to trzeba przenieść ją na system docelowy.
- Jeśli wykonujesz eksport/import tylko wybranych użytkowników, nie zapomnij o wcześniejszym przeniesieniu profili oraz ról dla nich. W przeciwnym wypadku import zakończy się błędem.
- Na koniec najważniejsza zasada – jeśli ją pominiesz, to Twoja prawdopodobnie będziesz musiał powtórzyć całą operację. Postaraj się wykonać spójny eksport danych, czyli najlepiej przed całą operacją:
- Wykonaj restart bazy danych – jesli nie masz takiej możliwości, to sprawdź, czy nie ma dużych operacji, które modyfikują bazę.
- Zatrzymaj joby bazodanowe one również mogą zacząć modyfikować dane w trakcie importu.
- Włącz na bazie tryb restricted – wtedy tylko użytkownicy z uprawnieniami DBA mogą się zalogować. Eksport również, musi wykonać użytkownik z prawami DBA.
- Uruchom eksport z opcją flashback_time=systimestamp.
Ta lista pozwoli Ci uniknąć 90% problemów i jeśli przygotowujesz się do migracji tym sposobem, warto przez nią przejść. Zostanie 10% problemów do rozwiązania. Większość będzie wynikała ze specyfiki danych i aplikacji, więc jest duża szansa, że nie trafisz na żadne inne problemy.
