oracle rman recovery - ghdrako/doc_snipets GitHub Wiki

Most common recovery scenarios

  • Incomplete recovery of an entire database
  • Complete database recovery with zero data loss
  • Recovery of corrupted or missing control files due to loss of all control file copies
  • Datafile-level and tablespace-level recovery
  • Tablespace point-in-time recovery
  • Recovery of a single table or table partition
  • Recovery of one or more database blocks
  • Recovery of a lost, damaged, or missing SPFILE
  • Loss of one or more online redo log members
  • Loss of an entire online redo log group (especially the current group!)
  • Complete disaster recovery when the entire database—all datafiles, control file copies, and SPFILE—is lost
  • Hardware, firmware, or software failures (including partial or complete loss of an Oracle Clusterware, Grid Infrastructure, or database home and related binary files)

Test recovery scenario

Test without actually performing the recovery operation.

RMAN> RESTORE DATABASE VALIDATE;
RMAN> RESTORE ARCHIVELOG ALL VALIDATE;

SQL> SELECT name,item,sofar,total FROM v$recovery_progress;

Lost data file

Utrata pliku danych może nastąpić w wyniku przypadkowego usunięcia lub uszkodzenia pliku, zwłaszcza w nagłówku pliku. Ponieważ wszystkie inne części bazy danych są nienaruszone, wystarczy zapisać brakujący plik danych z ostatniej kopii zapasowej i zaktualizować go. Baza danych może być dostępna podczas procesu odzyskiwania. Jednak użytkownicy otrzymują komunikaty o błędach, gdy próbują uzyskać dostęp do pliku danych, którego dotyczy problem, lub skojarzonego obszaru tabel.

 $ rm /u01/oracle/oradata/MITP/users01.dbf

W systemie operacyjnym Windows nie jest możliwe usunięcie pliku danych przy otwartej bazie danych. Zapobiega temu system operacyjny.

SQL> CREATE TABLE test(id NUMBER) TABLESPACE users;
 CREATE TABLE test(id NUMBER) TABLESPACE users
 FEHLER in Zeile 1:
 ORA-01116: Fehler beim Öffnen der Datenbankdatei 4
 ORA-01110: Datendatei 4: 
'/u01/oracle/oradata/MITP/users01.dbf'
 ORA-27041: Datei kann nicht geöffnet werden
 Linux-x86_64 Error: 2: No such file or directory
 Additional information: 3

Wykonaj następujące kroki, aby przywrócić bazę danych

  1. Ustaw skojarzony tablespace w trybie OFFLINE.
 SQL> ALTER TABLESPACE users OFFLINE IMMEDIATE;
  1. Wykonaj przywracanie i odzyskiwanie utraconego pliku danych
RMAN> RUN {
 2> RESTORE DATAFILE 4;
 3> RECOVER DATAFILE 4;
 4> }
  1. Przełącz tablespace users w stan ONLINE
 SQL> ALTER TABLESPACE users ONLINE;

Disaster Recovery

Przywrócenia bazy danych po całkowitej utracie. Typowym przykładem jest całkowita awaria serwera, w tym podsystemu we/wy. Baza danych musi zostać zapisana z powrotem na nowym serwerze. Aby się przygotować, instalowane jest oprogramowanie Oracle i tworzona jest identyczna struktura katalogów. Baza danych może zostać przywrócona na nośnik zewnętrzny do czasu wykonania ostatniej kopii zapasowej.

Utrata plików dziennika redo log online

Scenariusz odzyskiwania dla utraty wszystkich członków grupy dziennika ponawiania online zależy od ich bieżącego stanu. Utrata grupy ze statusem INACTIVE może zostać skorygowana bez odzyskiwania. Grupa nie jest obecnie używana i nie jest potrzebna do odzyskiwania po awarii.

SQL> SELECT group#,status
  2  FROM v$log;
    GROUP# STATUS
---------- ---------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT

Pliki z grupy 3 zostały utracone. Grupa ma status CURRENT. W takim przypadku nalezy wykonać odszyskiwanie W takim przypadku nalezy wykonac Incomplete Recovery z backupu.

STARTUP NOMOUNT
SET DBID 1426949183;
RMAN> RUN {
 2> SET UNTIL TIME "TO_DATE('24.03.2019 23:30:00',
 'DD.MM.YYYY HH24:MI:SS')";
 3> RESTORE CONTROLFILE FROM AUTOBACKUP;
 4> ALTER DATABASE MOUNT;
 5> RESTORE DATABASE;
 6> RECOVER DATABASE;
 7> ALTER DATABASE OPEN RESETLOGS;
 8> }

Łatwiej jest przywrócić, jeśli grupa dzienników ponawiania ze stanem INACTIVE zostanie utracona. Musisz jednak szybko zareagować, zanim grupa osiągnie status ACTIVE. Uruchom następujące polecenie, aby ponownie utworzyć grupę plików dziennika:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 2;