Rajat DBA blogja

ez a Metalink 22908.1 hivatkozási jegyzetének másolata azok számára, akik nem férnek hozzá.

1. mi az a retesz?
   a reteszek alacsony szintű szerializációs mechanizmusok, amelyeket az SGA megosztott adatstruktúráinak védelmére használnak. A reteszek megvalósítása operációs rendszerfüggő, különös tekintettel arra, hogy egy folyamat vár-e egy reteszre és mennyi ideig.

a retesz olyan típusú zár, amely nagyon gyorsan megszerezhető és felszabadítható. A reteszeket általában arra használják, hogy megakadályozzák, hogy egynél több folyamat végrehajtsa ugyanazt a kóddarabot egy adott időben. Az egyes reteszekhez egy tisztítási eljárás tartozik, amelyet akkor hívnak meg, ha egy folyamat meghal, miközben a reteszt tartja. A reteszeknek van egy társított szintje, amelyet a holtpontok megelőzésére használnak. Miután egy folyamat megszerez egy reteszt egy bizonyos szinten, később nem szerezhet reteszt egy olyan szinten, amely egyenlő vagy annál kisebb (hacsak nem szerzi meg nowait).

2.Reteszek vs. Enqueues

az Enqueues egy másik típusú reteszelő mechanizmus, amelyet az Oracle használ.
az enqueue egy kifinomultabb mechanizmus, amely lehetővé teszi, hogy több párhuzamos folyamat különböző mértékben megossza az “ismert” erőforrásokat. Bármely objektum, amely egyidejűleg használható, védhető enqueues. Jó példa erre az asztalok zárolása. Különböző szintű megosztást engedélyezünk az asztalokon, pl. két folyamat zárolhat egy táblát megosztás módban vagy megosztás frissítés módban stb. Az egyik különbség az, hogy az enqueue-t egy OS-specifikus reteszelő mechanizmus segítségével kapjuk meg. Az enqueue lehetővé teszi a felhasználó számára, hogy egy értéket tároljon a zárban, azaz azt a módot, amelyben azt kérjük. Az OS lock manager nyomon követi a zárolt erőforrásokat. Ha egy folyamat nem adható meg a zárolásnak, mert nem kompatibilis a kért móddal, és a zárolást várással kérik, az operációs rendszer a kérési folyamatot egy várakozási sorba helyezi, amelyet a FIFO szervizel.

egy másik különbség a reteszek és az enqueues között az, hogy a reteszekben nincs megrendelt pincérsor, mint az enqueues-ben. A reteszelő pincérek időzítőket használhatnak az ébresztéshez, az újraprocesszorhoz vagy a centrifugáláshoz (csak multiprocesszorokban). Mivel minden pincér egyszerre próbálkozik (az ütemezőtől függően), bárki megkaphatja a reteszt, és elképzelhető, hogy az első próbálkozó lesz az utolsó.

1. mikor kell beszerezni a reteszt?

egy folyamat reteszt kap, amikor az SGA (System Global Area) struktúrájával dolgozik. Továbbra is tartja a reteszt, amíg a szerkezettel működik. A retesz leesik, amikor a folyamat befejeződik a szerkezettel. Minden retesz különböző adatkészletet véd, amelyet a retesz neve azonosít.

az Oracle olyan atomi utasításokat használ, mint a “test and set” a reteszek működtetéséhez. Azok a folyamatok, amelyek arra várnak, hogy végrehajtsák a kód egy részét, amelyhez valamilyen más eljárással már reteszt kaptak, megvárják, amíg a reteszt elengedik. Ilyenek például a redo allokációs reteszek, másolási reteszek, archív vezérlő retesz stb. Az alapötlet a megosztott adatstruktúrákhoz való egyidejű hozzáférés blokkolása. Mivel a szabad reteszek beállítására vonatkozó utasítások atomi jellegűek, az operációs rendszer garantálja, hogy csak egy folyamat kapja meg. Mivel ez csak egy utasítás, elég gyors. A reteszeket rövid ideig tartják, és mechanizmust biztosítanak a tisztításhoz abban az esetben, ha a tartó rendellenesen meghal, miközben tartja. Ez a tisztítás a PMON szolgáltatásaival történik.

