Rajat DBAS Blogg

Dette er en kopi Av Metalinks Referansenotat 22908.1, for de som ikke har tilgang til det.

1. Hva er en latch?
   Låsene er lavt nivå serialisering mekanismer som brukes til å beskytte delte datastrukturer I SGA. Implementeringen av låser er operativsystemavhengig, spesielt med hensyn til om en prosess vil vente på en lås og hvor lenge.

en lås er en type lås som kan kjøpes veldig raskt og frigjøres. Låsene brukes vanligvis til å hindre at mer enn en prosess fra å utføre samme stykke kode på et gitt tidspunkt. Tilknyttet hver lås er en oppryddingsprosedyre som vil bli kalt hvis en prosess dør mens du holder låsen. Låsene har et tilhørende nivå som brukes til å forhindre vranglåser. Når en prosess oppnår en lås på et visst nivå, kan den ikke senere skaffe seg en lås på et nivå som er lik eller mindre enn det nivået (med mindre det kjøper det nowait).

2.Låser vs. Enqueues

Enqueues er en annen type låsemekanisme som brukes I Oracle.
En enqueue er en mer sofistikert mekanisme som tillater flere samtidige prosesser å ha varierende grad av deling av” kjente ” ressurser. Ethvert objekt som kan brukes samtidig, kan beskyttes med enqueues. Et godt eksempel er låser på bord. To prosesser kan låse et bord i delingsmodus eller i del oppdateringsmodus etc. En forskjell er at enqueue er oppnådd ved hjelp AV EN OS – spesifikk låsemekanisme. En enqueue tillater brukeren å lagre en verdi i låsen, dvs. modusen der vi ber om det. OS lock manager holder styr på ressursene låst. Hvis en prosess ikke kan gis låsen fordi den er uforenlig med den forespurte modusen og låsen blir bedt om med vent, setter OS den forespurte prosessen på en ventekø som betjenes I FIFO.

En annen forskjell mellom låser og enqueues er at i låser er det ingen bestilt kø av servitører som i enqueues. Latch servitører kan enten bruke tidtakere til å våkne opp og prøve på nytt eller spinne (bare i multiprosessorer). Siden alle servitører samtidig prøver på nytt (avhengig av planleggeren), kan noen få låsen og tenkes den første til å prøve, kan være den siste som får.

1. når trenger vi å skaffe en lås?

en prosess kjøper en lås når du arbeider med en struktur I Sga (System Global Area). Det fortsetter å holde låsen i den perioden det fungerer med strukturen. Låsen slippes når prosessen er ferdig med strukturen. Hver lås beskytter et annet sett med data, identifisert med navnet på låsen.

Oracle bruker atomiske instruksjoner som “test og sett” for drift på låser. Prosesser som venter på å utføre en del av koden som en lås allerede er oppnådd av en annen prosess, vil vente til låsen slippes ut. Eksempler er redo tildeling låsene, kopiere låsene, arkiv kontroll låsen etc. Den grunnleggende ideen er å blokkere samtidig tilgang til delte datastrukturer. Siden instruksjonene for å sette og frigjøre låser er atomiske, GARANTERER OS at bare en prosess får det. Siden det bare er en instruksjon, er det ganske fort. Låsene holdes i korte perioder og gir en mekanisme for opprydding i tilfelle en holder dør unormalt mens du holder den. Denne rengjøringen gjøres ved hjelp av PMONS tjenester.

1. Låser forespørsel moduser?

Låseforespørsel kan gjøres i to moduser: “villig til å vente” eller “nei vent”. Normalt vil låsene bli forespurt i” villig til å vente ” -modus. En forespørsel i” villig til å vente ” -modus
vil sløyfe, vente og be om igjen til låsen er oppnådd. I” nei vent ” modus prosessen be om låsen. Hvis en ikke er tilgjengelig, i stedet for å vente, blir en annen forespurt. Bare når alle mislykkes, må serverprosessen vente.

Eksempler på” villig til å vente “låsene er: delte utvalg og bibliotek cache låsene
et eksempel på” nei vente ” låsene er gjenta kopi låsen.

5. Hva forårsaker latch contention?Hvis en nødvendig lås er opptatt, spinner prosessen som ber om det, prøver igjen, og hvis det fortsatt ikke er tilgjengelig, spinner det igjen. Sløyfen gjentas opp til et maksimalt antall ganger bestemt AV initialiseringsparameteren _SPIN_COUNT. Hvis etter hele denne sløyfen, er låsen fortsatt ikke tilgjengelig, må prosessen gi CPU og gå i dvale. I utgangspunktet sover for en centiandre. Denne gangen blir doblet i hver etterfølgende søvn.

