Archiwizowanie danych i odtwarzanie bazy danych po awarii (cz. 3)

W poprzednich dwóch artykułach zostały omówione struktury wykorzystywane do odtwarzania bazy danych i sposoby sporządzania kopii bezpieczeństwa. W tej części omówimy metody odtwarzania bazy danych po awarii nośników.

5. Metody odtwarzania bazy danych po awarii nośników

Ilość danych, jaką można odzyskać po awarii bazy danych (np. uszkodzenie dysku) jest zależna od zastosowanego sposobu archiwizacji.
Kopia bezpieczeństwa całej bazy danych sporządzona dla bazy pracującej w trybie NOARCHIVELOG umożliwia odzyskanie bazy danych z kopii archiwalnej (ang. restore) do stanu jaki był w momencie sporządzania tej kopii. Oznacza to, że wszystkie zmiany wprowadzone do bazy po sporządzeniu kopii są tracone.
Kopia bezpieczeństwa całej bazy danych sporządzona dla bazy pracującej w trybie ARCHIVELOG umożliwia odzyskanie bazy danych z kopii, a następnie odtworzenie danych na podstawie informacji zapisanych w zarchiwizowanych plikach dziennika powtórzeń. Jeżeli wszystkie pliki dziennika są dostępne, to zawartość bazy danych można odzyskać do momentu bezpośrednio poprzedzającego awarię.
Baza danych pracująca w trybie ARCHIVELOG może zostać odtworzona:

  • w pełni, tj. do momentu bezpośrednio poprzedzającego awarię – odtwarzanie pełne (ang. full recovery) lub
  • do określonego momentu w czasie – jest to tzw. odtwarzanie niepełne (ang. partial recovery).

Kopia bezpieczeństwa sporządzona za pomocą programu export umożliwia odtworzenie danych z momentu, w którym wykonano eksport bazy danych.
W kolejnych punktach zostaną omówione sposoby:

  • odtwarzania bazy danych z kopii bezpieczeństwa wykonanych dla bazy danych pracującej w trybie NOARCHIVELOG;
  • odtwarzania pełnego;
  • tworzenia pliku kontrolnego;
  • odtwarzania niepełnego;
  • odtwarzania bazy danych na podstawie pliku eksportu.

5.1. Odtwarzanie bazy danych w trybie NOARCHIVELOG

W przypadku gdy baza danych pracuje w trybie NOARCHIVELOG zniszczenie jakiegokolwiek pliku danych zwykle wiąże się ze stratą części danych. Możliwe są dwie procedury naprawienia bazy danych. Pierwsza polega na zastąpieniu aktualnych plików bazy danych pełną kopią archiwalną. Druga procedura polega na usunięciu uszkodzonej przestrzeni tabel i zastąpieniu jej nową.

5.1.1. Wczytanie pełnej kopii archiwalnej

Procedura odtwarzania jest w tym przypadku następująca:

  1. Zamknięcie bazy danych poleceniem shutdown lub shutdown abort.
  2. Wgranie wszystkich plików bazy danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca.
  3. Otwarcie bazy danych poleceniem startup.

5.1.2. Zastąpienie zniszczonej przestrzeni tabel nową przestrzenią

Opisany niżej sposób naprawienia bazy danych nie może być stosowany w przypadku uszkodzenia przestrzeni tabel SYSTEM i przestrzeni zawierającej aktywne segmenty wycofania.
Załóżmy, że przestrzeń tabel o nazwie LAB_DANE składa się z dwóch plików: labdane1.dbf i labdane2.dbf. W trakcie pracy bazy danych uszkodzeniu uległ plik danych o nazwie labdane2.dbf. Administrator zamknął więc bazę danych w trybie ABORT. Próba otwarcia bazy danych została zilustrowana poniżej.

SVRMGR> startup
ORACLE instance started
Total System Global Area 4504784 bytes
Fixed Size 35208 bytes
Variable Size 4051784 bytes
Database Buffers 409600 bytes
Redo Buffers 8192 bytes
Database mounted.  
ORA-01157: cannot identify data file 3 – file not found
ORA-01110: data file 2: ‚C:LABLABDANE2.DBF’

Wyświetlenie informacji o plikach danych daje rezultat przedstawiony niżej.

SVRMGR> select status, enabled, bytes, name from v$datafile;
STATUS ENABLED CHECKPOINT BYTES NAME
…………………… ………………………… ……………………….. …………………. …………………………………………
SYSTEM READ WRITE 4823 7340032 C:LABLABSYSTEM.DBF
ONLINE READ WRITE 4823 1048576 C:LABLABDANE1.DBF
ONLINE READ WRITE 4823 0 C:LABLABDANE2.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABTEMP.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABRBS.DBF

Procedura odtwarzania bazy danych jest w tym przypadku następująca:

1. Wyłączenie uszkodzonego pliku.
Jeżeli baza danych pracuje w trybie NORACHIVELOG, to plik można wyłączyć jedynie stosując polecenie z klauzulą offline drop.

VRMGR> alter database datafile ‚C:LABLABDANE2.DBF’
    2> offline drop;
Statement processed.

Wyświetlenie informacji o plikach danych.

SVRMGR> select status, enabled, bytes, name from v$datafile;
STATUS ENABLED CHECKPOINT BYTES NAME
………………… ……………………… ……………………….. ……………… …………………………………….
SYSTEM READ WRITE 4823 7340032 C:LABLABSYSTEM.DBF
ONLINE READ WRITE 4823 1048576 C:LABLABDANE1.DBF
ONLINE READ WRITE 4823 0 C:LABLABDANE2.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABTEMP.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABRBS.DBF

2. Otwarcie bazy danych.

SVRMGR> alter database open;
Statement processed.

Wyświetlenie informacji o przestrzeniach tabel.

SVRMGR> select tablespace_name, status, contents
     2> from dba_tablespaces;

TABLESPACE_NAME STATUS CONTENTS
…………………………………… …………………….. ………………………………..
SYSTEM ONLINE PERMANENT
LAB_DANE ONLINE PERMANENT
LAB_TEMP ONLINE TEMPORARY
LAB_RBS ONLINE PERMANENT

