Rajat DBA: n blogissa

tämä on kopio Metalinkin Viitehuomautuksesta 22908.1, niille, joilla ei ole siihen pääsyä.

1. mikä on salpa?
   salvat ovat matalan tason sarjalisaatiomekanismeja, joita käytetään SGA: n jaettujen tietorakenteiden suojaamiseen. Salvien toteutus on käyttöjärjestelmäriippuvaista erityisesti sen suhteen, odottaako prosessi salvaa ja kuinka kauan.

salpa on Lukkotyyppi, joka voidaan hankkia ja vapauttaa hyvin nopeasti. Salvat käytetään tyypillisesti estämään useampaa kuin yhtä prosessia suorittamasta samaa koodinpätkää tiettynä aikana. Liittyy kunkin salpa on puhdistus menettely, joka kutsutaan, jos prosessi kuolee samalla salpa. Salvat on liittyvä taso, jota käytetään estämään umpikujia. Kun prosessi hankkii salvan tietyllä tasolla, se ei voi myöhemmin hankkia salvaa tasolla, joka on yhtä suuri tai pienempi kuin tämä taso (ellei se Hanki sitä nyt).

2.Salvat vs. Enqueues

Enqueues ovat toinen Oraclessa käytetty lukitusmekanismi.
tiedustelu on kehittyneempi mekanismi,joka mahdollistaa useiden samanaikaisten prosessien vaihtelevan “tunnettujen” resurssien jakamisen. Kaikki objektit, joita voidaan käyttää samanaikaisesti, voidaan suojata kyselyillä. Hyvä esimerkki on pöytien lukot. Sallimme taulukoiden jakamisen eri tasoilla, esim. kaksi prosessia voi lukita taulukon Jaa-tilassa tai jaa-päivitystilassa jne. Yksi ero on se, että enqueue saadaan KÄYTTÖJÄRJESTELMÄKOHTAISELLA lukitusmekanismilla. Tiedustelun avulla käyttäjä voi tallentaa lukkoon arvon eli tilan, jossa pyydämme sitä. Käyttöjärjestelmän lukituspäällikkö pitää kirjaa lukituista resursseista. Jos prosessille ei voida myöntää lukkoa, koska se on yhteensopimaton pyydetyn tilan kanssa ja Lukkoa pyydetään odotusajankohdalla, käyttöjärjestelmä asettaa pyytävän prosessin odotusjonoon, joka huolletaan FIFO: ssa.

toinen ero salvojen ja kyselyjen välillä on se, että salvoissa ei ole tilattua jonoa tarjoilijoita kuten kyselyissä. Salpa tarjoilijat voivat joko käyttää ajastimia herätä ja yrittää uudelleen tai spin (vain multiprocessors). Koska kaikki tarjoilijat ovat samanaikaisesti retriing (riippuen aikataulu), kuka tahansa saattaa saada salpa ja mahdollisesti ensimmäinen yrittää saattaa olla viimeinen saada.

1. milloin tarvitaan salpa?

prosessi saa salvan työskennellessään SGA: n (System Global Area) rakenteen kanssa. Se jatkaa pitää salpa ajan se toimii rakenteen. Salpa pudotetaan, kun prosessi on valmis rakenne. Jokainen salpa suojaa eri tietosarjaa, jonka tunnistaa salvan nimestä.

Oracle käyttää atomiohjeita, kuten “test and set”, toimiessaan salvoilla. Prosessit, jotka odottavat suorittavansa koodin osan, jolle salpa on jo saatu jollakin muulla prosessilla, odottavat salvan vapauttamista. Esimerkkejä ovat redo jako salvat, kopio salvat, arkisto ohjaus salpa jne. Perusajatuksena on estää samanaikainen pääsy yhteisiin tietorakenteisiin. Koska asetusohjeet ja vapaat salvat ovat atomisia, käyttöjärjestelmä takaa, että vain yksi prosessi saa sen. Koska kyseessä on vain yksi ohje, se on melko nopea. Salvat pidetään lyhyitä aikoja, ja ne tarjoavat mekanismin puhdistusta varten, jos haltija kuolee epänormaalisti pitäessään sitä. Puhdistus tapahtuu pmon-palvelun avulla.

1. Salvat pyyntötilat?