dette fører til en nedgang og resulterer i ekstra CPU-bruk, til en lås er tilgjengelig. CPU-bruken er en konsekvens av” spinning ” av prosessen. “Spinning” betyr at prosessen fortsetter å lete etter tilgjengeligheten av låsen etter bestemte tidsintervaller, hvor den sover.

1. hvordan identifisere strid for interne låser?

Relevante dataordlistevisninger til spørring:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

Hver rad i tabellen V$LATCH inneholder statistikk for en annen type latch. Kolonnene i tabellen gjenspeiler aktivitet for ulike typer sperreforespørsler. Forskjellen mellom disse typer forespørsler er om forespørselsprosessen fortsetter å be om en lås hvis den ikke er tilgjengelig:

villig til å vente Hvis sperren forespurt med en villig til å vente
forespørsel ikke er tilgjengelig, venter forespørselsprosessen
kort tid og ber om sperren igjen.
prosessen fortsetter å vente og be om til
låsen er tilgjengelig.

nei vent Hvis sperren forespurt med en umiddelbar forespørsel er
ikke tilgjengelig, venter ikke forespørselsprosessen
, men fortsetter behandlingen.

V$LATCHNAME nøkkelinformasjon:

FÅR antall vellykkede villige til å vente forespørsler for
en lås.

SAVNER Antall ganger en innledende villig til å vente forespørsel
mislyktes.

SOVEPLASS Antall ganger en prosess ventet a be om en lås
etter en innledende wiling-to-wait-foresporsel.

IMMEDIATE_GETS Antall vellykkede umiddelbare forespørsler for hver lås.

IMMEDIATE_MISSES Antall mislykkede umiddelbare forespørsler for hver lås.

Beregning av latch hit ratio

for Å få Hit ratio for låser gjelder følgende formel:

“villig til å vente” Hit Ratio=(GETS-MISSES)/GETS
“no wait” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

dette tallet skal være nær 1. Hvis ikke, tune i henhold til latch navn

1. Nyttige SQL-skript for å få latch informasjon

/*
** Display system-wide latch statistikk.
*/
kolonnenavn format A32 avkortet overskrift “LATCH NAME”
kolonne pid overskrift “HOLDER PID”
velg c.name, a. addr,a.gets,a.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b.pid
fra v$lås a, v$låseholder b, v$latchname c
hvor a.addr = b. laddr(+)
og a. lås# = c. lås#
bestill med a. lås#;

/*
** Gitt en lås adresse, finne ut låsen navn.
*/
kolonnenavn format a64 overskrift ‘Navn’
velg a.name fra v $ latchname a, v$latch b
hvor b. addr = ‘& addr ‘
og b. latch#=a. latch#;

/*
** Vis latch statistikk etter latch navn.
*/
kolonnenavn format a32 overskrift ‘LATCH NAME’
kolonne pid overskrift ‘HOLDER PID’
velg c.name, a. addr,a.gets,a.misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b.pid
fra v$lås a, v$låseholder b, v$latchname c
hvor a.addr = b.laddr(+) og a.lås# = c. lås#
og c.name liker ‘& latch_name% ‘ rekkefølge av en. latch#;

1. Liste over alle låsene

Oracle-versjoner kan variere i låsen # som er tilordnet de eksisterende låsene.
følgende spørring vil hjelpe deg med å identifisere alle låser og nummeret som er tildelt.

kolonnenavnformat a40 overskrift ‘LATCH NAME’
velg latch#, navn fra v$latchname;

1. Liste over låser som er mest bekymret FOR EN DBA

• BUFFER CACHE LÅSER: det er to hovedlåser som beskytter datablokker i bufferbufferen. Strid for disse to låsene ses vanligvis når en database har høye i / O-priser. Vi kan redusere strid for disse låsene og justere dem ved å justere visse init.ora parametere.

Cache buffere kjeder latch:

denne låsen er kjøpt når en blokk i bufferbufferen er tilgjengelig (festet).

Redusere strid for cache buffer kjeder låsen vil vanligvis kreve å redusere logiske i / O priser ved tuning og minimere I / o kravene TIL SQL involvert. Høye i / O-priser kan være et tegn på en varm blokk (som betyr en blokk som er svært tilgjengelig).

Se Note 163424.1 Slik Identifiserer Du En Hot Block I Databasen for å identifisere dette problemet riktig.

Bufferbuffere LRU chain latch:

