Rajat DBA’ s Blog

dette er en kopi af Metalinks Referencenote 22908.1, for dem der ikke har adgang til det.

1. Hvad er en lås?
   låse er serialiseringsmekanismer på lavt niveau, der bruges til at beskytte delte datastrukturer i SGA. Implementeringen af låse er operativsystemafhængig, især med hensyn til, om en proces vil vente på en lås, og hvor længe.

en lås er en type lås, der meget hurtigt kan erhverves og frigøres. Låse bruges typisk til at forhindre mere end en proces i at udføre det samme stykke kode på et givet tidspunkt. Tilknyttet hver lås er en oprydningsprocedure, der kaldes, hvis en proces dør, mens du holder låsen. Låse har et tilknyttet niveau, der bruges til at forhindre deadlocks. Når en proces erhverver en lås på et bestemt niveau, kan den ikke efterfølgende erhverve en lås på et niveau, der er lig med eller mindre end dette niveau (medmindre det erhverver det nu).

2.Låse vs. forespørgsler

forespørgsler er en anden type låsemekanisme, der bruges i Oracle.
en forespørgsel er en mere sofistikeret mekanisme, der tillader flere samtidige processer at have varierende grad af deling af “kendte” ressourcer. Ethvert objekt, der kan bruges samtidigt, kan beskyttes med forespørgsler. Et godt eksempel er låse på borde. Vi tillader forskellige niveauer af deling på tabeller, f.eks. to processer kan låse en tabel i delingstilstand eller i delopdateringstilstand osv. En forskel er, at forespørgslen opnås ved hjælp af en OS-specifik låsemekanisme. En forespørgsel giver brugeren mulighed for at gemme en værdi i låsen, dvs.den tilstand, hvor vi anmoder om det. OS lock manager holder styr på de låste ressourcer. Hvis en proces ikke kan tildeles låsen, fordi den er uforenelig med den ønskede tilstand, og låsen anmodes om med vent, OS sætter den anmodende proces i en ventekø, der serviceres i FIFO.

en anden forskel mellem låse og forespørgsler er, at der i låse ikke er nogen bestilt kø af tjener som i forespørgsler. Latch tjenere kan enten bruge timere til at vågne op og prøve igen eller spin (kun i multiprocessorer). Da alle tjener samtidig forsøger igen (afhængigt af planlæggeren), kan nogen få låsen og tænkeligt den første til at prøve kan være den sidste til at få.

1. Hvornår skal vi få en lås?

en proces erhverver en lås, når man arbejder med en struktur i SGA (System Global Area). Det fortsætter med at holde låsen i den periode, det virker med strukturen. Låsen falder, når processen er færdig med strukturen. Hver lås beskytter et andet sæt data, identificeret ved navnet på låsen.

Oracle bruger atominstruktioner som “test and set” til drift på låse. Processer, der venter på at udføre en del af koden, som en lås allerede er opnået ved en anden proces, venter, indtil låsen frigives. Eksempler er redo allokering låse, kopiere låse, arkiv kontrol låsen etc. Den grundlæggende ide er at blokere samtidig adgang til delte datastrukturer. Da instruktionerne om at indstille og frigøre låse er atomare, garanterer operativsystemet, at kun en proces får det. Da det kun er en instruktion, er det ret hurtigt. Låse holdes i korte perioder og giver en mekanisme til oprydning, hvis en holder dør unormalt, mens den holdes. Denne rengøring udføres ved hjælp af PMON ‘ s tjenester.

1. låse anmodning tilstande?

anmodning om låse kan foretages i to tilstande: “villig til at vente” eller “ingen ventetid”. Normalt vil låse blive anmodet om i” villig til at vente ” -tilstand. En anmodning i” villig til at vente ” -tilstand
vil sløjfe, vente og anmode om igen, indtil låsen er opnået. I” ingen ventetid ” – tilstand anmoder processen om låsen. Hvis en ikke er tilgængelig, i stedet for at vente, anmodes der om en anden. Først når alt mislykkes, skal serverprocessen vente.

eksempler på “villige til at vente” låse er: delt pool og bibliotek cache låse
et eksempel på “ingen vent” låse er redo kopi låsen.

5. Hvad forårsager latch påstand?Hvis en påkrævet lås er optaget, spinder processen, der anmoder om den, igen, og hvis den stadig ikke er tilgængelig, spinder den igen. Sløjfen gentages op til et maksimalt antal gange bestemt af initialiseringsparameteren _SPIN_COUNT. Hvis låsen efter hele denne sløjfe stadig ikke er tilgængelig, skal processen give CPU ‘ en og gå i dvale. I første omgang er sover for en centisekund. Denne gang fordobles i hver efterfølgende søvn.

