Redo Transport Compression in a Data Guard Environment

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ě.

Komprese síťového provozu

Jedno z míst, kde komprese nachází využití, je v prostředí, kde pro záložní lokalitu používá IT infrastruktura technologii Oracle Data Guard. Tato technologie poskytuje spolehlivou ochranu podnikových dat vytvořením jedné nebo více pohotovostních databází a umožňuje správu, sledování a automatizaci provozu pro případ selhání primární databáze, nebo katastrofy v primární lokalitě, chyby či datové korupce. 
Data Guard v principu udržuje synchronizaci mezi primární a záložní databází (standby) pomocí redo dat (informace pro obnovu transakce). Jakmile dojde k potvrzení transakce v primární databázi, jsou redo data zapsána do lokálních redo log souborů (Online Redo Logs – ORL).
Data Guard

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, viz http://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.

Porovnání přenesených redo dat v nekomprimované a komprimované podobě

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

Porovnání časů u dávkové úlohy bez komprese 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í.

Porovnání časů u dávkové úlohy s kompresí

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ů.

Vliv komprese 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%

Propusnost sítě

Komprese zakázána

Komprese povolena

11 Mbit

1.3 MB/sec

2.1 MB/sec

22 Mbit

2.8 MB/sec

4.2 MB/sec

45 Mbit

5.7 MB/sec

8.5 MB/sec

90 Mbit

11.3 MB/sec

13.4 MB/sec

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%!

Comments:

Do you have an english version of this post?
Thanks

Posted by jc nars on březen 21, 2013 at 03:24 odp. CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Česky o všem co se točí kolem Oracle Database.

Autoři:

Patrik Plachý
Technology Sales Consultant

David Krch
Principal Consultant
Oracle Expert Services

Oracle Czech

Search

Archives
« duben 2014
PoÚtStČtSoNe
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today