3. Wyeksportowanie obiektów użytkowników z przestrzeni tabel, której plik uległ uszkodzeniu.

Jeżeli przestrzeń tabel składa się z kilku plików, a nie wszystkie uległy uszkodzeniu, wówczas należy wyeksportować te dane użytkowników, które znajdują się w nieuszkodzonych plikach tej przestrzeni.
Poniżej przedstawiono listing eksportu użytkownika scott. Dane tabeli o nazwie z2 znajdowały się zarówno w nieuszkodzonym pliku labdane1.dbf, jak i w pliku uszkodzonym labdane2.dbf i dlatego nie zostały w całości wyeksportowane.

D:export>exp system/manager compress=y owner=scott
file=scott_exp.dat
Export: Release 7.3.4.0.0 – Production on Wed Dec 30 19:30:42 1998

About to export specified users …
About to export SCOTT’s objects …
. exporting snapshots

. about to export SCOTT’s tables via Conventional Path …
. . exporting table P1 3584 rows exported
. . exporting table Z1
EXP-00014: error on row 2620 of table Z1
EXP-00008: ORACLE error 376 encountered
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: ‚C:LABLABDANE2.DBF’
. exporting synonyms
. exporting views
. exporting stored procedures
. exporting referential integrity constraints
. exporting triggers
. exporting posttables actions
Export terminated successfully with warnings.

4. Wyłączenie przestrzeni tabel LAB_DANE.

SVRMGR> alter tablespace LAB_DANE offline temporary;
Statement processed.

W przypadku gdy nie wszystkie pliki przestrzeni tabel są dostępne wyłączenie takiej przestrzeni realizuje się z wykorzystaniem klauzuli offline temporary lub offline immediate. W przypadku drugim dla plików tej przestrzeni nie jest wykonywany punkt kontrolny.
Wyświetlenie informacji o przestrzeniach tabel.

SVRMGR> select tablespace_name, status, contents
     2> from dba_tablespaces;

TABLESPACE_NAME STATUS CONTENTS
………………………………….. …………………… …………………………….
SYSTEM ONLINE PERMANENT
LAB_DANE OFFLINE PERMANENT
LAB_TEMP ONLINE TEMPORARY
LAB_RBS ONLINE PERMANENT

Wyświetlenie informacji o plikach danych.

SVRMGR> select status, enabled, bytes, name from v$datafile;
STATUS ENABLED CHECKPOINT BYTES NAME
…………………. ……………………….. ……………………….. …………………… ……………………………………….
SYSTEM READ WRITE 4823 7340032 C:LABLABSYSTEM.DBF
OFFLINE DISABLED 4823 1048576 C:LABLABDANE1.DBF
OFFLINE DISABLED 4823 0 C:LABLABDANE2.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABTEMP.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABRBS.DBF

5. Usunięcie przestrzeni tabel LAB_DANE wraz z zawartością.

SVRMGR> drop tablespace LAB_DANE including contents;
Statement processed.

Wyświetlenie informacji o przestrzeniach tabel.

SVRMGR> select tablespace_name, status, contents
    2> from dba_tablespaces;

TABLESPACE_NAME STATUS CONTENTS
……………………………………. …………….. ……………………………
SYSTEM ONLINE PERMANENT
LAB_TEMP ONLINE TEMPORARY
LAB_RBS ONLINE PERMANENT
3 rows selected.

Wyświetlenie informacji o plikach danych.

SVRMGR> select status, enabled, bytes, name from v$datafile;
STATUS ENABLED CHECKPOINT BYTES NAME
………………… ……………………….. ……………………… ……………… ………………………………………
SYSTEM READ WRITE 4823 7340032 C:LABLABSYSTEM.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABTEMP.DBF
ONLINE READ WRITE 4823 1048576 D:LABLABRBS.DBF

6. Usunięcie w systemie operacyjnym plików przestrzeni LAB_DANE.

7. Utworzenie nowej przestrzeni tabel LAB_DANE o początkowym rozmiarze 5MB.

SVRMGR> create tablespace LAB_DANE
  2> datafile ‚C:LABLABDANE1.DBF’ size 5M;

8. Wczytanie za pomocą programu imp (zob. punkt 5.4.1) wyeksportowanych wcześniej danych.

Poniżej przedstawiono listing importu użytkownika scott. Do jego schematu zostały wczytane wszystkie rekordy tabeli p1 i ta część rekordów tabeli z2, która pierwotnie znajdowała się w pliku labdane1.dbf.

D:export>imp system/manager fromuser=scott touser=scott file=scott_exp.dat
Import: Release 7.3.4.0.0 – Production on Wed Dec 30 20:44:54 1998

Export file created by EXPORT:V07.03.04 via conventional path
. . importing table "P1" 3584 rows imported
. . importing table "Z1" 2619 rows imported
Import terminated successfully without warnings.

5.2. Odtwarzanie pełne w trybie ARCHIVELOG

Baza danych pracująca w trybie z archiwizacją plików dziennika powtórzeń (ARCHIVELOG) może zostać odtworzona w pełni, tj. do momentu bezpośrednio poprzedzającego awarię. Odtwarzanie takie można zrealizować na trzy następujące sposoby:

  • Odtwarzanie całej bazy danych – realizuje się w trybie MOUNT. Oznacza to, że baza jest niedostępna dla użytkowników. Jest to jedyny sposób odtworzenia bazy danych w przypadku zniszczenia plików należących do przestrzeni tabel SYSTEM.
  • Odtwarzanie pojedynczej przestrzeni tabel – realizuje się w trybie OPEN, przy wyłączonej (offline) tej przestrzeni tabel, której zawartość jest odtwarzana. W czasie odtwarzania użytkownicy mogą korzystać z bazy danych, ale wyłączona przestrzeń tabel jest dla nich niedostępna. Tego trybu nie można jednak stosować odtwarzając przestrzeń tabel SYSTEM, ponieważ przestrzeń ta jest niezbędna do pracy bazy danych.
  • Odtwarzanie pojedynczych plików danych – realizuje się przy otwartej lub zamkniętej bazie danych. Odtwarzane pliki danych muszą być wyłączone (offline), natomiast do danych znajdujących się w pozostałych plikach użytkownicy mają dostęp pod warunkiem, że baza jest otwarta. Tego trybu nie można jednak stosować w przypadku gdy są odtwarzane pliki należące do przestrzeni tabel SYSTEM.

