Oracle Data Guard
Mjukvaran som Oracle Corporation marknadsför som Oracle Data Guard utgör en förlängning av Oracles relationsdatabashanteringssystem (RDBMS). Det hjälper till att etablera och underhålla sekundära standby-databaser som alternativa/kompletterande arkiv till primära produktionsdatabaser.
Oracle tillhandahåller både grafiskt användargränssnitt (GUI) och kommandoradsverktyg (CLI) för att hantera Data Guard-konfigurationer.
Data Guard stöder både fysisk standby och logiska standby- sajter. Oracle Corporation gör Data Guard endast tillgänglig som en medföljande funktion som ingår i dess "Enterprise Edition" av Oracle RDBMS .
Med lämpligt inställda Data Guard-operationer kan DBA: er underlätta failovers eller byten till alternativa värdar på samma eller alternativa platser.
Konfigurationer
För Data Guards syften fungerar varje Oracle-databas antingen i en primär databasroll eller i en beredskapsdatabasroll - med möjlighet att övergå från en roll till en annan.
Fysiskt vänteläge (gör om apply)
En fysisk standby-databas replikerar det exakta innehållet i dess primära databas över Oracle Net- nätverkslagret . Även om de relativa fysiska lagringsplatserna kan skilja sig åt, kommer data i databasen att vara exakt samma som i den primära databasen. Fysiska standby-databaser kan fungera antingen i hanterat återställningsläge eller i skrivskyddat läge, men inte i båda lägena samtidigt (såvida inte databaserna är på Oracle Database 11.1 eller högre och alternativet Active Data Guard är licensierat - se nedan) . Standby-läget använder sig av "Redo Apply"-teknik.
Fysiska standbydatabaser har samma DBID-identifierare som deras primära motsvarigheter.
Logiskt vänteläge (SQL Apply)
Logiska standbydatabaser konverterar redogörelsen som genereras i den primära databasen till data och SQL och tillämpar sedan dessa SQL-transaktioner på nytt i det logiska standbyläget. Således kommer fysiska strukturer och organisation att skilja sig från den primära databasen. Användare kan läsa från logiska standbydatabaser medan ändringarna tillämpas och, om GUARD är inställd på STANDBY (ALTER DATABASE GUARD STANDBY;), skriva till tabeller i den logiska standbydatabasen som inte underhålls av SQL Apply.
Tyvärr finns det ett antal objekt som inte stöds (t.ex. tabeller eller sekvenser som ägs av SYS, tabeller som använder tabellkomprimering, tabeller som ligger bakom en materialiserad vy eller globala temporära tabeller (GTT)) och datatyper som inte stöds (dvs: datatyperna BFILE, ROWID och UROWID, användardefinierade TYPER, multimediadatatyper som Oracle Spatial, ORDDICOM och Oracle Text Collections (t.ex. kapslade tabeller, VARRAYs), SecureFile LOBs, OBJECT RELATIONAL XMLTypes och BINÄR XML). Logisk standby kanske inte är lämplig i ett sådant fall.
Active Data Guard
Alternativet "Oracle Active Data Guard", en extra kostnadsfunktion, utökar Oracle Data Guard-funktionaliteten i Oracle 11g-konfigurationer. Den tillåter skrivskyddad åtkomst på den fysiska standbynoden samtidigt som arkiverade transaktioner från den primära noden tillämpas. Den har också automatisk blockreparation och snabb inkrementell säkerhetskopiering i fysisk standby,
Drift
Funktionalitet på serversidan
LNS (log-write network-server) och ARCH (archiver) processer som körs på den primära databasen väljer arkiverade redo logs och skickar dem till standby-databasvärden, där RFS (remote file server) bakgrundsprocessen inom Oracle-instansen utför uppgift att ta emot arkiverade redo-loggar som kommer från den primära databasen och skriva dem till en standby redo-logg (SRL).
Alternativt kan en kompletterande mekanism överföra de arkiverade redo-loggarna. På standbydatabasen övervakar en FAL- klient (Fetch Archive Log) efter luckor i sekvensen av mottagna loggar. Om den hittar en lucka kan den anropa en eller flera FAL-servrar (Fetch Archive Log) för att köras på den primära databasen för att vidarebefordra de saknade objekten.
När de arkiverade redo-loggarna har anlänt till standby-värden, kan andra processer - såsom en ARCH (arkiveringsprocess), en MRP (Managed Recovery Process) och/eller en LSP (Logical Standby Process) - börja tillämpa logginnehållet till standby-databasen.
Användningen av standby redo logs kan påskynda tillämpningen av ändringar i en standby databas med realtidstillämpning.
Data Guard Connection-processen ( DRCX ) spelar en roll vid överföring av data mellan databaser.
Åtkomst på klientsidan
Data Guard Broker-undersystemet kan hjälpa till med installation, hantering och övervakning av Data Guard-konfigurationer.
Fördelar
Data Guard ger hög tillgänglighet för ett databassystem. Det kan också minska det mänskliga ingreppet som krävs för att växla mellan databaser vid katastrofåterställning ("failover") eller uppgradering / underhåll ("switchover").
Genom att använda redo-loggfiler i standbyläge kan Data Guard minimera dataförlust.
Den stöder heterogena konfigurationer där de primära och standby-systemen kan ha olika CPU-arkitekturer, operativsystem (till exempel Microsoft Windows och Linux), operativsystembinärer (32-bitar/64-bitar) eller Oracle-databasbinärer (32- bit/64-bitar).
Nackdelar
Om nätverkslänken som ansluter primär och standby är övertecknad, skickas inte redo-loggarna i kronologisk ordning, vilket kan resultera i att stora luckor uppstår i den tillgängliga redo i standby-läge. Ett sådant tillstånd resulterar i att beredskapen ligger bakom primären. Detta kan övervinnas med hjälp av Oracles Active Data Guard Farsync-teknik.
Samma version av Oracle Database Enterprise Edition måste installeras på den primära databasen och alla standby-databaser, förutom under rullande databasuppgraderingar med logiska standby-databaser.
Oracle Data Guard är endast tillgänglig som en funktion i Oracle Database Enterprise Edition.