Oracle 11g Advanced Compression a snížení síťového přenosu v prostředí Data Guard

Úvod

Oracle Database 11g Advanced Compression Option (ACO) přináší soubor funkcí, které pomáhají zákazníkům maximalizovat využití zdrojů a snížit náklady. IT administrátoři mohou snížit celkovou velikost databázového úložiště a to díky tomu, že lze zavést kompresi pro všechny typy dat – ať už jsou to relace (tabulky), nestrukturované data (soubory), nebo zálohy. 

Ačkoliv primární použití komprese je často cíleno na hmatatelné sníženíúložného prostoru, inovace, které jsou v Advanced Compression Option zahrnuty umožňují snížit požadavky na všechny komponenty IT infrastruktury, včetně např. požadavků na paměť a propustnosti sítě.

Služby Data Guard Redo Transport Services se používají pro přenos těchto redo dat na záložní stranu. Očtení redo data z redo bufferu nebo z online redo logů (ORL), podle stavu a konfigurace, se stará proces Log Network Server (LNS) a odesílá je přes Oracle Net Services do standby databáze. Zde je zpracovává proces Remote File Server (RFS), který vytváří tzv. standby redo logy (SRL), které jsou aplikovány.

Při využití Advanced Compression můžou být redo data přenášeny v komprimovaném formátu, čímž dojde ke snížení spotřeby šířky síťového pásma a v některých případech se i sníží přenosovýčas redo dat.

Oracle Database 11g Release 2 umožňuje přednášet redo data v komprimovaném formátu a to v módech, kdy je Oracle Data Guard v synchronní (SYNC) nebo asynchronní (ASYNC) konfiguraci.

Přínosy komprese

Pokud databáze může využít komprese redo dat, tak ve většině prostředí je díky tomu dosaženo:

• Zlepšení ochrany dat, protože dojde k redukci zpoždění při přenosu redo dat
• Redukce síťové utilizace
• Poskytnutí rychlejšího rozpoznání problému při přenosu redo dat
• Snížení přenosových časů redo dat

Tyto přínosy jsou velmi důležité při použití Data Guard na sítích s vysokou latencí a nízkou šířkou pásma u WAN sítí.

Cena za rychlé a bezpečné spojení mezi primární a záložní lokalitou je mnohdy velmi vysoká a v těchto případech má komprese redo dat jednoznačné přínosy.

Rychlejší vyřešení gapů

Při využití komprese přenášených redo dat může dojít k rychlejšímu doplnění tzv. děr (GAPs) na standby straně. Gapy vznikají ve chvíli, kdy dojde k situaci, že LNS proces čeká na přenos redo dat, nebo dojde k výpadku sítě a dochází k tomu, že na standby straně chybí redo data a vznikají tyto gapy. Jakmile LNS proces znovu dostane informaci o spojení, ať už např. nahozením sítě, posílá aktuální redo data do standby databáze. Chybějící redo data jsou odesílána z primární databáze pomocí ARCH procesu, paralelně pomocí LNS s výše uvedenými redo daty, aby došlo k vyřešení gapů na standby databázi. Jakmile standby databáze přečte všechny archivní redo data, přejde ke čtení aktuálních standby redo logů.

Výkon doplnění gapů na standby databázi je kritický a má vliv na dobu, jak dlouho bude standby strana nesynchronní s primární databází!

Použití komprese redo dat

Komprese má nejlepší přínosy při požadavku na rychlé obnovení provozu (Recovery Point Objectives – RPO) a to u sítí, kde je nízkášířka pásma. Při zvyšováníšířky pásma sítě (bandwidth roste) klesá benefit pro RPO.

Komprese je výhodná zejména v případě:

• Velikost generovaných databázových redo dat je vyšší než je schopná přenést dostupná síť
• Jsou dostupné CPU zdroje pro zpracování komprese

Komprese má nejlepší přínosy v případě problému s dodávkou redo dat na standby stranu a je závislá na šířce pásma sítě. V praxi to znamená, že v prostředí Data Guard standardně dochází k významné konzumaci CPU na dvou místech. Při detekcí gapů a při kompresi.

Efektivita a dopady komprese

Na jednu stranu komprese zvýší využití procesoru, ale na druhou stranu v prostředí s omezenoušířkou pásma, je nutné brát v úvahu cenu CPU a případný neúspěch při plnění bodu obnovy (RPO) a možné ztráty dat.

Naše společnost, konkrétně pobočka Oracle Japan, provedla měření ve společnosti Hitachi Ltd, vizhttp://www.hitachi.co.jp/Prod/comp/soft1/oracle/pdf/OBtecinfo-08-008.pdf

Při hrubém měření se potvrdilo, že komprese redo dat výrazně sníží množství přenesených dat po síti.

Dále se provedlo měření, kdy se sledoval vliv rychlosti sítě na dávkovou úlohu (batch processing).

Z grafu je vidět, že u rychlé sítě 1Gb/s nebyl žádný vliv na čas zpracováníúlohy a u pomalejší sítě začalo docházet k tomu, že redo data už nebyly odebírány z bufferu a došlo ke čtení online redo logů a docházelo ke zpoždění.

Následně se provedlo měření se zapnutou kompresí, kde se ukázal vliv na čas zpracování.

Vliv komprese při latenci sítě se ukázal v dalším měření, kde je vidět, jak komprese sníží celkovýčas na vyřešení gapů.

 Dále naše společnost provedla tzv. „gap resolution testing“, kde se potvrdilo, že poměr utilizace CPU je u vysokorychlostních sítí více na straně komprese, než na straně zpracování a odesílání redo dat. Např. u dvou sítí OC1 (51,8 Mb/s) a T3 (44,7 Mb/s) docházelo při kompresi redo dat k 50 % utilizaci CPU na každý ARCH proces a při přechodu na 100Mbit/sec se utilizoval celý CPU.

Jestliže je rozhodující RPO, tak při sítích nad 100Mbit/sec se nedoporučuje použít kompresi, protože může mít dopad do výsledného času přenosu redo dat. Pokud se však dává přednost vytížení sítě i u sítí s vyššíšířkou pásma, tak lze kompresi použít.

Vždy se doporučuje provést test ve vybraném prostředí.

Ve verzi 11gR2 lze nastavit kompresi na všechny metody přenosu u Data Guard (SYNC, ASYNC, ARCH), včetně detekce GAP i všech režimů ochrany (Maximum Protection, Maximum Availability a Maximum Performance).

Testy provedené naší společností potvrdili kompresní poměr 35% a vyšší a snížení přenosového času REDO o 15-35%

Zjištění kompresního poměru.

Mechanismus komprese redo logů používá při své práci algoritmus zlib, proto pro zjištění aktuálního kompresního poměru lze použít utilitu gzip s parametrem -1 např. u archivních redo logů generovaných vybranou databází.

$ gzip -1 <archive redo logfile>.arc

a přímo vypsáním kompresního poměru

$ gzip --list <archive redo logfile.arc>.gz

Např.

$ gzip -1 arch1_100_6767894522.dbf

$ gzip --list arch1_100_6767894522.dbf.gz

compressed uncompressed ratio uncompressed_name

245146 1167360 79.0% arch1_100_6767894522.dbf

Test v tomto případě proběhl na databázi, kde jsou uložena finanční data a dochází opravdu v praxi ke kompresnímu poměru 70-80%!