Celem odtwarzania bazy danych po awarii jest uzyskanie spójnego jej stanu, tzn. stanu w którym zawartość wszystkich plików danych pochodzi z tej samej chwili. Baza danych jest spójna (ang. consistent), jeżeli numery sekwencyjne punktu kontrolnego znajdujące się w nagłówkach plików danych są takie same jak odpowiadające im numery sekwencyjne w pliku kontrolnym.

5.2.1. Odtwarzanie pełne całej bazy danych

Odtwarzanie pełne całej bazy danych uruchamia się wydając polecenie recover database o następującej składni:

recover [automatic] [from ‚ścieżka_log’] database;

automatic

automatycznie aplikuje zmiany zawarte w plikach dziennika powtórzeń;

ścieżka_log

umożliwia wskazanie katalogu, w którym znajdują się zarchiwizowane pliki dziennika powtórzeń. Domyślnie, pliki te znajdują się w katalogu wskazywanym przez parametr LOG_ARCHIVE_DEST, pliku init<SID>.ora.

Uwaga: automatyczne aplikowanie zarchiwizowanych plików dziennika powtórzeń można wymusić również przed rozpoczęciem całego procesu odtwarzania. W tym celu, przed poleceniem recover należy wydać polecenie:

SVRMGR> set autorecovery on
Autorecovery ON

Wyłączenie automatycznego aplikowania realizuje się poleceniem:

SVRMGR> set autorecovery off
Autorecovery OFF

Jako przykład ilustrujący sposób odtwarzania pełnego całej bazy danych rozważmy bazę danych posiadającą m.in. przestrzeń tabel o nazwie LAB_DANE złożoną z dwóch plików o nazwach labdane1.dbf i labdane2.dbf. Oba pliki znajdują się w katalogu: C:lab. Załóżmy, że plik labdane1.dbf uległ uszkodzeniu, co symulujemy jego usunięciem. Próba otwarcia bazy danych zakończy się wówczas następującym komunikatem:

SVRMGR> startup
ORACLE instance started.
Total System Global Area 4504784 bytes
Fixed Size 35208 bytes
Variable Size 4051784 bytes
Database Buffers 409600 bytes
Redo Buffers 8192 bytes
Database mounted.
ORA-01157: cannot identify data file 2 – file not found
ORA-01110: data file 2: ‚C:LABLABDANE1.DBF’
SVRMGR> shutdown abort
ORACLE instance shut down.

Procedura odtworzenia bazy danych przebiega w następujących krokach:

  1. Wgranie kopii archiwalnej pliku labdane1.dbf.
  2. Uruchomienie bazy danych.
    Baza danych zostanie zamontowana ale nie otwarta ponieważ plik labdane1.dbf wymaga odtworzenia.
    SVRMGR> startup
    ORACLE instance started.
    Total System Global Area 4504784 bytes
    Fixed Size 35208 bytes
    Variable Size 4051784 bytes
    Database Buffers 409600 bytes
    Redo Buffers 8192 bytes
    Database mounted.
    ORA-01113: file 2 needs media recovery
    ORA-01110: data file 2: ‚C:LABLABDANE1.DBF’
  3. Odtworzenie bazy danych.
    SVRMGR> recover database
    ORA-00279: Change 8415 generated at 08/18/98 17:20:26 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00082.arc
    ORA-00280: Change 8415 for thread 1 is in sequence #82
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Wciśnięcie klawisza ENTER spowoduje zaaplikowanie zawartości proponowanego przez system zarchiwizowanego pliku dziennika powtórzeń. Natomiast wpisanie AUTO spowoduje automatyczne aplikowanie wszystkich wymaganych plików dziennika.

Wciśnięto ENTER
Log applied.
ORA-00279: Change 8442 generated at 08/18/98 17:40:22 needed for thread 1
ORA-00289: Suggestion : D:Log_Archivesarch00083.arc
ORA-00280: Change 8442 for thread 1 is in sequence #83
ORA-00278: Logfile ‚D:Log_Archivesarch00082.arc’ no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Wciśnięto ENTER
Log applied.
Media recovery complete.
SVRMGR> alter database open;
Statement processed.

5.2.2. Odtwarzanie pełne pojedynczej przestrzeni tabel

Odtwarzanie pełne wybranych przestrzeni tabel realizuje się wydając polecenie recover tablespace o następującej składni:
recover [automatic] [from ‚ścieżka_log’]
tablespace przestrzeń1, …, przestrzeńn;

Sposób odtworzenia przestrzeni tabel LAB_DANE, w przypadku wystąpienia awarii opisanej w punkcie 5.2.1, został przedstawiony poniżej. Po wystąpieniu awarii baza danych została zamknięta i administrator wykonał poniższe kroki.

  1. Wgranie kopii archiwalnej pliku labdane1.dbf.
  2. Uruchomienie bazy danych w trybie MOUNT.
    SVRMGR> startup mount
    ORACLE instance started.
    Total System Global Area 4504784 bytes
    Fixed Size 35208 bytes
    Variable Size 4051784 bytes
    Database Buffers 409600 bytes
    Redo Buffers 8192 bytes
    Database mounted.
  3. Wyłączenie wgranego pliku przestrzeni tabel LAB_DANE.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> offline;
    Statement processed.
  4. Otwarcie bazy danych.
    SVRMGR> alter database open;
    Statement processed.
  5. Wyłączenie przestrzeni tabel LAB_DANE.
    Wyłączenie przestrzeni tabel jest możliwe tylko gdy baza danych jest otwarta. Jeżeli przynajmniej jeden plik przestrzeni tabel jest wyłączony (offline), to taką przestrzeń tabel należy wyłączyć z wykorzystaniem klauzuli offline temporary lub offline immediate (por. punkt 2.5). Próba wyłączenia takiej przestrzeni tabel w trybie normalnym zakończy się komunikatem przedstawionym poniżej.
    SVRMGR> alter tablespace lab_dane offline;
    alter tablespace lab_dane offline
    *
    ORA-01191: file 2 is already offline – cannot do a normal offline
    ORA-01110: data file 2: ‚C:LABLABDANE1.DBF’

    Wyłączenie przestrzeni tabel LAB_DANE w trybie temporary.
    SVRMGR> alter tablespace lab_dane offline temporary;
    Statement processed.

  6. Odtworzenie przestrzeni tabel.
    SVRMGR> recover tablespace lab_dane;
    ORA-00279: Change 8415 generated at 08/18/98 17:20:26 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00082.arc
    ORA-00280: Change 8415 for thread 1 is in sequence #82
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    auto
    Log applied.
    ORA-00279: Change 8442 generated at 08/18/98 17:40:22 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00083.arc
    ORA-00280: Change 8442 for thread 1 is in sequence #83
    ORA-00278: Logfile ‚D:Log_Archivesarch00082.arc’ no longer needed for this recovery
    Log applied.
    Media recovery complete.
  7. Włączenie przestrzeni tabel.
    SVRMGR> alter tablespace lab_dane online;
    Statement processed.

