Výkon databáze Oracle ve službě Azure NetApp Files s více svazky

  • Článek

Migrace vysoce výkonných databází úrovně Exadata do cloudu se stále více stává imperativním pro zákazníky Microsoftu. Softwarové sady dodavatelského řetězce obvykle nastavují vysoký pruh kvůli intenzivním požadavkům na vstupně-výstupní operace úložiště se smíšeným zatížením čtení a zápisu řízeným jedním výpočetním uzlem. Infrastruktura Azure v kombinaci se službou Azure NetApp Files dokáže splňovat požadavky této vysoce náročné úlohy. Tento článek představuje příklad toho, jak byla tato poptávka splněna pro jednoho zákazníka a jak Může Azure splňovat požadavky vašich důležitých úloh Oracle.

Výkon Oracle na podnikové úrovni

Při zkoumání horních limitů výkonu je důležité rozpoznat a omezit všechna omezení, která by mohla falešně zkosit výsledky. Pokud například záměrem je prokázat možnosti výkonu systému úložiště, měl by být klient ideálně nakonfigurovaný tak, aby se procesor nestal omezujícím faktorem před dosažením limitů výkonu úložiště. K tomuto účelu testování začalo s typem instance E104ids_v5, protože tento virtuální počítač je vybaven nejen síťovým rozhraním 100 Gb/s, ale s stejně velkým limitem výchozího přenosu dat (100 Gb/s).

Testování proběhlo ve dvou fázích:

  1. První fáze se zaměřila na testování pomocí standardního nástroje SLOB2 (Silly Little Oracle Benchmark) Kevin Clossona – verze 2.5.4. Cílem je řídit co nejvíce vstupně-výstupních operací Oracle z jednoho virtuálního počítače na více svazků Azure NetApp Files a pak škálovat pomocí více databází, aby bylo možné demonstrovat lineární škálování.
  2. Po otestování limitů škálování se naše testování přepíná na levnější, ale téměř tak schopné E96ds_v5 pro fázi testování zákazníka pomocí skutečné úlohy aplikace dodavatelského řetězce a dat z reálného světa.

Výkon vertikálního navýšení kapacity SLOB2

Následující grafy zachycují profil výkonu jednoho E104ids_v5 virtuálního počítače Azure s jednou databází Oracle 19c s osmi svazky Azure NetApp Files s osmi koncovými body úložiště. Svazky jsou rozdělené do tří skupin disků ASM: data, protokol a archivace. Skupině datových disků bylo přiděleno pět svazků, dva svazky do skupiny disků protokolu a jeden svazek archivní skupině disků. Všechny výsledky zachycené v tomto článku byly shromážděny pomocí produkčních oblastí Azure a aktivních produkčních služeb Azure.

Pokud chcete nasadit Oracle na virtuální počítače Azure pomocí více svazků Azure NetApp Files na více koncových bodech úložiště, použijte skupinu svazků aplikací pro Oracle.

Architektura s jedním hostitelem

Následující diagram znázorňuje architekturu, pro kterou bylo testování dokončeno; Všimněte si, že databáze Oracle se rozprostírá mezi několika svazky a koncovými body služby Azure NetApp Files.

Diagram podsítě Oracle s fondem kapacity služby Azure NetApp Files

Vstupně-výstupní operace úložiště s jedním hostitelem

Následující diagram znázorňuje 100 % náhodně vybraných úloh s poměrem dosažení vyrovnávací paměti databáze přibližně 8 %. SLOB2 dokázalo řídit přibližně 850 000 vstupně-výstupních požadavků za sekundu při zachování latence událostí sekvenčního čtení souboru databáze v milisekundách. S velikostí bloku databáze 8 tisíc, která se rovná přibližně 6 800 MiB/s propustnosti úložiště.

Graf znázorňující vstupně-výstupní operace náhodného úložiště s jedním hostitelem

Propustnost jednoho hostitele

Následující diagram ukazuje, že pro úlohy náročné na šířku pásma náročné na sekvenční vstupně-výstupní operace, jako jsou úplné prohledávání tabulek nebo aktivity RMAN, může Služba Azure NetApp Files poskytovat možnosti plné šířky pásma samotného virtuálního počítače E104ids_v5.

Pruhový graf zobrazující sekvenční propustnost jednoho hostitele

Poznámka:

Vzhledem k tomu, že výpočetní instance má teoretickou maximální šířku pásma, přidání další souběžnosti aplikací vede pouze ke zvýšení latence na straně klienta. Výsledkem je, že úlohy SLOB2 překračují cílový časový rámec dokončení, takže počet vláken byl omezen na šest.