dette medfører en afmatning og resulterer i yderligere CPU-brug, indtil en lås er tilgængelig. CPU-brugen er en konsekvens af” spinning ” af processen. “Spinning” betyder, at processen fortsætter med at kigge efter tilgængeligheden af låsen efter bestemte tidsintervaller, hvor den sover.

1. hvordan man identificerer strid for interne låse?

relevante dataordbogsvisninger til forespørgsel:

V$LATCH
V$LATCHHOLDER
V$LATCHNAME

hver række i V$LATCH-tabellen indeholder statistikker for en anden type lås. Kolonnerne i tabellen afspejler aktivitet for forskellige typer låseanmodninger. Sondringen mellem disse typer anmodninger er, om den anmodende proces fortsætter med at anmode om en lås, hvis den ikke er tilgængelig:

villig til at vente hvis den lås, der anmodes om med en villig til at vente
anmodning, ikke er tilgængelig, venter den anmodende proces
kort tid og anmoder om låsen igen.
processen fortsætter med at vente og anmode om, indtil
låsen er tilgængelig.

ingen ventetid hvis låsen, der anmodes om med en øjeblikkelig anmodning, er
ikke tilgængelig, venter den anmodende proces ikke
, men fortsætter behandlingen.

v$LATCHNAME nøgleoplysninger:

får antal vellykkede villige til at vente anmodninger om
en lås.

MISSES antal gange en indledende villig til at vente anmodning
mislykkedes.

sover antal gange en proces ventede en anmodet om en lås
efter en indledende vilje til at vente anmodning.

IMMEDIATE_GETS antal vellykkede øjeblikkelige anmodninger for hver lås.

IMMEDIATE_MISSES antal mislykkede øjeblikkelige anmodninger om hver lås.

beregning af latch hit ratio

for at få Hit ratio for låse skal du anvende følgende formel:

“villig til at vente” Hit Ratio=(GETS-MISSES)/GETS
“ingen ventetid” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

dette tal skal være tæt på 1. Hvis ikke, tune i henhold til låsen navn

1. nyttige

/*
** Display system-dækkende latch statistik.
*/
kolonnenavn format A32 Afkort overskrift”LATCH NAME”
kolonne pid overskrift”HOLDER PID”
vælg c.name,a.addr,a.gets,a.misses, a. sleeps,
a. immediate_gets, a. immediate_misses, b. pid
fra v$latch a, v$latchholder b, v$latchname c
hvor A.addr = b.laddr(+)
og A.latch# = c.latch#
Bestil efter a.latch#;

/*
** Giv en låseadresse, find ud af låsens navn.
*/
kolonnenavn format A64 overskrift ‘navn’
vælg a.name fra v $ latchname a, v$latch b
hvor b. addr = ‘&addr ‘
og b. latch#=a. latch#;

/*
** Display latch statistik ved låsen navn.
*/
kolonnenavn format a32 overskrift ‘LATCH NAME’
kolonne pid overskrift ‘HOLDER PID’
vælg c.name,a.addr,a.gets,a.misses, a. sleeps,
a. immediate_gets, a. immediate_misses, b. pid
fra v$latch a, v$latchholder b, v$latchname c
hvor A. addr = b. laddr (+) og A. latch# = c. latch#
og c.name ligesom ‘&latch_name% ‘ bestil med en. latch#;

1. liste over alle låse

Oracle-versioner kan variere i låsen# tildelt de eksisterende låse.
følgende forespørgsel hjælper dig med at identificere alle låse og det tildelte nummer.

kolonnenavn format a40 overskrift ‘LATCH NAME’
vælg latch#, navn fra v$latchname;

1. liste over låse, der er mest bekymrede for en DBA

• BUFFER CACHE-låse: der er to hovedlåse, der beskytter datablokke i buffercachen. Påstand om disse to låse ses normalt, når en database har høje i/o-satser. Vi kan reducere strid for disse låse og tune dem ved at justere visse init.ora parametre.

Cache buffere kæder låsen:

denne låsen er erhvervet, når en blok i bufferen cache er adgang (pinned).

reduktion af strid for cachebufferkædernes lås vil normalt kræve reduktion af logiske i/O-satser ved at indstille og minimere I/O-kravene i den involverede KVL. Høje I / O-satser kan være et tegn på en varm blok (hvilket betyder en blok, der er meget tilgængelig).

