Itl slots oracle

Dette innlegget gir en kort ide om hvordan Oracle laser radene pa vegne av transaksjonene. For du gar videre pa lasing, vil det v re bra for deg a sjekke forrige innlegg pa transaksjonsadministrasjon for a forsta isolasjonsnivaet til Oracle. Her vil vi diskutere et viktig omrade tilstede i Oracle-blokk som er ITL (Interessert Transaksjonsliste).

Tenk deg den enorme mengden data som finnes i Oracle-databasen, og transaksjoner hopper kontinuerlig pa databasen for a fa dataene. Hvis lasing og samtidighet system av oracle er gjort sentralisert sa forestill deg hvor darlig ytelsen til Oracle databasen ville v re. Fordi pa dette nivaet for skalerbarhet er det umulig a sentralisere lasemekanismen for databasen. Det er grunnen til at oracle gjor en intelligent beslutning om a desentralisere lasemekanismen. I Oracle-databasen har vi ikke en sentral lasesjef, og lasene pa data styres pa blokkniva. Hver blokk er ansvarlig for a gi laser pa rader som den opprettholder. Dette holder databasens ytelse oppe.

Na kan vi vurdere at en database er oppe og en transaksjon treffer databasen til en av datablokken. Hvordan gir datablokken lasene? Hvor vil den lagre lasinformasjonen for radene transaksjonen ber om? Her kommer strukturen & # 8211; Interessert transaksjonsliste (ITL). Dette er en liten struktur i oracle-blokk, som inneholder informasjon om listen over transaksjoner, som er interessert i noen av rader i denne blokken. Derfor kalles det Interessert Transaksjonsliste. ITL er til stede i den variable delen av Oracle-blokken. For a forsta den eksakte plasseringen av ITL, kan vi fa en kort forklaring om strukturen i databasen.

Oracle Data blokk er delt inn i 3 hoveddeler.

Oracle Fast-size header Oracle Variabel storrelse header Oracle Data content space.

Her er Oracle Fast Size Header overst i datablokken, etterfulgt av Oracle-variabelstorrelsesoverskrift, og deretter er igjen plass for Oracle-datainnhold som vist i det folgende diagrammet.

Pa slutten har vi kontroll av blokkkonsekvenser. Variabel header info vokser fra toppen ned (like under den faste overskriften) om nodvendig, og rader settes inn fra bunnen opp (rett over halen). ITL (Interessert Transaksjonsliste) ligger i variabel del av datablokkehodet. Det er denne delen av datablokket, som inneholder informasjon om lasing.