Výkon horizontálního navýšení kapacity SLOB2

Následující grafy zachycují profil výkonu tří E104ids_v5 virtuálních počítačů Azure, na kterých běží jedna databáze Oracle 19c a každá má vlastní sadu svazků Azure NetApp Files a stejné rozložení skupiny disků ASM, jak je popsáno v části Vertikální navýšení výkonu. Grafika ukazuje, že s azure NetApp Files s více svazky nebo více koncovými body se výkon snadno škáluje s konzistencí a předvídatelností.

Architektura s více hostiteli

Následující diagram znázorňuje architekturu, pro kterou bylo testování dokončeno; všimněte si tří databází Oracle rozložených mezi více svazky a koncovými body služby Azure NetApp Files. Koncové body můžou být vyhrazené pro jednoho hostitele, jak je znázorněno u virtuálního počítače Oracle 1 nebo sdílené mezi hostiteli, jak je znázorněno v oracle VM2 a Oracle VM 3.

Diagram automatické správy úložiště Oracle pro Azure NetApp Files

Vstupně-výstupní operace úložiště s více hostiteli

Následující diagram znázorňuje 100 % náhodně vybraných úloh s poměrem dosažení vyrovnávací paměti databáze přibližně 8 %. SLOB2 dokázalo řídit přibližně 850 000 vstupně-výstupních požadavků za sekundu ve všech třech hostitelích jednotlivě. SLOB2 toho dokázal dosáhnout při paralelním provádění souhrnného součtu přibližně 2 500 000 vstupně-výstupních požadavků za sekundu s každým hostitelem, který stále udržuje sekvenční latenci událostí čtení souboru databáze v milisekundách. S velikostí bloku databáze 8 KB se mezi třemi hostiteli rovná přibližně 20 000 MiB/s.

Spojnicový graf kolektivního náhodného úložiště z pohledu vstupně-výstupních operací

Propustnost více hostitelů

Následující diagram ukazuje, že u sekvenčních úloh může Azure NetApp Files stále poskytovat možnosti plné šířky pásma samotného virtuálního počítače E104ids_v5 i v případě, že se škáluje směrem ven. SLOB2 dokázal řídit vstupně-výstupní operace celkem přes 30 000 MiB/s napříč třemi hostiteli během paralelního spouštění.

Skládaný pruhový graf kolektivní sekvenční propustnosti

Skutečný výkon

Po otestování limitů škálování pomocí SLOB2 se testy prováděly se sadou aplikací v reálném dodavatelském řetězci proti Oracle v Azure NetApp files s vynikajícími výsledky. Následující data ze sestavy AWR (Oracle Automatic Workload Repository) jsou zvýrazněná na to, jak se provedla jedna konkrétní kritická úloha.

Tato databáze má kromě úlohy aplikace významné další vstupně-výstupní operace, protože je povolená funkce flashback a má velikost bloku databáze 16 tisíc. V části profilu vstupně-výstupních operací sestavy AWR je zřejmé, že ve srovnání se čtením existuje velký poměr zápisů.

- Čtení a zápis za sekundu Čtení za sekundu Zápis za sekundu
Celkem (MB) 4,988.1 1,395.2 3,592.9

Navzdory události sekvenčního čekání na čtení souboru db s vyšší latencí při 2,2 ms než při testování SLOB2 tento zákazník zaznamenal patnáctminutové snížení doby provádění úloh pocházející z databáze RAC v Exadata na databázi jedné instance v Azure.

Omezení prostředků Azure

Všechny systémy nakonec narazily na omezení prostředků, tradičně označované jako chokepointy. Databázové úlohy, zejména velmi náročné, jako jsou sady aplikací dodavatelského řetězce, jsou entity náročné na prostředky. Nalezení těchto omezení prostředků a jejich zpracování je nezbytné pro úspěšné nasazení. Tato část objasňuje různá omezení, se kterými se můžete setkat v právě takovém prostředí, a způsob jejich práce. V jednotlivých dílčích oddílech se dozvíte jak osvědčené postupy, tak odůvodnění.

Virtuální počítače

Tato část podrobně popisuje kritéria, která se mají zvážit při výběru virtuálních počítačů pro zajištění nejlepšího výkonu, a odůvodnění výběru provedeného při testování. Azure NetApp Files je služba NaS (Network Attached Storage), proto je pro optimální výkon důležitá vhodná velikost šířky pásma sítě.

Chipsety

Prvním tématem zájmu je výběr čipové sady. Ujistěte se, že libovolná skladová položka virtuálního počítače, kterou vyberete, je postavená na jedné čipové sadě z důvodů konzistence. Varianta Intel E_v5 virtuálních počítačů běží na konfiguraci Intel Xeon Platinum 8370C (Ice Lake) třetí generace. Všechny virtuální počítače v této rodině jsou vybaveny jedním síťovým rozhraním 100 Gb/s. Naproti tomu řada E_v3, kterou jsme zmínili například, je postavená na čtyřech samostatných čipových sadách s různými šířkami pásma fyzické sítě. Čtyři čipové sady používané v E_v3 rodině (Broadwell, Skylake, Cascade Lake, Haswell) mají různé rychlosti procesoru, které ovlivňují charakteristiky výkonu počítače.

Pečlivě si přečtěte dokumentaci ke službě Azure Compute a věnujte pozornost možnostem čipové sady. Pro Azure NetApp Files se také podívejte na osvědčené postupy skladových položek virtuálních počítačů Azure. Výběr virtuálního počítače s jednou čipovou sadou je vhodnější pro nejlepší konzistenci.

Dostupná šířka pásma

Je důležité pochopit rozdíl mezi dostupnou šířkou pásma síťového rozhraní virtuálního počítače a měřenou šířkou pásma použitou na stejné straně. Pokud dokumentace ke službě Azure Compute hovoří o limitech šířky pásma sítě, použijí se tyto limity jenom pro výchozí přenos dat (zápis). Příchozí provoz (čtení) není měřený a proto je omezený pouze fyzickou šířkou pásma samotné síťové karty. Šířka pásma sítě většiny virtuálních počítačů odsadí limit výchozího přenosu použitého pro počítač.

Vzhledem k tomu, že jsou svazky Azure NetApp Files připojené k síti, je možné omezení výchozího přenosu dat považovat za použití proti zápisům konkrétně, zatímco příchozí přenos dat je definován jako úlohy typu čtení a čtení. I když je výchozí limit většiny počítačů větší než šířka pásma sítě síťové karty, totéž nelze říci pro E104_v5 použité při testování tohoto článku. E104_v5 má také 100 Gb/s s limitem výchozího přenosu dat nastaveným na 100 Gb/s. Ve srovnání s E96_v5 má její síťová karta 100 Gb/s limit výchozího přenosu dat 35 Gb/s s nefetterovaným příchozím přenosem dat na 100 Gb/s. S tím, jak se virtuální počítače zmenšují, omezení výchozího přenosu dat se zmenší, ale příchozí přenos dat zůstává nefetterovaný logickými limity.

Omezení výchozího přenosu dat jsou pro virtuální počítače široká a používají se jako takové pro všechny síťové úlohy. Při použití Oracle Data Guard se všechny zápisy zdvojnásobí na archivační protokoly a musí být důležité zvážit omezení výchozího přenosu dat. To platí také pro protokol archivu s více cíli a RMAN, pokud se používá. Při výběru virtuálních počítačů se seznamte s nástroji příkazového řádku, jako ethtooljsou nástroje příkazového řádku, které zpřístupňují konfiguraci síťové karty, protože Azure nekomentuje konfigurace síťového rozhraní.

Souběžnost sítě

Virtuální počítače Azure a svazky Azure NetApp Files jsou vybaveny určitými objemy šířky pásma. Jak je znázorněno dříve, pokud má virtuální počítač dostatečnou kapacitu procesoru, může úloha teoreticky spotřebovat šířku pásma, která je k dispozici – to je v mezích použitého limitu síťové karty nebo výchozího přenosu dat. V praxi se ale množství dosažitelné propustnosti predikuje na souběžnost úlohy v síti, tedy počtu síťových toků a koncových bodů sítě.

Pokud chcete lépe porozumět, přečtěte si část omezení toku sítě virtuálních počítačů v dokumentu o šířce pásma sítě. Poznatky: čím více síťových toků připojuje klienta k úložišti, tím větší je potenciální výkon.

Oracle podporuje dva samostatné klienty NFS, systém souborů NFS jádra a přímý systém souborů NFS (dNFS). Systém souborů NFS jádra až do konce podporuje jeden síťový tok mezi dvěma koncovými body (výpočetní – úložiště). Přímý systém souborů NFS, tím výkonnější ze dvou, podporuje proměnlivý počet síťových toků – testy ukázaly stovky jedinečných připojení na koncový bod – zvýšení nebo snížení požadavků na zatížení. Vzhledem k škálování síťových toků mezi dvěma koncovými body je přímý systém souborů NFS daleko upřednostňovaný před systémem souborů NFS jádra a proto doporučenou konfigurací. Produktová skupina Azure NetApp Files nedoporučuje používat systém souborů NFS jádra s úlohami Oracle. Další informace najdete v tématu Výhody používání služby Azure NetApp Files se službou Oracle Database.