Se Note 163424.1 Sådan identificeres en varm blok i databasen for korrekt at identificere dette problem.

Cache buffere LRU chain latch:

cache buffer LRU chain latch er erhvervet for at introducere en ny blok i buffercachen og når du skriver en buffer tilbage til disken, specifikt når du prøver at scanne LRU (mindst brugt) kæde, der indeholder alle de beskidte blokke i buffercachen.

det er muligt at reducere strid om cachebufferen lru-kædelåsen ved at øge størrelsen på buffercachen og derved reducere den hastighed, hvormed nye blokke indføres i buffercachen. To parametre dikterer størrelsen på buffercachen, DB_BLOCK_STØRRELSE og DB_BLOCK_BUFFERS. I virkeligheden kan kun DB_BLOCK_BUFFERS ændres uden at genskabe databasen. Forsigtig, når du indstiller bufferpuljen, skal du undgå brug af yderligere Buffere, der bidrager lidt eller intet til cache-hitforholdet. En almindelig fejl er at fortsætte med at øge værdien af DB_BLOCK_BUFFERS. Sådanne stigninger har ingen effekt, hvis du laver fuld tabelscanninger eller andre operationer, der ikke bruger buffercachen. Flere bufferpuljer kan hjælpe med at reducere strid på denne lås.Du kan oprette yderligere cache buffer lru kæde låse ved at justere konfigurationsparameteren DB_BLOCK_LRU_LATCHES. Du kan muligvis reducere belastningen på cachebufferkædelåsene ved at øge konfigurationsparameteren _DB_BLOCK_HASH_BUCKETS

• REDOLOG BUFFERLÅSE: der er to redo bufferlåse, redo allocation latch og redo copy latch. Redo-tildelingslåsen skal erhverves for at tildele plads i bufferen. Hvis den genindførelseslog, der skal foretages, er større end konfigurationsparameteren LOG_SMALL_ENTRY_MAKS_STØRRELSE, kan den session, der erhverver genindførelsesallokeringslåsen, kopiere indgangen til gentagelsesbufferen med det samme, mens tildelingslåsen holdes. Hvis logposten er større end LOG_SMALL_ENTRY_MAKS_STØRRELSE, vil sessionen frigive redo allocation latch og vil erhverve redo copy latch for at kopiere posten. Der er kun en redo allokering låsen, men der kan være op til LOG_SIMULTANEOUS_COPIES allokering låse.

Redo allocation latch:

denne lås styrer tildelingen af plads til redo poster i redo log buffer. Der er en redo-allokeringslås pr.

påstand om denne lås i Oracle7 kan reduceres ved at reducere værdien af LOG_SMALL_ENTRY_MAKS_STØRRELSE på multi-cpu-systemer for at tvinge brugen af
redo kopi låsen. I Oracle8i er denne parameter forældet, så du skal overveje at øge størrelsen på LOG_BUFFER eller reducere belastningen af logbufferen ved hjælp af nologging-funktioner, når det er muligt.

Redo copy latch:

denne lås bruges til at skrive redo-poster i redolog-bufferen. Denne lås ventes på både enkelt-og multi-cpu-systemer.

på multi-cpu-systemer kan strid reduceres ved at øge værdien af LOG_SIMULTANEOUS_COPIES (skjult i Oracle8i) og/eller øge LOG_ENTRY_PREBUILD_THRESHOLD (udokumenteret i Oracle7).

• BIBLIOTEKSCACHE

Bibliotekscachelås:

bibliotekscachelåsene beskytter de cachelagrede udsagn og objektdefinitioner, der findes i bibliotekscachen i den delte pool. Bibliotekets cache-lås skal erhverves for at tilføje en ny erklæring til bibliotekets cache. Under en analyse søger Oracle i bibliotekets cache efter en matchende erklæring. Hvis en ikke findes, så Oracle vil parse den sætning, få biblioteket cache låsen og indsætte den nye.

den første ressource til at reducere strid på denne lås er at sikre, at applikationen genbruger så meget som muligt. Brug bind variabler, når det er muligt i applikationen. Misser på denne lås kan også være et tegn på, at applikationen analyserer høj hastighed og kan lide af for meget parse CPU-overhead.Hvis applikationen allerede er indstillet, kan SHARED_POOL_STØRRELSE øges. Vær opmærksom på, at hvis applikationen ikke bruger bibliotekets cache korrekt, kan påstanden være værre med en større struktur, der skal håndteres.