W powyższym przykładzie przed rozpoczęciem odtwarzania administrator zamknął bazę danych. Jeżeli plik przestrzeni tabel uległ uszkodzeniu, a baza danych musi być cały czas otwarta, wówczas należy wykonać poniższe kroki prowadzące do odtworzenia uszkodzonej przestrzeni.

  1. Wyłączenie uszkodzonego pliku przestrzeni tabel LAB_DANE.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> offline;
  2. Wyłączenie przestrzeni tabel LAB_DANE.
    SVRMGR> alter tablespace lab_dane offline temporary;
  3. Wgranie kopii archiwalnej pliku labdane1.dbf.
  4. Odtworzenie przestrzeni tabel.
    SVRMGR> recover tablespace lab_dane;
  5. Włączenie przestrzeni tabel.
    SVRMGR> alter tablespace lab_dane online;

5.2.3. Odtwarzanie pełne pojedynczego pliku danych

Odtwarzanie pełne wybranych plików danych uruchamia się wydając polecenie recover datafile o następującej składni:
recover [automatic] [from ‚ścieżka_log’]
datafile plik1, …, plikn;

Sposób odtworzenia pliku labdane1.dbf przestrzeni tabel LAB_DANE, w przypadku wystąpienia awarii opisanej w punkcie 5.2.1, został przedstawiony poniżej. Po wystąpieniu awarii baza danych została zamknięta i administrator wykonał poniższe kroki.

  1. Wgranie kopii archiwalnej pliku labdane1.dbf.
  2. Uruchomienie bazy danych w trybie MOUNT.
    SVRMGR> startup mount
    ORACLE instance started.
    Total System Global Area 4504784 bytes
    Fixed Size 35208 bytes
    Variable Size 4051784 bytes
    Database Buffers 409600 bytes
    Redo Buffers 8192 bytes
    Database mounted.
  3. Przełączenie wgranego pliku labdane1.dbf w tryb offline.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> offline;
    Statement processed.
  4. Otwarcie bazy danych.
    SVRMGR> alter database open;
    Statement processed.
  5. Odtworzenie pliku danych.
    SVRMGR> recover datafile ‚C:lablabdane1.dbf’;
    ORA-00279: Change 8415 generated at 08/18/98 17:20:26 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00082.arc
    ORA-00280: Change 8415 for thread 1 is in sequence #82
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    auto
    Log applied.
    ORA-00279: Change 8442 generated at 08/18/98 17:40:22 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00083.arc
    ORA-00280: Change 8442 for thread 1 is in sequence #83
    ORA-00278: Logfile ‚D:Log_Archivesarch00082.arc’ no longer needed for this recovery
    Log applied.
    Media recovery complete.
  6. Przełączenie odtworzonego pliku labdane1.dbf w tryb online.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> online;
    Statement processed.

W powyższym przykładzie przed rozpoczęciem odtwarzania administrator zamknął bazę danych. Jeżeli jednak baza danych musi być cały czas otwarta, wówczas należy wykonać odtwarzanie w sposób przedstawiony poniżej.

  1. 1. Wyłączenie uszkodzonego pliku przestrzeni tabel LAB_DANE.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> offline;
  2. 2. Wgranie kopii archiwalnej pliku labdane1.dbf.
  3. 3. Odtworzenie pliku danych labdane1.dbf.
    SVRMGR> recover datafile ‚C:lablabdane1.dbf’;
  4. 4. Przełączenie odtworzonego pliku labdane1.dbf w tryb online.
    SVRMGR> alter database datafile ‚C:lablabdane1.dbf’
    2> online;

5.2.4. Odtwarzanie bazy danych w przypadku utraty systemowej przestrzeni tabel

W przypadku uszkodzenia plików należących do przestrzeni tabel SYSTEM bazę danych odtwarza się w sposób opisany poniżej.

  1. Wgranie wszystkich uszkodzonych plików przestrzeni systemowej z ostatniej kopii bezpieczeństwa na ich oryginalne miejsce.

  2. Zamontowanie bazy danych.
    SVRMGR> startup mount

  3. Odtworzenie całej bazy danych.
    SVRMGR> recover database;

  4. Otwarcie bazy danych.
    SVRMGR> alter database open;

5.2.5. Tworzenie nowego pliku kontrolnego

Uszkodzony plik kontrolny można utworzyć uruchamiając instancję w trybie NOMOUNT, a następnie wydając polecenie create controlfile.
Jeżeli dostęp do bazy danych jako internal wymaga podania hasła, to przed uruchomieniem instancji należy w pliku init<SID>.ora zmienić wartość parametru remote_login_passwordfile na SHARED. W przeciwnym przypadku w czasie tworzenia plików kontrolnych pojawi się komunikat:

ORA-01503: CREATE CONTROLFILE failed
ORA-01991: invalid password file ‚D:ORAWIN95DATABASEPWDsid.ORA’