Souběžnost spouštění

Použití systému souborů NFS s přímým přístupem, jedné čipové sady pro konzistenci a pochopení omezení šířky pásma sítě vám zatím stačí. Aplikace nakonec řídí výkon. Testování konceptu využívající SLOB2 a testování konceptu využívající sadu aplikací reálného dodavatelského řetězce proti skutečným zákaznickým datům dokázala řídit značné objemy propustnosti pouze proto, že aplikace běžely ve vysoké míře souběžnosti; dříve používající významný počet vláken na schéma, druhý pomocí více připojení z více aplikačních serverů. Stručně řečeno souběžnost řídí úlohy, nízkou souběžnost a nízkou propustnost, vysokou souběžnost– vysokou propustnost, pokud je infrastruktura zavedená tak, aby podporovala stejnou propustnost.

Akcelerované síťové služby

Akcelerované síťové služby povolují na virtuálním počítači virtualizaci rozhraní SR-IOV (Single-Root I/O Virtualization), která výrazně zvyšuje výkon sítě. Tato cesta s vysokým výkonem obchází hostitele z cesty k datům, což snižuje latenci, zpoždění a využití procesoru u nejnáročnějších síťových úloh na podporovaných typech virtuálních počítačů. Při nasazování virtuálních počítačů prostřednictvím nástrojů pro správu konfigurace, jako je terraform nebo příkazový řádek, mějte na paměti, že akcelerované síťové služby nejsou ve výchozím nastavení povolené. Pro zajištění optimálního výkonu povolte akcelerované síťové služby. Poznamenejte si, akcelerované síťové služby jsou povolené nebo zakázané v síťovém rozhraní podle síťového rozhraní. Akcelerovaná síťová funkce je ta, která může být dynamicky povolená nebo zakázaná.

Poznámka:

Tento článek obsahuje odkazy na termín SLAVE, termín, který už Microsoft nepoužívá. Až bude tento termín ze softwaru odstraněn, odstraníme ho i z tohoto článku.

Autoritativní přístup k vytváření akcelerovaných síťových adaptérů je povolený prostřednictvím terminálu Linux. Pokud je pro síťové rozhraní povolené akcelerované síťové rozhraní, je k první síťové kartě přidružená druhá virtuální síťová karta. Tato druhá síťová karta je nakonfigurována systémem s povoleným příznakem SLAVE . Pokud není k dispozici žádná síťová karta s příznakem SLAVE , akcelerované síťové služby nejsou pro toto rozhraní povolené.

Ve scénáři, kdy je nakonfigurováno více síťových adaptérů, je potřeba určit, které SLAVE rozhraní je přidružené k síťové kartě používané k připojení svazku NFS. Přidání síťových karet na virtuální počítač nemá žádný vliv na výkon.

Pomocí následujícího postupu identifikujte mapování mezi nakonfigurovaným síťovým rozhraním a přidruženým virtuálním rozhraním. Tento proces ověří, že je pro konkrétní síťovou kartu na vašem počítači s Linuxem povolená akcelerovaná síťová karta, a zobrazí rychlost fyzického příchozího přenosu dat, kterého může síťová karta potenciálně dosáhnout.

  1. ip a Spusťte příkaz:Snímek obrazovky s výstupem příkazu IP
  2. /sys/class/net/ Uveďte adresář ID síťové karty, které ověřujete (eth0v příkladu) a grep pro slovo nižší:
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. ethtool Spusťte příkaz na ethernetovém zařízení označeném jako nižší zařízení v předchozím kroku. Snímek obrazovky s výstupem nastavení pro eth1

Virtuální počítač Azure: Síťová vs. omezení šířky pásma disku

Při čtení dokumentace k limitům výkonu virtuálních počítačů Azure se vyžaduje úroveň odborných znalostí. Mějte na paměti:

  • Dočasná propustnost úložiště a čísla IOPS odkazují na možnosti výkonu dočasného úložiště přímo připojeného k virtuálnímu počítači.
  • Propustnost disku bez mezipaměti a vstupně-výstupní čísla odkazují konkrétně na Disk Azure (Premium, Premium v2 a Ultra) a nemají žádný vliv na síťové připojené úložiště, jako je Azure NetApp Files.
  • Připojení dalších síťových adaptérů k virtuálnímu počítači nemá žádný vliv na limity výkonu nebo možnosti výkonu virtuálního počítače (zdokumentované a otestované tak, aby byly pravdivé).
  • Maximální šířka pásma sítě odkazuje na omezení výchozího přenosu dat (tj. při zápisu, když je zahrnuta služba Azure NetApp Files) na šířku pásma sítě virtuálních počítačů. Nejsou použita žádná omezení příchozího přenosu dat (tj. čtení při použití služby Azure NetApp Files). Vzhledem k dostatečnému využití procesoru, dostatek souběžnosti sítě a dostatek koncových bodů může virtuální počítač teoreticky řídit příchozí provoz na limity síťové karty. Jak je uvedeno v části Dostupná šířka pásma sítě, použijte nástroje, které ethtool slouží k zobrazení šířky pásma síťové karty.

