Dintre toti parametrii pentru noi sunt cele mai importante ...

Dintre toti parametrii pentru noi sunt cele mai importante ...

Parametrii funcționării DBMS specificate în fișierul INIT, așa cum este cunoscut, în Oracle abundă. Numărul lor variază de la versiune la versiune. Pe versiunea 8.1.5 pentru NT, de exemplu, există 195 dintre ele:







SQL> selectați numărul (*) din parametrul v $;
COUNT (*)
---------
195
Acestea sunt cele care (nu întotdeauna, din păcate, clar) sunt documentate. În plus, puteți adăuga încă 248 de documente nedocumentate:

SQL> selectați numărul (*) din x $ ksppi unde substr (ksppinm, 1,1) = '_';
COUNT (*)
---------
248
Pe o astfel de practică, o abundență de ajustări a funcționării sistemului poate acționa deprimant și, de fapt, trebuie adăugat că nu toți acești parametri sunt independenți și că mulți acționează contradictoriu în raport cu ceilalți.

Din fericire, cunoașterea tuturor celor 195 de parametri (despre conversația nedocumentată - o conversație specială), deși onorează administratorul (dacă se găsește doar așa), dar nu neapărat pentru utilizările tipice ale sistemului. Majoritatea parametrilor sunt folositori numai în cazuri speciale, nu foarte frecvente, care necesită cunoașterea subtilităților reale ale activității Oracle.

În "viața" obișnuită, în plus, nu toți parametrii sunt echivalenți. Puteți să conduceți cumva și să nu observați impactul și un proces lung de înțelegere a regulilor de expunere a altora poate duce la un câștig de performanță, de exemplu, de numai 1%.

În același timp, valorile expuse în mod implicit, Oracle (și care, de altfel, pot fi diferite pe diferite platforme) nu este neapărat bun, chiar și în delicii obișnuite, fără pretenții la cazurile de exploatare. Unele dintre ele trebuie încă să fie corectate.

Mai jos sunt cateva INIT-parametrii din rândul care influențează stabilirea structurilor din memorie instanță Oracle, care ar trebui să acorde o atenție în primul rând, pentru că efectul adecvat lor pentru facturarea mediu poate duce la o productivitate crescută, depășind semnificativ menționat 1%.

Aceștia sunt parametrii:

Specifică numărul maxim de blocuri cu date în SGA. Dacă trebuie să citiți mai multe tampoane de pe disc decât cele specificate în DB_BLOCK_BUFFERS, blocurile din SGA sunt scoase în spațiile de tabel pe baza principiului First-Out-First-Out (LRU). Această comandă, totuși, poate fi eliminată în mod individual pentru mese mici (capabile să se încadreze în întregime în SGA în sine și să lase loc pentru alții).

Dimensiunea părții variabile a grupului comun de date în octeți. Este percepută de Oracle ca o recomandare și este aproape întotdeauna corectată, pe baza propriilor limitări (aceasta poate fi verificată prin reinstalarea SHARED_POOL_SIZE și examinarea rezultatului). Partea variabilă a bazinului comun este utilizată ca spațiu pentru a satisface nevoile dinamice ale RAM ale sistemului. Dacă dimensiunea bazei comune este mai mult decât necesară, atunci datorită creșterii listelor de memorie liberă și cu dinamică mare, cheltuielile de gestiune rezultate pot duce la o scădere a performanței sistemului. În plus, o dimensiune prea mare a SGA poate provoca un proces de schimb de pagini de memorie RAM cu un disc care încetinește activitatea generală.







Zona în piscină comună, rezervat pentru memorie dinamică care rezultă suprafețe mari continue ale cererilor în timpul procesării SGA SQL. Valoarea implicită este setată la 5% din SHARED_POOL_SIZE (în octeți), dar, în funcție de condițiile de funcționare, acest loc poate fie să dispară sau să fie în scurt de aprovizionare. „Mutarea“ parametru SHARED_POOL_RESERVED_SIZE într-o parte mai mică sau mai mare (mai mult de 50% Oracle nu permit expun), nu modificați dimensiunea totală a piscină comună, dar poate îmbunătăți sau afecta eficiența utilizării acestei zone.

Dacă executați NT și nu utilizați un server "partajat", un server paralel sau un monitor de tranzacții, această opțiune va fi setată la 0 în mod implicit.

Specifică cantitatea de memorie alocată pentru fiecare proces de sortare (UGA, poate fi localizată în SGA sau PGA, utilizată, de exemplu, atunci când se procesează DISTINCT sau ORDER BY). Dacă nu este suficientă memorie, se va folosi spațiul pe disc - o modalitate bună de a "instala" sistemul. Creșterea parametrului va reduce numărul de tipuri de discuri; în același timp, tipurile volumetrice ale discului nu pot fi evitate. La sfârșitul sortimentului, memoria este complet returnată la "heap" -ul UGA, adică neplăcut din punct de vedere al consumului de memorie, se realizează simultan prin mai multe procese de sortare.

Specifică dimensiunea maximă a memoriei solicitate dinamic de UGA pentru faza finală a rutinei de sortare efectuată cu utilizarea spațiului de stocare pe disc. După terminarea procedurii de sortare, această memorie este returnată, însă în etapa finală de sortare ea poate fi consumată pentru o perioadă de timp de către proces în plus față de memoria "principală" controlată de parametrul SORT_AREA_SIZE. (În acest moment, totalul RAM consumat de procesul de sortare poate ajunge la SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE)

Scopul setării acestui parametru este plasarea unui buffer secundar special în tamponul blocului de date pentru care mecanismul de înlocuire a blocului LRU normal nu funcționează. Dacă există unul sau mai multe obiecte (tabele) foarte active și volumul total este relativ mic, atunci fixarea lor în memorie poate crește viteza răspunsului sistemului.

Scopul acestui parametru este emitent instituție alt sub-tampon specifice, încalcă din nou ordinea standard a blocurilor de substituție, dar în sens invers. În cazul în care un obiect mare este rar utilizat (o masă foarte mare), acesta poate fi atribuit recicla sub-tampon, și apoi Oracle „da drumul“ unităților sale imediat după utilizare (care poate obține performanțe precum și următoarea referire la blocul nu va curând).

Vă permite să specificați numărul de blocuri simultan citibile atunci când executați citirea DBMS din disc. Creșterea DB_FILE_MULTIBLOCK_READ_COUNT oferă un efect vizibil atunci când scanați tabele mari.

Vladimir Przhilkovsky, profesor al UCS Interface Ltd.







Articole similare

Trimiteți-le prietenilor: