Az összes paraméter közül számunkra a legfontosabb ...
Az összes paraméter közül számunkra a legfontosabb ...
Az INIT-fájlban megadott, a DBMS működésének paraméterei, mint ismert, az Oracle-ben bővelkednek. Számuk változik verzióról verzióra. A 8.1.5-ös verzióra NT-re például 195 közülük van:
SQL> select count (*) a v $ paraméterről;
COUNT (*)
---------
195
Ezek azok, amelyek (nem mindig, sajnos, egyértelműen) dokumentáltak. Plusz hozzáadhat még 248 dokumentumot is:
SQL> select count (*) az x $ ksppi-ból, ahol substr (ksppinm, 1,1) = '_';
COUNT (*)
---------
248
A felkészületlen, ilyen mértékű kiigazítások a rendszer mûködésére nyomasztóan cselekedhetnek, s valójában hozzá kell tenni, hogy nem mindegyik paraméter független, és sokan egymásnak ellentmondóan járnak el.
Szerencsére mind a 195 paraméter ismerete (a nem dokumentált - egy speciális beszélgetésről), bár tiszteletben tartja az adminisztrátort (ha csak ilyen megtalálható), de nem feltétlenül a tipikus rendszerként. A legtöbb paraméter hasznos csak olyan speciális, nem túl gyakori esetekben, amelyek az Oracle munkájának valódi finomságait ismerik.
A "szokásos" "élet" mellett nem minden paraméter egyenértékű. Valamilyen módon szabályozhatod, és nem is észlelheted a hatásokat, és a hosszú mulasztási folyamat a mások felfedésére szolgáló szabályok megszerzéséhez vezethet úgy, hogy csak 1% -os teljesítménynövekedést eredményez.
Ugyanakkor az Oracle által alapértelmezés szerint beállított értékek (és különben különböző platformokon eltérőek lehetnek) nem feltétlenül jók, még a szokásos, szerény módokon is, hogy felfedezzék a kizsákmányolás eseteit. Néhányat még ki kell javítani.
Az alábbiakban felsorolunk néhány INIT-paraméterek közül befolyásoló beállítás szerkezeti Oracle példány memória, amely kell figyelni az első helyen, mert a hatásuk megfelelő a környezet számlázási növelheti a termelékenységet, ami jelentősen meghaladta a már említett 1%.
Ezek a paraméterek:
Meghatározza az SGA-n lévő adatok blokkjainak maximális számát. Ha a lemez van szüksége tovább pufferek, mint amennyit a DB_BLOCK_BUFFERS, háztömbnyire a SGA kijut táblaterületre elve „elsőnek jött - elsőnek ki” (FVT). Ezt a rendelést azonban külön-külön eldobhatjuk a kis táblázatokhoz (amelyek teljes mértékben illeszkednek az SGA-be, és helyet hagynak másoknak).
A megosztott adatkészlet változó részének mérete bájtban. Oracle'om érzékelhető, mint egy ajánlást, és szinte mindig igazítani a saját korlátait (ellenőrizni tudja ezt, ha újratelepíti shared_pool_size, és nézze meg az eredményt). A megosztott pool változó részét a rendszer dinamikusan felmerülő RAM igényeinek kielégítésére használják. Ha a megosztott pool mérete a szükségesnél nagyobb, akkor a szabad memóriajegyek növekedése és nagy dinamika miatt a kezelt felső vezetés a rendszer teljesítményének csökkenéséhez vezethet. Ráadásul egy túlságosan nagy méretű SGA-méret a RAM-memória memória cseréjének folyamatát eredményezheti egy lemezzel, amely lelassítja az általános munkát.
A megosztott medencében lévő terület a dinamikusan előforduló nagy folyamatos memóriaegységek számára fenntartva az SGA-ban az SQL feldolgozásakor. Alapértelmezés szerint a SHARED_POOL_SIZE 5% -ában (bájtban kifejezve) van beállítva, de az üzemeltetési feltételektől függően ez a hely elveszhet, vagy hiányos lehet. „Mozgó” SHARED_POOL_RESERVED_SIZE paraméter kisebb vagy nagyobb oldalon (több mint 50% Oracle tárnak nem teszi lehetővé), akkor nem változik a teljes mérete a közös medence, de javítani vagy rontani felhasználásának hatékonysága ezen a területen.
Ha NT-t futtat, és nem használ egy "megosztott" szervert, párhuzamos szervert vagy tranzakció-figyelőt, akkor ezt az opciót alapértelmezés szerint 0-ra állítja.
Meghatározza az egyes felhasználói folyamatokhoz rendelt memória mennyiségét a rendezéshez (UGA, SGA vagy PGA esetén is használható, például a DISTINCT vagy ORDER BY feldolgozásakor). Ha nincs elég memória, a lemezterületet használják - ez a jó módszer a "telepítésre". A paraméter növelése csökkenti a "lemez" sorszámot; ugyanakkor a lemez volumetrikus fajtái még mindig nem kerülhetők el. A válogatás végén a memória teljes egészében visszatért az UGA "kupájába", vagyis a memóriafelhasználás szempontból kellemetlenül többféle sorrendi eljárással történik.
Meghatározza az UGA által dinamikusan igényelt memória maximális méretét a tárcsázási módszerrel végrehajtott rendezési eljárás végső fázisában. Az adagolás befejezése után a válogatás eljárás, ez a memória vissza, de a végső válogatási lépésben, akkor a folyamat során felhasználódnak egy ideig amellett, hogy a „core” memória, beállítható paraméter SORT_AREA_SIZE. (Ekkor a feldolgozáshoz felhasznált összes RAM elérheti a SORT_AREA_SIZE + SORT_AREA_RETAINED_SIZE értéket)
Ennek a paraméternek a beállítása, hogy egy speciális alpuffert helyezzen az adatblokkpufferbe, amelyhez a normál LRU blokkcsere-mechanizmus nem működik. Ha egy vagy több nagyon aktívan használt objektum van (táblázatok) és teljes térfogata viszonylag kicsi, akkor a memóriában történő rögzítés növelheti a rendszer válaszának gyorsaságát.
Ennek a paraméternek a beállítása egy másik speciális alpuffert hoz létre, ami ismételten megszegi a blokkok cseréjének szokásos sorrendjét, de ellentétes módon. Ha egy nagy tárgy ritkán használják (a nagyon nagy tábla), akkor annak tulajdonítható, hogy az al-puffer RECYCLE, majd az Oracle „elengedni” az ő egységek közvetlenül a használat után (ami lehet szerezni teljesítményt, valamint a következő hivatkozás a blokk nem hamarosan).
Lehetővé teszi az egyidejűleg olvasható blokkok számának megadását a lemezről történő DBMS leolvasásakor. A nagy táblák szkennelésekor a DB_FILE_MULTIBLOCK_READ_COUNT növelése észrevehető hatást fejt ki.
Vladimir Przhilkovsky, az UCS Interface Kft. Tanára