parameteren _kgl_latch_count styrer antallet af bibliotekscachelåse. Standardværdien skal være tilstrækkelig, men hvis strid om bibliotekets cache-lås ikke kan løses, kan det være tilrådeligt at øge denne værdi. Standardværdien for _KGL_LATCH_COUNT er det næste primtal efter CPU_COUNT. Denne værdi må ikke overstige 66 (se: ).

Library cache pin latch:

bibliotekets cache-PIN-lås skal erhverves, når en erklæring i bibliotekets cache udføres igen. Misser på denne lås opstår, når der er meget høje satser.

der er lidt, der kan gøres for at reducere belastningen på bibliotekets cache-PIN-lås, selvom man bruger private snarere end offentlige synonymer eller direkte objektreferencer som ejer.Tabel kan hjælpe.

• delte POOLRELATEREDE låse

delt poollås:

mens bibliotekets cache-lås beskytter operationer inden for bibliotekets cache, bruges den delte poollåse til at beskytte kritiske operationer, når du tildeler og frigør hukommelse i den delte pool.
hvis en applikation gør brug af bogstavelig (ikke-delt) KVM, kan dette alvorligt begrænse skalerbarhed og gennemstrømning. Omkostningerne ved at analysere en ny KVL-erklæring er dyre både med hensyn til CPU-krav og antallet af gange, bibliotekets cache og delte poollåse muligvis skal erhverves og frigives. Før Oracle9 bruges der kun en sådan lås til hele databasen for at beskytte tildelingen af hukommelse i bibliotekets cache. I Oracle9 blev der introduceret flere børn for at aflaste strid om denne ressource.

måder at reducere den delte poollås er, Undgå hårde parser, når det er muligt, parse en gang, udfør mange. Det er også nyttigt at undgå den delte poollås. Størrelsen på shared_pool og brugen af MTS (shared server option) påvirker også i høj grad den delte poollås. Note 62143.1 forklarer, hvordan du identificerer og retter problemer med den delte pool og den delte poollås.

række cache-objekter lås:

denne lås kommer i spil, når brugerprocesser forsøger at få adgang til de cachelagrede dataordbogsværdier.

det er ikke almindeligt at have strid i denne lås, og den eneste måde at reducere strid for denne lås er ved at øge størrelsen på den delte pool (SHARED_POOL_STØRRELSE).

1. Tuning _SPIN_COUNT (_LATCH_SPIN_COUNT i Oracle7)

SPIN_COUNT styrer, hvor mange gange processen vil forsøge at få låsen igen, før du bakker ud og går i seng. Dette betyder dybest set, at processen er i en stram CPU-sløjfe, der hele tiden forsøger at få låsen til SPIN_COUNT-forsøg. På et enkelt CPU-system, hvis en Oracle-proces forsøger at erhverve en lås, men den holdes af en anden, frigiver processen CPU ‘ en og går i dvale i en kort periode, før du prøver igen. På et MULTIPROCESSORSYSTEM (SMP) er det imidlertid muligt, at processen, der holder låsen, kører på en af de andre CPU ‘ er, og det vil potentielt frigøre låsen i de næste par Instruktioner (låse holdes normalt kun i meget korte perioder).

ydeevne kan justeres ved at ændre værdien af SPIN_COUNT. Hvis der anvendes en høj værdi, opnås låsen hurtigere, end hvis du bruger en lav værdi. Du kan dog bruge mere CPU – tid til at dreje for at få låsen, hvis du bruger en høj værdi for SPIN_COUNT. Du kan reducere denne sandsynlighed for session sover ved at øge værdien af konfigurationsparametrene _LATCH_SPIN_COUNT eller SPIN_COUNT. Denne parameter styrer antallet af forsøg, som sessionen vil gøre for at få låsen, før du sover. Spinning på låsen forbruger CPU, så hvis du øger denne parameter, kan du se en stigning i dine systems samlede CPU-udnyttelse. Hvis din computer er tæt på 100% CPU, og din applikation er gennemstrømning snarere end responstidsdrevet, kan du overveje at reducere SPIN_COUNT for at spare CPU. Justering af SPIN_COUNT er forsøg og fejl. Generelt skal du kun øge SPIN_COUNT, hvis der er nok gratis CPU-ressourcer til rådighed på systemet, og reducer det kun, hvis der ikke er nogen ekstra CPU-kapacitet.