Kroki prowadzące do odtworzenia pliku kontrolnego przedstawiono poniżej.

  1. Uruchomienie instancji.
    SVRMGR> startup nomount
    ORACLE instance started.
    Total System Global Area 4504784 bytes
    Fixed Size 35208 bytes
    Variable Size 4051784 bytes
    Database Buffers 409600 bytes
    Redo Buffers 8192 bytes
  2. Utworzenie pliku kontrolnego za pomocą polecenia create controfile.
    Przykładowe polecenie tworzące plik kontrolny dla bazy danych LAB przedstawiono poniżej.

    SVRMGR> CREATE CONTROLFILE REUSE DATABASE "LAB"
    2> NORESETLOGS ARCHIVELOG
    3> MAXLOGFILES 32
    4> MAXLOGMEMBERS 2
    5> MAXDATAFILES 20
    6> MAXINSTANCES 16
    7> MAXLOGHISTORY 1600
    8> LOGFILE
    9> GROUP 1 ‚C:LABLABLOG1.ORA’ SIZE 500K,
    10> GROUP 2 ‚C:LABLABLOG2.ORA’ SIZE 500K,
    11> GROUP 3 ‚C:LABLABLOG3.ORA’ SIZE 500K,
    12> GROUP 4 ‚C:LABLABLOG4.ORA’ SIZE 500K
    13> DATAFILE
    14> ‚C:LABLABSYSTEM.DBF’,
    15> ‚C:LABLABDANE1.DBF’,
    16> ‚C:LABLABDANE2.DBF’,
    17> ‚D:LABLABTEMP.DBF’,
    18> ‚D:LABLABRBS.DBF’;
    Statement processed.

    REUSE

    powoduje nadpisane istniejących plików kontrolnych;

    DATABASE

    określa nazwę bazy danych;

    NORESETLOGS

    umożliwia otwarcie bazy danych bez zerowania numerów sekwencyjnych, natomiast słowo kluczowe RESETLOGS wymusza otwarcie bazy danych z zerowaniem numerów sekwencyjnych;

    ARCHIVELOG

    oznacza tryb pracy bazy danych – z archiwizacją plików dziennika powtórzeń, natomiast NOARCHIVELOG oznacza tryb bez archiwizacji.
  3. Zarchiwizowanie plików dziennika powtórzeń.
    SVRMGR> alter system archive log all;
    Statement processed.

  4. Otwarcie bazy danych.
    SVRMGR> alter database open;
    Statement processed.

Uwaga: jeżeli dodatkowo wgrano kopie bezpieczeństwa plików danych lub wcześniej zamknięto bazę danych w trybie ABORT, to przed otwarciem baza danych musi zostać odtworzona. Przykładowy komunikat wyświetlany przy próbie otwarcia bazy danych, która wcześniej została zamknięta w trybie ABORT został przedstawiony poniżej.

SVRMGR> alter database open;
alter database open
*
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: ‚C:LABLABSYSTEM.DBF’
SVRMGR> recover database;
Media recovery complete.
SVRMGR> alter database open;
Statement processed.

5.3. Odtwarzanie niepełne w trybie ARCHIVELOG

Baza danych pracująca w trybie ARCHIVELOG może zostać odtworzona do określonego momentu w przeszłości – jest to tzw. odtwarzanie niepełne (ang. incomplete recovery). Odtwarzanie niepełne stosuje się najczęściej w przypadku gdy:

  1. użytkownik usunął przypadkowo dane (np. tabelę),

  2. uszkodzeniu uległ plik danych i niektóre zarchiwizowane pliki dziennika powtórzeń.

Jako przykład ilustrujący przypadek a) odtwarzania niepełnego rozważmy rysunek 5 przedstawiający akcje realizowane w bazie danych. W chwili t0 została sporządzona pełna kopia fizyczna bazy danych, a w chwili t1 baza została uruchomiona w trybie ARCHIVELOG. Od tego momentu zostały zarchiwizowane dwa pliki dziennika powtórzeń. W chwili t3 użytkownik przypadkowo usunął tabelę T. W tym przypadku, usunięte dane zostaną odzyskane po wczytaniu kopii wszystkich plików danych   (z chwili t0) i odtworzeniu bazy danych do momentu sprzed usunięcia tabeli, tj. do chwili t2.

Rys. 5

Rys. 5. Wykorzystanie odtwarzania niepełnego po przypadkowym usunięciu danych

Przypadek b) – uszkodzenia zarchiwizowanych plików dziennika powtórzeń i pliku danych, został przedstawiony na rysunku 6. Załóżmy, że uszkodzeniu uległy dwa zarchiwizowane pliki dziennika, tj. arch04.arc i arch05.arc. W tym przypadku bazę danych będzie można odtworzyć tylko do chwili t4. W tym celu należy wczytać kopie wszystkich plików bazy danych (z chwili t0) i zaaplikować zmiany zapisane w plikach arch01.arc, arch02.arc i arch03.arc.
W obu powyższych przypadkach po odtworzeniu bazy danych należy wyzerować numery sekwencyjne wszystkich plików bazy danych (por. punkt 5.3.1 i 5.3.2).

Rys. 6

Rys. 6. Wykorzystanie odtwarzania niepełnego gdy uszkodzeniu uległy zarchiwizowane pliki dziennika powtórzeń

Odtwarzanie niepełne może być wykonane m.in. na dwa sposoby, w zależności od rodzaju awarii systemu i celów odtwarzania, tj.:

  • do określonego momentu w czasie (ang. time-based),
  • do przerwania (ang. cancel-based).

Odtwarzanie niepełne przywraca zawartość bazy danych do stanu, w którym znajdowała się w danym momencie w przeszłości. Dlatego, przed przystąpieniem do aplikowania zapisów ze zarchiwizowanych plików dziennika powtórzeń należy wgrać z ostatniej kopii bezpieczeństwa wszystkie pliki danych. Jeżeli plik kontrolny nie uległ uszkodzeniu, to nie należy wgrywać jego kopii.
Jeżeli wraz z uszkodzeniem plików danych ulegają uszkodzeniu również pliki kontrolne, wówczas bazę danych należy odtworzyć z wykorzystaniem kopii archiwalnej pliku kontrolnego. W tym celu w poleceniu recover należy użyć klauzuli using backup controlfile.
W wyniku odtwarzania niepełnego baza danych znajduje się w stanie niespójnym (por. rysunek 7) – w pliku kontrolnym jest zapisany inny numer sekwencyjny (bieżącego pliku dziennika powtórzeń) niż w nagłówkach plików danych. W celu zrównania tych numerów, bezpośrednio po odtworzeniu bazy danych, należy wyzerować numery sekwencyjne w nagłówkach wszystkich plików danych i odpowiadające im numery sekwencyjne w pliku kontrolnym. Zerowanie numerów sekwencyjnych wymusza się otwierając bazę danych z opcją resetlogs:

