La cosa più importante da capire sul parallelismo di Oracle è che è complicato. L'ottimizzazione del parallelismo richiede molta conoscenza di Oracle, lettura dei manuali, controllo di molti parametri, test di query di lunga durata e molto scetticismo.
Fai le domande giuste
I problemi paralleli coinvolgono in realtà tre diverse domande:
- Quanti server paralleli sono stati richiesti?
- Quanti server paralleli sono stati allocati?
- Quanti server paralleli sono stati utilizzati in modo significativo?
Utilizza gli strumenti migliori
Vai direttamente allo strumento migliore:il monitoraggio SQL con report attivi. Trova il tuo SQL_ID e genera il report HTML:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual; . Questo è l'unico modo per sapere quanto tempo è stato dedicato a ciascuna fase del piano di esecuzione. E ti dirà quanto parallelismo è stato effettivamente utilizzato e dove. Per esempio:
Un'altra buona opzione è type => 'text' . Non ha molte informazioni ma è più veloce da guardare e più facile da condividere.
SQL Monitoring comprende anche il DOP richiesto e il DOP allocato:
Un select parallelo di 100 righe può funzionare magnificamente, ma poi tutto si interrompe in un unico passaggio a causa di una sequenza non memorizzata nella cache. Puoi fissare un piano di spiegazione, una traccia o un rapporto AWR per ore e non vedere il problema. Il report attivo rende i passaggi lenti quasi banali da trovare. Non perdere tempo a indovinare dove sta il problema.
Tuttavia, sono ancora necessari altri strumenti. Un piano di spiegazione generato con explain plan for ... e select * from table(dbms_xplan.display); fornirà alcune informazioni chiave. In particolare le Notes può includere molti motivi per cui la query non ha richiesto il parallelismo.
Ma PERCHÉ ho ricevuto quel numero di server paralleli?
Le informazioni rilevanti sono distribuite su diversi manuali, che sono molto utili ma a volte imprecisi o fuorvianti. Ci sono molti miti e molti cattivi consigli sul parallelismo. E la tecnologia cambia in modo significativo ad ogni versione.
Quando si mettono insieme tutte le fonti affidabili, l'elenco dei fattori che influenzano il numero di server paralleli è sorprendentemente ampio. L'elenco seguente è ordinato approssimativamente in base a quelli che ritengo siano i fattori più importanti:
- Parallelismo tra operazioni Qualsiasi query che utilizzi l'ordinamento o il raggruppamento allocherà il doppio dei server paralleli rispetto al DOP. Questo è probabilmente responsabile del mito "Oracle alloca quanti più server paralleli possibile!".
- Suggerimento query Preferibilmente un suggerimento a livello di istruzione come
/*+ parallel */, o eventualmente un suggerimento a livello di oggetto come/*+ noparallel(table1) */. Se un passaggio specifico di un piano è in esecuzione in serie, di solito è a causa di suggerimenti a livello di oggetto solo su una parte della query. - SQL ricorsivo Alcune operazioni possono essere eseguite in parallelo ma possono essere serializzate in modo efficace da SQL ricorsivo. Ad esempio, una sequenza non memorizzata nella cache su un inserto di grandi dimensioni. Anche l'SQL ricorsivo generato per analizzare l'istruzione sarà seriale; ad esempio query di campionamento dinamico.
- Modifica sessione
alter session [force|enable] parallel [query|dml|ddl];Nota che il DML parallelo è disabilitato per impostazione predefinita. - Laurea in tabella
- Diploma indice
- L'indice era più conveniente I suggerimenti paralleli dicono solo all'ottimizzatore di considerare una scansione completa della tabella con un determinato DOP. In realtà non forzano il parallelismo. L'ottimizzatore è ancora libero di utilizzare un accesso all'indice seriale se pensa che sia più economico. (Il
FULLsuggerimento può aiutare a risolvere questo problema.) - Gestione del piano Linee di base del piano SQL, contorni, profili, riscrittura avanzata e traduttori SQL possono tutti modificare il grado di parallelismo alle tue spalle. Controlla la sezione Note del piano.
- Edizione Solo le edizioni Enterprise e Personal consentono operazioni parallele. Ad eccezione del pacchetto DBMS_PARALLEL_EXECUTE.
- PARALLEL_ADAPTIVE_MULTI_USER
- SINTONIZZAZIONE_AUTOMATICA_PARALLELA
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- FORZA_PARALLELA_LOCALE
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVER Questo è il limite superiore per l'intero sistema. C'è un compromesso qui. L'esecuzione di troppi server paralleli contemporaneamente è dannosa per il sistema. Ma il downgrade di una query a seriale può essere disastroso per alcune query.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVER
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- Numero di nodi RAC Un altro moltiplicatore per il DOP predefinito.
- CPU_COUNT Se viene utilizzato il DOP predefinito.
- RECOVERY_PARALLELISMO
- FAST_START_PARALLEL_ROLLBACK
- Profilo
SESSIONS_PER_USERlimita anche i server paralleli. - Gestore delle risorse
- Carico del sistema Se parallel_adaptive_multi_user è true. Probabilmente impossibile indovinare quando Oracle inizierà a rallentare.
- PROCESSI
- Restrizioni DML parallele Parallel DML non funzionerà se uno di questi casi:
- COMPATIBILE <9.2 per intra-partizione
- INSERT VALUES, tabelle con trigger
- replica
- integrità autoreferenziale o eliminazione dei vincoli di integrità a cascata o differita
- accesso a una colonna oggetto
- tabella non partizionata con LOB
- parallelismo all'interno della partizione con una LOB
- transazione distribuita
- tabelle a grappolo
- tavoli temporanei
- Le subquery scalari non vengono eseguite in parallelo? Questo è nel manuale e vorrei che fosse vero, ma i miei test indicano che il parallelismo funziona qui in 11g.
- ENQUEUE_RESOURCES Parametro nascosto in 10 g, è più rilevante?
- Tabelle organizzate per indici Non è possibile inserire il percorso diretto negli IOT in parallelo? (È ancora vero?)
- Requisiti delle funzioni con pipeline parallele Deve utilizzare un
CURSOR(?). DA FARE. - Le funzioni devono essere PARALLEL_ENABLE
- Tipo di dichiarazione Le versioni precedenti limitavano il parallelismo su DML a seconda del partizionamento. Alcuni degli attuali manuali lo includono ancora, ma di certo non è più vero.
- Numero di partizioni Solo per join a livello di partizione su versioni precedenti.(?)
- Bug In particolare ho visto molti bug con l'analisi. Oracle assegnerà il giusto numero di server paralleli ma non accadrà nulla poiché tutti aspettano eventi come
cursor: pin s wait on x.
Questo elenco non è certamente completo e non include le funzionalità 12c. E non affronta i problemi del sistema operativo e dell'hardware. E non risponde alla domanda orribilmente difficile, "qual è il miglior grado di parallelismo?" (Risposta breve:di solito di più è meglio, ma a scapito di altri processi.) Si spera che almeno ti dia un'idea di quanto possano essere difficili questi problemi e un buon punto di partenza per iniziare a cercare.
