Limitare il grado di parallelismo (DOP) disponibile per qualsiasi query

Su Oracle Exadata (11gR2), abbiamo un database relativamente robusto.

• cpu_count è 24
• parallel_server_instances è 2
• parallel_threads_per_cpu è 2

Abbiamo osservato, attraverso l'osservazione in Oracle Enterprise Manager (OEM), che le prestazioni sono state terribili a causa delle query eseguite in serie. Per risolvere questo problema, tutte le tabelle, le viste materializzate e gli indici sono stati modificati per sfruttare il parallelismo. per esempio:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

Il sistema è stato modificato per attivare la parallelizzazione:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Ciò ha portato a prestazioni migliori, ma occasionalmente abbiamo osservato in OEM che una singola query avrebbe legato un DOP di 96 (tutte le risorse disponibili). Ciò ha comportato il downgrade delle query successive a un DOP di 1 (nessuna parallelizzazione). Il risultato è una prestazione scadente fino al completamento della query di hogging.

Per risolvere questo problema, abbiamo cercato di limitare il DOP disponibile a qualsiasi query con:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Questo non ha avuto effetto. Osserviamo frequentemente query che useranno più del limite (generalmente 48 o 96, ma nessun modello reale).

Come possiamo impedire a una singola query di registrare tutte le risorse disponibili?

Set di server paralleli: PARALLEL_DEGREE_LIMIT limita il grado di parallelismo, ma se la query sta ordinando o raggruppando il numero di processi paralleli può essere il doppio (due set di server per abilitare il parallelismo tra processi). Questo spiega perché vedrai 48 processi paralleli anche con un limite di 24. Questo succede anche se usi il gestore delle risorse per limitare il DOP.

Suggerimenti paralleli: PARALLEL_DEGREE_LIMIT si applica solo alle istruzioni che utilizzano il grado di parallelismo automatico. Qualsiasi istruzione che utilizza un grado hardcoded, o anche qualsiasi tipo di suggerimento parallelo a livello di oggetto, ignorerà il limite. Se hai questi suggerimenti, questo potrebbe spiegare perché ne vedi 96 alcune volte.

Calibra IO: forse il DOP automatico non viene utilizzato e quindi il limite non viene rispettato perché l'IO non è stato calibrato . Questa query ti dirà se l'IO è stato calibrato:

select * from V$IO_CALIBRATION_STATUS;

Ho già visto questa causa di problemi, ma il mio sistema attuale non è calibrato e il DOP automatico sembra funzionare bene. Puoi capire se questo è davvero un problema guardando la sezione Note del piano esplicativo. Se vedi qualcosa del genere - automatic DOP: Computed Degree of Parallelism is 2, stai bene, ma non vuoi vederlo automatic DOP: skipped because of IO calibrate statistics are missing.

Aumenta PARALLEL_MAX_SERVERS: invece di preoccuparti di rimanere senza server paralleli, ti consiglio di aumentare significativamente PARALLEL_MAX_SERVERS. Dovresti almeno provare a tornare al valore predefinito , PARALLEL_THREADS_PER_CPU x CPU_COUNT x concurrent_parallel_users x 5, tra 240 e 960 a seconda delle impostazioni di memoria.

Quei numeri alti sembrano ridicoli per molti DBA, ma in realtà hanno molto senso per i seguenti motivi:

• I server paralleli Oracle sono più leggeri di quanto si pensi. (E quasi nessuno lo prova mai, trovano solo una situazione in cui un grande DOP provoca un problema e ipotizzano che un DOP elevato sia sempre negativo.)
• È comune eseguire una query ad hoc in uno strumento GUI che recupera solo le prime 50 righe, ma utilizza comunque dozzine di server paralleli. Queste query NON consumano risorse significative, a meno che PARALLEL_MAX_SERVERS non sia troppo basso. Quindi le persone vengono urlate per l'esecuzione di domande perfettamente ragionevoli, che possono portare a brutte situazioni.
• Un DOP molto grande per una singola query non è sempre negativo. Tutti presumono che se si continua ad aumentare il DOP, il sovraccarico diventerà troppo alto e le prestazioni diminuiranno in modo significativo. Ma su molti sistemi ho scoperto che anche un DOP ridicolmente alto porterà a prestazioni migliori, anche se ci sono rendimenti decisamente decrescenti e può essere molto ingiusto rispetto ad altre sessioni. Ma non indovinare, provalo; accetta una query ed eseguilo con tutti i tipi di DOP, fino a 1000. Potresti essere sorpreso.
• Sì, troppo parallelismo può essere negativo. Ma cosa c'è di peggio per il sistema, avendo un numero leggermente superiore rispetto al numero ottimale di sessioni o forzando una query su seriale e sostanzialmente uccidendo un lavoro importante? È necessario monitorare il sistema prima di introdurre limiti arbitrari.