Oracle-låse og bordlåse:Sådan fungerer det

Oracle-database er den meget brugte database i industrien. Her forsøger jeg at forklare  om oracle-låse, oracle-bordlåse

Indholdsfortegnelse

Hvad er Oracle Enqueue og låse

Enqueue er Oracle-låse, som serialiserer operationerne til den delte struktur. Den delte struktur kunne være tabel, gentag tråde og transaktioner.

Når en bruger A opdaterer en række 12 i tabellen, erhverver den transaktionen Enqueue (lås). Dette er erhvervet, så enhver bruger, som jeg forsøger at opdatere den samme række 12 i tabellen, vil vente, indtil brugeren A begår transaktionen. Så nu, hvis bruger B forsøger at opdatere den samme række, vil den vente på køen.

Når bruger A forpligter transaktionen, fortsætter bruger B transaktion

Vi har lokal kø i enkeltinstansdatabasen, mens vi med Oracle RAC har lokal kø og global kø til at administrere den delte ressource

Hvad er Enqueue identifier

Enqueue identificeres entydigt ved hjælp af formatet

Ressource kan

TM -> bordlåse

MR-> Mediegendannelse

TX-> Transaktion

Id1 og id2 er tal, der er forskellige for forskellige ressourcetyper

Ligesom for table lock (TM) skrives det som

TM--0

Når en bruger anmoder om adgang til ressourcen i en bestemt tilstand, genereres en kø-id, som forklaret ovenfor

Kø holdes i disse tilstande

SS:  Rækkedelingstilstand

SX:Rækkeeksklusiv tilstand

S:  Lås bordet i deletilstand

SSX:Lås tabellen i deletilstand og række i eksklusiv tilstand

X:Lås bordet i eksklusiv tilstand

Hvad er Enqueue-ressource

Hver kø vedligeholdes gennem en ressourcestruktur af Oracle-serveren, og den identificeres som forklaret ovenfor. En ressourcestruktur har tre lister

1. Ejerliste
2. Venteliste
3. Konverterliste

Når en bruger anmoder om en lås på ressource i en bestemt tilstand, opnåede den en låsestruktur, og den fremsender en anmodning om at erhverve låsen på en bestemt ressource. Det er placeret på disse lister over ressourcestrukturen i henhold til den påkrævede lås.

Så brugeren   anmoder først om den ressource, og derefter placeres den på ejerlisten

Ressourcestruktur er hentet fra ressourcetabel og låsestruktur er hentet fra låstabel . De er begge allokeret i SGA

Antallet af rækker i ressourcetabellen er defineret af initialiseringsparameteren enqueue_resources. Værdierne i brug kan ses i v$ressourcevisning

Antallet af rækker i låsestrukturtabellen er defineret af initialiseringsparameteren _enqueue_locks. Værdierne i brug kan ses i v$enqueue_lock

Hvordan udføres opslaget i ressourcetabellen?

• Ressourcetabellen indeholder hele ressourcestrukturen. En hashing-algoritme bruges til at finde og få adgang til ressourcestrukturen i ressourcetabellen.
• Ressourcetabellen er arrangeret i hash-bucket. Hver hash-bucket indeholder en liste over ressourcestruktur i linket listeform.

• Når ressourcen søges, opnås dens hash ved hjælp af hash-algoritme, og derefter opnås låsen for at finde den tilsvarende hash-bucket, og derefter søges ressourcen på listen i hash-bucket. Hvis ressourcen findes, opnås låsestruktur, og anmodningen placeres på ejer-, tjener- og konverterlisten i henhold til det angivne låseniveau.

Eksempel TM-575-0 ressource hashed til bucket 1, En låsende enqueue hash kæde er opnået for at få adgang til hash bucket og listen tilgås i bucket for at få ressourcestrukturen

• Hvis ressourcen ikke findes i bucketlisten, og en ny ressourcestruktur hentes fra ressourcefri liste og placeres i bucketlisten. Dette sker under låsen Enqueue. Der er også tildelt en låsestruktur