Pro referenci se zobrazí ukázkový graf:

Snímek obrazovky tabulky zobrazující ukázková data grafu

Azure NetApp Files

Služba Azure NetApp Files prvního výrobce úložiště azure poskytuje vysoce dostupné plně spravované řešení úložiště, které podporuje náročné úlohy Oracle zavedené dříve.

Vzhledem k tomu, že omezení výkonu úložiště vertikálního navýšení kapacity v databázi Oracle jsou dobře pochopitelné, tento článek se záměrně zaměřuje na výkon úložiště se škálováním na více systémů. Horizontální navýšení kapacity úložiště znamená, že poskytuje jednu instanci Oracle přístup k mnoha svazkům Azure NetApp Files, kde se tyto svazky distribuují přes několik koncových bodů úložiště.

Škálováním databázové úlohy napříč několika svazky takovým způsobem se výkon databáze neztratuje z horních limitů svazku i koncového bodu. Díky tomu, že úložiště už neukládá omezení výkonu, stane se architektura virtuálního počítače (omezení výkonu, procesoru, síťové karty a výchozích přenosů virtuálních počítačů). Jak je uvedeno v části virtuálních počítačů, výběr E104ids_v5 a E96ds_v5 instancí se na to upozornil.

Bez ohledu na to, jestli je databáze umístěná na jednom svazku s velkou kapacitou nebo rozložená do několika menších svazků, celkové finanční náklady jsou stejné. Výhodou distribuce vstupně-výstupních operací mezi více svazků a koncových bodů na rozdíl od jednoho svazku a koncového bodu je zabránění limitům šířky pásma – můžete použít úplně to, za co platíte.

Důležité

Pokud chcete nasadit službu Azure NetApp Files v multiple volume:multiple endpoint konfiguraci, požádejte o pomoc specialistu na Azure NetApp Files nebo architekta cloudových řešení.

Databáze

Databáze Oracle verze 19c je aktuální verze dlouhodobé verze Oracle a ta, která se používá k vytvoření všech výsledků testů probíraných v tomto dokumentu.

Pro zajištění nejlepšího výkonu se všechny databázové svazky připojily pomocí systému souborů NFS s přímým přístupem, doporučuje se systém souborů NFS jádra z důvodu omezení výkonu. Porovnání výkonu mezi těmito dvěma klienty najdete v tématu Výkon databáze Oracle na jednotlivých svazcích Azure NetApp Files. Všimněte si, že byly použity všechny relevantní opravy dNFS (Oracle Support ID 1495104), stejně jako osvědčené postupy popsané v databázích Oracle v Microsoft Azure pomocí sestavy Azure NetApp Files .

I když Oracle a Azure NetApp Files podporují NFSv3 i NFSv4.1, protože NFSv3 je vyspělejší protokol, který je obecně považován za nejstabilnější a je spolehlivější možností pro prostředí, která jsou vysoce citlivá na přerušení. Testování popsané v tomto článku bylo dokončeno přes NFSv3.

Důležité

Některé z doporučených oprav, které dokumenty Oracle v ID podpory 1495104 jsou důležité pro zachování integrity dat při použití dNFS. Aplikace těchto oprav se důrazně doporučuje pro produkční prostředí.

Pro svazky NFS se podporuje automatická správa úložiště (ASM). I když je obvykle spojeno s blokovým úložištěm, kde ASM nahrazuje správu logických svazků (LVM) i systém souborů, hraje ASM důležitou roli ve scénářích NFS s více svazky a stojí za to zvážit. Jednou z takových výhod ASM, dynamického online přidávání a vyrovnávání mezi nově přidaných svazky NFS a koncovými body, zjednodušuje správu umožňující rozšíření výkonu i kapacity. I když ASM nezvyšuje ani nezvyšuje výkon databáze, jeho použití zabraňuje horkým souborům a nutnost ruční údržby distribuce souborů – to je výhoda, která se snadno zobrazí.

Ke generování všech výsledků testů probíraných v tomto článku se použila konfigurace ASM přes dNFS. Následující diagram znázorňuje rozložení souboru ASM ve svazcích Azure NetApp Files a přidělení souborů skupinám disků ASM.

