Oracle 12c Active Data Guard Sokkal több mint egy DR... Gecseg Gyula Oracle DBA

Oracle Active Data Guard Gecseg Gyula Oracle DBA

Data Guard felépítése

DR környezetek napjainkban - Sok pénzt költenek disaster recovey (DR) -re, mely környezetek hosszú ideig kihasználatlanok maradnak - Beruházás hardverba, korszerű adatközpontokba, szoftverlicenszbe, magas karbantartási költségek - A DR környzetek gyakran azonos kapacitásúak, mint produktív környzetben és a legtöbb esetben kihasználatlanok - A hagyományosan erőforrásigényes tevékenységek, mint riportálás, a mentések nem használták a standby oldalon - A készenléti adatbázisok a DR segítségével a szinkronizált másolatai a produktív adatbázisokna, miért-ne használjuk őket - Az Oracle 12c Active Data Guard úgy változott, hogy lehetővé teszi számunkra, hogy a befektetett pénz megtérüljön a standby oldalon

Active Data Guard használatának előnyei - Javítja a primary adatbázis teljesítményét: a standby oldalt használhatjuk bármilyen alkalmazásra read/only módban, sőt a mentéseket is elvégezhetjükk ezen az oldalon - Az Oracle Active Data Guard 12c nyújt egy új támogatást a DML-ek számára: globális ideiglenes táblák és szekvenciák alkalmazása a standby adatbázishoz, ez kiterjeszti a számát a read-only alkalmazásoknak - Oracle Data Guard Protection Modes: - Maximum Availability: Ha a primary adatbázis nem működik, akkor ez a mód biztosítja, hogy nem következik be adatvesztés. SYNC/AFFIRM megvárja az elismervény megérkeztét arról hogy megtörtént a változás írása a fizikai standby adatbázisba, a SYSNC/NOAFFIRM esetén csak arról kapunk elismervényt, hogy az adatok megérkeztek fizikai standby adatbázisba. - Maximum Performancia - Maximum Protection - Konfigurálásuk a primary adatbázison: ALTER DATBASE > SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY PERFORMANCE PROTECTION}

Active Data Guard használatának előnyei -Növeli a mentés teljesítményét azáltal, hogy áthelyzi a primary adatbázis gyors inkrementális mentéseket a standby oldalra felhasználva hogy az Oracle Active Data Guard támogatja az RMAN block change tracking metódust. -Megnövelt rendelkezésre állás: Az Active Data Guard autómatikusan teljesít egy blokk média recovery-t, ahogy a hiba felmerül, kijavítja a fizikai korrupciót a jó blokk verziót használva a standby adatbázisból. megvalósítása : az alábbi init.ora paramétereket kell beállítani - DB_BLOCK_CHECKSUM=FULL - DB_BLOCK_CHECKING=FULL or MEDIUM - DB_LOST_WRITE_PROTECT=TYPICAL - Engedélyezni a Flashback fast point-in-time helyreállítás opciót - Az Active Data Guard engedélyezni az Automatic Block Repair opciót -Megnövelt rendelkezésre állás, tervezett leállások csökkentése a DG -hez fejlesztett fejlett automatizáció az Oracle Database patch-set-ek, és adatbázis releases-hez nyújt egy magas rendelkezésre állású upgrade-et

Active Data Guard felépítése Manage by Oracle 12c Cloud Controll or Data Guard

Active Data Guard felépítése Ligh-weight instance: menedzsel csak egy control file-t és logfile-okat. A CPU, memória, I/O csak egy töredékére van szüksége. Célja, hogy tehermentesíti a PA-t a nagy számú redo átviteltől A terhelési adatbázis tehermentesítése szinkron módban, nulla adatvesztés konfigurációban ahol ahol a primary a standbay adatbázis nagy távolságra van (ligh-weight instance) használata inaccessible ligh-weight instance

Data Guard transport and multi-standby configuration -Ahogy a cégek száma növekszik, úgy használják egyre jobban ki a DG azon képességeit, hogy képes támogatni több standby adatbázist. -Példa: Egy Primary Adatbázis (DB01) tovább szinkronizál egy helyi Standby adatbázishoz nevezzük DB02-ek. DB02 tovább küldi a redo-t egy második Standby Adatbázisnak DB03 mely távol helyezkedik el, és amelyet Disaster Recovery célból hoztak létre (DR). Használjuk a Real-Time Cascade -t Activ Data Guard -al (Oracle Database 12c részei) a DB02 használja az asszinkron módú adatátvitellel küldi az adatokat a távoli DB03-ak, megtartva a zárt szinkronizációt a helyi DB01 DB02 között.

Active Data Guard megvalósítása - Enable force loging mode - Create standby redo log files - Set primary database initalization parameters - Set DB_NAME and DB_UNIQUE_NAME - Set LOG_ARCHIVE_CONFIG and LOG_ARCHIVE_DEST_2 parameters - Enable automatic archiving - Set SQL*Net configuration primary and standby side - Lsnrctl reload listener12c - Copy the remote login password fájl from primary database to standby system, renaming it orapw standby - Set in init.ora remote_login_passwordfile='exclusive' - mkdir adump dpdump pfile scripts - Specify the list of unique database names - Configure the redo transport server between yor two databases - Connect to Primary and auxiliary connection to standby - Startup nomount standby database - Use in RMAN the duplicate target database for standby from active database spfile - Mount the standby database

Active Data Guard megvalósítása - Create broker configuration including a profile for the primary database - Add your physical standby database to the broker configuration - Show configuration - Enable the entire configuration - Verify that the configuration was successfully enabled