validate oracle rman backup
Hvordan lage og validere Oracle RMAN Backup: Lær med RMAN-kommandoer og gjenopprettingsprosess
hvordan bli testere for nye produkter
I denne veiledningen skal vi diskutere verifisering og testing av sikkerhetskopier av Oracle-databaser. Vi vil forklare begreper som hva, hvorfor og hva med databasesikkerhetskopier og metoder for å teste sikkerhetskopien.
Vi tar Oracle-database som en casestudie for denne veiledningen.
Casestudie: Testing av Oracle RMAN Database-sikkerhetskopier:
Hva du vil lære:
Oracle Database Backup Valideringsprosess ved bruk av RMAN
Vi har kategorisert det i de følgende fire seksjonene
- Hva er en sikkerhetskopi?
- Hvorfor sikkerhetskopiere?
- Hvordan ta sikkerhetskopi?
- Hvordan teste / validere databasesikkerhetskopien - Recovery Strategies?
Les også=> Alt om databasetesting
Hva er en sikkerhetskopi av en database?
Før vi begynner å lære mer om sikkerhetskopier, må vi forstå organisasjonens viktigste ressurs - Data. Tatt i betraktning at organisasjonen din kjører på Oracle-databasen. For å forstå begrepet 'database' kan du referere til Oracle Database Testing-serien her .
Data fra en organisasjon er den mest integrerte delen av en organisasjon. Vurder et detaljhandels-, bankselskap. De har alle enorme mengder data - bruker, system osv. Som databaseadministrator, systemadministrator eller ethvert personell som har fått tildelt jobben for å beskytte disse dataene, bør være klar over hvor viktig data er for en organisasjon. Hvordan sørge for at dataene alltid er tilgjengelige? Sikkerhetskopier disse dataene.
En sikkerhetskopi er en nøyaktig kopi av databasen som kan hjelpe deg med å rekonstruere dataene dine i tilfelle tap av data.
Hvorfor sikkerhetskopiere databasen?
Tenk på et enkelt tilfelle der bankorganisasjonen din som har data om millioner av kunder når det gjelder kontonummer, navn, nominerte, banksaldo og organisasjonen mistet alle dataene, hvordan ville kundene reagere på det? Hvordan ville organisasjonen takle presset om å miste så mye data? Hvordan ville de være ansvarlige for så mange misnøye kunder?
Dette er grunnen til at vi tar sikkerhetskopi av disse dataene, slik at i tilfelle feil på en disk (lagring), diskkontrolleren (lagringskontrolleren), kan vi alltid stole på vår sikkerhetskopi hvorfra vi kan gjenopprette den i databasen, dvs. lagringsfilsystem og ikke har kunder mister dataene sine.
Antag det hypotetisk at det er millioner av kunder, og hver av dem som utfører millioner av transaksjoner, og databasen ved et uhell krasjer og mister dataene sine. Vil vi be alle disse kundene om å legge inn dataene sine igjen? Hvordan takler du å miste så mye data? Det ville være høyst uakseptabelt.
På samme måte kan du vurdere et telekommunikasjonsselskap som støtter millioner av kunder og har alle dataene sine angående telefonnumre, adresser, kreditt tilgjengelig, i påvente av betaling. Hva om vi mister alle dataene deres? Selskapet er dømt og vil måtte bære store kostnader som potensielt vil stoppe organisasjonen. Det ville absolutt være en enorm katastrofe.
Hvordan ta sikkerhetskopi av databasen?
For å sikkerhetskopiere data i en Oracle-database, har vi flere metoder. De kan stort sett klassifiseres som fysiske og logiske sikkerhetskopier
Metode nr. 1)Fysiske sikkerhetskopier :
- 3rdpartysikkerhetskopier - som Veritas NetBackup, SAP, IBM Tivoli Manager, EMC, HP
- Brukerstyrte sikkerhetskopier - Sikkerhetskopiering av en database ved hjelp av OS-verktøy som copy (windows), cp (Unix).
- Oracle Secure Backup
- Min favoritt og det mest foretrukne anbefalte Oracle-verktøyet - Recover Manager ( RMAN ).
Metode 2)Logiske sikkerhetskopier:
- Konvensjonelle eksport- / importverktøy og datapumpeverktøy. En logisk sikkerhetskopi er en sikkerhetskopi av logiske data - objekter som tabeller, indekser osv. Som er bestanddeler av en database uavhengig av plasseringen av objektene ovenfor.
For å forstå fysiske og logiske lagringsstrukturer i en database kan du referere til dette og denne orakeldokumentasjonen .
Hvilken er den beste metoden for sikkerhetskopiering av databaser?
Hver av disse sikkerhetskopistrategiene har sine egne fordeler og ulemper, og vi skal ikke håndtere for mye med dem i denne artikkelen.
Vi må forstå at med mindre du har en fysisk sikkerhetskopi på plass, er det ikke alltid trygt å ha en logisk sikkerhetskopi mot fysisk datakorrupsjon, maskinvarelagringsproblemer. Å ha en gyldig, god fysisk sikkerhetskopi gjør det til en god sikkerhetskopierings- og gjenopprettingsstrategi. Sørg alltid for at du har en fysisk sikkerhetskopi på plass.
I virkeligheten kan vi bruke noen av metodene ovenfor, men vi må alltid sørge for at vi har en god sikkerhetskopierings- og gjenopprettingsstrategi for å unngå unødvendige hikke i løpet av driften av en database. Det anbefales alltid å teste rygg- og gjenopprettingsstrategier på et speilet testsystem, slik at vi kan forutsi hvor lang tid det tar å få databasen din i gang i tilfelle uforutsette situasjoner.
I denne artikkelen vil vi hovedsakelig fokusere på RMAN-sikkerhetskopier. Dette bringer oss til et punkt hvor vi vet hvor nøyaktig vi utfører sikkerhetskopien.
Oracle RMAN (Oracle Recovery Manager) sikkerhetskopikommandoer
Vi kan sikkerhetskopiere data enten ved hjelp av Enterprise Manager (GUI) -modus eller via OS-kommandolinje.
RMAN er et robust, sofistikert verktøy levert av Oracle for å utføre sikkerhetskopiering og gjenoppretting.
RMAN installeres automatisk når du installerer Oracle-databasen, slik at det ikke er behov for ytterligere installasjon RMAN .
De RMAN miljø består av to komponenter:
1) Måldatabase (databasen du vil sikkerhetskopiere, utføre gjenoppretting av og
to) RMAN-klient som er klienten som tolker brukerkommandoer og utfører dem på vegne av brukeren mens den kobles til måldatabasen.
En enkel kommando for å koble til databasen ved hjelp av RMAN er som følger:
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 her er den unike identifikatoren som er unik for hver database vi planlegger å jobbe med.
I dette eksemplet har vi å gjøre med en database som heter ORCL .
Vi tar sikkerhetskopi av dataene som tilhører ORCL-databasen.
Siden en sikkerhetskopi er en fysisk kopi av databasen din, trenger vi en plassering / katalog der vi kan lagre dem.
For å oppnå dette kan vi bruke en spesiell katalog som heter db_recovery_file_dest som fungerer som sikkerhetskopieringssted. Definer størrelsen på denne parameteren med db_recovery_file_dest_size som markerer størrelsen på dette stedet for sikkerhetskopiering.
Selv om vi har flere måter å komprimere sikkerhetskopiene dine på, og flere teknikker som kan redusere størrelsen på en sikkerhetskopi, kan du i det minste prøve å stille inn DB_RECOVERY_FILE_DEST_SIZE til størrelsen på dine faktiske data i databasen. Forsikre deg om at du også tar hensyn til arkivlogger, noe som ikke er annet enn omloggingslogger uten nett som registrerer endringer i datablokkene dine.
Sikkerhetskopieringsstrategien din vil bestå av alle filene relatert til databasen, for eksempel datafiler, kontrollfiler, parameterfiler, nettverksrelaterte filer, arkiverte loggfiler på nytt.
RMAN eller andre fysiske sikkerhetskopieringsverktøy kan ta sikkerhetskopi av datafiler, kontrollfiler, parameterfiler, arkiverte omloggfiler. Nettverksrelaterte filer må sikkerhetskopieres manuelt ved hjelp av OS-verktøy som cp eller copy.
For å sikkerhetskopiere en database bruker vi:
'Backup-database' - det er så enkelt som det. Så la oss begynne å ta sikkerhetskopi av ORCL-databasen vår.
Siden vi allerede har koblet til måldatabasen (ORCL), utløser vi kommandoen “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
Her observerer vi at sikkerhetskopien av alle relaterte filer i databasen - datafiler, kontrollfiler, spfile (parameterfil) er fullført. Sikkerhetskopieringen tok omtrent 4 minutter og 27 sekunder (medgått tid). Dette er en liten testdatabase med bare 5 datafiler, så det tok veldig kortere tid å sikkerhetskopiere.
I tilfeller der vi ønsker å ta sikkerhetskopi av data fra databaser fra gigantiske organisasjoner, kan det være hundrevis av datafiler, og hver datafil kan være i terabyte-størrelser, og det kan potensielt ta flere timer å ta en fullstendig sikkerhetskopi av databasen.
For å vite detaljene angående sikkerhetskopien vi nettopp opprettet, skal vi utføre:
RMAN> liste backup;
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
Denne sikkerhetskopien plasseres på DB_RECOVERY_FILE_DEST-plasseringen som er definert som 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
Størrelsen som er definert for sikkerhetskopieringen vår, er 3912 MB.
Bruk VALIDATE til å sjekke databasefiler og sikkerhetskopier:
RMAN> VALIDER DATABASIS;
Valider RMAN Backup
Hvordan tester eller validerer vi at vi kan gjenopprette databasen vår under en krise?
Hvis vi på grunn av maskinvarefeil eller ødeleggelse på lagringsplatene dine, trenger vi en god sikkerhetskopi tilgjengelig for å gjenopprette disse ødelagte dataene, slik at vi ikke mister data som tilhører lagringsfilene.
Alt avhenger av hvordan du har designet sikkerhetskopiene, intervallene der sikkerhetskopiene er planlagt, om du tar full sikkerhetskopi og har trinnvise sikkerhetskopier.
I tilfelle brukerfeil - for eksempel unødvendig manipulering av data, kan vi gjenopprette deler av data eller all data som er endret gjennom logiske sikkerhetskopier.
I praksis bør vi være klar over og forutse eventuelle feil som kan oppstå i fremtiden og teste hver strategi for å unngå dem.
Bruk BACKUP VALIDATE-kommandoen for å validere sikkerhetskopifiler:
Kommandoen for bare fysisk korrupsjonskontroll:
RMAN> BACKUP VALIDATE
DATABASE
ARCHIVELOG ALLE;
Kommandoen for fysisk og logisk korrupsjonskontroll:
RMAN> BACKUP VALIDATE
KONTROLLER LOGISK
DATABASE
ARCHIVELOG ALLE;
RMAN> BACKUP VALIDER DATABASE ;
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
Som du kan se ovenfor er statusen for hver fil “ OK ”Som betyr at disse er brukbare og kan brukes til å gjenopprette filene når som helst.
Vi kan utføre en forhåndsvisning av databasegjenopprettingen. Dette gir deg en fin liste over filer og deres tilgjengelighet uten å faktisk gjenopprette filene.
Bruk RESTORE-kommandoen for å validere sikkerhetskopi:
RMAN> GJENBAR DATABASEVALIDATEN;
GJENOPPRETT ARKIVLOGG ALLE GODKJENNER;
RMAN> GJENBESTILL DATABASISUTSIKT;
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
Konklusjon
Dette er bare enkle teknikker å bekreft Oracle RMAN-sikkerhetskopiene. Håper du har en klar forståelse av RMAN-sikkerhetskopierings- og gjenopprettingsprosessen ved hjelp av forskjellige viktige RMAN-kommandoer.
Selv om det i virkelighets tilfeller er basert på størrelsen på dataene, kan vi ha flere hundre datafiler, og vi må sørge for at vi sikkerhetskopierer hver eneste av dem for å ha en god sikkerhetskopieringsstrategi. Også, teste utvinningen på testsystemer for å sikre at du kan bruke de samme teknikkene på produksjonen.
Vi har behandlet forskjellige metoder for å sikkerhetskopiere kritiske / testdatabaser og forskjellige metoder for å teste dem. Som allerede foreslått flere ganger, vil det å redde jobben din og organisasjonen din ha en god strategi for sikkerhetskopiering og gjenoppretting.
Gi oss beskjed hvis du har spørsmål relatert til Oracle eller andre tester for sikkerhetskopiering og gjenoppretting av databaser.
Anbefalt lesing
- In-Depth Eclipse Tutorials For Beginners
- MongoDB Lag sikkerhetskopi av database
- QTP opplæring # 24 - Bruk av virtuelle objekter og gjenopprettingsscenarier i QTP-tester
- Java Reflection Tutorial med eksempler
- Topp Oracle Apps tekniske spørsmål og Oracle SOA intervju spørsmål
- SVN Tutorial: Source Code Management Using Subversion
- Python DateTime Tutorial med eksempler
- Tortoise SVN Tutorial: Revisions In Code Repository