![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nMed det h\u00e4r lilla inl\u00e4gget skulle jag vilja klarg\u00f6ra ett missf\u00f6rst\u00e5nd som r\u00f6r analysen av AWR-databaser som k\u00f6rs p\u00e5 Oracle Exadata. I n\u00e4stan 10 \u00e5r har jag st\u00e4ndigt st\u00f6tt p\u00e5 fr\u00e5gan: vad \u00e4r Exadata Softwares bidrag till prestandan? Eller med nybildade ord: hur mycket \"exadaterar\" arbetet hos en viss databas?<\/p>\n
<\/p>\n
Ofta ges ett felaktigt svar p\u00e5 denna r\u00e4tta fr\u00e5ga, enligt min mening, med h\u00e4nvisning till AWR-statistik. I den presenteras en metod f\u00f6r systemv\u00e4ntan som tolkar svarstiden som summan av processorns arbetstid (DB CPU) och v\u00e4ntetiden f\u00f6r olika klasser.<\/p>\n
Med inf\u00f6randet av Exadata har specifika systemv\u00e4ntor som \u00e4r relaterade till Exadata Software dykt upp i AWR-statistiken. Vanligtvis b\u00f6rjar namnen p\u00e5 s\u00e5dana v\u00e4ntor med ordet \"cell\" (en cell kallas Exadata Storage-server), och de vanligaste v\u00e4ntorna har beskrivande namn som \"cell smart table scan\", \"cell multiblock physical read\" och \"cell single block physical read\".<\/p>\n
I de flesta fall \u00e4r andelen s\u00e5dana Exadata-v\u00e4ntor i den totala svarstiden l\u00e5g, och d\u00e4rf\u00f6r kan de till och med inte hittas i sektionen Top10 Foreground Events by Total Wait Time (i s\u00e5 fall m\u00e5ste de s\u00f6kas i avsnittet Foreground Wait Events). Vi hade stora sv\u00e5righeter att hitta ett exempel p\u00e5 en daglig AWR-rapport hos v\u00e5ra kunder d\u00e4r Exadata-v\u00e4ntor kom in i sektionen Top10 och totalt utgjorde cirka 5 %:<\/p>\n
H\u00e4ndelse<\/strong><\/p>\n V\u00e4ntningar<\/strong><\/p>\n Total v\u00e4ntetid (sek)<\/strong><\/p>\n Genomsnittlig v\u00e4ntan<\/strong><\/p>\n % DB tid<\/strong><\/p>\n V\u00e4ntklass<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net mer data fr\u00e5n dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n N\u00e4tverk<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676.07us<\/p>\n 2.3<\/p>\n Anv\u00e4ndare I\/O<\/p>\n Sync ASM rebalance<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Annat<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Anv\u00e4ndare I\/O<\/p>\n direkt path read<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Anv\u00e4ndare I\/O<\/p>\n SQL*Net meddelande fr\u00e5n dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n N\u00e4tverk<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1.25ms<\/p>\n 0.8<\/p>\n Anv\u00e4ndare I\/O<\/p>\n direkt path read temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Anv\u00e4ndare I\/O<\/p>\n enq: TM \u2014 inneh\u00e5ll<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Application<\/p>\n Fr\u00e5n s\u00e5dan AWR-statistik dras ofta f\u00f6ljande slutsatser:<\/p>\n 1. Bidraget fr\u00e5n Exadata-magi till databasens prestanda \u00e4r inte h\u00f6g \u2014 det \u00f6verstiger inte 5 %, och databasen \"exadatar\" d\u00e5ligt.<\/p>\n 2. Om en s\u00e5dan databas flyttas fr\u00e5n Exadata till en klassisk arkitektur \"server + array\", kommer prestandan inte att f\u00f6r\u00e4ndras mycket. F\u00f6r \u00e4ven om denna array skulle vara tre g\u00e5nger l\u00e5ngsammare \u00e4n lagringssystemet Exadata (vilket knappast \u00e4r m\u00f6jligt f\u00f6r moderna All Flash-array), f\u00e5r vi genom att multiplicera 5% med tre en \u00f6kning av andelen I\/O-v\u00e4ntan till 15% \u2014 en s\u00e5dan databas klarar s\u00e4kert av!<\/p>\n B\u00e5da dessa utsagor \u00e4r oklara, dessutom f\u00f6rvr\u00e4nger de f\u00f6rst\u00e5elsen av id\u00e9n bakom Exadata Software. Exadata erbjuder inte bara snabb in- och utmatning, den fungerar principiellt annorlunda j\u00e4mf\u00f6rt med klassisk arkitektur \"server + lagring\". Om databasen verkligen \"exadateras\" \u2014 s\u00e5 flyttas SQL-logiken till lagringssystemet. Storage servrar<\/a> Tack vare en rad speciella mekanismer (fr\u00e4mst Exadata Storage Indexes, men inte bara) hittar de sj\u00e4lva de n\u00f6dv\u00e4ndiga uppgifterna och skickar dem till DB-servrarna. De g\u00f6r detta ganska effektivt, d\u00e4rf\u00f6r \u00e4r andelen karakteristiska Exadata-v\u00e4ntetider i den totala svarstiden l\u00e5g. <\/p>\n Hur kommer denna andel att f\u00f6r\u00e4ndras utanf\u00f6r Exadata? Hur kommer det att p\u00e5verka databasens prestanda \u00f6verlag? Det b\u00e4sta svaret p\u00e5 dessa fr\u00e5gor f\u00e5r man genom testning. Till exempel kan v\u00e4ntan p\u00e5 \"cell smart table scan\" utanf\u00f6r Exadata bli s\u00e5 tuff att det ist\u00e4llet blir en tung Table Full Scan, vilket g\u00f6r att in- och utmatning tar upp all svarstid och prestandan f\u00f6rs\u00e4mras dramatiskt. Just d\u00e4rf\u00f6r \u00e4r det felaktigt att i analysen av AWR r\u00e4kna den totala andelen v\u00e4ntetider fr\u00e5n Exadata som en del av dess magi f\u00f6r prestanda, och \u00e4n mindre anv\u00e4nda denna procentandel f\u00f6r att prognosticera prestanda utanf\u00f6r Exadata. F\u00f6r att f\u00f6rst\u00e5 hur mycket \"exadaterad\" arbetsbelastningen \u00e4r, m\u00e5ste man studera statistik fr\u00e5n AWR-sektionen \"Instance Activity Stats\" (d\u00e4r finns mycket statistik med talande namn) och j\u00e4mf\u00f6ra dem med varandra.<\/p>\n Och f\u00f6r att f\u00f6rst\u00e5 hur databasen kommer att m\u00e5 utanf\u00f6r Exadata, \u00e4r det b\u00e4st att g\u00f6ra en klon av databasen fr\u00e5n en backup p\u00e5 den m\u00e5larkitektur som ska anv\u00e4ndas och analysera prestandan hos denna klon under belastning. Den m\u00f6jligheten har oftast de som innehar Exadata.<\/p>\n