bufferbufferen lru chain latch er anskaffet for å introdusere en ny blokk i bufferbufferen og når du skriver en buffer tilbake til disken, spesielt når du prøver å skanne LRU-kjeden (minst nylig brukt) som inneholder alle de skitne blokkene i bufferbufferen.

det Er mulig å redusere strid for bufferbufferen lru – kjedelåsen ved å øke størrelsen på bufferbufferen og dermed redusere hastigheten som nye blokker blir introdusert i bufferbufferen. To parametere dikterer størrelsen på bufferbufferen, DB_BLOCK_SIZE og DB_BLOCK_BUFFERS. I virkeligheten kan bare DB_BLOCK_BUFFERS endres uten å gjenskape databasen. Forsiktig, når tuning buffer utvalget, unngå bruk av ekstra buffere som bidrar lite eller ingenting til cache hit ratio. En vanlig feil er å fortsette å øke verdien AV DB_BLOCK_BUFFERS. Slike økninger har ingen effekt hvis du gjør full tabellskanning eller andre operasjoner som ikke bruker bufferbufferen. Flere buffer bassenger kan bidra til å redusere strid på denne låsen.Du kan opprette flere bufferbuffer lru – kjedelåser ved å justere konfigurasjonsparameteren DB_BLOCK_LRU_LATCHES. DU kan kanskje redusere belastningen PÅ hurtigbufferkjedelåsene ved å øke konfigurasjonsparameteren _DB_BLOCK_HASH_BUCKETS

• REDOLOG BUFFERLÅSER: det er to Lag bufferlåser på nytt, lag tildelingslåsen og lag kopierlåsen. Redo tildeling låsen må skaffes for å tildele plass i bufferen. Hvis loggoppføringen som skal gjøres på nytt, er større enn konfigurasjonsparameteren LOG_SMALL_ENTRY_MAX_SIZE, kan økten som kjøper lås på nytt tildeling kopiere oppføringen til bufferen på nytt umiddelbart mens du holder låsen tildeling. Hvis loggoppføringen er større ENN LOG_SMALL_ENTRY_MAX_SIZE, vil økten frigi redo tildeling låsen og vil hente redo kopi låsen for å kopiere oppføringen. Det er bare en redo allocation latch, men det kan v re OPPTIL LOG_SIMULTANEOUS_COPIES allocation latches.

Gjør om tildelingslås:

denne låsen styrer tildeling av plass for gjør om oppføringer i gjør om loggbufferen. Det er en gjenta tildelingslås per forekomst.

Påstand for denne låsen I Oracle7 kan reduseres ved å redusere verdien AV LOG_SMALL_ENTRY_MAX_SIZE på multi-cpu-systemer for å tvinge bruken av
gjenta kopieringslåsen. I Oracle8i er denne parameteren foreldet, så du må vurdere å øke STØRRELSEN PÅ LOG_BUFFER eller redusere belastningen på loggbufferen ved HJELP AV nologging-funksjoner når det er mulig.

Gjenta kopilås:

denne låsen brukes til å skrive gjenta poster i redologbufferen. Denne låsen er ventet på både enkelt-og multi-cpu-systemer.

på multi-cpu-systemer kan strid reduseres ved å øke verdien AV LOG_SIMULTANEOUS_COPIES (Skjult I Oracle8i) og / eller øke LOG_ENTRY_PREBUILD_THRESHOLD (udokumentert I Oracle7).

• BIBLIOTEKBUFFER

bibliotekbufferlås:

bibliotekbufferlåsene beskytter DE bufrede SQL-setningene og objektdefinisjonene i bibliotekbufferen i det delte utvalget. Bibliotekbufferlåsen må hentes for å kunne legge til en ny setning i bibliotekbufferen. Under en analyse søker Oracle i bibliotekbufferen etter en samsvarende setning. Hvis man ikke blir funnet, vil Oracle analysere SQL-setningen, få bibliotekets hurtigbufferlås og sett inn den nye SQL.

den første ressursen for å redusere strid på denne låsen er å sikre at programmet gjenbruker SÅ MYE SOM MULIG SQL-setning representasjon. Bruk bind variabler når det er mulig i programmet. Savner på denne låsen kan også være et tegn på at programmet analyserer SQL i høy hastighet og kan lide av for mye analyse AV CPU overhead.HVIS programmet allerede er innstilt SHARED_POOL_SIZE kan økes. Vær oppmerksom på at hvis programmet ikke bruker bibliotekbufferen på riktig måte, kan det være verre med en større struktur som skal håndteres.

