![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nSelle v\u00e4ikese postitusega soovin hajutada \u00fchte arusaamatust, mis on seotud AWR anal\u00fc\u00fcsiga andmebaasidest, mis t\u00f6\u00f6tavad Oracle Exadata s\u00fcsteemil. Peaaegu 10 aastat olen pidevalt silmitsi seisnud k\u00fcsimusega: milline on Exadata tarkvara panus j\u00f5udlusesse? V\u00f5i, uute s\u00f5nadega v\u00e4ljendades: kui palju \"ekzadatiseerib\" mingi andmebaasi t\u00f6\u00f6?<\/p>\n
<\/p>\n
Sageli antakse sellele \u00f5igetele k\u00fcsimustele, minu arvates, vale vastus, viidates AWR statistikale. Selles on esitatud s\u00fcsteemsete ootuste meetod, mis t\u00f5lgendab reageerimise aega kui protsessorite (DB CPU) t\u00f6\u00f6aega ja erinevate klasside ootuste aega summana.<\/p>\n
Exadata ilmumisega on AWR statistikasse ilmunud Exadata tarkvaraga seotud spetsiifilised s\u00fcsteemsed ootused. Nende ootustega seotud nimed algavad tavaliselt s\u00f5naga \"cell\" (Exadata salvestusseadet nimetatakse rakuks); k\u00f5ige sagedamini esinevad ootused, millel on r\u00e4\u00e4kivad nimed nagu \"cell smart table scan\", \"cell multiblock physical read\" ja \"cell single block physical read\".<\/p>\n
Enamikul juhtudel on selliste Exadata ootuste osakaal kogu reageerimise ajas v\u00e4ike ja seet\u00f5ttu 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\u00e4ite \u00f6\u00f6p\u00e4evasest AWR-ist, kus Exadata ootused p\u00e4\u00e4sesid Top10 sektsiooni ja kokku moodustasid umbes 5%:<\/p>\n
S\u00fcndmus<\/strong><\/p>\n Ootused<\/strong><\/p>\n Kogu ooteaeg (sekundites)<\/strong><\/p>\n Keskmine ooteaeg<\/strong><\/p>\n % DB aeg<\/strong><\/p>\n Oote klass<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net rohkem andmeid dblinkilt<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n V\u00f5rk<\/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 Kasutaja I\/O<\/p>\n Sync ASM tasakaalustus<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Muu<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Kasutaja I\/O<\/p>\n otsene path read<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Kasutaja I\/O<\/p>\n SQL*Net s\u00f5num dblinkilt<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n V\u00f5rk<\/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 Kasutaja I\/O<\/p>\n otsene path read temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Kasutaja I\/O<\/p>\n enq: TM \u2014 contention<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Application<\/p>\n Sellest AWR statistikast tehakse sageli selliseid j\u00e4reldusi:<\/p>\n 1. Exadata maagia panus andmebaasi j\u00f5udluses on madal \u2014 ei \u00fcleta 5%, ja andmebaas \"ekzaditiseb\" halvasti.<\/p>\n 2. Kui selline andmebaas viia Exadatast tagasi klassikalisse arhitektuuri \"server + maht\", siis j\u00f5udlus ei muutu oluliselt. Sest isegi kui see maht osutub Exadata salvestuss\u00fcsteemist kolm korda aeglasemaks (mis ebat\u00f5en\u00e4oline kaasaegsete All Flash mahtude puhul), siis korrutades 5% kolme v\u00f5rra saame I\/O ootuste osa t\u00f5usuks 15% \u2014 sellisega suudab andmebaas kindlasti hakkama saada!<\/p>\n M\u00f5lemad need v\u00e4ljendid on ebat\u00e4psed, lisaks moonutavad nad arusaama Exadata Software'i ideest. Exadata ei paku mitte ainult kiiret sisendi-v\u00e4ljundi, vaid t\u00f6\u00f6tab p\u00f5him\u00f5tteliselt erinevalt klassikalisest arhitektuurist \u201eserver + salvestus\u201d. Kui andmebaasi t\u00f6\u00f6 t\u00f5eliselt \u201eekzadatiitub\u201d, siis SQL-loogika kantakse salvestuss\u00fcsteemi. Storage serverid<\/a> k\u00f5ik t\u00e4nu mitmele erimehhanismile (esmaj\u00e4rjekorras Exadata Storage Indexes, aga mitte ainult) leiavad ise vajalikud andmed ja edastavad need DB serveritele. Nad teevad seda piisavalt efektiivselt, seet\u00f5ttu on Exadata spetsiifiliste ootuste osakaal kogu vastamisajas madal. <\/p>\n Kuidas see osakaal Exadata-st v\u00e4ljaspool muutub? Kuidas see m\u00f5jutab andmebaasi j\u00f5udlust \u00fcldiselt? Parim viis nendele k\u00fcsimustele vastata on testimine. N\u00e4iteks v\u00f5ib ootamine \u201ecell smart table scan\u201d Exadata-st v\u00e4ljaspool muutuda nii raskeks Table Full Scan'iks, et sisendi-v\u00e4ljund v\u00f5tab kogu vastamisaja ja j\u00f5udlus halveneb dramaatiliselt. Just seet\u00f5ttu on vale anal\u00fc\u00fcsides AWR pidada Exadata ootuste kogusummat selle maagia panuseks j\u00f5udluses ja veelgi enam kasutada seda protsenti j\u00f5udluse prognoosimiseks Exadata-st v\u00e4ljaspool. Et m\u00f5ista, kui palju \u201eekzadataitub\u201d andmebaasi t\u00f6\u00f6, tuleb uurida AWR statistikat jaotises \u201cInstance Activity Stats\u201d (seal on palju statistikat k\u00f5lava nimega) ja v\u00f5rrelda neid omavahel.<\/p>\n Ja et m\u00f5ista, kuidas andmebaas v\u00e4ljaspool Exadata tunneb, on k\u00f5ige parem teha varukoopiast kloon sihtarhitektuuril ja anal\u00fc\u00fcsi selle klooni j\u00f5udlust koormuse all. Selline v\u00f5imalus on Exadata omanikel tavaliselt olemas.<\/p>\n