Denne variable delen av datablokken inneholder spor for transaksjoner for a sette laseinformasjonen. Nar en rad i blokken er last for forste gang, plasserer transaksjonen en las i en av sporene med den raske av raden som er last. Med andre ord, gjor transaksjonen det kjent at det er interessert i raden (derav navnet & # 8220; Interessert transaksjonsliste & # 8221;). Nar samme transaksjon eller en annen laser en annen rad, lagres informasjonen i et annet spor, og sa videre.

Det neste logiske sporsmalet som kommer opp er hvor mange spor er vanligvis tilgjengelige? Under tabellopprettelsen definerer INITRANS-parameteren hvor mange spor som opprinnelig ble opprettet i ITL. Nar transaksjonene avgir alle tilgjengelige spor og en ny transaksjon kommer inn for a lase en rad, vokser ITL for a skape et nytt spor. ITL kan vokse opp til tallet definert av MAXTRANS-parameteren i tabellen, forutsatt at det er plass i blokken. Likevel, hvis det ikke er mer plass i blokken, selv om MAXTRANS er hoyt nok, kan ITL ikke vokse.

Hva om det ikke er nok spor tilgjengelig i ITL? Hva skjer? Apenbart ma den nye transaksjonen som ber om lasen pa radene vente til den eksisterende transaksjonen er ferdig og frigjore sporet. Dette kalles ITL-ventetid. Nar den eksisterende transaksjonen er ferdig og frigjor sporet, kan den nye transaksjonen fortsette.

La oss se denne beskrivelsen av ventetiden i handling. Anta at vart bord har INITRANS av en og MAXTRANS 11. En typisk datablokke rett etter opprettelsen av tabellen vil se ut som figur 1 nedenfor.

Siden INITRANS er en, er det bare ett spor for ITL. Resten av blokken er tom. Na setter vi tre rader inn i bordet. Disse vil ga inn i denne blokken, og blokken vil se ut som figur 2.

Legg merke til hvordan tomt plass er redusert. Pa dette tidspunktet, en transaksjon kalt Txn1 oppdaterer Row1, men ikke forplikte seg. Dette laser Row1, og transaksjonen plasserer lasen i sporet nummer ett i ITL som vist i figur 3.

Deretter oppdaterer en annen transaksjon, Txn2, raden Row2 og vil lase raden. Det er imidlertid ikke flere spor i ITL tilgjengelig for a betjene transaksjonen. MAXTRANS-oppforingen er 11, noe som betyr at ITL kan vokse opp til 11 spor og blokken har tomt rom. Derfor kan ITL vokse med et annet spor og Slot nummer to er opprettet og allokert til Txn2 (se figur 4).

Na er tomt plass i blokken sv rt begrenset, og det vil ikke v re i stand til a passe til et annet ITL-spor. Hvis det na kommer en annen transaksjon for a oppdatere rad tre, ma den ha en ledig plass i ITL. MAXTRANS er 11 og for oyeblikket er det bare laget to spor, slik at en annen er mulig; men siden det ikke er plass i blokken for a vokse, kan sporet ikke bli opprettet. Derfor ma Txn3 vente til en av de andre transaksjonene ruller tilbake eller forplikter seg, og sporet som holdes av det, blir gratis. Pa denne tiden vil okten oppleve en ITL venter hendelse som sett fra visningen V $ SESSION_WAIT.

Hvert ITL-spor tar opp 24 byte ledig plass i variabel topptekst av datablokken. Maksimum antall spor er styrt av MAXTRANS parameter. Storrelsen pa variabel del av datablokkehodet kan imidlertid ikke overstige 50% av blokkstorrelsen. Dette setter den ovre grensen pa antall ITL tillatt. Hvis vi legger sv rt hoy verdi for MAXTRANS, vil det ikke v re i stand til a oppfylle det samme fordi storrelsen pa variabel overskrift vil vokse utover grensen.

En ITL inneholder den unike transaksjons-IDen (XID), som er en peker til en oppforing i transaksjonstabellen til rullingssegmentet. Enhver transaksjon som vil utfore DML-setningen pa radene som er tilstede i databasen, bor fa et ITL-spor for det kan fortsette. En ITL-oppforing bestar av en transaksjons-ID (XID), angre blokkadresse (UBA), flagger som viser statusen for transaksjon og lasingstelling som gir antall rader som er last av denne transaksjonen. XID identifiserer transaksjonen unikt og gir angre informasjon for den transaksjonen. Folgende figur forklarer forholdet mellom ITL-oppforingene i radene som er last og transaksjonstabellen i rollback-segmentet.

Mens transaksjonen forpligter, fullforer Oracle den bare minste oppgaven den har a gjore siden Oracle er optimalisert for maksimal gjennomstromning. Dette kalles rask commit. Det vil oppdatere statusen for transaksjonen i transaksjonstabellen til rullingssegmentet, og den vil ikke besoke blokken igjen. Sa forpliktet er bare a endre flagget i transaksjonstabell mens de faktiske verdiene som skal endres (dataverdier) allerede er oppdatert ved transaksjon nar den pagikk. I lopet av den tiden transaksjonen pagar, kalles ITL-oppforingen apen ITL. Hvis forekomsten krasjet for transaksjonen er begatt eller tilbakestilt, utfores en transaksjonsgjenoppretting ved hjelp av dataene fra tilbakekallingssegmenter.

Mens en transaksjon pagar og har en apen ITL, vil en annen transaksjon velge dataene, og for a fa konsistent lese (CR), ser 2de transaksjon opp transaksjonstabellen i tilbakeringingssegment for a finne statusen for transaksjonen. Hvis transaksjonen ikke er kommittert, vil den andre transaksjonen opprette en kopi av data som er tilstede i minnet (Denne dataen kan ha blitt endret ved forste transaksjon) og vil bruke angre dataene som er tilstede i tilbakeringingssegmenter for a fa konsistente lesedata. Hvis statusen i transaksjonstabellen viser transaksjonen som forpliktet, anses transaksjonen forpliktet. I sa fall er ikke rekkene lases ved transaksjon, men lasebytta i radhode blir ikke fjernet for neste DML utfores pa blokken. Lasen byte cleanout er piggybacked med DML drift. Blokkrengjoring er piggybacked av noe tidsintervall pa grunn av rask commit. Denne cleanout-operasjonen lukker den apne ITL for forpliktede transaksjoner og genererer omformingsinformasjon, da blokkrengjoring kan inneb re oppdateringsblokk med ny SCN. Dette er grunnen til at vi ser gjenopprettingsgenerering for noen utvalgte uttalelser.

Sa kort nar vi forplikter transaksjonen, blir statusflagget i transaksjonstabell for tilbakeleveringssegment oppdatert og merket at transaksjonen er forpliktet. Neste gang nar en ny DML eller select statement kontrollerer overskriften i datablokker, ser den at disse radene blir oppdaterte, og far ogsa angrepet blokkadresse. Nar den nye transaksjonen sjekker for a angre blokkeringsadressen i transaksjonstabell for tilbakeringingssegment, finner den at transaksjonen er forpliktet (eller rullet tilbake), og den nye transaksjonen oppdaterte blokkhodet og fjerner ogsa lasebyten i radhodet. Dette genererer noen gjenta informasjon.

Haper dette hjelper !!

Oracle Real Application Cluster Handbook & # 8211; Av K. Gopalakrishnan.

Dele denne:

I slekt.

Post navigasjon.

12 tanker om & ldquo; Interessert transaksjonsliste (ITL) & rdquo;

MAXTRANS parameter startende fra 10G er deprecated.Whatever verdi vi satt det er helt ignorert av oracle.

Sa hvis vi setter maxtrans selv 1 ville det ikke fore til at en annen okt opplever noen las.

& # 8220; ITL kan vokse opp til tallet definert av MAXTRANS-parameteren i tabellen, forutsatt at det er plass i blokken. & # 8221;

holder ikke for 10g og over.

Kan du gjerne gi meg en ide i lenken mellom denne transaksjonstabellen, rollback segement jobbet med Commit and rollback og hvordan det er klart a lase & # 8230 ;.

Dette er en flott forklaring pa et komplisert tema. Jeg liker det. Takk for at du deler din kunnskap!

det er en utmerket forklaring pa ITL.

Takk for denne forklaringen & # 8230; Jeg venter svar fra en TAR / SR bare for a fa mengden byte som et ITL-spor tar. Pluss vil dele noe som skjedde da du spilte med INITRANS, synes at opptil 10g2 DB-blokker blir midlertidig odelagt & # 8230; Fortell deg ikke mer, vennligst folg denne linken http://oracledisect.blogspot.com/2009/10/how-to-innocently-corrupt-data-table.html.

Jeg har to sporsmal, som jeg tror er relatert, derfor adresserer jeg begge to i denne ene meldingen.

1) Du skriver & # 8220; Nar samme transaksjon eller en annen laser en annen rad, lagres informasjonen i et annet spor, og sa videre. & # 8221;