Låseanmodningen placeres på ejerlisten for ressourcestrukturen

Hvordan fungerer kø-operationer?

Når en bruger anmoder om en lås på ressourcen, udfører Oracle-serveren følgende ting

• Hvis den ikke ejes i øjeblikket, tildeles ressourcen til brugeren
• Hvis den er ejet, og der er tjenere og konverter, så placeres den nederst i tjenerkøen
• Hvis den ejes, men der ikke er nogen tjener og konverter, så imødekommes anmodningen, hvis den er kompatibel med ejerlåsen. Hvis det ikke er kompatibelt, placeres det på tjenerlisten
• En konverter har tilladelse til at fortsætte, hvis anmodningen er mindre restriktiv end den lås, der holdes i øjeblikket, eller den anmodede tilstand er kompatibel med den lås, som den anden ejer har
• En tjener har lov til at fortsætte, hvis konverterlisten er tom, der ikke er nogen tjenere foran den, og den anmodede lås er kompatibel med den lås, den har i øjeblikket
• Konverteren behandles altid før tjenerne.
• Oracle-serveren tjekker disse køer, hver gang låsen frigives eller konverteres.

Hvordan køen kontrolleres, når Oracle-låsen frigives eller konverteres

• Processer, der venter på, at ressourcerne sover på semaforerne, og semaforer bruges som søvn-/opvågningsmekanismer. Efter at have stået i kø i køen, vil anmodningsprocessen sove på semaforen ved hjælp af sync_op-kaldet.

sync_op(SYNC_WAIT, SYNCF_BINARY, 300) =1

• Når processen, der holder ressourcen, er klar til at frigive ressourcen, ser den på køen knyttet til ressourcestrukturen. Hvis der er en proces i køen, sender den et semaforsignal til venteprocessen ved hjælp af

sync_op-opkald.

sync_op(0x0005, SYNCF_BINARY, 134491620) =1

• Venteprocessen håndterer signalet og vågner. Denne venteproces ændrer status i henhold til trinene givet i kødrift

Almindelige typer kø

JQ – Jobkø. Når et job (indsendt af DBMS_JOB.SUBMIT) kører, er det beskyttet af en JQ-kø (hvilket betyder, at kun én SNP-proces kan køre jobbet).

ST – Space management Transaction . ST-køen skal afholdes, hver gang sessionen tildeler/af-allokerer omfang (hvilket betyder ønsker at ændre UET$- og FET$-ordbogstabellerne), som f.eks. koalescing, drop/truncate segmenter og disk-sortering. Hvis sessionen får en timeout, når der anmodes om ST-køen, returneres "ORA-1575 timeout venter på pladsstyring".

TM – DML (tabel)  kø. Hver gang en session ønsker at låse et bord, anmodes der om en TM-kø. Hvis en session sletter en række i den overordnede tabel (DEPT), og der oprettes en referentiel begrænsning (fremmednøgle) uden et indeks på den underordnede tabel (EMP), eller hvis sessionen opdaterer den eller de kolonner, som den fremmede nøglereferencer til derefter en delingslås (niveau 4)  optages på det underordnede bord. Hvis en anden session forsøger at foretage ændringer i børnebordet, må de vente (fordi de vil have køen i rækkeeksklusiv tilstand, og det er ikke kompatibelt med deletilstanden). Hvis der oprettes et indeks på børnetabellens fremmednøglekolonne, kræves der ingen delelås på børnetabellen.

TX – Transaktion. Så snart en transaktion er startet, er en TX-kø nødvendig. En transaktion er entydigt defineret af rollback segmentnummeret, slotnummeret i rollbacksegmentets transaktionstabel og slotnummerets sekvensnummer. En session kan vente på en TX-kø af flere årsager:

1) En anden session låser den anmodede række.