alter database open resetlogs
;

Po odtworzeniu bazy danych i wyzerowaniu numerów sekwencyjnych należy sporządzić nową kopię bezpieczeństwa całej bazy danych. Wyzerowanie numerów sekwencyjnych powoduje, że:

Rys. 7

Rys.7. Niepełne odtwarzanie bazy danych

  • po otwarciu bazy danych pliki dziennika powtórzeń będą otrzymywały numery sekwencyjne począwszy od 1;
  • poprzednio zarchiwizowane pliki dziennika powtórzeń staną się nieprzydatne do odtwarzania bazy danych.

W dalszej części rozdziału zostaną omówione dwa sposoby odtwarzania niepełnego, tj. odtwarzanie do określonego momentu w czasie i odtwarzanie do przerwania.

5.3.1. Odtwarzanie do określonego momentu w czasie

Ten sposób odtwarzania realizuje się za pomocą polecenia recover o następującej składni:

recover
[automatic] [from ‚ścieżka_log’] database
until time
‚YYYY-MM-DD:HH24:MI:SS’
[using backup controlfile];

Podczas odtwarzania do określonego momentu w czasie zawartość kolejnych zarchiwizowanych plików dziennika powtórzeń aplikowana jest do momentu, w którym baza danych osiągnie stan z podanego momentu czasowego. Moment ten musi być podany w ściśle określonym formacie: ‚YYYY-MM-DD:HH24:MI:SS’, np. ‚1998-05-25:20:31:00’.
Kroki prowadzące do odtworzenia bazy danych do określonego momentu w czasie zostały przedstawione poniżej.

  1. Zatrzymanie bazy danych.
  2. Wgranie wszystkich plików danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca.
    Uwaga: nie należy wgrywać plików kontrolnych, jeżeli nie uległy uszkodzeniu i plików dziennika powtórzeń.
  3. Uruchomienie bazy danych w trybie MOUNT.
    SVRMGR> startup mount
    Database mounted.
  4. Odtworzenie bazy danych do stanu z określonego momentu.
    Poniższe polecenie odtwarza bazę danych do stanu z 19 sierpnia 1998, godziny 818:50.
    SVRMGR> recover database until time ‚1998-08-19:08:18:50’;
  5. Otwarcie bazy danych z zerowaniem numerów sekwencyjnych.
    SVRMGR> alter database open resetlogs;

Uwaga: jeżeli administrator stosuje odtwarzanie z wykorzystaniem kopii pliku kontrolnego, to powinien pamiętać o tym, że wszystkie przestrzenie tabel tylko do odczytu muszą być wyłączone w czasie odtwarzania.

5.3.2. Odtwarzanie do przerwania

Ten sposób odtwarzania realizuje się za pomocą polecenia recover o następującej składni:
recover [from ‚ścieżka_log’] database
until cancel

[using backup controlfile];

Odtwarzanie do przerwania polega na aplikowaniu kolejnych zarchiwizowanych plików dziennika powtórzeń do momentu zatrzymania tego procesu przez administratora. Przed zaaplikowaniem każdego z plików dziennika system wyświetla informacje o tym pliku i żąda potwierdzenia, bądź odwołania operacji.
Przykładowa sesja odtwarzania do przerwania została przestawiona poniżej.

  1. Zatrzymanie bazy danych.

  2. Wgranie wszystkich plików danych z ostatniej kopii bezpieczeństwa na ich właściwe miejsca.
    Uwaga: nie należy wgrywać plików kontrolnych, jeżeli nie uległy uszkodzeniu i plików dziennika powtórzeń.

  3. Uruchomienie bazy danych w trybie MOUNT.
    SVRMGR> startup mount
    Database mounted.

  4. Odtworzenie bazy danych do przerwania.
    SVRMGR> recover database until cancel;
    ORA-00279: Change 6963 generated at 08/19/98 08:09:07 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00082.arc
    ORA-00280: Change 6963 for thread 1 is in sequence #82
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    Log applied.
    ORA-00279: Change 6986 generated at 08/19/98 08:41:52 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00083.arc
    ORA-00280: Change 6986 for thread 1 is in sequence #83
    ORA-00278: Logfile ‚D:Log_Archivesarch00082.arc’ no longer needed for this recovery
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    Log applied.
    ORA-00279: Change 6991 generated at 08/19/98 08:43:50 needed for thread 1
    ORA-00289: Suggestion : D:Log_Archivesarch00084.arc
    ORA-00280: Change 6991 for thread 1 is in sequence #84
    ORA-00278: Logfile ‚D:Log_Archivesarch00083.arc’ no longer needed for this recovery
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    cancel
    Media recovery cancelled.

  5. Otwarcie bazy danych z zerowaniem numerów sekwencyjnych.
    SVRMGR> alter database open resetlogs;
    Statement processed.

5.4. Odtwarzanie na podstawie zawartości pliku eksportu

Baza danych, która uległa uszkodzeniu może zostać odtworzona na podstawie zawartości pliku eksportu (por. część II, punkt 4.2). Do wczytania zawartości tego pliku do bazy danych służy program imp. Program ten jest dostępny po zainstalowaniu binariów serwera bazy danych, jednak wymaga utworzenia dodatkowych obiektów systemowych. Obiekty te, tworzone za pomocą skryptu catexp.sql (wywoływanego za pomocą skryptu catalog.sql), muszą być własnością użytkownika SYS.

5.4.1. Program imp – importowanie danych

Program imp umożliwia importowanie: pojedynczych tabel (ang. table mode), całych schematów użytkowników (ang. user mode) lub całej bazy danych (ang. full database mode). Mechanizm importowania ma również zastosowanie do przenoszenia danych z jednej bazy danych do drugiej.
Program imp wymaga określenia szeregu parametrów, z których najczęściej używane omówiono poniżej.

