AWR: kui palju "ekzadatiseerib" andmebaasi töö?

Selle väikese postitusega soovin hajutada ühte arusaamatust, mis on seotud AWR analüüsiga andmebaasidest, mis töötavad Oracle Exadata süsteemil. Peaaegu 10 aastat olen pidevalt silmitsi seisnud küsimusega: milline on Exadata tarkvara panus jõudlusesse? Või, uute sõnadega väljendades: kui palju "ekzadatiseerib" mingi andmebaasi töö?

Sageli antakse sellele õigetele küsimustele, minu arvates, vale vastus, viidates AWR statistikale. Selles on esitatud süsteemsete ootuste meetod, mis tõlgendab reageerimise aega kui protsessorite (DB CPU) tööaega ja erinevate klasside ootuste aega summana.

Exadata ilmumisega on AWR statistikasse ilmunud Exadata tarkvaraga seotud spetsiifilised süsteemsed ootused. Nende ootustega seotud nimed algavad tavaliselt sõnaga "cell" (Exadata salvestusseadet nimetatakse rakuks); kõige sagedamini esinevad ootused, millel on rääkivad nimed nagu "cell smart table scan", "cell multiblock physical read" ja "cell single block physical read".

Enamikul juhtudel on selliste Exadata ootuste osakaal kogu reageerimise ajas väike ja seetõttu ei saa nad isegi Top10 Foreground Events by Total Wait Time sektsiooni (sellisel juhul tuleb neid otsida Foreground Wait Events sektsioonist). Oleme oma klientide juures vaevu leidnud näite ööpäevasest AWR-ist, kus Exadata ootused pääsesid Top10 sektsiooni ja kokku moodustasid umbes 5%:

Sündmus

Ootused

Kogu ooteaeg (sekundites)

Keskmine ooteaeg

% DB aeg

Oote klass

DB CPU

115.2K

70.4

SQL*Net rohkem andmeid dblinkilt

670,196

5471.5

8.16ms

3.3

Võrk

cell single block physical read

5,661,452

3827.6

676.07us

2.3

Kasutaja I/O

Sync ASM tasakaalustus

4,350,012

3481.3

800.30us

2.1

Muu

cell multiblock physical read

759,885

2252

2.96ms

1.4

Kasutaja I/O

otsene path read

374,368

1811.3

4.84ms

1.1

Kasutaja I/O

SQL*Net sõnum dblinkilt

7,983

1725

216.08ms

1.1

Võrk

cell smart table scan

1,007,520

1260.7

1.25ms

0.8

Kasutaja I/O

otsene path read temp

520,211

808.4

1.55ms

0.5

Kasutaja I/O

enq: TM — konkurents

652

795.8

1220.55ms

0.5

Application

Sellest AWR statistikast tehakse sageli selliseid järeldusi:

1. Exadata maagia panus andmebaasi jõudlusesse ei ole kõrge — ei ületa 5%, ja andmebaas "ekzadatiseerib" halvasti.

2. Kui selline andmebaas viia Exadata süsteemist klassikalisele arhitektuurile "server + maht", siis jõudlus ei muutu oluliselt. Sest isegi kui see maht osutub kolmandiku võrra aeglasemaks kui Exadata salvestussüsteem (mis on tänapäevaste All Flash mahtude puhul vaevalt võimalik), siis 5% korrutades kolm korda saame I/O ootuste osakaalu tõusuks 15% — sellise koormuse talub andmebaas kindlasti!

Mõlemad need väljendid on ebatäpsed, lisaks moonutavad nad arusaama Exadata Software'i ideest. Exadata ei paku mitte ainult kiiret sisendi-väljundi, vaid töötab põhimõtteliselt erinevalt klassikalisest arhitektuurist „server + salvestus”. Kui andmebaasi töö tõeliselt „ekzadatiitub”, siis SQL-loogika kantakse salvestussüsteemi. Storage serverid kõik tänu mitmele erimehhanismile (esmajärjekorras Exadata Storage Indexes, aga mitte ainult) leiavad ise vajalikud andmed ja edastavad need DB serveritele. Nad teevad seda piisavalt efektiivselt, seetõttu on Exadata spetsiifiliste ootuste osakaal kogu vastamisajas madal. 

Kuidas see osakaal Exadata-st väljaspool muutub? Kuidas see mõjutab andmebaasi jõudlust üldiselt? Parim viis nendele küsimustele vastata on testimine. Näiteks võib ootamine „cell smart table scan” Exadata-st väljaspool muutuda nii raskeks Table Full Scan'iks, et sisendi-väljund võtab kogu vastamisaja ja jõudlus halveneb dramaatiliselt. Just seetõttu on vale analüüsides AWR pidada Exadata ootuste kogusummat selle maagia panuseks jõudluses ja veelgi enam kasutada seda protsenti jõudluse prognoosimiseks Exadata-st väljaspool. Et mõista, kui palju „ekzadataitub” andmebaasi töö, tuleb uurida AWR statistikat jaotises “Instance Activity Stats” (seal on palju statistikat kõlava nimega) ja võrrelda neid omavahel.

Ja et mõista, kuidas andmebaas väljaspool Exadata tunneb, on kõige parem teha varukoopiast kloon sihtarhitektuuril ja analüüsi selle klooni jõudlust koormuse all. Selline võimalus on Exadata omanikel tavaliselt olemas.

Autor: Aleksei Strutsjenko, andmebaaside juht „Infosüsteemid Jet”

Allikas: habr.com