Un posibil scenariu de film de groază
Ideea e cam așa: folosim RMANu' să facem backup-uri regulate ale bazei de date. În plus, așa cum recomandă băieții de la Oracle (vezi nota 388422.1 de pe Oracle Support), e bine să ai configurată opțiunea de AUTOBACKUP a fișierului de control. Cu opțiunea asta setată, Oracle are grijă să faca un backup la fișierul de control și la SPFILE după fiecare backup, dar și după orice DDL care are impact asupra structurii fizice a bazei de date: ștergere/creare de fișiere de date noi sau tablespace-uri, schimbarea stării unui fișier de date (spre exemplu din ONLINE în OFFLINE) etc.Buuun, am configurat autobackup-ul fișierului de control și, în plus, ne gandim noi că ar fi frumos să avem și o politică de retenție: REDUNDANCY 2. Ce înseamnă asta? Că un backup devine "bun de șters" de îndată ce avem cel puțin două backup-uri mai recente. Sună bine! În fond și la urma urmei asta înseamnă că vom avea cel puțin două backup-uri, ceea ce ne va proteja dacă, doamne ferește, unul din ele se corupe din varii motive.
Mai jos, iată o posibilă serie de evenimente "nevinovate":
Dacă ne uităm bine, se poate observa că avem căte un auto-backup la fișierul de control după fiecare backup al bazei de date (la momentele t1, t2, t3), dar și două auto-backup-uri intermediare la momentele t2' și la t2'', atunci când au intervenit modificări de structură a bazei de date. Deoarece avem configurată o politică de retenție, scriptul care face zilnic backup-ul la baza de date execută la final și o comanda de "DELETE NOPROMPT OBSOLETE", altfel politica de retenție nu prea și-ar mai avea rostul.
Să vedem ce se întâmplă după rularea acestei comenzi:
Faptul că backup-ul bazei de date de la momentul t1, cel mai vechi, este șters nu e nici o surpriză. Pe de altă parte, se poate observa că backup-uri mult mai recente ale fișierului de control sunt șterse fără drept de apel. Într-adevăr, redundanța backup-urilor fișierului de control este tot doi, însă, din păcate, pierdem fișierul de control dinaintea momentului t', adică înainte de ștergerea tablespace-ului. Asta înseamnă că suntem într-o mare încurcătură dacă suntem solicitați să restaurăm baza de date astfel încât să recuperăm tablespace-ul șters. Pentru asta ne-ar trebui un fișier de control de dinaintea ștergerii. Interesant, nu?
Fapte, nu vorbe!
Asta era un slogan cretinel dintr-o campanie electorală. Ideea e că am tot discutat la nivel teoretic ce s-ar putea întâmpla, dar frumos ar fi să vedem și transpunerea lui în practică.Baza de date cobai se cheama TEODB. Să vedem ce setări de RMAN are:
RMAN> show all; RMAN configuration parameters for database with db_unique_name TEODB are: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.2.0/db_1/dbs/snapcf_teodb.f'; # defaultFacem un prim backup al bazei de date:
RMAN> backup as compressed backupset (database tag 't1') plus archivelog tag 't1'; ... RMAN> list backup of database summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 9 B F A DISK 18-SEP-13 1 1 YES T1 RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-SEP-13 1 1 NO TAG20130918T180843După cum se poate observa avem backup-ul bazei de date cu tag-ul "T1" și un auto-backup pentru fișierul de control cu un tag ciudat. Dacă am rula acum o comanda de "DELETE OBSOLETE", evident, nici un backup nu va fi șters.
RMAN> delete obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 2 using channel ORA_DISK_1 no obsolete backups foundSă mergem mai departe cu cel de-al doilea backup. Folosim fix aceeași comandă doar cu tag-ul modificat în t2:
RMAN> backup as compressed backupset (database tag 't2') plus archivelog tag 't2'; ... RMAN> list backup of database summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 9 B F A DISK 18-SEP-13 1 1 YES T1 13 B F A DISK 18-SEP-13 1 1 YES T2 RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-SEP-13 1 1 NO TAG20130918T180843 15 B F A DISK 18-SEP-13 1 1 NO TAG20130918T181601Nimic spectaculos! Avem două backup-uri pentru baza de date plus două auto-backup-uri pentru fișierul de control. Să vedem ce se întâmplă dacă excutăm comanda "DELETE OBSOLETE"
RMAN> delete noprompt obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 2 using channel ORA_DISK_1 Deleting the following obsolete backups and copies: Type Key Completion Time Filename/Handle -------------------- ------ ------------------ -------------------- Archive Log 15 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_4_93mjf1md_.arc Backup Set 8 18-SEP-13 Backup Piece 8 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T1_93mjf1xk_.bkp deleted archived log archived log file name=/u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_4_93mjf1md_.arc RECID=15 STAMP=826481233 deleted backup piece backup piece handle=/u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T1_93mjf1xk_.bkp RECID=8 STAMP=826481233 Deleted 2 objectsCeea ce RMAN a considerat "bun de șters" a fost o arhivă de dinaintea primului backup, plus backup-ul acesteia. În acest moment suntem fix pe axa "T2" din schema cu desfășurarea evenimentelor.
Bun, acum să simulăm momentele t2' și t2''. La t2' ștergem un tablespace foarte important pentru baza de date. La beție se poate întâmpla orice, nu-i așa?
SQL> drop tablespace muci_tbs including contents and datafiles; Tablespace dropped.După rularea comenzii de mai sus ar trebui ca Oracle să se prindă și să facă automat un backup la fișierul de control. Din păcate, în 11g se prinde mai greu, prin urmare va trebui să așteptăm câteva minute bune până să vedem auto-backup-ul făcut. Documentația oficială zice:
Starting with Oracle 11g Release 2, RMAN creates a single autobackup file encompassing all of the structural changes that have occurred within a few minutes of each other rather than creating a new backup of the controlfile on each structural change to the database.
După câteva minute ar trebui să vedem trei backup-uri pentru fișierul de control.
RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-SEP-13 1 1 NO TAG20130918T180843 15 B F A DISK 18-SEP-13 1 1 NO TAG20130918T181601 16 B F A DISK 18-SEP-13 1 1 NO TAG20130918T183503Pentru momentul t2'' haideți să creăm un nou tablespace astfel încât să mai obținem un backup la fișierul de control. Știu, în schemă era ceva cu setarea pe READONLY a unui tablespace, dar dat fiind ca baza de date cobai este "cheală" (adik instalata cu next, next, next) nu am nici un tablespace DUMMY sa-l fac READONLY. Oricum, ideea e aceeasi, vrem sa obținem încă un auto-backup pentru fișierul de control.
SQL> create tablespace test_tbs datafile size 10M; Tablespace created.În câteva minute ar trebui să putem vedea cel de-al patrulea autobackup:
RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-SEP-13 1 1 NO TAG20130918T180843 15 B F A DISK 18-SEP-13 1 1 NO TAG20130918T181601 16 B F A DISK 18-SEP-13 1 1 NO TAG20130918T183503 17 B F A DISK 18-SEP-13 1 1 NO TAG20130918T184503Buoooon! Mai avem momentul "T3" pe axa de evenimente. Simplu! Mai facem un backup:
RMAN> backup as compressed backupset (database tag 't3') plus archivelog tag 't3'; ... RMAN> list backup of database summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 9 B F A DISK 18-SEP-13 1 1 YES T1 13 B F A DISK 18-SEP-13 1 1 YES T2 19 B F A DISK 18-SEP-13 1 1 YES T3 RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 11 B F A DISK 18-SEP-13 1 1 NO TAG20130918T180843 15 B F A DISK 18-SEP-13 1 1 NO TAG20130918T181601 16 B F A DISK 18-SEP-13 1 1 NO TAG20130918T183503 17 B F A DISK 18-SEP-13 1 1 NO TAG20130918T184503 21 B F A DISK 18-SEP-13 1 1 NO TAG20130918T191128În sfârșit, avem șirul complet din seria de evenimente prevăzute în "scenariul de groază". Să vedem ce se întâmplă în acest moment daca rulăm "DELETE OBSOLETE" command:
RMAN> delete obsolete; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 2 using channel ORA_DISK_1 Deleting the following obsolete backups and copies: Type Key Completion Time Filename/Handle -------------------- ------ ------------------ -------------------- Archive Log 16 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_5_93mjhsg2_.arc Backup Set 9 18-SEP-13 Backup Piece 9 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T1_93mjf3w7_.bkp Backup Set 10 18-SEP-13 Backup Piece 10 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T1_93mjhtc2_.bkp Backup Set 11 18-SEP-13 Backup Piece 11 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826481323_93mjhwc6_.bkp Archive Log 17 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_6_93mjvcqj_.arc Backup Set 12 18-SEP-13 Backup Piece 12 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T2_93mjvcy4_.bkp Backup Set 15 18-SEP-13 Backup Piece 15 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826481761_93mjxldk_.bkp Backup Set 16 18-SEP-13 Backup Piece 16 18-SEP-13 /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826482903_93ml190b_.bkpCu ce backup-uri am ramas?
RMAN> list backup of database summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 13 B F A DISK 18-SEP-13 1 1 YES T2 19 B F A DISK 18-SEP-13 1 1 YES T3 RMAN> list backup of controlfile summary; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 17 B F A DISK 18-SEP-13 1 1 NO TAG20130918T184503 21 B F A DISK 18-SEP-13 1 1 NO TAG20130918T191128În acest moment sunt fix în situația prezentată în cea de-a doua figură. Precum se poate observa, am pierdut fișierul de control de dinaintea ștergerii tablespace-ului MUCI_TBS!
Se mai poate face ceva?
După ce ne revenim din starea de perplexitate ar trebui să vedem cum putem, totuși, recupera datele pierdute. Putem merge pe mai multe piste.Încercarea 1: Funcționează cu fișierul de control curent?
Păi să vedem. Ar trebui să facem un "restore" la fișierele de date din backup-ul "T2" și să facem un "incomplete recovery" până fix înainte de ștergerea tablespace-ului. Haideți să vedem cum arată backup-ul "T2":
RMAN> list backup of database tag "T2";
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
13 Full 273.84M DISK 00:00:57 18-SEP-13
BP Key: 13 Status: AVAILABLE Compressed: YES Tag: T2
Piece Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp
List of Datafiles in backup set 13
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
1 Full 1482443 18-SEP-13 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_system_93joylqx_.dbf
2 Full 1482443 18-SEP-13 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_sysaux_93joylt5_.dbf
3 Full 1482443 18-SEP-13 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_undotbs1_93joylvk_.dbf
4 Full 1482443 18-SEP-13 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_users_93joym23_.dbf
5 Full 1482443 18-SEP-13
După cum se poate observa, deși backup-ul "T2" are o referință la fișierul de date 5, s-a pierdut legătura cu
fișierul de date din baza de date. Legătura era în fișierul de control, dar, dat fiind că respectivul tablespace
a fost șters, s-a efectuat și ștergerea înregistrării corespunzătoare din fișierul de control. Orice tentativă de a face
restore la vechiul fișier de date #5 folosind RMAN este sortită eșecului.
RMAN> restore datafile 5 from tag "T2"; Starting restore at 19-SEP-13 using channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 09/19/2013 10:37:37 RMAN-06026: some targets not found - aborting restore RMAN-06023: no backup or copy of datafile 5 found to restore
Încercarea 2: Adăugăm manual fișierul lipsă
În unele scenarii de "recovery", trebuia adăugat la mână un fișier de date nou-nouț peste care Oracle să poată aplica redolog. Ne gândim că poate reușim să-l pacălim pentru a restabili legătura dintre backup-ul nostru și informația din fișierul de control:SQL> alter database create datafile 5 as '/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf'; alter database create datafile 5 as '/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf' * ERROR at line 1: ORA-01182: cannot create database file 5 - file is in use or recovery ORA-01110: data file 5: '/u01/app/oracle/oradata/TEODB/datafile/o1_mf_test_tbs_93ml83bm_.dbf'Nici o șansă! În acest moment există un alt fișier de date cu identificatorul 5:
RMAN> report schema;
Report of database schema for database with db_unique_name TEODB
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 720 SYSTEM *** /u01/app/oracle/oradata/TEODB/datafile/o1_mf_system_93joylqx_.dbf
2 630 SYSAUX *** /u01/app/oracle/oradata/TEODB/datafile/o1_mf_sysaux_93joylt5_.dbf
3 70 UNDOTBS1 *** /u01/app/oracle/oradata/TEODB/datafile/o1_mf_undotbs1_93joylvk_.dbf
4 5 USERS *** /u01/app/oracle/oradata/TEODB/datafile/o1_mf_users_93joym23_.dbf
5 10 TEST_TBS *** /u01/app/oracle/oradata/TEODB/datafile/o1_mf_test_tbs_93ml83bm_.dbf
Este vorba de fișierul de date al tablespace-ului pe care l-am creat la momentul t2''. Oricum, chiar daca nu ar fi existat acest fișier de
date, tot nu ar fi funcționat!
SQL> alter database create datafile 6 as '/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf'; alter database create datafile 6 as '/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf' * ERROR at line 1: ORA-01516: nonexistent log file, data file, or temporary file "6"Precum se poate observa, am folosit un identificator de fișier de date despre care fișierul de control nu știe. Deci putem renunța liniștiți la ideea asta.
Încercarea 3: Recreăm fișierul de control
Următoarea idee ar fi să recreăm "la mânuță" fișierul de control. Nu e chiar așa complicat!SQL> alter database backup controlfile to trace; Database altered.Căutam frumușel fișierul de trace și ar trebui să avem acolo comenzile necesare recreării fișierului de control. Evident, dat fiind că discutăm de un "incomplete recovery" al bazei de date, vom merge pe varianta RESETLOGS. Dat fiind că ce am generat acum corespunde structurii actuale a bazei de date, va trebui să facem căteva modificări:
CREATE CONTROLFILE REUSE DATABASE "TEODB" RESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 (
'/u01/app/oracle/oradata/TEODB/onlinelog/o1_mf_1_93jymhly_.log',
'/u01/app/oracle/fast_recovery_area/TEODB/onlinelog/o1_mf_1_93jymhpt_.log'
) SIZE 50M BLOCKSIZE 512,
GROUP 2 (
'/u01/app/oracle/oradata/TEODB/onlinelog/o1_mf_2_93jymsht_.log',
'/u01/app/oracle/fast_recovery_area/TEODB/onlinelog/o1_mf_2_93jymsmw_.log'
) SIZE 50M BLOCKSIZE 512,
GROUP 3 (
'/u01/app/oracle/oradata/TEODB/onlinelog/o1_mf_3_93jyn2y9_.log',
'/u01/app/oracle/fast_recovery_area/TEODB/onlinelog/o1_mf_3_93jyn34t_.log'
) SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
'/u01/app/oracle/oradata/TEODB/datafile/o1_mf_system_93joylqx_.dbf',
'/u01/app/oracle/oradata/TEODB/datafile/o1_mf_sysaux_93joylt5_.dbf',
'/u01/app/oracle/oradata/TEODB/datafile/o1_mf_undotbs1_93joylvk_.dbf',
'/u01/app/oracle/oradata/TEODB/datafile/o1_mf_users_93joym23_.dbf',
'/u01/app/oracle/oradata/TEODB/datafile/o1_mf_test_tbs_93ml83bm_.dbf'
'/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf'
CHARACTER SET AL32UTF8
;
Am sters referința la fișierul de date ce aparținea tablespace-ului TEST_TBS pentru că oricum într-un "incomplete database
recovery" nu mai ajungem în punctul în care acel tablespace a fost creat. În plus, am adăugat referința la vechiul fișier de
date al tablespace-ului MUCI_TBS pe care dorim să-l restaurăm. Să vedem ce se întâmplă când rulăm comanda de mai sus:
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup nomount ORACLE instance started. Total System Global Area 839282688 bytes Fixed Size 2233000 bytes Variable Size 528485720 bytes Database Buffers 306184192 bytes Redo Buffers 2379776 bytes SQL> @create_ctl.sql CREATE CONTROLFILE REUSE DATABASE "TEODB" RESETLOGS ARCHIVELOG * ERROR at line 1: ORA-01503: CREATE CONTROLFILE failed ORA-01565: error in identifying file '/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf' ORA-27037: unable to obtain file status Linux-x86_64 Error: 2: No such file or directory Additional information: 3Ouch! Asta a durut! Ca să meargă comanda de creare a fișierului de control, fișierele de date trebuie să fie accesibile. Avem tot ce ne trebuie mai puțin fișierul tablespace-ului MUCI_TBS. Dacă vă gandiți că putem păcăli serverul creând un fișier gol la locația cu pricina, luati-vă gândul! Nu va funcționa pentru că Oracle va verifica și header-ul fișierului și se va prinde că nu e unul valid. Oricum faza "cretină" e că avem backup-ul la acest fișier de date, dar nu putem să-l extragem din backupset folosind RMAN.
RMAN> restore datafile 5; Starting restore at 19-SEP-13 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 09/19/2013 RMAN-20201: datafile not found in the recovery catalog RMAN-06010: error while looking up datafile: 5Bun, e clar! E timpul să "hackerim" RMAN-ul și să incercăm să extragem fișierul de date prin metoda "brută". S-ar părea că există un API PL/SQL de RMAN, nedocumentat, dar folosit de RMAN ca să-și facă treaba. Pentru cei interesați, se poate googăli după: DBMS_BACKUP_RESTORE. În cazul nostru, soluția salvatoare este:
DECLARE
devtype varchar2(256);
done boolean;
BEGIN
devtype := dbms_backup_restore.DeviceAllocate(type => '',
ident => 'RESTORE_DBFILE');
dbms_backup_restore.RestoreSetDatafile;
dbms_backup_restore.RestoreDatafileTo(dfnumber => 5,
toname =>'/u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf');
dbms_backup_restore.RestoreBackupPiece(done=>done,
handle =>'/u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp',
params =>null);
dbms_backup_restore.DeviceDeallocate;
END;
/
Pare complicat, dar nu e! Specificăm destinația RESTORE-ului cu "RestoreDatafileTo", iar cu "RestoreBackupPiece" inidicăm în ce fișier de backup
se găsește fișierul nostru de date. Să vedem ce se întâmplă:
SQL> @restore_muci.sql PL/SQL procedure successfully completed. SQL> !ls /u01/app/oracle/oradata/TEODB/datafile/ muci_tbs.dbf o1_mf_sysaux_93joylt5_.dbf o1_mf_system_93joylqx_.dbf o1_mf_test_tbs_93ml83bm_.dbf o1_mf_undotbs1_93joylvk_.dbf o1_mf_users_93joym23_.dbfSună promițător! Am reușit să restaurăm fișierul "muci_tbs.dbf" ocolind interfața RMAN. Să vedem acum dacă putem recrea fișierul de control:
SQL> @create_ctl.sql Control file created.Wow, avem fișierul de control! Acum să vedem dacă putem să-l folosim pentru a recupera tablespace-ul pierdut. Întâi de toate, dat fiind că fișierul asta de control e "chelbos", trebuie sa-i zicem unde se găsesc backup-urile.
RMAN> catalog start with '/u01/app/oracle/fast_recovery_area/TEODB/'; using target database control file instead of recovery catalog searching for all files that match the pattern /u01/app/oracle/fast_recovery_area/TEODB/ List of Files Unknown to the Database ===================================== File Name: /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826483503_93mln09m_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826485088_93mn5kf9_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T3_93mn3n80_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T3_93mn5h60_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T3_93mn3oh7_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T2_93mjxj49_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_9_93mn5gdg_.arc File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_8_93mn3n12_.arc File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_7_93mjxh8d_.arc Do you really want to catalog the above files (enter YES or NO)? YES cataloging files... cataloging done List of Cataloged Files ======================= File Name: /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826483503_93mln09m_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/autobackup/2013_09_18/o1_mf_s_826485088_93mn5kf9_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T3_93mn3n80_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T3_93mn5h60_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T3_93mn3oh7_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_annnn_T2_93mjxj49_.bkp File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_9_93mn5gdg_.arc File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_8_93mn3n12_.arc File Name: /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_7_93mjxh8d_.arcSă verificăm daca acum, cu noul fișier de control, backup-ul "T2" arată bine:
RMAN> list backup of database tag "t2";
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
3 Full 273.84M DISK 00:00:00 2013-18-09 18:14:53
BP Key: 3 Status: AVAILABLE Compressed: YES Tag: T2
Piece Name: /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp
List of Datafiles in backup set 3
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ------------------- ----
1 Full 1482443 2013-18-09 18:14:53 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_system_93joylqx_.dbf
2 Full 1482443 2013-18-09 18:14:53 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_sysaux_93joylt5_.dbf
3 Full 1482443 2013-18-09 18:14:53 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_undotbs1_93joylvk_.dbf
4 Full 1482443 2013-18-09 18:14:53 /u01/app/oracle/oradata/TEODB/datafile/o1_mf_users_93joym23_.dbf
5 Full 1482443 2013-18-09 18:14:53 /u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf
Perfect! Avem referința la fișierul de date al tablespace-ului MUCI_TBS. Tot ce ne-a mai rămas de făcut e să dăm drumul la
restaurarea bazei de date:
RMAN> run {
2> set until time "to_date('2013-09-18 18:15', 'yyyy-mm-dd hh24:mi')";
3> restore database;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 19-SEP-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=18 device type=DISK
skipping datafile 5; already restored to file /u01/app/oracle/oradata/TEODB/datafile/muci_tbs.dbf
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/TEODB/datafile/o1_mf_system_93joylqx_.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/TEODB/datafile/o1_mf_sysaux_93joylt5_.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/TEODB/datafile/o1_mf_undotbs1_93joylvk_.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/TEODB/datafile/o1_mf_users_93joym23_.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp
channel ORA_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/TEODB/backupset/2013_09_18/o1_mf_nnndf_T2_93mjvfdw_.bkp tag=T2
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:15
Finished restore at 2013-19-09 12:35:10
Starting recover at 19-SEP-13
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 7 is already on disk as file /u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_7_93mjxh8d_.arc
archived log file name=/u01/app/oracle/fast_recovery_area/TEODB/archivelog/2013_09_18/o1_mf_1_7_93mjxh8d_.arc thread=1 sequence=7
media recovery complete, elapsed time: 00:00:00
Finished recover at 19-SEP-13
RMAN> alter database open resetlogs;
using target database control file instead of recovery catalog
database opened
Momentul adevărului! Avem sau n-avem tablespace-ul mult dorit?
SQL> select tablespace_name from dba_tablespaces; TABLESPACE_NAME ------------------------------ SYSTEM SYSAUX UNDOTBS1 TEMP USERS MUCI_TBSVictorieee! Sau, cu alte cuvinte: "un fleac, i-am ciuruit"...
Concluzii
E timpul să tragem câteva concluzii. În primul rând, politica de retenție bazată pe redundanță nu e chiar o idee bună, mai ales dacă folosim opțiunea de AUTOBACKUP pentru fișierul de control. Mai degrabă e recomandat să mergem pe varianta "RECOVERY WINDOW OF n DAYS", politică de retenție mai "deșteaptă" în acest caz. Dacă vă încăpățânați să folosiți politica bazată pe retenție, atunci asigurați-vă că aveți o altă metodă prin care salvați versiunile vechi de backup-uri la fișierul de control sau le puneți pe "KEEP FOREVER".În al doilea rând, nu vă bazați pe faptul că o comandă de tip "BACKUP DATABASE INCLUDE CUREENT CONTROLFILE..." va include fișierul de control în același fișier de backup, împreună cu alte fișiere ale bazei de date. Ca idee, sună bine! Adică, respectivele backup-uri nu vor fi considerate ca bune de șters pentru simplu fapt că ele conțin backup-urile fișierelor de date care nu pot fi șterse încă. Totuși, mare atenție! Acest lucru, nu se întâmplă decât dacă discutăm de acceeași dimensiune a blocului fișierului de control și al fișierelor de date. În general, acest lucru nu este valabil, ceea ce înseamnă ca backup-ul la fișierul de control se va face într-un backup-piece separat și va fi șters de îndată ce politica de reduntanță va da undă verde.
0 commentarii:
Trimiteți un comentariu