USERID

Określa nazwę i hasło użytkownika, który importuje dane.

BUFFER

Określa rozmiar bufora (w bajtach) pamięci operacyjnej wykorzystywanego do przetwarzania importowanych danych.

FILE

Wskazuje nazwę pliku przechowującego wyeksportowane dane.

SHOW

Wartość Y oznacza, że dane nie zostaną zaimportowane do bazy danych, a zawartość pliku eksportu zostanie tylko wyświetlona na ekranie. Natomiast wartość N spowoduje wczytanie do bazy danych zawartości pliku eksportu.

IGNORE

Określa sposób reagowania na błędy powstające w czasie importowania danych, wynikające z istnienia w bazie danych importowanego obiektu
Jeżeli parametr ten przyjmuje wartość Y, a importowane są definicje obiektów już istniejących w bazie danych, to program nie tworzy ponownie tych obiektów, lecz je pomija nie wyświetlając informacji o błędach.
W przypadku importowania tabel nie posiadającej ograniczeń integralnościowych zapewniających unikalność wartości jej kolumn i gdy:
  • importowana tabela już istnieje w bazie danych,
  • parametr IGNORE=Y i importowana jest zarówno definicja tabeli, jak i jej zawartość,

wówczas program imp powoduje wczytanie zawartości tabeli z pliku eksportu do tabeli w bazie danych. W tym przypadku mogą powstać rekordy posiadające takie same wartości.
W przypadku gdy parametr IGNORE przyjmie wartość N (domyślną), próba wczytania definicji obiektu już istniejącego zakończy się niepowodzeniem i wyświetleniem informacji o błędzie:
IMP-00015: following statement failed because the object already exists
po czym program będzie kontynuował wczytywanie kolejnych obiektów.

FULL

Wartość Y powoduje import całej bazy danych, natomiast N (wartość domyślna) umożliwia importowanie obiektów wybranych użytkowników lub tylko określonych tabel, w zależności od wartości parametrów FROMUSER i TABLES. Importu całej bazy danych może dokonać tylko użytkownik posiadający rolę IMP_FULL_DATABASE.

FROMUSER

Określa zbiór użytkowników, których obiekty zostaną wczytane.
Przykładowo, poniższe polecenie powoduje wczytanie z pliku exp01.dmp obiektów użytkownika scott, do schematu użytkownika scott, jeżeli istnieje on w bazie danych. W przeciwnym przypadku obiekty tego użytkownika zostaną wczytane do schematu użytkownika system.
imp system/manager FORMUSER=scott FILE=exp01.dmp

TOUSER

Określa zbiór użytkowników, do których schematów zostaną zaimportowane dane. Opcję tę może wykorzystać tylko użytkownik posiadający rolę IMP_FULL_DATABASE.
Przykładowo, poniższe polecenie powoduje wczytanie obiektów użytkownika lab do schematu użytkownika u1.
imp system/manager FROMUSER=lab TOUSER=u1 FILE=lab01.dmp

TABLES

Określa zbiór tabel, które zostaną wczytane.
Przykładowo, poniższe polecenie powoduje wczytanie tabeli pracownicy użytkownika lab do schematu użytkownika u1.
imp system/manager FROMUSER=lab TOUSER=u1 TABLES=pracownicy FILE=lab01.dmp

ROWS

Wartość Y (domyślna) powoduje wczytanie definicji tabeli wraz z jej zawartością, natomiast N – tylko definicji tabeli.

INDEXES

Wartość Y (domyślna) powoduje wczytanie indeksów związanych z importowanymi tabelami. W przypadku wyspecyfikowania N indeksy nie będą importowane.

INDEXFILE

Określa nazwę pliku, do którego zostaną zapisane polecenia tworzące indeksy. Oprócz tych poleceń w pliku znajdują się ujęte w komentarz definicje tabel. Plik ten może być następnie wykorzystany jako skrypt SQL. Wyspecyfikowanie parametru INDEXFILE spowoduje, że żadne obiekty użytkowników nie będą importowane do bazy danych.
Przykładowo, poniższe polecenie spowoduje zapisanie pliku o nazwie indx2.sql, zawierającego polecenia tworzące indeksy dla tabel użytkownika scott znajdujących się w pliku exportu scott_exp2.dat.
imp scott/tiger file=scott_exp2.dat indexfile=indx2.sql

GRANTS

Wartość Y (domyślna) powoduje wczytanie przywilejów związanych z importowanymi tabelami. W przypadku wyspecyfikowania N przywileje nie będą importowane.

COMMIT

Wartość Y powoduje, że po wczytaniu do bazy danych bloku informacji o wielkości określonej parametrem BUFFER system zatwierdzi transakcję. Natomiast wartość N (domyślna) powoduje zatwierdzenie transakcji dopiero po wczytaniu całej tabeli.

DESTROY

Wartość Y powoduje nadpisanie istniejących przestrzeni tabel definicjami zawartymi w importowanym pliku. Natomiast wyspecyfikowanie wartości N (domyślnej) spowoduje powstanie błędu w czasie próby zastąpienia istniejącej przestrzeni tabel przestrzenią importowaną.

INCTYPE

Określa tryb importowania danych i może przyjmować jedną z dwóch wartości: SYSTEM, lub RESTORE. Parametr ten jest wykorzystywany w czasie importowania danych z plików eksportów inkrementalnych, kumulacyjnych i kompletnych (zob. punkt 5.4.3).

LOG

Wskazuje plik, do którego zostaną zapisane informacje o przebiegu importu.

PARFILE

Wskazuje plik zawierający parametry importu.

HELP

Umożliwia wyświetlenie parametrów importu.

Importowanie danych, podobnie jak eksportowanie, jest możliwe w trzech następujących trybach:

  • w trybie interakcyjnym, w którym system pyta o wartości parametrów,
  • w linii komend polecenia imp,
  • w pliku parametrów określonym słowem kluczowym PARFILE.

5.4.2. Odtwarzanie bazy danych na podstawie pełnego eksportu