Diagram automatické správy úložiště Oracle pomocí služby Azure NetApp Files

Při používání ASM přes připojené svazky NFS služby Azure NetApp Files existují určitá omezení, pokud jde o snímky úložiště, které je možné překonat s určitými aspekty architektury. Pokud ho chcete podrobně zkontrolovat, obraťte se na odborníka na Azure NetApp Files nebo architekta cloudových řešení.

Syntetické testovací nástroje a nastavitelné

Tato část popisuje testovací architekturu, vyladěné a podrobné informace o konfiguraci. Zatímco předchozí část se zaměřuje na důvody, proč se provádějí rozhodnutí o konfiguraci, zaměřuje se tato část konkrétně na to, "co" rozhodnutí o konfiguraci.

Automatizované nasazení

  • Databázové virtuální počítače se nasazují pomocí skriptů Bash dostupných na GitHubu.
  • Rozložení a přidělení více svazků a koncových bodů Azure NetApp Files se dokončí ručně. Pokud potřebujete pomoc, musíte spolupracovat se specialistou na Azure NetApp Files nebo architektem cloudových řešení.
  • Instalace mřížky, konfigurace ASM, vytvoření a konfigurace databáze a prostředí SLOB2 na každém počítači se konfiguruje pomocí Ansible pro konzistenci.
  • Paralelní spouštění testů SLOB2 napříč více hostiteli se také dokončí pomocí Ansible pro konzistenci a souběžné provádění.

Konfigurace virtuálního počítače

Konfigurace Hodnota
Oblast Azure Západní Evropa
Skladová položka virtuálního počítače E104ids_v5
Počet síťových adaptérů 1 POZNÁMKA: Přidání virtuálních síťových adaptérů nemá žádný vliv na počet systémů
Maximální šířka pásma odchozí sítě (Mb/s) 100 000
Dočasné úložiště (SSD): GiB 3,800

Konfigurace systému

Všechna požadovaná nastavení konfigurace systému Oracle pro verzi 19c byla implementována podle dokumentace Oracle.

Do systémového souboru Linuxu /etc/sysctl.conf byly přidány následující parametry:

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

Všechny svazky Azure NetApp Files byly připojeny s následujícími možnostmi připojení NFS.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Parametry databáze

Parametry Hodnota
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3g
pga_aggregate_limit 3g
sga_target 25g
shared_io_pool_size 500 m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

Konfigurace SLOB2

Všechna generování úloh pro testování byla dokončena pomocí nástroje SLOB2 verze 2.5.4.

Čtrnáct schémat SLOB2 se načetla do standardního prostoru tabulek Oracle a spustila se proti kterým v kombinaci s uvedením nastavení konfiguračního souboru SLOB2 byla nastavena sada dat SLOB2 na 7 TiB. Následující nastavení odráží náhodné spuštění čtení pro SLOB2. Parametr SCAN_PCT=0 konfigurace se během sekvenčního testování změnil na SCAN_PCT=100 .

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

V případě náhodného testování čtení se provedlo devět spuštění SLOB2. Počet vláken byl zvýšen o šest při každé iteraci testů počínaje jednou.

Pro sekvenční testování bylo provedeno sedm spuštění SLOB2. Počet vláken byl zvýšen o dva s každou iterací testů počínaje jednou. Počet vláken byl omezen na šest kvůli dosažení maximálních limitů šířky pásma sítě.

Metriky AWR

Všechny metriky výkonu byly hlášeny prostřednictvím úložiště AWR (Oracle Automatic Workload Repository). Ve výsledcích jsou uvedené následující metriky:

  • Propustnost: součet průměrné propustnosti čtení a propustnosti zápisu z oddílu Profil zatížení AWR
  • Průměrné požadavky na vstupně-výstupní operace čtení z oddílu Profilu zatížení AWR
  • Db soubor sekvenční čtení čekací událost průměrná doba čekání z AWR Foreground Wait Events oddílu

Migrace z účelově vytvořených, inženýrovaných systémů do cloudu

Oracle Exadata je navržená systémová kombinace hardwaru a softwaru, která je považována za nejoptimaličtější řešení pro spouštění úloh Oracle. Přestože cloud má v celkovém schématu technického světa významné výhody, tyto specializované systémy můžou vypadat neuvěřitelně atraktivní pro ty, kteří si přečetli a prohlédli optimalizace, které Oracle vytvořil na základě svých konkrétních úloh.

Pokud jde o spuštění Oracle na Exadata, existuje několik běžných důvodů, proč je exadata zvolena:

  • 1–2 vysoké vstupně-výstupní úlohy, které jsou přirozeně vhodné pro funkce Exadata, a protože tyto úlohy vyžadují významné funkce analýzy Exadata, zbytek databází spuštěných spolu s nimi byl konsolidovaný do Exadata.
  • Složité nebo obtížné úlohy OLTP, které vyžadují škálování RAC a jsou obtížné navrhovat s proprietárním hardwarem bez hlubších znalostí o optimalizaci Oracle nebo může být technický dluh, který se nedá optimalizovat.
  • Nevyužitá stávající exadata s různými úlohami: existuje buď kvůli předchozím migracím, ukončení životnosti předchozího exadata, nebo kvůli tomu, že si přejete pracovat/testovat interní exadata.

Je nezbytné, aby všechny migrace ze systému Exadata pochopili z hlediska úloh a jak jednoduchá nebo složitá může být migrace. Sekundární potřeba je pochopit důvod nákupu Exadata z pohledu stavu. Dovednosti Exadata a RAC jsou ve vyšší poptávce a mohly by na základě doporučení koupit jeden z technických zúčastněných stran.

Důležité

Bez ohledu na scénář by měla být celková hodnota pro všechny databázové úlohy pocházející z Exadata, čím více používaných funkcí Exadata, tím složitější je migrace a plánování. Prostředí, která nevyužívají proprietární funkce Exadata, mají příležitosti pro jednodušší proces migrace a plánování.

K vyhodnocení těchto příležitostí k úlohám je možné použít několik nástrojů:

  • Automatické úložiště úloh (AWR):
    • Všechny databáze Exadata mají licenci k používání sestav AWR a připojených funkcí výkonu a diagnostiky.
    • Je vždy zapnutá a shromažďuje data, která je možné použít k zobrazení historických informací o úlohách a vyhodnocení využití. Hodnoty ve špičce můžou vyhodnotit vysoké využití v systému,
    • Sestavy AWR s větším oknem můžou posoudit celkovou úlohu a poskytnout cenný přehled o využití funkcí a o tom, jak efektivně migrovat úlohy na jiné než Exadata. Sestavy AWR ve špičce jsou nejlepší pro optimalizaci výkonu a řešení potíží.
  • Globální sestava AWR (RAC-Aware) pro Exadata obsahuje také část specifickou pro Exadata, která přejde k podrobnostem o využití konkrétních funkcí Exadata a poskytuje cenné informace o mezipaměti flash informací, protokolování blesku, vstupně-výstupní operace a další využití funkcí podle databáze a uzlu buňky.

Oddělení od Exadata

Při identifikaci úloh Oracle Exadata pro migraci do cloudu zvažte následující otázky a datové body:

  • Využívá úloha více funkcí Exadata mimo výhody hardwaru?
    • Inteligentní kontroly
    • Indexy úložiště
    • Mezipaměť Flash
    • Protokolování flash
    • Hybridní sloupcová komprese
  • Je úloha efektivním snižováním zátěže Exadata? Jaký je poměr úloh (více než 10 % času databáze) v událostech popředí v nejvyšším čase pomocí:
    • Kontrola inteligentní tabulky v buňce (optimální)
    • Víceblokové fyzické čtení buněk (méně optimální)
    • Jednoblokové fyzické čtení buňky (nejméně optimální)
  • Hybridní sloupcová komprese (HCC/EHCC): Co je komprimovaný vs. nekomprimovaný poměr:
    • Utrácí databáze více než 10 % času databáze při komprimaci a dekompresi dat?
    • Prozkoumejte zvýšení výkonu u predikátů pomocí komprese v dotazech: stojí za to hodnota oproti množství uložené s kompresí?
  • Fyzické vstupně-výstupní operace buněk: Zkontrolujte úspory poskytnuté z:
    • množství směrované na uzel databáze pro vyrovnávání zatížení procesoru.
    • určuje počet bajtů vrácených inteligentní kontrolou. Tyto hodnoty je možné odečíst v vstupně-výstupních operacích pro procento fyzického čtení jednoho bloku buňky, jakmile se migruje z Exadata.
  • Všimněte si počtu logických čtení z mezipaměti. Určete, jestli bude pro úlohu vyžadována mezipaměť Flash v cloudovém řešení IaaS.
  • Porovnejte celkový počet bajtů fyzického čtení a zápisu s celkovým součtem provedeným v mezipaměti. Je možné zvýšit paměť, aby se eliminovaly požadavky na fyzické čtení (u některých je běžné zmenšit SGA, aby se vynutilo snižování zátěže exadata)?
  • Ve statistikách systému určete, na jaké objekty má vliv jaká statistika. Pokud ladění SQL, další indexování, dělení nebo jiné fyzické ladění může úlohy výrazně optimalizovat.
  • Zkontrolujte parametry inicializace pro podtržítka (_) nebo zastaralé parametry, které by měly být odůvodněny z důvodu dopadu na úroveň databáze, které můžou způsobovat výkon.