2) Når to sessioner forsøger at indsætte den samme unikke nøgle i en tabel (ingen af ​​dem har lavet en COMMIT), så venter den sidste session på, at den første skal COMMIT eller ROLLBACK.

3) Der er ingen ledig ITL (Interested Transaction List) i blokoverskriften (øg INI_TRANS og PCT_FREE for segmentet).

UL – Brugerlås . En session har låst med DBMS_LOCK.REQUEST-funktionen.

Visninger og tabel for at se Oracle-kø og Oracle-låse

V$session og v$session_wait

Hvornår er session venter på kø eller lås, dette kan være session fra V$session (i 11g og derover) og v$session_wait

Vælg * fra v$session_wait, hvor hændelse som 'enq%'; Parameteren for enqueue wait-hændelsen   har følgende betydningP1:ressourcetype og mode wantedP2:ID1 for ressourceP3:ID2 for ressourcen

Vi kan bruge nedenstående forespørgsel til at få hele køen i systemet

Vælg begivenhed,p1, p2,p3 fra v$session_wait  hvor wait_time=0 og begivenhed som 'enq%';

1. V$lock er en anden nyttig visning til at kontrollere køen 's
2. V$lock liste over alle de låsestrukturer, der i øjeblikket findes i systemet
3. Kolonnetypen ,id1 og id2 repræsenterer ressourcetypen  ,id1 og id2 for ressourcestrukturen.så den kan forbindes med V$resource, som indeholder listen over hele ressourcestrukturen

• LMODE og anmodning fortæller os, hvilken kø (ejer, konverter, tjenere) der er sessionen

Nedenstående forespørgsel kan bruges til at finde holder og tjener

SELECT inst_id,DECODE(request,0,'Holder:','Tjener:')||sid sess,id1, id2, lmode, request, typeFROM V$LOCKWHERE (id1, id2, type) IN(SELECT id1 , id2, skriv FRA V$LOCK WHERE request>0)ORDER BY id1, request;

I tilfælde af RAC kan nedenstående forespørgsel bruges til at finde ud af blokkere og tjenere

SELECT inst_id,DECODE(request,0,'Holder:','Tjener:')||sid sess,id1, id2, lmode, request, typeFROM GV$LOCKWHERE (id1, id2, type) IN(SELECT id1 , id2, skriv FRA gV$LOCK WHERE request>0)ORDER BY id1, request;

V$locked_object

det er en anden nyttig visning til Oracle-bordlåse

Den indeholder alle TM-låsene i databasen. Det giver transaktionspladsen, OS-processen og sessions-id'et for den session, som holder TM-låsene

Der er flere visninger, som kan bruges til at finde låseoplysningerne. Disse visninger er skabt af catblock.sql

Forespørgsel for at finde ud af ventesession og afholdelse af sessioner i Oracle 

indstil linjestørrelse 1000column waiting_session heading 'WAITING|SESSION'column holding_session overskrift 'HOLDING|SESSION'column lock_type format a15column mode_held format a15column mode_requested format a15selectwaiting_session,holding_session,/requeheld_15selectwaiting_session,holding_session,/requeheld_2 

 Forespørgsel for at finde ud af alle de låste objekter  
 
