validate oracle rman backup
Cum să creați și să validați Oracle RMAN Backup: învățați cu comenzile RMAN și procesul de recuperare
cum să falsifici o adresă de e-mail
În acest tutorial, vom discuta despre verificarea și testarea copiilor de rezervă ale bazei de date Oracle. Vom explica concepte precum ce, de ce și cum despre copiile de rezervă ale bazelor de date și metodele de testare a copiei de rezervă.
Vom lua Baza de date Oracle ca studiu de caz pentru acest tutorial.
Studiu de caz: Testarea backup-urilor bazei de date Oracle RMAN:
Ce veți învăța:
Procesul de validare a backupului bazei de date Oracle utilizând RMAN
L-am clasificat în următoarele patru secțiuni
- Ce este o copie de rezervă?
- De ce backup?
- Cum se face backup?
- Cum să testați / validați backupul bazei de date - Strategii de recuperare?
Citește și=> Totul despre testarea bazei de date
Ce este o copie de rezervă a bazei de date?
Înainte de a începe să aflăm mai multe despre copiile de rezervă, trebuie să înțelegem cel mai important atu al unei organizații - datele. Având în vedere că organizația dvs. rulează pe baza de date Oracle. Pentru a înțelege termenul „bază de date”, vă puteți referi la Seria Oracle Database Testing aici .
Datele unei organizații sunt cea mai integrantă parte a unei organizații. Luați în considerare o companie bancară cu amănuntul. Toate au o cantitate enormă de date - utilizator, sistem etc. În calitate de administrator de bază de date, administrator de sistem sau orice personal căruia i sa atribuit sarcina de protejare a acestor date, ar trebui să fie conștienți de cât de importante sunt datele pentru o organizație. Cum să vă asigurați că datele sunt întotdeauna disponibile? Faceți o copie de rezervă a acestor date.
O copie de rezervă este o copie exactă a bazei de date care vă poate ajuta să vă reconstruiți datele în caz de pierdere a datelor.
De ce Backup Baza de Date?
Luați în considerare un caz simplu în care organizația dvs. bancară care are date referitoare la milioane de clienți în ceea ce privește numerele de cont, nume, nominalizați, sold bancar și organizația și-au pierdut toate datele, cum ar reacționa clienții lor la aceasta? Cum s-ar confrunta organizația cu presiunea de a pierde atât de multe date? Cum ar fi ele răspunzătoare pentru atât de mulți clienți nemulțumiți?
Acesta este motivul pentru care salvăm aceste date astfel încât, în cazul unei defecțiuni a unui disc (stocare), controlerului de disc (controlerului de stocare) să ne putem baza întotdeauna pe backupul nostru de unde îl putem restabili în baza de date, adică sistemul de fișiere de stocare și să nu clienții își pierd oricare dintre datele lor.
Ipotetic vorbind, să presupunem că există milioane de clienți și fiecare dintre aceștia efectuează milioane de tranzacții, iar baza de date se blochează accidental și își pierde datele, le-am cere tuturor acestor clienți să-și reintroducă din nou datele? Cum ar face față pierderii atâtor date? Ar fi extrem de inacceptabil.
În mod similar, luați în considerare o companie de telecomunicații care susține milioane de clienți și dispune de toate datele lor cu privire la numerele de telefon, adrese, creditul utilizat, plăți în așteptare. Ce se întâmplă dacă pierdem toate datele lor? Compania este condamnată și ar trebui să suporte costuri uriașe care ar putea opri organizația. Ar fi cu siguranță o catastrofă uriașă.
Cum se face backup pentru baza de date?
Pentru a copia datele dintr-o bază de date Oracle, avem mai multe metode. Ele pot fi clasificate în general ca copii de rezervă fizice și logice
Metoda nr. 1)Backup-uri fizice :
- 3rdcopii de rezervă pentru petreceri - cum ar fi Veritas NetBackup, SAP, IBM Tivoli Manager, EMC, HP
- Copii de siguranță gestionate de utilizator - Copie de rezervă a unei baze de date utilizând utilitare OS cum ar fi copierea (Windows), cp (Unix).
- Oracle Secure Backup
- Utilitarul meu preferat și cel mai preferat recomandat Oracle - Recover Manager ( RMAN ).
Metoda # 2)Copii de rezervă logice:
- Utilități convenționale de export / import și utilități Datapump. O copie de rezervă logică este o copie de rezervă a datelor logice - obiecte cum ar fi tabele, indici etc. care constituie o bază de date independentă de locația obiectelor de mai sus.
Pentru a înțelege structurile de stocare fizice și logice ale unei baze de date la care ați putea face trimitere acest și această documentație oracle .
Care este cea mai bună metodă pentru Backup-ul bazei de date?
Fiecare dintre aceste strategii de rezervă are propriile argumente pro și contra și nu vom trata prea mult cu ele în acest articol.
Trebuie să înțelegem că, cu excepția cazului în care aveți o copie de rezervă fizică, doar să aveți o copie de rezervă logică nu este întotdeauna sigur împotriva corupției fizice a datelor, a problemelor de stocare hardware. Având o copie de siguranță fizică validă, bună, o face o strategie bună de copiere de rezervă și recuperare. Asigurați-vă întotdeauna că aveți o copie de rezervă fizică.
În realitate, putem folosi oricare dintre metodele de mai sus, dar trebuie întotdeauna să ne asigurăm că avem o strategie bună de backup și recuperare, pentru a evita orice sughiț inutil în timpul funcționării unei baze de date. Este întotdeauna recomandat să vă testați strategiile de recuperare și spate pe un sistem de testare în oglindă, astfel încât să putem prezice timpul necesar pentru ca baza de date să funcționeze și să funcționeze în cazul unor situații neprevăzute.
În acest articol, ne vom concentra în principal pe copiile de rezervă RMAN. Acest lucru ne aduce la un punct de a cunoaște exact cum efectuăm backupul.
Comenzi de backup Oracle RMAN (Oracle Recovery Manager)
Putem face backup datelor fie cu ajutorul modului Enterprise Manager (GUI), fie prin promptul din linia de comandă a sistemului de operare.
RMAN este un instrument robust și sofisticat furnizat de Oracle pentru a efectua backup și recuperare.
RMAN este instalat automat când instalați baza de date Oracle, deci nu este necesară instalarea suplimentară RMAN .
RMAN mediul cuprinde două componente:
1) Baza de date țintă (baza de date pe care ați face backup, efectuați recuperarea și
2) Client RMAN care este clientul care interpretează comenzile utilizatorului și le execută în numele utilizatorului în timp ce se conectează la baza de date țintă.
O comandă simplă pentru conectarea la baza de date utilizând RMAN este următoarea:
C:Usersxyz> rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Sun Sep 28 17:32:48 2014 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1361070653) RMAN>
DBID aici este identificatorul unic care este unic pentru fiecare bază de date cu care intenționăm să lucrăm.
În acest exemplu, avem de-a face cu o bază de date numită ORCL .
Vom face copii de rezervă ale datelor care aparțin bazei de date ORCL.
Deoarece o copie de rezervă este o copie fizică a bazei de date, avem nevoie de o locație / director în care să le putem salva.
Pentru a realiza acest lucru, putem folosi un director special numit db_recovery_file_dest care servește drept locație de rezervă. Definiți dimensiunea acestui parametru cu db_recovery_file_dest_size care marchează dimensiunea acestei locații de rezervă.
Deși avem mai multe moduri de a vă comprima copiile de rezervă și mai multe tehnici care pot reduce dimensiunea unei copii de rezervă, încercați cel puțin să setați DB_RECOVERY_FILE_DEST_SIZE la o dimensiune a datelor dvs. reale din baza de date. Asigurați-vă că țineți cont și de jurnalele de arhivă, care nu sunt altceva decât jurnalele de refacere offline care înregistrează modificările blocurilor dvs. de date.
Strategia dvs. de backup ar consta în toate fișierele legate de baza de date, cum ar fi fișierele de date, fișierele de control, fișierele de parametri, fișierele legate de rețea, fișierele jurnal de refacere arhivate.
RMAN sau orice alt instrument de backup fizic poate face backup fișierelor de date, fișierelor de control, fișierelor de parametri, fișierelor jurnal de refacere arhivate. Fișierele legate de rețea trebuie să fie copiate manual cu ajutorul utilitarelor OS cum ar fi cp sau copy.
Pentru a face backup unei baze de date folosim:
„Baza de date de rezervă” - este la fel de simplă. Deci, să începem să facem backup pentru baza noastră de date ORCL.
Deoarece ne-am conectat deja la baza de date Target (ORCL), lansăm comanda „backup database”.
RMAN> backup database; Starting backup at 05-OCT-14 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=198 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:04:27 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 05-OCT-14 channel ORA_DISK_1: finished piece 1 at 05-OCT-14 piece handle=D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP tag=TAG20141005T162412 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:04 Finished backup at 05-OCT-14
Aici, observăm că backupul tuturor fișierelor aferente ale bazei de date - fișiere de date, fișiere de control, fișier spfile (fișier parametru) a fost finalizat. Operațiunea de backup a durat aproximativ 4 minute și 27 de secunde (Timp scurs). Aceasta este o bază de date de testare mică, cu doar 5 fișiere de date, astfel încât a fost nevoie de mai puțin timp pentru backup.
În cazurile în care dorim să facem backup datelor din bazele de date ale organizațiilor gigant, ar putea exista sute de fișiere de date și fiecare fișier de date ar putea avea dimensiuni terabyte, iar efectuarea unei copii de rezervă complete a bazei de date ar putea dura câteva ore.
Pentru a cunoaște detaliile referitoare la copierea de rezervă pe care tocmai am creat-o, vom executa:
RMAN> backup de listă;
List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5 Full 9.58M DISK 00:00:06 05-OCT-14 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NCSNF_TAG20141005T162412_B3293806_.BKP SPFILE Included: Modification time: 05-OCT-14 SPFILE db_unique_name: ORCL Control File Included: Ckp SCN: 9705762 Ckp time: 05-OCT-14
Această copie de rezervă este plasată în locația DB_RECOVERY_FILE_DEST care este definită ca D: APP1 SUNTYADA FLASH_RECOVERY_AREA
SQL> show parameter DB_RECOVERY_FILE_DEST NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string D:app1suntyadaflash_recovery_area db_recovery_file_dest_size big integer 3912M
Dimensiunea definită pentru locația noastră de rezervă este de 3912 MB.
Utilizați VALIDARE pentru a verifica fișierele și copiile de rezervă ale bazei de date:
RMAN> VALIDAȚI BAZA DE DATE;
Validați backupul RMAN
Cum testăm sau validăm faptul că ne putem recupera baza de date în timpul oricărei crize?
Dacă din cauza unei defecțiuni hardware sau a unor corupții ale discurilor dvs. de stocare, am avea nevoie de o copie de rezervă bună disponibilă pentru a restabili aceste date corupte, astfel încât să nu pierdem niciun fel de date care au aparținut acelor fișiere de stocare.
Totul depinde de modul în care ați proiectat copiile de rezervă, de intervalele la care sunt programate copiile de rezervă, dacă faceți o copie de rezervă completă și aveți copii de rezervă incrementale.
În caz de erori de utilizator - cum ar fi o manipulare inutilă a datelor, putem restaura părți de date sau toate datele care au fost modificate prin backup-uri logice.
În practică, ar trebui să fim conștienți și să prevedem orice erori care ar putea apărea în viitor și să testăm fiecare strategie pentru a le sustrage.
Utilizați comanda BACKUP VALIDATE pentru a valida fișierele de rezervă:
Comanda pentru verificarea numai a corupției fizice:
RMAN> VALIDARE BACKUP
BAZĂ DE DATE
ARHIVELOG TOATE;
Comanda pentru verificarea corupției fizice și logice:
RMAN> VALIDARE BACKUP
VERIFICAȚI LOGICA
BAZĂ DE DATE
ARHIVELOG TOATE;
RMAN> BAZA DE DATE DE VALIDARE A CUPURILOR DE SECURITATE ;
Starting backup at 05-OCT-14 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF input datafile file number=00002 name=D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF input datafile file number=00005 name=D:APP1SUNTYADAORADATAORCLEXAMPLE01.DB input datafile file number=00003 name=D:APP1SUNTYADAORADATAORCLUNDOTBS01.DB input datafile file number=00004 name=D:APP1SUNTYADAORADATAORCLUSERS01.DBF channel ORA_DISK_1: backup set complete, elapsed time: 00:00:45 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 1 OK 0 13430 106376 9708800 File Name: D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 75217 Index 0 12706 Other 0 5015 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 2 OK 0 21161 95409 9708826 File Name: D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 23010 Index 0 21760 Other 0 29429 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 3 OK 0 0 5762 9708826 File Name: D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 5760 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 4 OK 1125 228 5765 9528788 File Name: D:APP1SUNTYADAORADATAORCLUSERS01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 2295 Index 0 39 Other 0 3198 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 5 OK 0 1687 10498 9585679 File Name: D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 4760 Index 0 1261 Other 0 2788 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined ------------ ------ -------------- --------------- SPFILE OK 0 2 Control File OK 0 608 Finished backup at 05-OCT-14
După cum puteți observa mai sus, starea fiecărui fișier este „ Bine ”Ceea ce înseamnă că acestea sunt utilizabile și pot fi folosite pentru a restabili fișierele în orice moment.
Putem efectua o previzualizare a restaurării bazei de date. Acest lucru vă oferă o listă frumoasă de fișiere și disponibilitatea acestora fără a restabili efectiv fișierele.
Utilizați comanda RESTORE pentru a valida backupul:
RMAN> RESTAURĂ VALABILA BAZEI DE DATE;
RESTAURĂ ARHIVELOGUL TOATE VALIDE;
RMAN> RESTAURĂ PREVIZUALIZAREA BAZEI DE DATE;
Starting restore at 05-OCT-14 using channel ORA_DISK_1 List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 4 Full 1.39G DISK 00:04:23 05-OCT-14 BP Key: 4 Status: AVAILABLE Compressed: NO Tag: TAG20141005T162412 Piece Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLBACKUPSET2014_10_05O1_MF_NNNDF_TAG20141005T162412_B328TXQG_.BKP List of Datafiles in backup set 4 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSTEM01.DBF 2 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLSYSAUX01.DBF 3 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUNDOTBS01.DBF 4 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLUSERS01.DBF 5 Full 9684060 05-OCT-14 D:APP1SUNTYADAORADATAORCLEXAMPLE01.DBF List of Archived Log Copies for database with db_unique_name ORCL ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 367 1 366 A 02-OCT-14 Name: D:APP1SUNTYADAFLASH_RECOVERY_AREAORCLARCHIVELOG2014_10_05O1_MF_1_366_B32925TJ_.ARC Media recovery start SCN is 9684060 Recovery must be done beyond SCN 9704654 to clear datafile fuzziness Finished restore at 05-OCT-14
Concluzie
Acestea sunt doar tehnici simple pentru a verificați copiile de rezervă Oracle RMAN. Sper că aveți o înțelegere clară a procesului de backup și recuperare RMAN cu ajutorul diferitelor comenzi RMAN importante.
Deși, în situații reale, bazate pe dimensiunea datelor, am putea avea câteva sute de fișiere de date și trebuie să ne asigurăm că facem copii de rezervă pentru fiecare dintre ele pentru a avea o strategie bună de backup. De asemenea, testați recuperarea pe sistemele de testare pentru a vă asigura că puteți utiliza aceleași tehnici la producție.
Ne-am ocupat de diferite metode de backup a bazelor de date critice / de testare și de diverse metode de testare a acestora. După cum sa sugerat deja de mai multe ori, dacă aveți o strategie bună de backup și recuperare, veți salva locul de muncă și organizația dvs.
Spuneți-ne dacă aveți întrebări legate de Oracle sau orice altă testare de backup și recuperare a bazei de date.
Lectură recomandată
- Tutoriale detaliate pentru eclipsă pentru începători
- MongoDB Creați o copie de rezervă a bazei de date
- QTP Tutorial # 24 - Utilizarea obiectelor virtuale și scenarii de recuperare în testele QTP
- Tutorial de reflecție Java cu exemple
- Top Oracle Apps Technical and Oracle SOA Interview Questions
- Tutorial SVN: Gestionarea codului sursă folosind Subversion
- Tutorial Python DateTime cu exemple
- Tutorial SVN Tortoise: Revizuiri în depozitul de coduri