Salpapyyntöjä voi tehdä kahdessa muodossa:” willing-to-wait “tai”no wait”. Normaalisti salvat pyydetään “valmis-odottamaan” – tilassa. Pyyntö “willing-to-wait” – tilassa
kierrättää, odottaa ja pyytää uudelleen, kunnes salpa on saatu. “No wait” – tilassa prosessi pyytää salpa. Jos yksi ei ole käytettävissä, odottamisen sijaan pyydetään toinen. Vain kun kaikki epäonnistuvat ei palvelimen prosessi on odotettava.

esimerkkejä “halukkaita odottamaan” – salkoista ovat: jaettu allas ja kirjaston välimuistisalvat
esimerkki” no wait ” – salkoista on uusittu kopio-salpa.

5. Mikä aiheuttaa salpa riitaa?Jos vaadittu salpa on varattu, sitä pyytävä prosessi pyörii, yrittää uudelleen ja jos se ei ole vielä käytettävissä, pyörii uudelleen. Silmukka toistetaan enintään alustusparametrin _SPIN_COUNT määrittämän määrän kertoja. Jos tämän koko silmukan jälkeen salpa ei ole vielä käytettävissä, prosessin on tuotettava CPU ja nukkumaan. Aluksi nukkuu yhden senttisekunnin. Tämä aika kaksinkertaistuu jokaisen myöhemmän unen aikana.

tämä aiheuttaa hidastumista ja lisää suorittimen käyttöä, kunnes salpa on käytettävissä. Suorittimen käyttö on seurausta prosessin “pyörimisestä”. “Spinning” tarkoittaa sitä, että prosessi etsii edelleen salvan saatavuutta tiettyjen aikavälien jälkeen, jolloin se nukkuu.

1. miten tunnistaa väite sisäsalkoista?

relevantti tietosanakirjan hakunäkymä:

V$salpa
V$salpa
V$SALPANIMI

V$SALVATAULUKON jokainen rivi sisältää tilastoja eri salvatyypistä. Taulukon sarakkeet kuvastavat erityyppisten salvatoiveiden aktiivisuutta. Ero näiden pyyntöjen välillä on se, jatkaako pyytävä prosessi salvan pyytämistä, jos se ei ole käytettävissä:

halukas-odottamaan jos salpa, jota pyydetään halukkaasti
pyyntö ei ole saatavilla, pyytävä prosessi
odottaa vähän aikaa ja pyytää salvan uudelleen.
prosessi jatkuu odottaen ja pyytäen, kunnes
salpa on käytettävissä.

no wait jos salpa, jota pyydetään välittömästi, on
ei ole saatavilla, pyytävä prosessi ei
odota, vaan jatkaa käsittelyä.

V$SALPANIMI avaintiedot:

saa useita onnistuneita halukkaita odottamaan pyyntöjä
salpa.

huti monta kertaa alkuperäisen odotushaluisen pyynnön
tuloksetta.

nukkuu monta kertaa prosessi odotti pyydettyä salpa
alkuperäisen wiling-to-wait-pyynnön jälkeen.

IMMEDIATE_GETS useita onnistuneita välittömiä pyyntöjä jokaiselle salvalle.

IMMEDIATE_MISSES kunkin salvan epäonnistuneiden välittömien pyyntöjen lukumäärä.

laskettaessa salvan osumasuhdetta

lukkojen Osumasuhteen saamiseksi sovelletaan seuraavaa kaavaa:

“willing-to-wait” Hit Ratio=(GETS-MISSES)/GETS
“no wait” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

tämän luvun tulisi olla lähellä 1. Jos ei, viritä salvan nimen mukaan

1. hyödyllisiä SQL-skriptejä salvan tietojen saamiseksi