1. reteszek kérési módok?

a reteszek kérése kétféle módon történhet: “hajlandó várni” vagy “nincs várakozás”. Normális esetben a reteszeket “hajlandó várni” módban kell kérni. A
“willing-to-wait” módban lévő kérés hurok, várakozás és ismét kérés lesz, amíg a reteszt meg nem kapjuk. “Nincs várakozás” módban a folyamat kéri a reteszt. Ha az egyik nem áll rendelkezésre, várakozás helyett egy másikat kérnek. Csak akkor, ha minden sikertelen, a szerver folyamatnak várnia kell.

a “willing-to-wait” zárak példái a következők: megosztott készlet és könyvtár gyorsítótár zárak
a “no wait” zárak példája a redo copy retesz.

5. Mi okozza a retesz állítását?Ha egy szükséges retesz foglalt, akkor az azt kérő folyamat forog, újra próbálkozik, ha pedig még mindig nem áll rendelkezésre, újra forog. A ciklus legfeljebb a _SPIN_COUNT inicializálási paraméter által meghatározott számú alkalommal ismétlődik. Ha a teljes hurok után a retesz még mindig nem áll rendelkezésre, akkor a folyamatnak el kell engednie a CPU-t, és aludnia kell. Kezdetben alszik egy centimásodperc. Ez az idő minden további alvás során megduplázódik.

ez lassulást okoz, és további CPU-használatot eredményez, amíg egy retesz nem áll rendelkezésre. A CPU használata a folyamat “forgatásának” következménye. A “fonás” azt jelenti, hogy a folyamat továbbra is keresi a retesz elérhetőségét bizonyos időintervallumok után, amely alatt alszik.

1. hogyan lehet azonosítani a belső reteszek állítását?

releváns adatszótár-nézetek a lekérdezéshez:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

A V$LATCH táblázat minden sora más típusú retesz statisztikáit tartalmazza. A táblázat oszlopai a különböző típusú reteszelési kérelmek tevékenységét tükrözik. Az ilyen típusú kérések közötti különbség az, hogy a kérési folyamat továbbra is kér-e reteszt, ha az nem érhető el:

hajlandó várni ha a várakozás hajlandó
kéréssel kért retesz nem érhető el, a
kérési folyamat rövid ideig vár, és újra kéri a reteszt.
a folyamat addig vár és kér, amíg
a retesz rendelkezésre nem áll.

nincs várakozás ha az azonnali kéréssel kért retesz
nem érhető el, a kérési folyamat nem
vár, hanem folytatja a feldolgozást.

V$LATCHNAME kulcsinformációk:

megkapja a
retesz sikeres várakozásra hajlandó kéréseinek számát.

elmulasztja a
kezdeti várakozásra hajlandó kérés sikertelen volt.

alszik hányszor folyamat várt a kért reteszt
után kezdeti wiling-to-wait kérés.

IMMEDIATE_GETS az egyes reteszekhez tartozó sikeres azonnali kérések száma.

IMMEDIATE_MISSES sikertelen azonnali kérések száma minden retesz.

a retesz találati arányának kiszámítása

a reteszek találati arányának meghatározásához használja a következő képletet:

“willing-to-wait” találati arány=(gets-MISSES)/GETS
“no wait” találati arány=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

ennek a számnak közel kell lennie az 1-hez. Ha nem, hangoljon a retesz neve szerint

1. hasznos SQL szkriptek a retesz információinak megszerzéséhez