Konfigurace serveru Exadata

Ve verzi Oracle 12.2 a novějších bude do globální sestavy AWR zahrnuta specifická hodnota Exadata. Tato sestava obsahuje oddíly, které poskytují výjimečnou hodnotu migrace z Exadata.

  • Podrobnosti o verzi Exadata a systému

  • Podrobnosti upozornění uzlu buňky

  • Neonline disky Exadata

  • Odlehlé hodnoty pro všechny statistiky operačního systému Exadata

    • Žlutá/růžová: Obavy. Exadata neběží optimálně.

    • Červená: Výkon Exadata je výrazně ovlivněný.

    • Statistika procesoru operačního systému Exadata: horní buňky

      • Tyto statistiky shromažďují operační systém v buňkách a nejsou omezeny na tuto databázi nebo instance.
      • Tmavě v žluté pozadí značí odlehlou hodnotu pod nízkým rozsahem.
      • Světle ^ žluté pozadí označuje odlehlou hodnotu nad vysokým rozsahem.
      • Horní buňky podle procenta procesoru se zobrazují a jsou v sestupném pořadí procent procesoru.
      • Průměr: 39,34% CPU, 28,57% uživatel, 10,77% sys

      Snímek obrazovky tabulky zobrazující horní buňky podle procentuálního využití procesoru

  • Čtení fyzického bloku s jednou buňkou

  • Využití mezipaměti Flash

  • Dočasné vstupně-výstupní operace

  • Efektivita sloupcové mezipaměti

Hlavní databáze podle propustnosti vstupně-výstupních operací

I když je možné provést posouzení velikosti, existují některé otázky týkající se průměrů a simulovaných špiček, které jsou integrované do těchto hodnot pro velké úlohy. Tato část, která se nachází na konci sestavy AWR, je mimořádně cenná, protože ukazuje průměrné využití flash disku i 10 nejlepších databází v Exadata. I když mnozí můžou předpokládat, že chtějí velikost databází za účelem maximálního výkonu v cloudu, pro většinu nasazení to nemá smysl (přes 95 % je v průměrném rozsahu; se simulovanou špičkou vypočítanou v průměru je průměrný rozsah větší než 98 %). Je důležité platit za to, co je potřeba, a to i v případě nejvyšších úloh Oracle na vyžádání a zkoumání hlavních databází podle propustnosti vstupně-výstupních operací může být lepší pochopit potřeby prostředků pro databázi.

Správná velikost Oracle pomocí AWR v Exadata

Při plánování kapacity pro místní systémy je přirozené mít do hardwaru integrovanou významnou režii. Za několik let musí přeřazovací hardware obsluhovat úlohu Oracle, a to bez ohledu na to, jestli se úlohy přibyly kvůli růstu dat, změnám kódu nebo upgradům.

Jednou z výhod cloudu je škálování prostředků v hostiteli virtuálního počítače a úložiště je možné provádět s rostoucími požadavky. To pomáhá šetřit náklady na cloud a licenční náklady, které jsou připojené k využití procesoru (relevantní pro Oracle).

Nastavení správné velikosti zahrnuje odebrání hardwaru z tradiční migrace metodou "lift and shift" a použití informací o úlohách poskytovaných úložištěm automatických úloh společnosti Oracle (AWR) k zvednutí a přesunutí úlohy do výpočetních prostředků a úložiště, které je speciálně navržené tak, aby ji podporovalo v cloudu podle výběru zákazníka. Proces správné velikosti zajišťuje, že architektura v budoucnu odebere technický dluh infrastruktury, redundanci architektury, ke které dojde, pokud by se duplikace místního systému replikovala do cloudu a implementuje cloudové služby, kdykoli je to možné.

Odborníci na danou problematiku Společnosti Microsoft Oracle odhadli, že více než 80 % databází Oracle je nadměrně zřízeno a mají stejné náklady nebo úspory v cloudu, pokud před migrací do cloudu zabírají čas správné velikosti databázové úlohy Oracle. Toto posouzení vyžaduje, aby odborníci na databáze v týmu přesunuli svůj názor na to, jak mohli v minulosti provádět plánování kapacity, ale stojí za investice zúčastněných stran do cloudu a cloudové strategie firmy.

Další kroky