![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nCon questo breve post vorrei chiarire un malinteso riguardante l'analisi AWR dei database che operano su Oracle Exadata. Da quasi 10 anni mi imbatto costantemente nella domanda: qual \u00e8 il contributo del software Exadata alle prestazioni? O, usando termini appena coniati, quanto \u00e8 \"exadatizzato\" il lavoro di un certo database?<\/p>\n
<\/p>\n
Spesso a questa giusta domanda, a mio avviso, viene data una risposta errata citando le statistiche AWR. Queste presentano un metodo di attesa del sistema, in cui il tempo di risposta \u00e8 considerato come la somma del tempo di lavoro dei processori (DB CPU) e dei tempi di attesa di diverse classi.<\/p>\n
Con l'introduzione di Exadata, nella statistica AWR sono emerse specifiche attese del sistema legate al funzionamento del software Exadata. Di solito i nomi di queste attese iniziano con la parola \u201ccell\u201d (il server di archiviazione Exadata \u00e8 chiamato cella), e le attese pi\u00f9 comuni hanno nomi tutti descrittivi come \u201ccell smart table scan\u201d, \u201ccell multiblock physical read\u201d e \u201ccell single block physical read\u201d.<\/p>\n
Nella maggior parte dei casi, la quota di tali attese Exadata nel tempo di risposta totale \u00e8 bassa, e pertanto non compaiono nemmeno nella sezione Top10 Foreground Events by Total Wait Time (in questo caso devono essere cercate nella sezione Foreground Wait Events). Con grande fatica abbiamo scoperto presso i nostri clienti un esempio di AWR giornaliero in cui le attese Exadata sono entrate nella sezione Top10 e in totale hanno rappresentato 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 more data from dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Network\n global\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 Utente 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 Utente I\/O<\/p>\n lettura percorso diretto<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Utente I\/O<\/p>\n SQL*Net message from dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Network\n global\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 Utente I\/O<\/p>\n lettura percorso diretto temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Utente 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 Dalla statistica AWR si fanno spesso tali conclusioni:<\/p>\n 1. Il contributo della magia di Exadata alle prestazioni del database \u00e8 basso \u2014 non supera il 5%, e il database \"exadata\" si comporta male.<\/p>\n 2. Se questo database viene trasferito da Exadata a un'architettura classica \"server + array\", le prestazioni non cambieranno di molto. Perch\u00e9 anche se questo array risultasse tre volte pi\u00f9 lento della sistema di archiviazione Exadata (cosa che \u00e8 poco probabile per i moderni array All Flash), moltiplicando il 5% per tre otterremmo un aumento della quota di attese di input\/output fino al 15% \u2014 un database del genere lo sopporter\u00e0 sicuramente!<\/p>\n Entrambi questi risultati sono imprecisi, e anzi distorcono la comprensione dell'idea trasmessa da Exadata Software. Exadata non fornisce solo un rapido input\/output, ma funziona in modo completamente diverso rispetto all'architettura classica \"server + array\". Se il lavoro del database \u00e8 veramente \"exadata-like\", allora la logica SQL viene trasferita nel sistema di storage. Storage servers<\/a> grazie a una serie di meccanismi speciali (in primo luogo gli Exadata Storage Indexes, ma non solo), trovano autonomamente i dati richiesti e li inviano ai server DB. Lo fanno in modo abbastanza efficiente, quindi la quota delle attese tipiche di Exadata nel tempo di risposta totale \u00e8 bassa. <\/p>\n Come cambier\u00e0 questa quota al di fuori di Exadata? Come influenzer\u00e0 le prestazioni del database in generale? Le migliori risposte a queste domande derivano dai test. Ad esempio, l'attesa \"cell smart table scan\" al di fuori di Exadata pu\u00f2 trasformarsi in una pesante scansione completa della tabella, causando un input\/output che occupa tutto il tempo di risposta e deteriorando le prestazioni drammaticamente. \u00c8 per questo che \u00e8 errato considerare nel'analisi AWR la percentuale totale delle attese di Exadata come un contributo della sua magia nelle prestazioni, tanto meno usare questa percentuale per prevedere le prestazioni al di fuori di Exadata. Per comprendere quanto sia \"exadata-like\" il lavoro del database, \u00e8 necessario studiare le statistiche AWR della sezione \"Instance Activity Stats\" (l\u00ec ci sono molte statistiche con nomi indicativi) e confrontarle tra loro.<\/p>\n E per capire come si comporter\u00e0 il database al di fuori di Exadata, \u00e8 meglio creare un clone del database a partire dal backup sull'architettura target e analizzare le prestazioni di questo clone sotto carico. Tale possibilit\u00e0 \u00e8 generalmente disponibile per i possessori di Exadata.<\/p>\n