![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nMed dette lille indl\u00e6g vil jeg gerne aflive en misforst\u00e5else omkring analysen af AWR-databaser, der k\u00f8rer p\u00e5 Oracle Exadata. I n\u00e6sten 10 \u00e5r har jeg konstant st\u00f8dt p\u00e5 sp\u00f8rgsm\u00e5let: Hvad er Exadata Softwares bidrag til ydeevnen? Eller med nydannede ord: Hvor meget vil arbejdet med en given database \"exadata-se\"?<\/p>\n
<\/p>\n
Ofte gives der et forkert svar p\u00e5 dette korrekte sp\u00f8rgsm\u00e5l, efter min mening, med henvisning til AWR-statistik. Den pr\u00e6senterer en metode til systemventetid, der fortolker respons tiden som summen af tid brugt af processorerne (DB CPU) og ventetider fra forskellige klasser.<\/p>\n
Med fremkomsten af Exadata er der i AWR-statistikken opst\u00e5et specifikke systemventetider relateret til Exadata Software. Normalt begynder navnene p\u00e5 disse ventetider med ordet \"cell\" (en celle kaldes Exadata Storage server), hvor de mest almindeligt forekommende ventetider har talende navne som \"cell smart table scan\", \"cell multiblock physical read\" og \"cell single block physical read\".<\/p>\n
I de fleste tilf\u00e6lde er andelen af s\u00e5danne Exadata-ventetider i den samlede responstid lille, og derfor kommer de endda ikke ind i sektionen Top10 Foreground Events by Total Wait Time (i dette tilf\u00e6lde skal de findes i afsnittet Foreground Wait Events). Vi har med stort besv\u00e6r opdaget et eksempel p\u00e5 en daglig AWR hos vores kunder, hvor Exadata-ventetider kom ind i sektionen Top10 og i alt udgjorde omkring 5%:<\/p>\n
H\u00e6ndelse<\/strong><\/p>\n Ventetider<\/strong><\/p>\n Total Ventetid (sek)<\/strong><\/p>\n Gns. Ventetid<\/strong><\/p>\n % DB tid<\/strong><\/p>\n Venteklasse<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net mere data fra dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Netv\u00e6rk<\/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 Bruger 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 Andet<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Bruger I\/O<\/p>\n direct path read<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Bruger I\/O<\/p>\n SQL*Net meddelelse fra dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Netv\u00e6rk<\/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 Bruger I\/O<\/p>\n direct path read temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Bruger 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 Applikation<\/p>\n Fra s\u00e5danne AWR-statistikker drages ofte f\u00f8lgende konklusioner:<\/p>\n 1. Bidraget fra Exadata-magi til databaseydelsen er begr\u00e6nset \u2014 det overstiger ikke 5 %, og databasen har sv\u00e6rt ved at \"exadata\".<\/p>\n 2. Hvis en s\u00e5dan database overf\u00f8res fra Exadata til en klassisk arkitektur \"server + array\", vil ydeevnen ikke \u00e6ndre sig meget. Fordi selv hvis dette array viser sig at v\u00e6re tre gange langsommere end Exadata lagringssystemet (hvilket n\u00e6ppe er muligt for moderne All Flash arrays), s\u00e5 ved at gange 5 % med tre f\u00e5r vi en stigning i I\/O ventetider til 15 % \u2014 s\u00e5dan en database vil uden tvivl klare det!<\/p>\n Begge disse output er un\u00f8jagtige, ja endda forvr\u00e6nger de forst\u00e5elsen af ideen bag Exadata Software. Exadata leverer ikke kun hurtig input-output; den fungerer fundamentalt anderledes end en klassisk arkitektur med \"server + lagring\". Hvis databasen virkelig \"exadateres\", s\u00e5 overf\u00f8res SQL-logikken til lagringssystemet. servere<\/a> takket v\u00e6re en r\u00e6kke specielle mekanismer (f\u00f8rst og fremmest Exadata Storage Indexes, men ikke kun dem) finder de selv de n\u00f8dvendige data og sender dem til DB-serverne. De g\u00f8r dette ret effektivt, s\u00e5 andelen af karakteristiske Exadata-ventetider i den samlede svartid er lille. <\/p>\n Hvordan vil denne andel \u00e6ndre sig uden for Exadata? Hvordan vil det p\u00e5virke databaseydelsen generelt? Testning vil give de bedste svar p\u00e5 disse sp\u00f8rgsm\u00e5l. For eksempel kan ventetiden \"cell smart table scan\" uden for Exadata blive til en s\u00e5 tung Table Full Scan, at input-output optager al svartiden, hvilket dramatisk forringer ydeevnen. Derfor er det forkert at betragte den samlede procentdel af Exadata-ventetider som et bidrag til dens magi i ydelsen, is\u00e6r ikke at bruge denne procent til at forudsige ydeevnen uden for Exadata. For at forst\u00e5, hvor meget databasen \"exadateres\", skal statistikkerne fra AWR-sektionen \"Instance Activity Stats\" studeres (der er mange statistikker med sigende navne) og sammenlignes med hinanden.<\/p>\n Og for at forst\u00e5, hvordan databasen vil have det uden for Exadata, er det bedst at lave en klon af databasen fra en backup p\u00e5 den m\u00e5larkitektur og analysere ydeevnen af denne klon under belastning. Ejere af Exadata har som regel denne mulighed.<\/p>\n