/*
** kijelző rendszer-szintű retesz statisztikák.
* /
oszlopnév formátum A32 csonka címsor “retesz neve”
oszlop pid címsor”tartó PID”
válasszon c.name,a.addr,a.gets,A.hiányzik, a.alszik,
a.immediate_gets,a.immediate_misses, b.pid
a v$retesztől a, v$latchholder b, v$latchname C
ahol a. addr = b. laddr (+)
és a. latch # = c. latch#
sorrend a. latch#;

/*
** adott egy retesz címet, megtudja a retesz nevét.
* /
oszlopnév formátum A64 fejléc ‘ név ‘
válasszon a.name tól v$latchname a, v$latch B
ahol b. addr = ‘&addr ‘
és b. latch # =a. latch#;

/*
** a retesz statisztikáinak megjelenítése retesz neve szerint.
* /
oszlopnév formátum A32 címsor ‘retesz neve’
oszlop pid címsor ‘tartó PID’
válasszon c.name,a.addr,a.gets,A.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b.pid
a v$retesztől a, v$latchholder b, v$latchname C
ahol a.addr = b.laddr(+) és a.latch# = c. latch#
és c.name like ‘&latch_name% ‘ sorrend egy. latch által#;

1. az összes retesz listája

az Oracle verziói eltérhetnek a meglévő reteszekhez rendelt retesz# – ben.
a következő lekérdezés segít azonosítani az összes zárat és a hozzárendelt számot.

oszlopnév formátum A40 fejléc ‘retesz neve’
válassza ki a reteszt#, név a v$latchname-ből;

1. a DBA számára leginkább aggasztó reteszek listája

• puffer gyorsítótár reteszek: két fő zár van, amelyek védik az adatblokkokat a puffer gyorsítótárban. E két retesz vitatása általában akkor látható, ha egy adatbázis magas I/O sebességgel rendelkezik. Csökkenthetjük ezeknek a reteszeknek a vitáját, és bizonyos init beállításával hangolhatjuk őket.ora paraméterek.

gyorsítótár pufferek láncok retesz:

ezt a reteszt akkor kapja meg a rendszer, amikor a puffer gyorsítótár egy blokkját eléri (rögzíti).

a gyorsítótár pufferláncok reteszének csökkentése általában a Logikai I/O sebességek csökkentését igényli az érintett SQL I/O követelményeinek beállításával és minimalizálásával. A magas I / O sebesség a forró blokk jele lehet (vagyis egy nagyon elérhető blokk).

Lásd A 163424 Megjegyzést.1 Hogyan lehet azonosítani egy forró blokkot az adatbázisban a probléma helyes azonosításához.

gyorsítótár pufferek LRU chain latch:

a gyorsítótár puffer LRU chain reteszt azért szerezte be, hogy új blokkot vezessen be a puffer gyorsítótárába, és amikor egy puffert ír vissza a lemezre, különösen akkor, amikor megpróbálja beolvasni a puffer gyorsítótárban lévő összes piszkos blokkot tartalmazó LRU (legkevésbé használt) láncot.

lehetséges a gyorsítótár puffer LRU lánczárral kapcsolatos viták csökkentése a puffer gyorsítótár méretének növelésével, ezáltal csökkentve az új blokkok bevezetésének sebességét a puffer gyorsítótárba. Két paraméter határozza meg a puffer gyorsítótár méretét, a DB_BLOCK_SIZE és a DB_BLOCK_BUFFERS. Valójában csak a DB_BLOCK_BUFFERS módosítható az adatbázis újbóli létrehozása nélkül. Vigyázat, a pufferkészlet hangolásakor kerülje a További pufferek használatát, amelyek alig vagy egyáltalán nem járulnak hozzá a gyorsítótár találati arányához. Gyakori hiba a DB_BLOCK_BUFFERS értékének növelése. Az ilyen növeléseknek nincs hatása, ha teljes táblázatos vizsgálatokat vagy más műveleteket végez, amelyek nem használják a puffer gyorsítótárat. A több pufferkészlet segíthet csökkenteni a retesz állítását.További gyorsítótár puffer LRU lánczárakat hozhat létre a db_block_lru_latches konfigurációs paraméter beállításával. A _db_block_hash_buckets

• konfigurációs paraméter növelésével csökkentheti a gyorsítótár pufferlánc-reteszeinek terhelését: két Redo pufferzár van, a redo allocation retesz és a redo copy retesz. A redo allokációs reteszt meg kell szerezni annak érdekében, hogy helyet foglaljon el a pufferen belül. Ha a végrehajtandó redo naplóbejegyzés nagyobb, mint a log_small_entry_max_size konfigurációs paraméter, akkor a redo allokációs reteszt megszerző munkamenet azonnal átmásolhatja a bejegyzést az redo pufferbe, miközben megtartja az allokációs reteszt. Ha a naplóbejegyzés nagyobb, mint a LOG_SMALL_ENTRY_MAX_SIZE, akkor a munkamenet elengedi a redo allokációs reteszt, és megszerzi a redo copy reteszt a bejegyzés másolásához. Csak egy redo allokációs retesz van, de lehet, hogy akár LOG_SIMULTANEOUS_COPIES allokációs reteszek is lehetnek.

redo allocation retesz:

ez a retesz szabályozza a redo log pufferben lévő redo bejegyzések számára fenntartott helyet. Példányonként egy redo allokációs retesz van.

az Oracle7-ben erre a reteszre vonatkozó állítás csökkenthető a LOG_SMALL_ENTRY_MAX_SIZE értékének csökkentésével a többprocesszoros rendszereken, hogy kényszerítsék a
másolat retesz használatát. Az Oracle8i-ban ez a paraméter elavult, ezért fontolóra kell vennie a LOG_BUFFER méretének növelését vagy a naplópuffer terhelésének csökkentését a NOLOGGING funkciók használatával, ha lehetséges.

redo copy retesz:

ez a retesz arra szolgál, hogy redo rekordokat írjon a redolog pufferbe. Ez a retesz mind az egy -, mind a többprocesszoros rendszereken vár.

többprocesszoros rendszereken a vita csökkenthető a LOG_SIMULTANEOUS_COPIES (Rejtett az Oracle8i-ban) és/vagy a LOG_ENTRY_PREBUILD_THRESHOLD (nem dokumentált az Oracle7-ben) értékének növelésével.

• könyvtári gyorsítótár

könyvtári gyorsítótár retesze:

a könyvtári gyorsítótár reteszei védik a megosztott készlet könyvtári gyorsítótárában tárolt gyorsítótárazott SQL utasításokat és objektumdefiníciókat. A könyvtár gyorsítótár reteszét meg kell szerezni ahhoz, hogy új utasítást adjon a könyvtár gyorsítótárához. Elemzés közben az Oracle a könyvtár gyorsítótárában keres egy megfelelő utasítást. Ha az egyik nem található, akkor az Oracle elemzi az SQL utasítást, megszerzi a könyvtár gyorsítótárának reteszét, és beszúrja az új SQL-t.

az első erőforrás, amely csökkenti a vitát ezen a reteszen, annak biztosítása, hogy az alkalmazás a lehető legnagyobb mértékben újrafelhasználja az SQL utasítás-ábrázolást. Használja a bind változókat, amikor csak lehetséges az alkalmazásban. A retesz hiánya azt is jelezheti, hogy az alkalmazás nagy sebességgel elemzi az SQL-t, és túl sok elemzési CPU-t szenvedhet.Ha az alkalmazás már be van hangolva, a SHARED_POOL_SIZE növelhető. Ne feledje, hogy ha az alkalmazás nem használja megfelelően a könyvtár gyorsítótárát, akkor az állítás rosszabb lehet, ha nagyobb struktúrát kell kezelni.

a _kgl_latch_count paraméter szabályozza a könyvtár gyorsítótár-reteszeinek számát. Az alapértelmezett értéknek megfelelőnek kell lennie, de ha a könyvtár gyorsítótár reteszének vitatása nem oldható meg, tanácsos lehet ezt az értéket növelni. A _KGL_LATCH_COUNT alapértelmezett értéke a CPU_COUNT után következő prímszám. Ez az érték nem haladhatja meg a 66-ot (lásd: ).

könyvtári gyorsítótár pin retesz:

a könyvtári gyorsítótár pin reteszt be kell szerezni, amikor a könyvtári gyorsítótárban lévő utasítás újra végrehajtásra kerül. Hiányzik ezen a reteszt akkor fordul elő, ha nagyon magas az SQL végrehajtás.

keveset lehet tenni a könyvtár gyorsítótár-reteszének terhelésének csökkentése érdekében, bár inkább privát, mint nyilvános szinonimákat vagy közvetlen objektumhivatkozásokat, például tulajdonos.Az asztal segíthet.

• SHARED POOL RELATED RETCHES

Shared pool retesz:

míg a library cache retesz védi a műveleteket a library cache-en kívül, a shared pool latch a kritikus műveletek védelmére szolgál, amikor memóriát foglal és szabadít fel a megosztott pool-ban.
ha egy alkalmazás literális (megosztatlan) SQL-t használ, akkor ez súlyosan korlátozhatja a skálázhatóságot és az átviteli sebességet. Az új SQL utasítás elemzésének költsége költséges mind a CPU követelmények, mind pedig a könyvtár gyorsítótárának és a megosztott készlet reteszeinek megszerzésének és felszabadításának száma szempontjából. Az Oracle9 előtt csak egy ilyen retesz van a teljes adatbázisban, hogy megvédje a memória elosztását a könyvtár gyorsítótárában. Az Oracle9-ben több gyermeket vezettek be, hogy enyhítsék az erőforrással kapcsolatos vitákat.

a megosztott medence reteszének csökkentésének módjai a következők: kerülje a kemény elemzéseket, ha lehetséges, elemezze egyszer, hajtson végre sokat. A literális SQL kiküszöbölése szintén hasznos a megosztott medence reteszének elkerülése érdekében. A shared_pool mérete és az MTS (shared server option) használata szintén nagyban befolyásolja a shared pool reteszt. A 62143.1. megjegyzés ismerteti, hogyan lehet azonosítani és kijavítani a megosztott készlet és a megosztott készlet reteszével kapcsolatos problémákat.

Row cache objects retesz:

ez a retesz akkor jön létre, amikor a felhasználói folyamatok megpróbálják elérni a gyorsítótárazott adatszótár értékeit.

nem gyakori, hogy ebben a reteszben vita van, és az egyetlen módja annak, hogy csökkentsük a vitát, ha növeljük a megosztott készlet méretét (SHARED_POOL_SIZE).

1. hangolás _SPIN_COUNT (_LATCH_SPIN_COUNT az Oracle7-ben)

a SPIN_COUNT szabályozza, hogy a folyamat hányszor próbálja meg újra megszerezni a reteszt, mielőtt hátrál és elalszik. Ez alapvetően azt jelenti, a folyamat egy szűk CPU hurok folyamatosan próbál a reteszt SPIN_COUNT kísérletek. Egyetlen CPU rendszeren, ha egy Oracle folyamat megpróbál reteszt szerezni, de valaki más tartja, a folyamat felszabadítja a CPU-t, és rövid ideig alszik, mielőtt újra megpróbálja. Azonban egy többprocesszoros rendszeren (SMP) lehetséges, hogy a reteszt tartó folyamat az egyik másik CPU-n fut, így a következő néhány utasításban potenciálisan elengedi a reteszt (a reteszeket általában csak nagyon rövid ideig tartják).

a teljesítmény a SPIN_COUNT értékének megváltoztatásával állítható be. Ha magas értéket használ, a retesz hamarabb érhető el, mint ha alacsony értéket használ. Azonban lehet, hogy több CPU időt forog, hogy a reteszt, ha használja a magas érték SPIN_COUNT. A munkamenet-alvás valószínűségét csökkentheti a _latch_spin_count vagy a SPIN_COUNT konfigurációs paraméterek értékének növelésével. Ez a paraméter szabályozza, hogy a munkamenet hány kísérletet tesz a retesz megszerzésére alvás előtt. A retesz forgatása CPU-t fogyaszt, így ha növeli ezt a paramétert, akkor a rendszerek teljes CPU-kihasználtságának növekedését tapasztalhatja. Ha a számítógép közel 100% CPU és az alkalmazás átviteli sebesség helyett válaszidő vezérelt, akkor érdemes csökkenő SPIN_COUNT megőrzése érdekében CPU. A SPIN_COUNT beállítása próba és hiba. Általában csak akkor növelje a SPIN_COUNT-ot, ha elegendő szabad CPU-erőforrás áll rendelkezésre a rendszeren, és csak akkor csökkentse, ha nincs szabad CPU-kapacitás.