Instrucțiuni SQL în documentația Oracle
- "Despre sintaxa: / * + HINT HINT ... * / în PL / SQL, spațiul dintre" + "și prima literă a indiciului este important, în absența unui spațiu, sugestia poate fi ignorată, adică / * + ALL_ROWS * / utilizarea corectă, și / * + ALL_ROWS * / - greșit
- Sfaturile întotdeauna "vigoare" utilizarea de optimizare a costurilor (în plus față de indiciu REGULAMENT)
- Dacă interogarea folosește aliasuri (alias de tabel), instrucțiunile ar trebui să utilizeze, de asemenea, pseudonime în loc de nume de tabele:
- În clauze nu ar trebui să existe niciun indiciu al denumirii schemei:
- Sugestiile incorecte (sugestii nevalabile) sunt ignorate fără avertismente ... incorectitatea indiciului poate să nu fie evidentă, de exemplu:
- specificând un prompt FIRST_ROWS (pentru a obține primele rânduri) pentru o interogare cu ORDER BY (deoarece datele trebuie sortate înainte ca primul șir de interogare să fie returnat, utilizând first_rows să nu producă rezultatul dorit)
- datele de acces specificate în sugestie ar trebui să fie disponibile, de exemplu: un indiciu INDEX indicând indicele inexistent va fi ignorat fără mesaje de eroare ... "
- obiective generale de optimizare
- ordin de acces
- Metode de conectare
- modalități de a executa [sub] o interogare
- statistici obiect
- Transformarea interogărilor [pentru]
- folosind cursoare
- executarea paralelă
Obiective de optimizare și abordări
Sugestii care definesc obiectivele și abordările comune pentru optimizarea planului de executare a interogărilor, inclusiv regulile și metodele de accesare a datelor. Ele corespund (aproape) cu descrierile valorilor parametrilor OPTIMIZER_MODE
/ * + REGULA * /
Oficial nu este suportat, deoarece Oracle 10, optimizarea bazată pe reguli exacte (Rule Based Optimization) este utilizată fără a ține seama de statisticile obiectelor. Descrierea regulilor aplicate pentru parametrul de inițializare optimizer_mode = regulă
În special, în ciuda utilizării indiciului RULE, Oracle va utiliza optimizarea bazată pe costuri. în cazul în care:
- În afară de RULE, în interogare sunt folosite alte instrucțiuni
- interogarea utilizează partiții sau tabele organizate ca index (IOT) sau vizualizări materializate (mview)
- interogarea folosește seturile SAMPLE, SPREADSHEET, GROUPING
- interogarea folosește interfața ANSI left | full extern
- cererea este executată în paralel
- Utilizați cursorul Flashback (din [scn | timestamp])
- ...
În 11.2 atunci când se utilizează RBO de optimizare de urmărire poate fi configurat și utilizat unele cereri de conversie, cu excepția Transformare Solicitare pe costuri (care este logic :) - a se vedea comentariile cu privire la starea indicelui inutilizabil, promptă și INDEX RBO actualizat în Oracle 11.2.
/ * + ALL_ROWS * /
«ALL_ROWS Sfat definește scopul punerii în aplicare anticipată a întregii cereri, cu un consum minim de resurse (cel mai bine atunci când debitul de a scoate întregul set de rezultate). În simultan cu sau ALL_ROWS FIRST_ROWS oferă sfaturi care definesc metode de acces la date (NO_INDEX_SS, INDEX_COMBINE.) Sau metode care indică obiectele bazei de date de asociere (CONDUCE, USE_NL_WITH_INDEX.), Optimizatorul privilegiază solicită metode de acces și de asociere "
/ * + FIRST_ROWS * /
Din documentația Oracle 8: "Indicația FIRST_ROWS definește o abordare bazată pe costuri pentru a optimiza blocul de solicitare pentru un timp de răspuns mai bun, consumul minim de resurse pentru returnarea primelor rânduri ale interogării. Conform acestui prompt, optimizatorul face următoarele preferințe [în alegerea operațiilor de acces la date și a metodelor de conectare]:
- Dacă este disponibil, optimizatorul utilizează o scanare index în loc de o scanare completă a tabelului,
- Dacă scanarea este disponibil pe un index (scanare index), instrumentul de optimizare selectează bucle imbricate se alăture în loc să se alăture atunci când tabel indexat scanat poate fi utilizat ca un tabel condus operații (tabel interior) sortare-îmbinare pentru bucle imbricate
- Dacă scanarea indexului poate fi utilizată pentru a prelua datele sortate (în ordinea specificată de clauza ORDER BY), optimizatorul alege accesul la index pentru a evita sortarea suplimentară "
Din moment ce Oracle 9i: «FIRST_ROWS Sfat spus că nu argumente sunt concepute pentru a optimiza planul de execuție pentru revenirea anticipată a primului șir de interogare este stocată numai pentru compatibilitate cu versiunile anterioare (compatibilitatea inversă) și a planurilor de execuție de stabilitate (stabilitate planul)»
Valoarea parametrului de inițializare OPTIMIZER_MODE = FIRST_ROWS (care este echivalentă cu aplicarea sugestii FIRST_ROWS pentru toate interogările) este anunțată în documentație până la Oracle 11.2
/ * + FIRST_ROWS (n) * /
Optimizarea bazată pe costuri + utilizarea regulilor (preferințe în alegerea unui plan) pentru a obține un timp de răspuns mai bun pentru obținerea primelor linii n. Planul este calculat ținând cont de valoarea lui n, deoarece numărul țintă al rândurilor de interogare selectate (cardinalitatea interogării).
Nu este o frază destul de clară în documentație. "Optimizatorul ignoră acest indiciu în instrucțiunile SQL DELETE și UPDATE și în interogările SELECT care includ operațiuni de blocare, cum ar fi sortarea și gruparea. Astfel de instrucțiuni SQL nu pot fi optimizate pentru cel mai bun timp de răspuns, deoarece Oracle trebuie să proceseze toate șirurile de interogare înainte de a reveni la primul rând al rezultatului. Dacă specificați această solicitare, cererile tipului specificat sunt optimizate pentru cel mai bun timp pentru a obține toate șirurile de interogare cu consumul minim de resurse (cea mai bună performanță, ca în cazul promptului ALL_ROWS). "
Oracle utilizează întotdeauna modul ALL_ROWS intern pentru declarația DML - blogul Dion Cho are un exemplu bun pentru versiunea 10.2
În Oracle 11.2, nimic nu sa schimbat - indiferent de numărul de rânduri actualizate (rânduri), instalate funcția sau punerea în aplicare a planurilor ROWNUM (cu excepția suplimentare STOPKEY chirurgie COUNT), fără nici un cost, nu este timp de așteptat (Timpul) nu se schimbă:
- atunci când încearcă să actualizeze un singur rând Oracle selectează același plan cu o HASH operațiune costisitoare ÎNREGISTREAZĂ SEMI (utilizate în construcții interogare EXISTS) - mai potrivite pentru toate rândurile din tabel este actualizat (modul ALL_ROWS)
Un test simplu pentru a arăta cât de diferite sunt modurile ALL_ROWS. FIRST_ROWS și FIRST_ROWS (n) afectează comportamentul optimizatorul: de fapt, planurile de execuție și metodele de accesare a datelor + Cost + Rânduri :) Exemple de sortare sau grupare condiții lipsite de sens folosind object_id> 1 - care satisfac toate rândurile din tabelul T1 - cu privire la crearea de condiții de masă min (obiect_id) = 2) *:
*) statisticile pentru tabelul T1 sunt actualizate și optimizatorul "cunoaște" bine valoarea minimă și maximă a T1.Object_id:
sau așa, mai ușor:
Sugestii privind parcursul de acces
Sfaturi pentru specificarea modalităților specifice de accesare a datelor, ordinea și metodele utilizate pentru combinarea seturilor de rezultate *
Tom Kite numește aceste sugestii proaste:
„Indicii Bad arată cum să procedeze de optimizare [când ia determinat] care indicele utilizat, în ce ordine de a procesa un tabel, prin care operațiune (alăture tehnica) pentru a produce compusul [sursa de date]“
*) Înainte de aplicare, este necesar să se ia în considerare probabilitatea schimbării statisticilor sistemului și a obiectelor (tabelelor și indexurilor) utilizate în interogare în timp și, ca o consecință, a posibilei nonoptimalități a operațiilor indicate pentru seturile de date viitoare. Planul de execuție optimizat cu acest tip de indiciu în mediul de dezvoltare poate să nu fie optim pentru sistemul de producție din cauza seturilor diferite de date și caracteristici ale sistemului (hardware)
/ * + LEADING ([@query_block] [tabele], [tabele]] * /
"Instrucțiunea LEADING instruiește optimizatorul să folosească ordinea de acces listată la construirea unui plan de executare a interogării ... mai flexibil decât ORDERAT ... Total ignorat atunci când se utilizează două sau mai multe instrucțiuni LEADING conflictuale. Pentru optimizator, indicatorul ORDERED are prioritate față de LEADING »
În versiunea 11.2, aceasta poate fi ignorată de către optimizator atunci când se efectuează Transformarea interogărilor bazate pe costuri, de exemplu Extinderea tabelului
/ * + ORDERAT * /
"Instrucțiunea ORDERED îi spune Oracle [să execute interogarea] pentru a se alătura tabelelor în aceeași ordine în care tabelele sunt listate în clauza FROM. Oracle recomandă în loc de ORDERED să utilizeze promptul LEADING, care are mai multă flexibilitate ... ", adică oferind optimizatorului mai multe opțiuni în alegerea unui plan de execuție
/ * + USE_HASH ([@query_block] [tabele] [tabele] ...) * /
/ * + NO_USE_HASH ([@query_block] [tabele] [tabele] ...) * /
... spune optimizatorului să utilizeze / nu utilizează operația de conectare hash pentru a conecta fiecare tabel specificat la alte surse de date. Operații CBO: Hash Join
/ * + USE_NL ([@query_block] [interior_table]) * /
/ * + NO_USE_NL ([@query_block] [interior_table]) * /
/ * + USE_NL_WITH_INDEX ([@query_block] interior_table [indexspec]) * /
Igor, vă mulțumesc foarte mult pentru material, ați făcut o treabă bună!
Există o întrebare. Completați articolul dacă știți cum să acționați în astfel de situații.
Tu scrii:
"DRIVING_SITE implică controlul întregului cursor (mai degrabă decât subunitățile individuale) ... [totuși, puteți muta executarea părții cursor / subquery într-o vizualizare la distanță]"
Acesta este un fapt. În nici un fel, nu pot să trimit în întregime un subquery către un server de la distanță. NO_MERGE nu ajută, DISTINCT și GROUP BY nu se află în subansamble. Ca rezultat, fiecare etapă a subdotării se extinde în întregime de la telecomandă la cea locală și numai pe serverul local există o tăiere a predicatelor de acces.
Bună ziua, Dmitry
ar fi bine, bineînțeles, să vedeți în întregime cererea / testul)
Trimiteți-le prietenilor: