![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nCon questo breve post vorrei fugare un malinteso riguardante l'analisi AWR dei database che operano su Oracle Exadata. Da quasi 10 anni mi trovo costantemente di fronte alla domanda: qual \u00e8 il contributo del software Exadata alle prestazioni? O, usando termini creativi: quanto \u00e8 \"exadatizzato\" il lavoro di un certo database?<\/p>\n
<\/p>\n
Spesso a questa domanda corretta, a mio avviso, viene data una risposta errata basata sulle statistiche AWR. Queste presentano un metodo di attesa sistemica che interpreta il tempo di risposta come la somma del tempo di lavoro dei processori (DB CPU) e il tempo di attesa di varie classi.<\/p>\n
Con l'arrivo di Exadata, nelle statistiche AWR sono emerse attese sistemiche specifiche legate al funzionamento del software Exadata. Di norma, i nomi di tali attese iniziano con la parola \"cell\" (il server di storage Exadata \u00e8 denominato cos\u00ec), e quelle pi\u00f9 comuni sono le attese con nomi esplicativi come \"cell smart table scan\", \"cell multiblock physical read\" e \"cell single block physical read\".<\/p>\n
Nella maggior parte dei casi, la quota di tali attese Exadata nel tempo di risposta totale \u00e8 bassa, e quindi non compare nemmeno nella sezione Top10 Foreground Events by Total Wait Time (in questo caso, occorre cercarle nella sezione Foreground Wait Events). Abbiamo faticato a trovare un esempio di AWR giornaliero tra i nostri clienti in cui le attese Exadata figurassero nella sezione Top10 e ammontassero a circa il 5%:<\/p>\n
Evento<\/strong><\/p>\n Attese<\/strong><\/p>\n Tempo Totale di Attesa (sec)<\/strong><\/p>\n Attesa Media<\/strong><\/p>\n % Tempo DB<\/strong><\/p>\n Classe di Attesa<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net pi\u00f9 dati da dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Network\n log \/dev\/log local0\n log \/dev\/log local1 notice\n chroot \/var\/lib\/haproxy\n stats timeout 30s\n user haproxy\n group haproxy\n daemon\n\ndefaults\n log global\n mode http\n option httplog\n option dontlognull\n timeout connect 5000\n timeout client 50000\n timeout server 50000\n\nfrontend http_front\n bind *:80\n stats uri \/haproxy?stats\n default_backend http_back\n\nbackend http_back\n balance roundrobin\n server server_name1 private_ip1:80 check\n server server_name2 private_ip2:80 check<\/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 User 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 Altro<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n User 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 User I\/O<\/p>\n SQL*Net messaggio da dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Network\n log \/dev\/log local0\n log \/dev\/log local1 notice\n chroot \/var\/lib\/haproxy\n stats timeout 30s\n user haproxy\n group haproxy\n daemon\n\ndefaults\n log global\n mode http\n option httplog\n option dontlognull\n timeout connect 5000\n timeout client 50000\n timeout server 50000\n\nfrontend http_front\n bind *:80\n stats uri \/haproxy?stats\n default_backend http_back\n\nbackend http_back\n balance roundrobin\n server server_name1 private_ip1:80 check\n server server_name2 private_ip2:80 check<\/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 User 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 User 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 Da tali statistiche AWR si traggono spesso le seguenti conclusioni:<\/p>\n 1. Il contributo della magia Exadata alle prestazioni del database \u00e8 limitato \u2014 non supera il 5%, e un database \"exadata\" non si comporta bene.<\/p>\n 2. Se un database del genere viene spostato da Exadata a un'architettura classica \"server + array\", le prestazioni cambieranno di poco. Anche se quell'array fosse tre volte pi\u00f9 lento rispetto al sistema di storage Exadata (il che \u00e8 difficile per i moderni array All Flash), moltiplicando il 5% per tre otterremmo un aumento della percentuale di attese I\/O fino al 15% \u2014 una situazione che un database potrebbe certamente tollerare!<\/p>\n Entrambe queste conclusioni sono imprecise e, anzi, distorcono la comprensione dell'idea alla base del software Exadata. Exadata non offre solo un input-output rapido, ma funziona in modo fondamentalmente diverso rispetto all'architettura classica \"server + array\". Se il lavoro del database \u00e8 davvero \"exadatizzato\" \u2014 allora la logica SQL viene trasferita al sistema di storage. server<\/a> Lo Storage, grazie a una serie di meccanismi speciali (in primo luogo gli Exadata Storage Indexes, ma non solo), trova autonomamente i dati necessari e li invia ai server DB. Lo fa in modo piuttosto efficiente, quindi la quota di attese Exadata caratteristiche nel tempo di risposta totale \u00e8 bassa. <\/p>\n Come cambier\u00e0 questa quota al di fuori di Exadata? Come influir\u00e0 sulle prestazioni del database nel suo complesso? La cosa migliore per rispondere a queste domande \u00e8 eseguire dei test. Ad esempio, l'attesa \"cell smart table scan\" al di fuori di Exadata pu\u00f2 trasformarsi in un costoso Table Full Scan, tanto che l'input-output occupa tutto il tempo di risposta e le prestazioni peggiorano drammaticamente. Proprio per questo non \u00e8 corretto, nell'analisi AWR, considerare la percentuale totale di attese Exadata come un contributo della sua magia alle prestazioni e tanto meno usare questa percentuale per prevedere le prestazioni al di fuori di Exadata. Per capire quanto sia \"exadatizzato\" il lavoro di un database, \u00e8 necessario esaminare le statistiche AWR della sezione \"Instance Activity Stats\" (l\u00ec ci sono molte statistiche con nomi esplicativi) e confrontarle fra loro.<\/p>\n E per capire come si comporter\u00e0 il database al di fuori di Exadata, la cosa migliore \u00e8 effettuare un clone del database dalla backup sull'architettura target e analizzare le prestazioni di questo clone sotto carico. Questa opportunit\u00e0 \u00e8 di solito disponibile per chi possiede Exadata.<\/p>\n