/*
** Näytä koko järjestelmän salpa tilastot.
* /
sarakkeen nimi muodossa A32 katkaistu otsikko “salvan nimi”
sarakkeen pid otsikko”haltija PID”
valitse c.name,a. addr, a. gets, a. misses, a.sleeps,
a.immediate_gets,a.immediate_misses, b.pid
from v$latch a, v$latchholder b, v$latchname C
where a.addr = b.laddr(+)
and a.salpa# = C. salpa#
order by a. salpa#;

/*
** koska salpa osoite, selvittää salpa nimi.
* /
sarakkeen nimi muodossa a64 otsikko “nimi”
valitse a.name alkaen v$salpanimi a, v$salpa b
missä B. addr = “& addr ”
ja B. salpa#=a. salpa#;

/*
** Näytä salvan tilastot salvan nimen mukaan.
* /
sarakkeen nimi muodossa a32 otsikko “salvan nimi”
sarakkeen pid otsikko “haltija PID”
valitse c.name,a. addr, a. gets, a. misses, a. sleeps,
a. immediate_gets, a. immediate_misses,b.pid
from V$latch a, v$latchholder b, v$latchname C
where a.addr = b.laddr(+) and a.latch# = C.latch#
and c.name kuten “&latch_name% ” järjestyksessään. salpa#;

1. luettelo kaikista salvoista

Oraakkeliversiot saattavat poiketa siinä salvassa#, joka on annettu olemassa oleville salvoille.
seuraava kysely auttaa tunnistamaan kaikki salvat ja annetun numeron.

sarakkeen nimi muodossa a40 otsikko “salvan nimi”
valitse salpa#, nimi V$lukitusnimestä;

1. luettelo salvat, jotka ovat eniten huolta DBA

• puskurin VÄLIMUISTISALVAT: puskurin välimuistissa on kaksi pääsalvaa, jotka suojaavat datalohkoja. Väite näistä kahdesta salvat nähdään yleensä, kun tietokanta on korkea I / O hinnat. Voimme vähentää riitaa näistä salvoista ja virittää niitä säätämällä tiettyjä sisuksia.ora-parametrit.

välimuistin Puskurit ketjusalpa:

tämä salpa hankitaan aina, kun Puskurin välimuistissa olevaa lohkoa käytetään (kiinnitetään).

cache-puskuriketjujen salvan väittelyn vähentäminen vaatii yleensä loogisten I/O-nopeuksien alentamista virittämällä ja minimoimalla SQL: n I/O-vaatimukset. Korkea I / O hinnat voivat olla merkki kuuma lohko (tarkoittaen lohko erittäin pääsee).

KS. Huomautus 163424.1 Miten tunnistaa kuuma lohko tietokannassa oikein tunnistaa tämän ongelman.

Välimuistipuskurit LRU-ketjusalpa:

välimuistipuskuri lru-ketjusalpa hankitaan uuden lohkon tuomiseksi puskurivälimuistiin ja kirjoitettaessa puskuria takaisin levylle, erityisesti kun yritetään skannata LRU-ketjua (vähiten käytetty), joka sisältää kaikki puskurivälimuistin likaiset lohkot.

on mahdollista vähentää riitaa välimuistipuskurin lru-ketjusalvan osalta kasvattamalla puskurivälimuistin kokoa ja siten vähentämällä nopeutta, jolla puskurivälimuistiin tuodaan uusia lohkoja. Kaksi parametria sanelevat puskurin välimuistin koon, DB_BLOCK_SIZE ja db_block_buffers. Todellisuudessa vain db_block_buffereita voidaan muuttaa ilman tietokannan luomista. Varovaisuus, kun tuning puskuri allas, vältä lisäpuskurit, jotka edistävät vähän tai ei mitään välimuistin osumasuhde. Yleinen virhe on jatkaa db_block_buffersin arvon nostamista. Tällaisilla korotuksilla ei ole vaikutusta, jos teet kokonaisia taulukoskannauksia tai muita toimintoja, jotka eivät käytä puskurivälimuistia. Useita puskuri altaat voivat auttaa vähentämään riitaa tämän salpa.Voit luoda lisää välimuistipuskuri LRU ketjun salvat säätämällä määritysparametri DB_BLOCK_LRU_LATCHES. Voit ehkä vähentää välimuistin puskuriketjujen lukkojen kuormitusta lisäämällä asetusparametria _DB_BLOCK_HASH_BUCKETS

• REDOLOG-PUSKURISALKOJA: puskuriketjuja on kaksi, redo-jakosalpa ja redo-kopiosalpa. Uudelleenjakosalpa on hankittava, jotta voidaan jakaa tilaa puskurissa. Jos tehtävä lokimerkintä on suurempi kuin konfiguraatioparametri LOG_SMALL_ENTRY_MAX_SIZE, istunto, joka hankkii redo-allokaatiosalvan, voi kopioida merkinnän redo-puskuriin välittömästi ja pitää allokaatiosalvaa. Jos lokimerkintä on suurempi kuin LOG_SMALL_ENTRY_MAX_SIZE, istunto vapauttaa redo allokointi salpa ja hankkii redo kopioi salpa jotta kopioida merkintä. On vain yksi redo allocation salpa, mutta voi olla jopa LOG_SIMULTANEOUS_COPIES allocation salvat.

Redo allocation-salpa:

tämä salpa ohjaa tilan jakamista redo-kirjauksille redo-lokipuskurissa. On yksi redo jakaminen salpa per instanssi.

väitettä tästä salvasta Oracle7: ssä voidaan pienentää pienentämällä log_small_entry_max_size-arvoa moniprosessorijärjestelmissä, jotta
kopiosalvan käyttö pakotettaisiin uusimaan. Oracle8i: ssä tämä parametri on vanhentunut, joten sinun on harkittava LOG_BUFFERIN koon kasvattamista tai lokipuskurin kuormituksen vähentämistä käyttäen NOLOGGING-ominaisuuksia, kun se on mahdollista.

Redo-kopiosalpa:

tätä salvaa käytetään redo-levyjen kirjoittamiseen redolog-puskuriin. Tätä salvaa odotellaan sekä yksi-että moniprosessorijärjestelmissä.

moniprosessorijärjestelmissä väitettä voidaan vähentää lisäämällä log_simultaneous_copiesin arvoa (Piilotettu Oracle8i: een) ja/tai lisäämällä LOG_ENTRY_PREBUILD_THRESHOLDIA (ei papereita Oracle7: ään).

• KIRJASTOVÄLIMUISTI

Kirjastovälimuisti salpa:

kirjaston välimuistilukot suojaavat välimuistissa olevia SQL-lausekkeita ja objektien määritelmiä, joita kirjastovälimuisti pitää jaetussa altaassa. Kirjaston välimuistisalpa on hankittava, jotta kirjaston välimuistiin voidaan lisätä Uusi lauseke. Jäsennyksen aikana Oracle etsii kirjaston välimuistista vastaavan lausunnon. Jos sellaista ei löydy, Oracle jäsentää SQL-lausekkeen, hankkii kirjaston välimuistisalvan ja lisää uuden SQL-lausekkeen.

ensimmäinen resurssi tämän salvan riitelyn vähentämiseksi on varmistaa, että sovellus käyttää uudelleen mahdollisimman paljon SQL-lauseenesitystä. Käytä sidontamuuttujia aina kun mahdollista sovelluksessa. Misss tämän salpa voi myös olla merkki siitä, että sovellus jäsentää SQL suurella nopeudella ja voi kärsiä liikaa jäsentää CPU yläpuolella.Jos sovellus on jo viritetty SHARED_POOL_SIZE voidaan lisätä. Huomaa, että jos sovellus ei käytä kirjaston välimuisti asianmukaisesti, väite voi olla huonompi suurempi rakenne käsiteltävä.

parametri _KGL_LATCH_COUNT määrää kirjaston välimuistisalkojen määrän. Oletusarvon pitäisi olla riittävä, mutta jos kirjaston välimuistisalvan riitaa ei voida ratkaista, voi olla suositeltavaa nostaa tätä arvoa. Oletusarvo _kgl_latch_countille on seuraava alkuluku CPU_COUNTIN jälkeen. Tämä arvo voi olla enintään 66 (Katso: ).

kirjaston välimuistin pin-salpa:

kirjaston välimuistin pin-salpa on hankittava, kun jokin kirjaston välimuistin lauseke tutkitaan uudelleen. Misss tämän salpa tapahtuu, kun on erittäin korkea SQL suoritus.

kirjaston välimuistin pin-salkoon kohdistuvan kuormituksen vähentämiseksi on vain vähän tehtävissä, joskin käytetään mieluummin yksityisiä kuin julkisia synonyymejä tai suoria objektiviittauksia, kuten omistajaa.Pöytä voi auttaa.

• SHARED POOL RELATED salvat

Shared pool salpa:

vaikka kirjastovälimuistin salpa suojaa kirjaston välimuistin toimintaa, yhteistä allaslukkoa käytetään suojaamaan kriittisiä operaatioita jaetun altaan muistin jakamisessa ja vapauttamisessa.
jos sovellus käyttää kirjaimellista (karkaisematonta) SQL: ää, tämä voi rajoittaa huomattavasti skaalautuvuutta ja läpimenoa. Uuden SQL-lausekkeen jäsentäminen on kallista sekä suorittimen vaatimusten että kirjaston välimuistin ja jaettujen poolisalkojen hankinnan ja julkaisemisen kannalta. Ennen Oracle9: ää käytössä on vain yksi tällainen salpa koko tietokantaan, joka suojaa muistin jakamista kirjaston välimuistissa. Vuonna Oracle9 useita lapsia otettiin käyttöön lievittää riitaa tästä resurssista.

tapoja vähentää jaettua allassalkaa ovat, välttää kovia jäsennyksiä mahdollisuuksien mukaan, jäsentää kerran, toteuttaa monia. Kirjaimellisen SQL: n poistaminen on myös hyödyllistä välttää jaettu allas salpa. Shared_poolin koko ja MTS: n käyttö (jaettu palvelin-vaihtoehto) vaikuttavat myös suuresti jaettuun allas-salvaan. Huomautus 62143.1 selittää, miten tunnistaa ja korjata ongelmia jaettu allas, ja jaettu allas salpa.

Rivivälimuistioobjektien salpa:

tämä salpa tulee käyttöön, kun käyttäjän prosessit yrittävät päästä käsiksi välimuistin tietosanakirjan arvoihin.

tässä salvassa ei yleensä ole riitaa ja ainoa tapa vähentää riitaa tästä salvasta on kasvattaa jaetun altaan kokoa (SHARED_POOL_SIZE).

1. Tuning_spin_count (_LATCH_SPIN_COUNT in Oracle7)

SPIN_COUNT ohjaa, kuinka monta kertaa prosessi yrittää uudelleen saada salpa ennen perääntymistä ja nukkumaan menoa. Tämä tarkoittaa käytännössä sitä, että prosessi on tiukassa CPU-silmukassa yrittäen jatkuvasti saada salvan SPIN_COUNT-yrityksille. Yhdellä SUORITINJÄRJESTELMÄLLÄ jos Oracle-prosessi yrittää hankkia salvan, mutta se on jonkun muun hallussa, prosessi vapauttaa suorittimen ja nukahtaa lyhyeksi ajaksi ennen kuin yrittää uudelleen. Moniprosessorijärjestelmässä (SMP) on kuitenkin mahdollista, että salvaa pitävä prosessi on käynnissä jommassakummassa muussa suorittimessa ja siten mahdollisesti vapauttaa salvan seuraavissa ohjeissa (salvat pidetään yleensä vain hyvin lyhyitä aikoja).

suorituskykyä voidaan säätää muuttamalla spin_count-arvoa. Jos käytetään suurta arvoa, salpa saavutetaan nopeammin kuin jos käytät alhaista arvoa. Kuitenkin, voit käyttää enemmän CPU aikaa spinning saada salpa jos käytät korkea arvo SPIN_COUNT. Voit vähentää tätä todennäköisyyttä istunnon nukkuu lisäämällä arvoa määritysparametrit _LATCH_SPIN_COUNT tai SPIN_COUNT. Tämä parametri määrää, kuinka monta yritystä istunto tekee saada salpa ennen nukkumista. Pyöriminen salvalla kuluttaa CPU: ta, joten jos lisäät tätä parametria, saatat nähdä järjestelmiesi yleisen suorittimen käyttöasteen kasvavan. Jos tietokone on lähellä 100% CPU ja sovellus on läpimeno eikä vasteaika ajetaan, voit harkita vähentämällä SPIN_COUNT säilyttämiseksi CPU. Spin_countin säätäminen on yrityksen ja erehdyksen tulosta. Yleensä spin_count kasvaa vain, jos järjestelmässä on riittävästi vapaita suoritinresursseja, ja vähentää sitä vain, jos ei ole ylimääräistä SUORITINKAPASITEETTIA.