set term on;set lines 130;column sid_ser format a12 heading 'session,|serial#';column username format a12 heading 'os user/|db user';column process format a9 heading 'os|process';column spid format a7 overskrift 'trace|number';column owner_object format a35 heading 'owner.object';column locked_mode format a13 heading 'locked|mode';column status format a8 heading 'status';selectsubstr(to_char(l.session_id)| |','||to_char(s.serial#),1,12) sid_ser,substr(l.os_user_name||'/'||l.oracle_username,1,12) username,l.process,p.spid, substr(o.owner||'.'||o.object_name,1,35) owner_object,decode(l.locked_mode,1,'No Lock',2,'Row Share',3,'Row Exclusive',4 ,'Share',5,'Share Row Excl',6,'Exclusive',null) locked_mode,substr(s.status,1,8) statusfromv$locked_object l,all_objects     o,v$session       s,v$process       pwherel .object_id =o.object_idand l.session_id =s.sidand s.paddr      =p.addrand s.status !='KILLED'/
 
Hvordan DML-låsene håndteres i Oracle-serveren
 

 Når en opdatering, indsætter, sletter eller vælger til opdatering udføres på Oracle-tabellen, tager Oracle disse to låse
 
 
DML-tabellås:For at sikre ensartet objektdefinition under transaktionens varighed. Dette forhindrer, at DDL-handlinger finder sted, mens en DML er i gang.
 
DML Row Lock:Dette er for at sikre konsistens af dataene under udførelsen af ​​transaktionen. Vi kan omformulere som Dette opnår en lås på den bestemte række, der berøres, og enhver anden transaktion, der forsøger at ændre den samme række, bliver blokeret, indtil den, der allerede ejer den, afsluttes
 
 
Sådan implementeres Oracle-bordlåse
 

 Vi har allerede forklaret infrastrukturen for Enqueue i forrige afsnit. Oracle Table-låse er implementeret som TM Enqueue
 

 Så Enqueue struktur ville være
 

 TM- -0
 

 Tilstande er
 

 RS:rækkedeling
 

 RX:række eksklusiv
 

 S:del
 

 SRX:eksklusiv delerække
 

 X:eksklusiv
 

 Hver markør vedligeholder en liste over tabellåsstruktur, som bygges, mens sætningen analyseres. Ved den første udførelse foretages funktionskald for at låse alle tabellen på listen. Låsene frigives, når transaktionen forpligtes eller rollback.
 

 Muligheden for rollback, især rollback til et lagringspunkt, tilføjer endnu en kompleksitetsdimension til ordbogslåsning. Nemlig, hvis en transaktion rulles tilbage ud over det punkt, hvor en lås blev opgraderet, så skal låsen nedgraderes tilsvarende, som en del af rollback-operationen, for at mindske risikoen for kunstige deadlocks.
 

 Kravene til ordbogslåsning til transaktioner og i særdeleshed vedligeholdelsen af ​​en historik for låsekonverteringer stilles til rådighed af DML-låse i forbindelse med TM-enqueue. Hver transaktion, der har en DML-lås, har også en TM-kølås. Den grundlæggende låsefunktionalitet leveres af køen, og DML-låsen tilføjer vedligeholdelsen af ​​konverteringshistorikken.
 

 Det faste array af DML-låsestrukturer er dimensioneret efter parameteren DML_LOCKS. Dens gratis liste er beskyttet af dml-låstildelingslåsen, og de aktive slots er synlige i V$LOCKED_OBJECT .
 

 For at indstille DML_LOCK'erne skal du kontrollere udnyttelsen i v$resource_limit. Vi kan indstille den generøst, da den tager meget mindre plads
 
Hvordan deaktiverer man bordlåsene?
 
 
DML-låse og de tilhørende TM-kølåse kan deaktiveres, enten helt eller kun for bestemte tabeller.
 
For at deaktivere disse låse helt skal parameteren DML_LOCKS sættes til nul. I en parallel serverdatabase skal den sættes til nul i alle tilfælde.
 
For at deaktivere sådanne låse mod en bestemt tabel, skal DISABLE TABLE LOCKS-sætningen i ALTER TABLE-sætningen bruges.
 
Hvis låse er deaktiveret for en tabel, kan DML-sætninger stadig ændre tabellens blokke, og låse på rækkeniveau holdes stadig. De underdelte tilstandstabellåse, der normalt er knyttet til forespørgsler, og de subeksklusive tilstandstabellåse, der normalt er knyttet til DML, tages dog ikke. I stedet er transaktioner mod bordet beskyttet mod modstridende DDL ved blot at forbyde alle forsøg på at tage en lås på hele bordet, og dermed alle DDL mod bordet.
 
Deaktivering af bordlåsene kan øge ydeevnen, da overhead til låseanskaffelse reduceres   Dette er især vigtigt i tilfælde af RAC, hvor denne overhead er ret høj.
 
Deaktivering af tabellåse forhindrer også oprettelse af fremmednøgleindekser. Som fremmednøgle skal indekseres for at undgå tabellås af den underordnede tabel, mens rækkerne manipuleres i den overordnede tabel. Så hvis vi deaktiverer tabellås alle sammen, er indekser ikke nødvendige
 
Det er at foretrække at bruge alter table for at deaktivere tabellåsene på en eller anden tabel og derefter sætte til dml_locks table. Som om dml_locks er sat til nul, bliver vi nødt til at hoppe instansen for at indstille den igen
 
I direkte indlæsningsindsættelse vil en session tage TM-køen i 'X'-tilstand. Dette forhindrer enhver anden DML i at finde sted, mens den direkte indlæsning sker, ud over at blokere al DDL
 
 
Hvordan DML rækkelåse implementeres
 

 DML Row-låse implementeres som en kombination af følgende to ting
 
 
Lås på rækkeniveau:Den implementeres som låsebyte i hver rækkeoverskrift og ITL (interesserede transaktionsliste) i hver data- eller indeksblok. Disse cachelagres ikke nogen steder  og da de er gemt i selve blokken ikke i SGA, som er begrænset, er denne mekanisme til Locking by oracle massivt skalerbar
 
Transaktionslåse:Disse implementeres som TX Enqueue
 
 

 Låsebyten peger på ITL-posten i blokken, og Alle ITL-poster for transaktionen peger på TX-køen, som i sidste ende bestemmer, om transaktionen er begået eller tilbagerulning. Tjenerne vil vente på transaktionslås
 

 Eksempel 
 
 
En transaktion A ønsker at opdatere række 2 og 3 i blokken. Det vil allokere en ITL (interesserede transaktionsliste). Transaktionen får adgang til række 2 og 3 og ser låsebyten. Hvis låsebyten er  nul, er den ikke låst. Transaktionen vil opdatere række 3 ,3
 
Nu starter en transaktion B  , og den vil opdatere rækkerne 1 . Det vil allokere en ITL (interesserede transaktionsliste). Transaktionen får adgang til række 1  og ser låsebyten . Hvis låsebyten er  nul, er den ikke låst. Transaktionen opdaterer række 1
 
Nu vil transaktionen opdatere række 2. Den vil få adgang til rækken og vil finde den låst, da låsebyte ikke vil være nul. Det vil se i ITL, som holder låsen. Det vil udføre ITL-rensning for at finde ud af, om transaktionen er aktiv eller ikke aktiv. I dette tilfælde vil den finde Transaktion A aktiv. Så transaktion B skal vente på transaktion A for at rulle tilbage eller forpligte sig. Transaktionen B vil vente på at kræve den TX-kø, som transaktionen A holder i eksklusiv tilstand
 
  
Hvad er interessetransaktionsliste(ITL)
 

 Når en session ønsker at ændre en blok, skal den allokere en ITL i blokken. ITL er datastrukturen i blokoverskriften, som indeholder mange slots, som tages af transaktionen. Den defineres af parameteren INITRANS og MAXTRANS, når tabellen oprettes. Det første antal slots oprettes i henhold til INITTRANS, og de vokser dynamisk til det maksimale antal MAXTRANS
 
Hvad er transaktion?
 

 Når en session opdaterer /delete/insert , startes en transaktion. Den er fuldført, når forpligtelsen eller tilbagerulningen skete. En transaktion identificeres ved hjælp af transaktions-id (XID). Transaktionen identificerer består af tre dele
 
 
Rulning eller fortryd segmentnummer
 
Transaktionstabel Slotnummer
 
Sekvens eller wrap no
 
 

 XID=usn#.slot#.wrap#
 

 Hver blok ITL vil indeholde XID'et
 

 En ITL-oprydning betyder at lede efter XID'et i ITL'en og søge i rollback-segmenterne baseret på dette og søge efter transaktionstabellen og wrap-nummeret for at kontrollere transaktionens aktivitet.
 

 Vi kan bruge nedenstående kommando til at dumpe ethvert rollback-segment
 

 Ændre systemdump fortryd header ;
 

 Hver aktiv transaktion kan ses i v$transaktionstabel
 
vælg addr, xidusn, xidslot, xidsqnfrom v$transaction;ADDR         XIDUSN    XIDSLOT     XIDSQN-------- ---------- ---------- --- -------3C485875         50         5      3000
 

 Transaktionsidentifikationen (XID) kan også fås i den egen session ved hjælp af
 
vælg dbms_transaction.local_transaction_id fra dual;
 

 Ventetiden på TX enq vil blive set i v$session_wait
 

 P1:Navn|tilstand
 

 P2:rbs3|wrap#
 

 P3:slot#
 

 For at opsummere DML-rækkelåsene 
 

 Den første DML i en session, hvor en transaktion ikke allerede eksisterer, vil implicit oprette en transaktion.
 
 
Et fortryd segmentnummer, slot og wrap vil blive tildelt
 
TX-kø vil blive instantieret
 
 

 Når en række, der skal ændres, er identificeret, vil sessionen tage en indtastning i ITL for datablokken, tildele den til transaktionen
 
 
USN/SLOT/WRAP vil blive skrevet til ITL-slot, og denne plads reserveres til den aktuelle transaktion
 
Lås vil blive taget på rækken ved at indstille låsebyten i rækkebiblioteket til at pege på den aktuelle transaktions ITL-slot
 
 

 Både TM- og TX-køen kan ses i V$lock 
 
 
Typen identificerer TM eller TX
 
ID1 og ID2 kan indeholde yderligere oplysninger, men er kontekstafhængige med hensyn til kø-TYPE
 
For TM-kø er ID1 OBJECT_ID for det objekt, der låses, som der kan refereres til i DBA_OBJECTS, og ID2 er altid 0
 
For TX Enqueue holder ID1 og ID2 fortryd segmentnummeret, slotnummeret og ombrydningen
 
 
Detaljeret eksempel for at forklare orakellåsene, der fungerer
 
 
 
Opret dummy-tabellen
 
 
Opret tabel fra j som vælg * fra dba_objects hvor rownum <3;Tabel oprettet Opret tabel fra j1 som vælg * fra dba_objects hvor rownum <3;Tabel oprettet
 
 
Session A
 
 
Vælg * fra j for opdatering;
 

 Lad os se, hvad der er til stede i v$lock
 
SQL> vælg særskilt side fra v$mystat; SID----------2125SQL> vælg * fra v$lock hvor sid=2125;ADDR             KADDR                  SID TY         ID1        ID2      LMODE---------------- --- ------------- ---------- -- ---------- ---------- ----- ----- Anmod om CTIME BLOCK ---------- ---------- ---------- 00000006B5D9D0D0 00000006B5D9D148 2125 TX 2883613 16425600 60 44 0FFFFFFF7DA4B360 FFFFFFFF7DA4B3C0 2125 TM 21488781          0          30         44          0
 

 Så vi ser her
 

 DML Oracle bordlås er oprettet
 

 TX (transaktionslås) er oprettet
 
 
Lad os starte session B
 
 
SQL>Vælg * fra j1 for opdatering;SQL> vælg særskilt side fra v$mystat; SID----------2302SQL> vælg * fra v$lock hvor sid=2302;ADDR             KADDR                  SID TY         ID1        ID2      LMODE---------------- --- ------------- ---------- -- ---------- ---------- ----- ----- Anmod om CTIME BLOCK ---------- ---------- ---------- 00000006AF7FF910 00000006AF7FF988 2302 TX 2949148 16884039 60 10 0FFFFFFF7DA4B360 FFFFFFF7DA4B3C0 2302 TM 33544 0 30 10 000000006DC289D60 00000006DC289DB8 2302 AE 15062272 0 40 106 0 
 

 Så vi ser her
 

 DML tabellås er oprettet
 

 TX (transaktionslås) er oprettet
 

 Lad os nu prøve at gøre
 
Vælg * fra j for opdatering;
 

 Dette vil hænge
 
 
Lad en ny session starte for at analysere problemet
 
 

 Hvis  du ser sessionen sid =2032 detaljer i V$lock
 
vælg * fra v$lock hvor sid=2302;ADDR             KADDR                   SID TY        ID1        ID2      LMODE---------------- ------------- --- ---------- -- ---------- ---------- ----------ANMODNING      CTIME      BLOKER-- -------- ---------- ---------- FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0 2302 TM 33544 0 30 47 000000006DC289D60 00000006DC289DB8 2302 AE 15062272 0 40 143 0  00000006dc289808 0000 000006060606060400 2302 TX    2883613   16425600          0          6          7          0 FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM   21488781          0          30          7           0
 

 Den fede række er anmodning 6 (eksklusiv lås ) på nogle TX enq
 

 Nu kan vi bruge nedenstående forespørgsel til at finde blokeringssessionen
 
vælg l1.sid, ' BLOKKERER ', l2.sid fra v$lock l1, v$lock l2hvor l1.block =1 og l2.request> 0og l1.id1=l2.id1and l1.id2=l2.id2SID 'ISBLOKERER'         SID------------ -------------- ----------2125  BLOKKERER        2302
 

 Nu kan vi commit eller rollback session 2125 for at transaktion B kan fortsætte. Vi kan dræbe session 2125 ved at bruge nedenstående kommando også for at frigive låsen
 
Alter system kill-session '2125,';
 

 Nogle flere yderligere oplysninger 
 

 TX-låsene i v$lock fortæller ikke rækkeoplysningerne, hvor striden er til stede. Vi kan se disse ting ved hjælp af forespørgslerne
 

 Nedenstående forespørgsel skal udføres fra den session, som  venter
 
SQL> vælg row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#fra v$session hvor sid=2302ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_--------------------- ---------- --------------- -------------21488781            461           81063             0 vælg do.object_name,row_wait_obj#, row_wait_file #; OBJECT_NAME ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# DBMS_ROWID.ROWID_C------------- -------------------- ----------- -------------- ------------------J21488781            461           81063             0 ABR+SNAHNAAATynAAA SQL> Vælg * fra j hvor rowid =' ABR+SNAHNAAATynAAA';
 

 Relaterede artikler 
 

 Sådan fungerer Oracle-låsning
Sådan finder du sessionsdetaljer i Oracle-databasen
Vigtigt databasesundhedstjek
oracle-apps dba-interviewspørgsmål
Forespørgsler til at kontrollere låse i Oracle-databasen
oracle dba interviewspørgsmål
 
Anbefalede  kurser
 

 Følgende er nogle af de anbefalede kurser, du kan købe, hvis du ønsker at komme et skridt videre 
 

 Givet nedenfor er links til nogle af kurserne 
 

 
Oracle DBA 11g/12c – Databaseadministration for Junior DBA  :Dette kursus er godt for de mennesker, der starter som Junior DBA eller ønsker at blive Oracle DBA. Dette vil give en god forståelse af backup og gendannelse og generelle administrationsopgaver
Oracle Database:Oracle 12C R2 RAC Administration  :Dette kursus dækker installation, administration af Oracle RAC. Et godt kursus for Oracle DBA, der ønsker at opgradere sine færdigheder til Oracle RAC
Oracle Data Guard:Database Administration for Oracle 12C R2  :Dette kursus dækker installation og administration af Oracle Dataguard. Et godt kursus for Oracle DBA, der ønsker at opgradere sine kompetencer til Oracle Dataguard