– & gt; Dette inneb rer at en transaksjon kan oppdatere mest like mange rader i en blokk som det er tilgjengelige ITL-spor. Dette virker ganske begrenset for meg, og jeg kunne ikke bekrefte det i tilsvarende eksperimenter jeg utforte. Kan du bekrefte om min konklusjon er riktig eller fortell meg hva jeg misforstatt.

2) Du skriver ogsa En ITL-oppforing bestar av en transaksjons-ID (XID), angre blokkadresse (UBA), flagger som viser statusen for transaksjon og lasingstall som gir antall rader som er last av denne transaksjonen. & # 8221;

– & gt; Fra denne setningen forstar jeg at en ITL-oppforing kan lase flere rader. Hvordan er ITL-oppforingen knyttet til radene som er last av denne oppforingen? Et ITL-spor 24 er byte stort, og jeg ser ikke muligheten for at en liste over radider blir lagret i ITL-sporet, sa hvordan holder Oracle oversikt over hvilke rader som er last av et gitt ITL-spor?

Takk for hjelpen.

Jeg har et tillegg til punkt 1) i min kommentar fra 17. februar.

Slik jeg forstar forklaringen ovenfor, kan det til og med fore til en dodlas, hvis en transaksjon prover a oppdatere flere rader enn ITL-spor er tilgjengelige. Anta at det bare er en transaksjon som oppdaterer en blokk, og blokken har nok ledig plass til a holde MAXTRANS ITL-spor. Transaksjonen kan dermed oppdatere MAXTRANS-rader. Nar du prover a oppdatere en annen rad, er det ikke flere ITL-spor tilgjengelig, sa okten ma vente & # 8211; siden alle ITL-sporene er opptatt av samme okt, vil okten vente pa ubestemt tid. Sa jeg er ganske sikker pa at jeg misforstatt noe.