Całą bazę danych można odtworzyć na podstawie pełnego eksportu wykonując kroki opisane poniżej.

  1. Utworzyć bazę danych.

    Baza ta może posiadać tylko systemową przestrzeń tabel. Wszystkie pozostałe przestrzenie, istniejące w źródłowej bazie danych zostaną utworzone w wyniku wykonania kroku 4 (opisanego niżej), pod warunkiem, że struktura katalogów, w których zostaną umieszczone pliki tych przestrzeni tabel będzie identyczna ze strukturą katalogów bazy źródłowej.
    Natomiast jeżeli oprócz przestrzeni systemowej zostaną utworzone wszystkie pozostałe przestrzenie istniejące w bazie źródłowej, to pliki tych przestrzeni będą mogły się znajdować w dowolnych katalogach. W tym przypadku importując dane należy nadać parametrowi importu DESTROY wartość N. Wówczas w wyniku wykonania kroku 4 system nie utworzy tych przestrzeni ponownie lecz wyświetli błąd:
    IMP-00015: following statement failed because the object already exists:
    "CREATE TABLESPACE …. "

    Uwaga
    : utworzona baza danych oprócz segmentu systemowego powinna posiadać przynajmniej jeden dodatkowy niesystemowy segment wycofania. Segment ten będzie wykorzystywany przez transakcje zapisujące do niesystemowych przestrzeni tabel. W przeciwnym przypadku, w czasie importowania danych użytkowników pojawi się komunikat:
    IMP-00003: ORACLE error 1552 encountered
    ORA-01552: cannot use system rollback segment for non-system tablespace ‚…’

  2. Zainstalować katalog (skrypt catalog.sql).

  3. Zainstalować opcję proceduralną, jeśli jest wymagana (skrypt catproc.sql). W przeciwnym przypadku procedury, funkcje, pakiety i wyzwalacze bazy danych nie zostaną zaimportowane z powodu braku obiektów systemowych opcji proceduralnej.
    Jeżeli nie zostanie zainstalowana opcja proceduralna, to w czasie dołączania użytkownika do bazy danych pojawi się komunikat:
    Error accessing package DBMS_APPLICATION_INFO
    ERROR:
    ORA-06553: PLS-213: package STANDARD not accessible

  4. Zaimportować plik eksportu całej bazy danych
    Poniższe polecenie umożliwia wczytanie pliku o nazwie exp_full.dmp.
    imp system/manager FULL=Y FILE=exp_full.dmp

5.4.3. Odtwarzanie bazy danych na podstawie eksportów inkrementalnych, kumulacyjnych i kompletnego

W celu odtworzenia bazy danych na podstawie eksportu kompletnego, eksportów inkrementalnych i kumulacyjnych należy:

1. Wykonać kroki 1-3 opisane w punkcie 5.4.2.

4. Zaimportować do bazy danych zawartość pliku ostatniego eksportu inkrementalnego, bądz eksportu kumulacyjnego, jeżeli był on wykonany jako ostatni
imp system/manager INCTYPE=SYSTEM FULL=Y FILE=exp_incrN.dmp

5. Zamknąć bazę danych w trybie NORMAL lub IMMEDIATE.

6. Zmodyfikować parametr rollback_segments tak, aby jego wartość odwzorowywała nową strukturę bazy danych (zgodną ze strukturą bazy z ródłowej).
Uwaga: utworzona baza danych powinna posiadać przynajmniej jeden dodatkowy segment wycofania, oprócz segmentu systemowego. W przeciwnym przypadku, w czasie importowania danych użytkowników pojawi się komunikat:
IMP-00003: ORACLE error 1552 encountered
ORA-01552: cannot use system rollback segment for non-system tablespace ‚…’

7. Uruchomić bazę danych.

8. Zaimportować zawartość pliku ostatniego eksportu kompletnego.
imp system/manager INCTYPE=RESTORE FULL=Y FILE=exp_compl.dmp

9. Zaimportować wszystkie pliki eksportów kumulacyjnych wykonanych od czasu wykonania ostatniego eksportu kompletnego. Pliki te należy importować w takiej samej kolejności, w jakiej były eksportowane.
imp system/manager INCTYPE=RESTORE FULL=Y FILE=exp_cumul1.dmp

imp system/manager INCTYPE=RESTORE FULL=Y FILE=exp_cumulN.dmp

10. Zaimportować wszystkie pliki eksportów inkrementalnych wykonanych od czasu wykonania ostatniego eksportu kumulacyjnego. Pliki te należy importować w takiej samej kolejności, w jakiej były eksportowane.
imp system/manager INCTYPE=RESTORE FULL=Y FILE=exp_incr1.dmp

imp system/manager INCTYPE=RESTORE FULL=Y FILE=exp_incrN.dmp

Poniżej przedstawiono przykładową procedurę importowania zawartości bazy danych, wyeksportowanej za pomocą kolejnych eksportów:

  • kompletnego X0,
  • inkrementalnego I1,
  • inkrementalnego I2,
  • kumulacyjnego C1,
  • inkrementalnego I3 (zob. część II artykułu, punkt 4.2.3).
  1. Wczytanie ostatniego eksportu, tj. inkrementalnego, tj. I7.
    imp system/manager INCTYPE=SYSTEM FULL=Y FILE=I7.dmp

  2. Wczytanie ostatniego eksportu kompletnego, tj. X0.
    imp system/manager INCTYPE=RESTORE FULL=Y FILE=X0.dmp

  3. Wczytanie eksportu kumulacyjnego C1.
    imp system/manager INCTYPE=RESTORE FULL=Y FILE=C1.dmp

  4. Wczytanie eksportu kumulacyjnego C2.
    imp system/manager INCTYPE=RESTORE FULL=Y FILE=C2.dmp

  5. Wczytanie pliku eksportu inkrementalnego I6.
    imp system/manager INCTYPE=RESTORE FULL=Y FILE=I6.dmp

  6. Wczytanie kolejnego pliku eksportu inkrementalnego, tj. I7.
    imp system/manager INCTYPE=RESTORE FULL=Y FILE=I7.dmp

Robert Wrembel
Instytut Informatyki Politechniki Poznańskiej
wrembel@cs.put.poznan.pl