parameteren _KGL_LATCH_COUNT styrer antall bibliotekbufferlåser. Standardverdien bør være tilstrekkelig, men hvis strid for bibliotekets hurtigbufferlås ikke kan løses, kan det være tilrådelig å øke denne verdien. Standardverdien FOR _KGL_LATCH_COUNT er neste primtall etter CPU_COUNT. Denne verdien kan ikke overstige 66 (Se: ).

lås For bibliotekets hurtigbuffer:

lås for bibliotekets hurtigbuffer må innhentes når en setning i bibliotekets hurtigbuffer kjøres på nytt. Savner på denne låsen oppstår når DET ER svært høye PRISER SQL-utførelse.

det er lite som kan gjøres for å redusere belastningen på biblioteket cache pin låsen, selv om du bruker private snarere enn offentlige synonymer eller direkte objekt referanser SOM EIER.BORDET kan hjelpe.

• DELTE BASSENGRELATERTE LÅSER

delte bassenglås:

mens bibliotekets hurtigbuffer beskytter operasjoner innen bibliotekets hurtigbuffer, brukes den delte bassenglåsen til å beskytte kritiske operasjoner ved tildeling og frigjøring av minne i det delte utvalget.
Hvis et program bruker literal (unshared) SQL, kan dette sterkt begrense skalerbarhet og gjennomstrømning. Kostnaden for å analysere en NY SQL-setning er dyrt både NÅR DET gjelder CPU-krav og antall ganger bibliotekets cache og delte bassenglåser må kanskje kjøpes og utgis. Før Oracle9, det bruker å være bare en slik klinke til hele databasen for å beskytte tildeling av minne i biblioteket cache. I Oracle9 flere barn ble introdusert for å avlaste strid på denne ressursen.

Måter å redusere den delte bassenglåsen er, unngå harde analyser når det er mulig, analyser en gang, utfør mange. Eliminere literal SQL er også nyttig for å unngå den delte bassenget låsen. Størrelsen på shared_pool og bruk AV MTS (delt server-alternativ) påvirker også den delte bassenglåsen. Merknad 62143.1 forklarer hvordan du identifiserer og løser problemer med det delte bassenget og det delte bassenget.

radbufferobjekter klinke:

denne låsen kommer i spill når brukerprosesser forsøker å få tilgang til de bufrede dataordlisteverdiene.

det er ikke vanlig å ha strid i denne låsen, og den eneste måten å redusere strid for denne låsen er ved å øke størrelsen på det delte bassenget (SHARED_POOL_SIZE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT I Oracle7)

SPIN_COUNT kontrollerer hvor mange ganger prosessen vil prøve å få tak i låsen før du går i dvale. Dette betyr i utgangspunktet at prosessen er i en stram CPU-sløyfe som kontinuerlig prøver å få låsen til SPIN_COUNT-forsøk. På et ENKELT CPU-system hvis En Oracle-prosess prøver å skaffe seg en lås, men den holdes av noen andre, vil prosessen frigjøre CPUEN og gå i dvale i en kort periode før du prøver igjen. På et multiprosessorsystem (SMP) er det imidlertid mulig at prosessen som holder låsen, kjører på en av de andre Cpuene, og det vil potensielt frigjøre låsen i de neste instruksjonene(låsene holdes vanligvis bare i svært korte perioder).

Ytelsen kan justeres ved å endre VERDIEN AV SPIN_COUNT. Hvis en høy verdi brukes, vil låsen oppnås raskere enn hvis du bruker en lav verdi. Du kan imidlertid bruke MER CPU – tid på å spinne for å få låsen hvis DU bruker en høy verdi for SPIN_COUNT. Du kan redusere denne sannsynligheten for at økten sover ved å øke verdien AV konfigurasjonsparametrene _LATCH_SPIN_COUNT eller SPIN_COUNT. Denne parameteren styrer antall forsøk økten vil gjøre for å få låsen før du sover. Spinning på låsen bruker CPU, så hvis du øker denne parameteren, kan du se en økning i systemets generelle CPU-utnyttelse. Hvis datamaskinen din er nær 100% CPU og søknaden din er gjennomstrømning i stedet for responstid drevet, kan du vurdere å redusere SPIN_COUNT for å spare CPU. Justering AV SPIN_COUNT er prøving og feiling. Generelt øker SPIN_COUNT bare hvis det er nok GRATIS CPU-ressurser tilgjengelig på systemet, og reduserer det bare hvis det ikke er ledig CPU-kapasitet.