du sa & # 8220; Lasebyte cleanout er piggybacked med DML-operasjon. & # 8221; og & # 8220; Hvis statusen i transaksjonstabell viser transaksjonen som forpliktet, anses transaksjonen forpliktet. & # 8221;

hva skjer hvis en bruker sporrer ett blokk som har en apen ITL i oyeblikket t0, en annen DML-transaksjon ble palagt samme blokk i oyeblikket t -1, blokken er fortsatt i minnet pa grunn av querys, var ikke opprettholdingen satt korrekt og info om den forpliktede transaksjonen er tapt, hvordan oracle vil vite om radene som er modifisert i blokken, er forpliktet (de for hvilke ITL-sporet var apent)?

Er oracle oppdatering av transaksjonsflagget i ITL-sporet hver gang transaksjonen er forpliktet? og bare lasbyten er & # 8220; venter & # 8221; for en DML?

Jeg fikk deg ikke helt her. Men jeg tror du sier hva som vil skje hvis a angre blir overskrevet, og sporringen er a fa tilgang til blokken, har apent ITL-spor som peker pa UNDO.

Vel, i sa fall antar jeg at for du angre blir overskrevet, blir ITL-sporet lukket.

Du nevnte at «Nar den samme transaksjonen eller en annen laser en annen rad, lagres informasjonen i et annet spor, og sa videre betyr det 1 transaksjonen (ordet SAME-transaksjonen)

vil okkupert mer enn en ITL-spor hvis den endrer mer de ene radene i datablokken; Jeg tviler pa det selv om jeg ikke er sa sikker, kan du bekreft?

Jeg hadde det samme sporsmalet nar jeg leser denne artikkelen (se mine sporsmal fra 17. februar og 19. april 2010).

Na vet jeg at en transaksjon bare vil okkupere et ITL-spor i en blokk, uansett hvor mange rader det endrer i den aktuelle blokk. Raden i seg selv inneholder en lasbyte, som er en peker i ITL, som indikerer hvilken ITL-oppforing (og dermed transaksjon) for tiden laser r kken. Du finner en beskrivelse av dette pa http://www.ixora.com.au/q+a/cr.htm eller i den utmerkede boken & # 8220; Oracle Core & # 8221; fra Jonathan Lewis (kapittel 2 og 3).

Tenk deg om det var sant at en transaksjon inntar en ITL-spor per rad, det endrer seg i blokken. En folge av dette ville v re at en transaksjon kan endre maksimalt sa mange rader i en blokk som det er tilgjengelige ITLer. Avhengig av INITRANS / MAXTRANS-verdiene i segmentet og avhengig av hvor full blokken er, kan dette bare v re sv rt fa rader. Dette ville v re en funksjonell begrensning, som jeg tror ikke ville v re akseptabelt for de fleste applikasjoner.

Takk Martin, faktisk gjorde jeg ogsa noen test med blokkdumpen, og det 100% bekreftet en.

transaksjonen opptar kun 1 ITL-spor uavhengig av antall rader som er modifisert.