Una dintre cele mai simple moduri de a accelera interogările este de a le analiza.
Acest lucru se face simplu prin:
* Indiciu
* Prin setarea sesiunii:
- Numărul N de fire
În teorie, acest lucru este suficient pentru a accelera interogarea uneori.
Dar există o serie de situații în care paralelismul este opusul.
În primul rând, să ne uităm la terminologia - să ne uităm la planul paralel cu două tabele:
- Cerere 1
Tabelul T2 are o caracteristică: fk_id_skew este umplut neuniform și înclinat către 1 - este mult mai comun decât altele.
- Cerere 2
Deci, am făcut o interogare simplă:
- Cerere 3
* regexp_replace în această interogare este necesar ca datele să nu fie selectate instantaneu, iar costurile CPU să fie vizibile în statistici.
* Sugestiile sunt inserate astfel încât interogarea din plan să arate exact așa cum este scris aici.
Cereți durata de execuție = 49 secunde.
Adăugați paranteza indiciu (8) înlocuind no_parallel.
Durata de funcționare = 8s. care este de 6 ori mai rapid.
Pentru înțelegerea planului de interogare:
- Planul 1
Fazele fundamentale:
* ITERATOR PX BLOCK - citirea tabelei în părți în mai multe fire
* PX TRIMITE - 1 flux trimite date la altul. Este important de știut că numai un singur producător (PX TRIMITE) poate fi activ la un moment dat, care impune restricții asupra planului de execuție în paralel mai detaliat: A doua parte a distribuției de date în paralel interogare
** RANGE - datele vor fi împărțite în intervale (deseori sortate)
** HASH - o gamă de date bazate pe hash-ul lor (hash join, group by)
** RANDOM - trimiterea aleatorie
** BROADCAST - (. De multe ori pe o masă mică, împreună cu ROUND ulterioară tabel dreapta ROBIN poate fi o problemă de performanță în cazul în care masa de stânga este mult mai mare decât cea indicată în statistici, deoarece datele sunt duplicate în toate fluxurile) trimiterea din tabel pentru toate fluxurile
** ROBIN ROUND - datele sunt trimise fluxurilor într-un cerc
Despre modalitățile de distribuire a datelor privind fluxurile trebuie discutate separat:
Merită menționat faptul că datele sunt rupte de valorile din coloanele rândului, și nu numai de rânduri.
Acest lucru este necesar pentru ca același interval de date de date din diferite tabele să se încadreze într-un singur fir pentru a se alătura.
Dacă Oracle nu a făcut acest lucru, atunci datele complet diferite ar putea intra în firul 1 și nu s-ar putea înscrie.
De aici merită să fiți atenți acest lucru poate fi motivul pentru încetinirea executării unei interogări paralele în cazul unei denaturări puternice a datelor (Despre motivele concatenării interogărilor paralele)
** P-> P - datele dintr-un grup paralel sunt transferate unui alt grup paralel
** P-> S - paralel cu execuția secvențială (blocajul sau sfârșitul interogării este al doilea dintre principalele motive pentru încetinirea interogării paralele)
** PCWP - paralel cu părintele: scana masa și imediat se unește cu alta
** PCWC - dimpotrivă: transferăm filtrul din fluxul extern și îl aplicăm în timpul scanării
* PX RECEIVE - primirea datelor de la un flux paralel la altul
* PX TRIMITE QC - trimiteți date coordonatorului
* COORDONATOR PX - receptor al tuturor cererilor paralele
* TQ - Numărul fluxului
1. Prezența în planul de evenimente "P-> S - paralel cu execuția secvențială", cu excepția cazului în care "PX COORDINATOR"
Acest lucru ne spune că Oracle a trebuit să adune toate firele dintr-o singură secvență (secvență), care a dat gâtul sticlei să aștepte pentru fluxul foarte lung toate celelalte.
Voi da un exemplu cu rownum. Adăugați selecția numărului de linie din fiecare tabel:
Planul sa schimbat,
* Pentru a calcula COUNT ROWNUM tabel proces paralel citit de pe disc „PX BLOCK reluatorul“ linia de sus „P-> S“, care negates toate perimeschustvo lectură distribuite.
* JOIN nu este executat acum într-un fir separat (: TQ10002)
deoarece ambele fluxuri au fost deja convertite într-un set de date seriale și nu pot fi utilizate simultan.
Ca urmare, timpul de executie de interogare a fost chiar mai mare (51) decât versiunea de bază non-paralele (49), din cauza costurilor suplimentare de sprijin pentru concurență, ceea ce nu este folosit
2. PX SEND skew - Data oblice
atunci când se formează diapozioane de date într-unul dintre fluxuri.
Demonstrați acest lucru pur și simplu utilizând coloana de înclinare creată anterior t_2.fk_id_skew.
Dacă executați interogarea, dar utilizați condiția pentru tabelele de îmbinare: t_2.fk_id_skew = t_1.id
Că planul general al interogării paralele nu se va schimba (vezi planul 1), dar aici timpul de execuție va crește la 38 de secunde.
Motivul constă în faptul că coloana t_2.fk_id_skew conține 1.500.000 valori = 1 și 3.500.000 altele. Iar atunci când se execută "PX SEND HASH", majoritatea rândurilor de tabel cad într-un fir pentru procesare, în loc să fie distribuite uniform.
Figura 1 - Cele mai multe ori o anchetă a fost efectuată într-un singur fir, alte fire de așteptare pentru el.
Fig. 2. - Același lucru este confirmat în tab-ul PARALLEL: 37c din timpul total, 1 fir lucrat.
Oracle are dreptate, pentru că Nu puteți să vă asociați date din diferite intervale.
Pentru statistici de execuție comparație cu aspect de solicitare extrem de parallelized (Model 1), cu condiția fără urzeli t_2.fk_id_uniform = t_1.id
Totul a fost făcut în 8 fire și fiecare fir a prelucrat în mod egal doar partea sa egală.
3. Filtre înflorire
Fără a intra în mecanica de a crea vectori de biți de filtrare în bloom, voi descrie avantajul utilizării lor.
Exemplu de interogare:
1. Filtru de masă T1 "filtru (". "" T1 MOD "= 42)" creează un filtru floare - PX-TE FILTER CREA
2. Filtrul de la punctul 1 este aplicat la utilizarea tabelului T2-PX FILTER JOIN
Aceasta limitează dimensiunea tabelului drept.
3. Masa filtrată T2 este conectată la HASH JOIN BUFFERED
Descriere detaliată Filter Bloom: Filter Bloom
bloom filter sunt bune la:
* Solicitări paralele - numărul de date transmise între firele scade datorită prefiltrarea tabelului drept
* Sisteme RAC - reduce numărul de date în rețea între noduri
* Tabele InMemory - implementarea prefiltrarea tabelei inmemory și implementarea în memorie nu se alăture într-o tabelă dreaptă filtrată
4. Partiția înțeleaptă
În general, este similar cu punctul anterior, dar filtrul este suprapus pe partițiile din tabelul din dreapta, reducând, de asemenea, scanările.
Dedicat în termeni de fraze:
* PART CREATE FILTRU CREATE (: BF0000) - creați un filtru în tabelul stâng
* Pstart | Pstop =: BF0000 |: BF0000 - aplicație filtru în operația de citire a tabelei din dreapta PCWC
Trimiteți-le prietenilor: