sql >> Databasteknik >  >> RDS >> Oracle

Återställningskrav före säkerhetskopiering

Alltför ofta ser jag människor ställa frågor om säkerhetskopieringsstrategier de bör använda för sina databaser. Det verkar aldrig misslyckas, varje fråga av detta slag som jag har stött på i en mängd olika forum inkluderar aldrig deras återställningskrav. Jag har ofta funderat på att överväga dina återställningskrav innan jag utformade din säkerhetskopieringsstrategi. När jag trycker på krav kommer jag ofta att få säkerhetskopieringskrav till exempel:

  • Säkerhetskopiering får inte införa några driftstopp
  • Behöver kunna säkerhetskopiera arkiverade redo-loggar
  • Säkerhetskopiering måste skrivas till band

Dessa krav är bra, men enligt min åsikt bör du aldrig utforma din säkerhetskopieringsstrategi utan att först dokumentera dina återställningskrav och få hanteringsförekomst.

Så här är några frågor som jag ställer mig själv när jag utformar en säkerhetskopieringsstrategi. Lägg märke till att alla dessa frågor är fokuserade på återhämtningssidan av saker och ting.

  1. Hur mycket dataförlust har jag råd med när jag återställer databasen? Ingen dataförlust? Är en timmes dataförlust acceptabel efter återställning av databasen?
  2. Behöver jag rulla vidare några transaktioner, d.v.s. utföra en punkt-i-tid-återställning?
  3. Behöver jag återställa innehållet i ett schema samtidigt som jag lämnar de andra scheman intakta?
  4. Hur lång tid har jag på mig att få igång databasen efter ett fel?
  5. Vilken typ av fel måste jag återhämta mig från? Självklart måste jag kunna återställa från ett fullständigt serverfel eller förlust av en disk. Men måste jag kunna återhämta mig från mänskliga misslyckanden som någon som av misstag raderade en tabell?
  6. Kommer jag att behöva återställa säkerhetskopian till andra servrar som en del av att uppdatera utvecklingen eller testa databaser från en kopia av produktionen?

Om du frågar de flesta i Oracle-gemenskapen nuförtiden, kommer de att säga åt dig att använda RMAN för att säkerhetskopiera din databas. RMAN är en fantastisk produkt och är för många saker bättre än de gamla användarhanterade varma eller kalla säkerhetskopiorna. Vissa Oracle DBA:er kommer att berätta för dig att använda RMAN för att utföra heta säkerhetskopieringar och köra din produktionsdatabas i arkivloggläge. Genom att göra det kommer du att täcka många av de återhämtningsscenarier som du sannolikt kommer att möta. Men tänk om ditt svar på fråga 4 är att du har 1 timme på dig att komma igång igen och din databas är 10TB stor. Lycka till med att försöka göra en fullständig återställning av en 10TB databas på 1 timme med RMAN. Och RMAN kommer inte att kunna hjälpa till med fråga 3 eftersom RMAN inte säkerhetskopierar på schemanivå.

Det finns många verktyg till DBA:s förfogande för att säkerhetskopiera och återställa data i databasen. Dessa verktyg inkluderar, men är inte också begränsade:

  • Oracle's Recovery Manager (RMAN)
  • Användarhanterade säkerhetskopior av Oracle
  • Oracle export/import eller datapump
  • Diskbaserade ögonblicksbilder
  • Diskbaserad replikering
  • Oracles Data Guard

Så vilken använder du? Tja, alla har sina för- och nackdelar. När du väl känner till dina återställningskrav börjar verktygen för att säkerhetskopiera din databas bli tydligare. Och du kan behöva använda mer än ett säkerhetskopieringsverktyg för att uppfylla alla dina återställningskrav. Om du, som något förslag, använder RMAN med arkivloggläge och inget annat, och din chef kommer till dig och säger "du måste få den här 10TB-databasen igång igen om 1 timme!" ditt jobb kan mycket väl vara på spel.

Vilket leder till nästa punkt, dokumentera dina återställningskrav och lägg in dem i ditt Service Level Agreement (SLA). När du skriver och granskar SLA:n kan din ledning säga att de vill ha noll dataförlust. Det är vid denna tidpunkt som du kan ta upp för- och nackdelarna med att implementera en lösning för noll dataförlust ... och även nämna kostnaderna! Många företag avskyr den höga kostnaden för en lösning utan dataförlust, men för andra företag är kostnaden liten jämfört med den ekonomiska bördan av att förlora en transaktion. Det är här köpslåendet och byteshandeln kommer in i bilden. Om ledningen insisterar på en lösning för noll dataförlust, måste de komma med medel för att stödja den eftersom RMAN (gratis) inte kommer att tillhandahålla det. När du väl har dina återställningskrav dokumenterade i SLA kommer det att vara svårt för ledningen att be dig återställa något som din säkerhetskopieringsstrategi inte är utformad för att stödja. Om SLA är på plats och de ber dig att återställa varje enskild transaktion och din säkerhetskopieringsstrategi inte tillåter det, då har du ett dokument som säger att ingen dataförlust aldrig krävdes och detta kan hjälpa till att rädda ditt jobb.

Med det sagt, när du väl har dina återställningskrav dokumenterade i SLA:n, se till att din säkerhetskopieringsstrategi gör att du kan utföra alla återställningsscenario som är dokumenterade i SLA:n. Ditt jobb kan bero på det. Om SLA säger noll dataförlust och du inte implementerar Data Guard trots att ledningen var villig att finansiera det, kan de säga upp dig eftersom du inte följde ditt jobb.

Slutligen är ingen säkerhetskopierings-/återställningsstrategi komplett om den inte är noggrant testad. Du bör testa alla nödvändiga återställningsstrategier för att säkerställa att du kan uppfylla alla krav som anges i SLA. Testning bör utföras minst en gång om året av två skäl... en säkerställer att ändringar i systemet inte negativt påverkar din förmåga att utföra en nödvändig återställning och två, håller dig uppdaterad om hur du utför återställning så att om du måste göra det på riktigt famlar du inte efter proceduren. När du testar kan du upptäcka att din säkerhetskopieringsmetod stöder återställningsscenarier som krävs, men är bra att ha om du behöver dem.

Och jag kan inte säga det nog...Testa, testa och testa!


  1. Hur testar man metoder som hanterar SQLite-databas i Android?

  2. Intel Xeon skalbara processorer och SQL Server 2017

  3. 4 sätt att kontrollera om en tabell finns innan du släpper den i SQL Server (T-SQL)

  4. SSL-nyckelhantering och kryptering av MySQL-data under transport