Met hierdie kort plasing wil ek een misverstand uit die weg ruim wat verband hou met die ontleding van AWR-databasisse wat op Oracle Exadata loop. Vir byna 10 jaar word ek voortdurend gekonfronteer met die vraag: wat is die bydrae van Exadata Software tot produktiwiteit? Of die gebruik van nuutgemaakte woorde: hoe “kundige” is die werk van 'n bepaalde databasis?
Dikwels word hierdie korrekte vraag, myns insiens, verkeerd beantwoord met verwysing na AWR-statistieke. Dit bied die stelselwagmetode aan, wat reaksietyd behandel as die som van die bedryfstyd van verwerkers (DB-SVE's) en die wagtyd van verskeie klasse.
Met die koms van Exadata het spesifieke stelselverwagtinge wat verband hou met die werking van Exadata-sagteware in AWR-statistieke verskyn. As 'n reël begin die name van sulke wagte met die woord "sel" (die Exadata Storage-bediener word 'n sel genoem), waarvan die mees algemene wagte is met noemende name "sel slim tafel skandering", "sel multiblok fisiese lees" en "sel enkelblok fisiese lees".
In die meeste gevalle is die aandeel van sulke Exadata-wagte in die totale reaksietyd klein, en daarom val hulle nie eers in die Top10 Voorgrondgebeurtenisse volgens Totale Wagtyd-afdeling nie (in hierdie geval moet jy dit in die Voorgrondwag soek Gebeurtenisse afdeling). Met groot moeite het ons 'n voorbeeld van daaglikse AWR van ons kliënte gevind, waarin Exadata-verwagtinge ingesluit is in die Top10-afdeling en in totaal ongeveer 5% beloop:
Event
wag
Totale wagtyd (sek.)
Gem. wag
%DB tyd
Wag Klas
DB SVE
115.2K
70.4
SQL*Net meer data vanaf dblink
670,196
5471.5
8.16ms
3.3
Netwerk
sel enkelblok fisiese lees
5,661,452
3827.6
676.07us
2.3
Gebruiker I/O
Sinkroniseer ASM-herbalansering
4,350,012
3481.3
800.30us
2.1
ander
sel multiblok fisiese lees
759,885
2252
2.96ms
1.4
Gebruiker I/O
direkte pad lees
374,368
1811.3
4.84ms
1.1
Gebruiker I/O
SQL*Net-boodskap vanaf dblink
7,983
1725
216.08ms
1.1
Netwerk
sel slim tafel skandering
1,007,520
1260.7
1.25ms
0.8
Gebruiker I/O
direkte pad lees temp
520,211
808.4
1.55ms
0.5
Gebruiker I/O
enq: TM - bewering
652
795.8
1220.55ms
0.5
Aansoek
Die volgende gevolgtrekkings word dikwels uit sulke AWR-statistieke gemaak:
1. Die bydrae van Exadata-magie tot databasisprestasie is nie hoog nie - dit oorskry nie 5% nie, en die databasis "exadatiseer" swak.
2. As so 'n databasis van Exadata na die klassieke "server + array"-argitektuur oorgedra word, sal die werkverrigting nie veel verander nie. Want selfs al blyk hierdie skikking drie keer stadiger te wees as die Exadata-bergingstelsel (wat beswaarlik moontlik is vir moderne All Flash-skikkings), as ons 5% met drie vermenigvuldig, kry ons 'n toename in die aandeel van I/O wag tot 15% - die databasis sal dit beslis oorleef!
Beide hierdie gevolgtrekkings is onakkuraat, boonop verdraai dit die begrip van die idee agter Exadata Software. Exadata bied nie net vinnige I/O nie, dit werk fundamenteel anders in vergelyking met die klassieke bediener + skikking argitektuur. As die databasisbewerking werklik "aangepas" is, word die SQL-logika na die stoorstelsel oorgedra. Bergingsbedieners, danksy 'n aantal spesiale meganismes (hoofsaaklik Exadata Storage Indexes, maar nie net nie), vind self die nodige data en stuur die DB na die bedieners. Hulle doen dit redelik doeltreffend, so die deel van tipiese Exadata-wagte in die totale reaksietyd is klein.
Hoe sal hierdie aandeel buite Exadata verander? Hoe sal dit die werkverrigting van die databasis as geheel beïnvloed? Toetsing sal hierdie vrae die beste beantwoord. Byvoorbeeld, om te wag vir 'n "sel slim tafel skandering" buite Exadata kan verander in so 'n swaar Table Full Scan dat I/O die hele reaksietyd in beslag neem en werkverrigting dramaties verswak. Dit is hoekom dit verkeerd is, wanneer AWR ontleed word, om die totale persentasie van Exadata-verwagtinge te beskou as die bydrae van sy magie tot prestasie, en nog meer om hierdie persentasie te gebruik om prestasie buite Exadata te voorspel. Om te verstaan hoe "presies" die werk van die databasis is, moet jy die AWR-statistieke van die "Instance Activity Stats"-afdeling bestudeer (daar is baie statistieke met selfverduidelikende name) en dit met mekaar vergelyk.
En om te verstaan hoe 'n databasis buite Exadata sal voel, is dit die beste om 'n databasiskloon van 'n rugsteun op die teikenargitektuur te maak en die werkverrigting van hierdie kloon onder lading te ontleed. As 'n reël het Exadata-eienaars hierdie geleentheid.
Author: Alexey Struchenko, hoof van die Jet Infosystems-databasisafdeling
Bron: will.com