Oracle Lås &bordslås:Hur det fungerar

Oracle-databasen är den mycket använda databasen inom industrin. Här försöker jag förklara  om orakellås, orakelbordslås

Innehållsförteckning

Vad är Oracle Enqueue och lås

Enqueue är Oracle-lås som serialiserar operationerna till den delade strukturen. Den delade strukturen kan vara tabell, redo-trådar och transaktioner.

När en användare A uppdaterar en rad 12 i tabellen, förvärvar den transaktionen Enqueue (lås). Detta förvärvas så att alla användare som jag försöker uppdatera samma rad 12 i tabellen kommer att vänta tills användaren A genomför transaktionen. Så nu om användare B försöker uppdatera samma rad, kommer den att vänta på kön.

När användaren A genomför transaktionen kommer transaktionen från användare B att fortsätta

Vi har lokal kö i en instansdatabasen medan vi med Oracle RAC har lokal kö och global kö för att hantera den delade resursen

Vad är Enqueue-identifierare

Enqueue identifieras unikt med formatet

Resurs kan

TM -> bordslås

MR-> Mediaåterställning

TX-> Transaktion

Id1 och id2 är nummer som är olika för olika resurstyper

Liksom för tabelllås (TM), skrivs det som

TM--0

När en användare begär åtkomst till resursen i ett visst läge genereras en köidentifierare som förklaras ovan

Kön hålls i dessa lägen

SS:  Raddelningsläge

SX:Rad exklusivt läge

S:  Lås bordet i delningsläge

SSX:Lås tabellen i delningsläge och rad i exklusivt läge

X:Lås bordet i exklusivt läge

Vad är Enqueue-resurs

Varje kö upprätthålls genom en resursstruktur av Oracle-servern och den identifieras enligt beskrivningen ovan. En resursstruktur har tre listor

1. Ägarlista
2. Väntelista
3. Konverterlista

När en användare begär en låsning av resursen i ett visst läge, erhöll den en låsstruktur och den gör en begäran om att skaffa låset på en viss resurs. Det placeras i dessa listor över resursstrukturen enligt det lås som krävs.

Så användaren begär först den resursen, sedan placeras den i ägarlistan

Resursstruktur erhålls från resurstabell och låsstruktur erhålls från låstabell . De är båda allokerade i SGA

Antalet rader i resurstabellen definieras av initialiseringsparametern enqueue_resources. Värdena som används kan ses i v$resursvyn

Antalet rader i låsstrukturtabellen definieras av initialiseringsparametern _enqueue_locks. Värdena som används kan ses i v$enqueue_lock

Hur går sökningen till i resurstabellen?

• Resurstabellen innehåller all resursstruktur. En hashalgoritm används för att hitta och komma åt resursstrukturen i resurstabellen.
• Resurstabellen är ordnad i hash-bucket. Varje hash-bucket innehåller en lista över resursstruktur i länkad listform.

• När resursen söks erhålls dess hash med hjälp av hash-algoritm och sedan erhålls spärren för att hitta motsvarande hash-bucket och sedan söks resursen på listan i hash-bucket. Om resursen hittas erhålls låsstrukturen och begäran placeras på ägare-, servitörs- och omvandlingslistan enligt den angivna låsnivån som begärts

Exempel TM-575-0-resurs hashad till bucket 1, En latch enqueue hashkedja erhålls för att komma åt hash-bucket och listan nås i hinken för att få resursstrukturen

• Om resursen inte hittas i hinklistan och en ny resursstruktur hämtas från resursfri lista och placeras i hinklistan. Detta händer under spärren Enqueue. En låsstruktur tilldelas också

Låsbegäran placeras på resursstrukturens ägarlista

Hur fungerar enqueue operations?

När en användare begär ett lås på resursen gör Oracle-servern följande saker

• Om den inte ägs för närvarande, beviljas resursen till användaren
• Om den ägs och det finns servitörer och konverterare, placeras den längst ner i servitörskön
• Om den ägs men det inte finns någon servitör och omvandlare, om den är kompatibel med ägarlåset, beviljas begäran. Om det inte är kompatibelt placeras det på servitörslistan
• En omvandlare tillåts fortsätta om begäran är mindre restriktiv än det lås som hålls för närvarande eller det begärda läget är kompatibelt med låset som innehas av den andra ägaren
• En servitör tillåts fortsätta om omvandlingslistan är tom, det inte finns några servitörer framför den och det begärda låset är kompatibelt med det lås som det har för närvarande
• Konverteraren bearbetas alltid före servitörerna.
• Oracle-servern kontrollerar dessa köer varje gång låset släpps eller konverteras.

Hur kön kontrolleras när Oracle-låset släpps eller konverteras

• Processer som väntar på resurserna sover på semaforerna, och semaforer används som sömn-/uppvakningsmekanismer. Efter att ha ställt sig i kö i kön, kommer den begärande processen att sova på semaforen med sync_op-anropet.

sync_op(SYNC_WAIT, SYNCF_BINARY, 300) =1

• När processen som innehåller resursen är redo att frigöra resursen, tittar den på kön som är kopplad till resursstrukturen. Om det finns en process i kön skickar den en semaforsignal till vänteprocessen med

sync_op-samtal.

sync_op(0x0005, SYNCF_BINARY, 134491620) =1

• Vänteprocessen kommer att hantera signalen och kommer att vakna. Denna vänteprocess ändrar statusen enligt stegen som ges i ködrift

Vanliga typer av kö

JQ – Jobbkö. När ett jobb (skickat av DBMS_JOB.SUBMIT) körs skyddas det av en JQ-kö (vilket innebär att endast en SNP-process kan köra jobbet).

ST – Space Management Transaction . ST-kön måste hållas varje gång sessionen allokerar/av-allokerar omfattningar (vilket betyder att man vill ändra UET$- och FET$-ordbokstabellerna), som koalescering, släpp/avkorta segment och disksortering. Om sessionen får en timeout när ST-kön begärs, returneras "ORA-1575 timeout som väntar på utrymmeshantering".

TM – DML (tabell)  kö. Varje gång en session vill låsa ett bord, begärs en TM-kö. Om en session tar bort en rad i den överordnade tabellen (DEPT) och en referensrestriktion (främmande nyckel) skapas utan ett index på den underordnade tabellen (EMP), eller om sessionen uppdaterar kolumnen/kolumnerna som den utländska nyckelreferenser till ett delningslås (nivå 4) tas på underordnat bord. Om en annan session försöker göra ändringar i den underordnade tabellen måste de vänta (eftersom de vill ha kön i rad exklusivt läge, och det är inte kompatibelt med delningsläget). Om ett index skapas på den underordnade tabellens främmande nyckelkolumn, krävs inget delningslås på den underordnade tabellen.

Sändning – Transaktion. Så snart en transaktion påbörjas behövs en sändningskö. En transaktion definieras unikt av återställningssegmentets nummer, luckans nummer i återställningssegmentets transaktionstabell och luckans sekvensnummer. En session kan vänta på en TX-kö av flera anledningar:

1) En annan session låser den begärda raden.

2) När två sessioner försöker infoga samma unika nyckel i en tabell (ingen av dem har gjort en COMMIT), väntar den sista sessionen på att den första ska COMMIT eller ROLLBACK.

3) Det finns ingen ledig ITL (Interested Transaction List) i blockhuvudet (öka INI_TRANS och PCT_FREE för segmentet).

UL – Användarlås . En session har låsts med funktionen DBMS_LOCK.REQUEST.

Vyer och tabell för att se Oracle-kö och Oracle-lås

V$session och v$session_wait

När är sessionen väntar på kö eller lås, detta kan vara session från V$session (i 11g och uppåt) och v$session_wait

Välj * från v$session_wait där händelse som 'enq%'; Parametern för enqueue wait-händelsen   har följande betydelseP1:resurstyp och läge wantedP2:ID1 för resursenP3:ID2 för resursen

Vi kan använda nedanstående fråga för att få all kö i systemet

Välj händelse,p1, p2,p3 från v$session_wait  där wait_time=0 och händelse som 'enq%';

1. V$lock är en annan användbar vy för att kontrollera enqueue 's
2. V$lock listar alla låsstrukturer som för närvarande finns i systemet
3. Kolumntypen ,id1 och id2 representerar resurstypen  ,id1 och id2 för resursstrukturen. så att den kan kopplas samman med V$resource som innehåller listan över all resursstruktur

• LMODE och begäran talar om för oss vilken kö (ägare, konverterare, servitörer) som är sessionen

Frågan nedan kan användas för att hitta hållare och servitör

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

I händelse av RAC, kan nedanstående fråga användas för att ta reda på blockerare och servitörer

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

V$locked_object

det är en annan användbar vy för Oracle-bordlås

Den innehåller alla TM-lås i databasen. Det ger transaktionsplatsen, OS-processen och sessions-id för sessionen som håller TM-låsen

Det finns flera vyer som kan användas för att hitta låsinformationen. Dessa vyer skapas av catblock.sql

Fråga för att ta reda på väntande sessioner och hålla sessioner i Oracle 

set linesize 1000column waiting_session heading 'WAITING|SESSION'column holding_session heading 'HOLDING|SESSION'column lock_type format a15column mode_held format a15column mode_requested format a15selectwaiting_session,holding_session,/remd_lock,holding_session,/requehelds,/ 

 Fråga för att ta reda på alla låsta objekt  
 
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 rubrik 'spår|nummer';kolonn ägare_objekt format a35 rubrik 'ägare.objekt';kolumn låst_läge format a13 rubrik 'låst|läge';kolumn status format a8 rubrik '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'/
 
Hur hanteras DML-låsen i Oracle-servern
 

 När en uppdatering, infogar, tar bort eller välj för uppdatering exekveras på Oracle-tabellen, tar Oracle dessa två lås
 
 
DML-tabelllås:För att säkerställa enhetlighet i objektdefinitionen under transaktionens varaktighet. Detta förhindrar att DDL-operationer inträffar medan en DML pågår.
 
DML Row Lock:Detta är för att säkerställa konsistens av data under utförandet av transaktionen. Vi kan omformulera som Detta erhåller ett lås på den specifika raden som berörs och alla andra transaktioner som försöker ändra samma rad blockeras, tills den som redan äger den avslutas
 
 
Hur implementeras Oracle-bordslås
 

 Vi har redan förklarat infrastrukturen för Enqueue i föregående avsnitt. Oracle Table-lås implementeras som TM Enqueue
 

 Så Enqueue struktur skulle vara
 

 TM- -0
 

 Lägen är
 

 RS:raddelning
 

 RX:rad exklusiv
 

 S:dela
 

 SRX:share row exklusiv
 

 X:exklusiv
 

 Varje markör upprätthåller en lista över tabelllåsstrukturen som byggs upp medan uttalandet analyseras. Vid den första exekveringen görs funktionsanrop för att låsa alla tabeller i listan. Låsen släpps när transaktionen genomförs eller återställs.
 

 Möjligheten till återställning, särskilt återställning till en sparad punkt, lägger till ytterligare en dimension av komplexitet till ordbokslåsning. Nämligen, om en transaktion rullas tillbaka efter den punkt då ett lås uppgraderades, måste låset nedgraderas på motsvarande sätt, som en del av återställningsoperationen, för att minska risken för konstgjorda dödlägen.
 

 Kraven på ordbokslåsning för transaktioner och i synnerhet underhållet av en historik av låskonverteringar tillhandahålls av DML-lås i samband med TM-kö. Varje transaktion som har ett DML-lås har också ett TM-kölås. Den grundläggande låsfunktionen tillhandahålls av enqueue, och DML-låset lägger till underhåll av konverteringshistoriken.
 

 Den fasta arrayen av DML-låsstrukturer dimensioneras med parametern DML_LOCKS. Dess gratislista skyddas av dml-låstilldelningsspärren, och de aktiva platserna är synliga i V$LOCKED_OBJECT .
 

 För att ställa in DML_LOCKs kontrollera användningen i v$resource_limit. Vi kan ställa in den generöst eftersom den tar mycket mindre plats
 
Hur inaktiverar man bordslåsen?
 
 
DML-lås och tillhörande TM-kölås kan inaktiveras, antingen helt eller bara för vissa tabeller.
 
För att inaktivera dessa lås helt måste parametern DML_LOCKS sättas till noll. I en parallell serverdatabas måste den vara noll i alla instanser.
 
För att inaktivera sådana lås mot en viss tabell måste DISABLE TABLE LOCKS-satsen i ALTER TABLE-satsen användas.
 
Om lås är inaktiverade för en tabell, kan DML-satser fortfarande ändra tabellens block, och lås på radnivå hålls fortfarande kvar. Emellertid tas inte de underdelade lägestabelllåsen som normalt är associerade med frågor och de subexklusiva lägestabelllåsen som normalt associeras med DML. Istället skyddas transaktioner mot bordet från motstridiga DDL genom att helt enkelt förbjuda alla försök att låsa hela bordet, och därmed all DDL mot bordet.
 
Att inaktivera bordslåsen kan öka prestandan eftersom omkostnader för låsning minskar   Detta är särskilt viktigt i fallet med RAC där denna omkostnad är ganska hög.
 
Att inaktivera tabelllåsen förhindrar också att index för främmande nyckel skapas. Som främmande nyckel måste indexeras för att undvika tabelllåsning av den underordnade tabellen medan raderna manipuleras i den överordnade tabellen. Så om vi inaktiverar tabelllåset tillsammans krävs inga index
 
Det är att föredra att använda alter table för att inaktivera tabelllåsen på vissa tabeller och sedan ställa in till dml_locks-tabellen. Som om dml_locks är inställt på noll måste vi studsa instansen för att ställa in den igen
 
I direktladdningsinfogning tar en session TM-kön i "X"-läge. Detta förhindrar att någon annan DML äger rum medan den direkta laddningen sker, förutom att blockera all DDL
 
 
Hur implementeras DML-radlås
 

 DML Row-lås implementeras som en kombination av följande två saker
 
 
Lås på radnivå:Det implementeras som låsbyte i varje radrubrik och ITL (intresserad transaktionslista) i varje data- eller indexblock. Dessa cachelagras inte någonstans och eftersom de lagras i själva blocket inte i SGA, vilket är begränsat, är den här mekanismen för låsning av oracle enormt skalbar
 
Transaktionslås:Dessa implementeras som TX Enqueue
 
 

 Låsbyten pekar på ITL-posten i blocket och Alla ITL-poster för transaktionen pekar på TX-kön som i slutändan avgör om transaktionen är genomförd eller återställs. Servitörerna väntar på transaktionslåset
 

 Exempel 
 
 
En transaktion A vill uppdatera rad 2 och 3 i blocket. Det kommer att allokera en ITL (intresserad transaktionslista). Transaktionen kommer åt rad 2 och 3 och ser låsbyten. Om låsbyten är noll är den inte låst. Transaktionen kommer att uppdatera rad 3 ,3
 
Nu startar en transaktion B   och den vill uppdatera raderna 1 . Det kommer att allokera en ITL (intresserad transaktionslista). Transaktionen kommer åt rad 1  och ser låsbyten. Om låsbyten är noll är den inte låst. Transaktionen uppdaterar rad 1
 
Nu vill transaktionen uppdatera rad 2. Den kommer åt raden och hittar den låst eftersom låsbyten inte kommer att vara noll. Det kommer att se i ITL som håller låset. Den kommer att utföra ITL-rensning för att ta reda på om transaktionen är aktiv eller inte. I det här fallet kommer Transaktion A att vara aktiv. Så transaktion B måste vänta på transaktion A för att återställa eller begå. Transaktionen B kommer att vänta på att kräva sändningskön som transaktionen A håller i exklusivt läge
 
  
Vad är intressetransaktionslista (ITL)
 

 När en session vill modifiera ett block måste den allokera en ITL i blocket. ITL är datastrukturen i blockhuvudet som innehåller många luckor som tas av transaktionen. Den definieras av parametern INITRANS och MAXTRANS när tabellen skapas. Initialt antal platser skapas enligt INITTRANS och de växer dynamiskt till maximalt MAXTRANS
 
Vad är transaktion?
 

 När en session uppdaterar /delete/insert  , startas en transaktion. Den är klar när commit eller rollback inträffade. En transaktion identifieras med transaktionsidentifierare (XID). Transaktionen identifierar består av tre delar
 
 
Återställ eller ångra segmentnummer
 
Transaktionstabell Slotnummer
 
Sekvens eller radbrytning nej
 
 

 XID=usn#.slot#.wrap#
 

 Varje block ITL kommer att innehålla XID
 

 En ITL-rensning innebär att leta efter XID i ITL:n och söka efter återställningssegmenten baserat på detta och leta efter transaktionstabellen och radbrytningsnumret för att kontrollera transaktionens aktivitet.
 

 Vi kan använda kommandot nedan för att dumpa alla återställningssegment
 

 Ändra systemdump ångra rubrik <ångra segmentnamn>;
 

 Varje aktiv transaktion kan ses i v$transaktionstabellen
 
välj addr, xidusn, xidslot, xidsqnfrom v$transaction;ADDR         XIDUSN    XIDSLOT     XIDSQN-------- ---------- ---------- --- -------3C485875         50         5      3000
 

 Transaktionsidentifieraren (XID) kan också erhållas i den egna sessionen med
 
välj dbms_transaction.local_transaction_id från dual;
 

 Väntan på TX enq kommer att ses i v$session_wait
 

 P1:Namn|läge
 

 P2:rbs3|wrap#
 

 P3:plats#
 

 För att sammanfatta DML-radlåsen 
 

 Den första DML i en session där en transaktion inte redan existerar kommer implicit att skapa en transaktion.
 
 
Ett ångra segmentnummer, plats och radbrytning kommer att tilldelas
 
Sändningskö kommer att instansieras
 
 

 När en rad som ska modifieras identifieras, kommer sessionen att ta en post i ITL för datablocket, tilldela den till transaktionen
 
 
USN/SLOT/WRAP kommer att skrivas till ITL-fack och reserverar den platsen för den aktuella transaktionen
 
Lås kommer att tas på raden genom att ställa in låsbyten i radkatalogen så att den pekar på den aktuella transaktionens ITL-plats
 
 

 Både TM- och TX-kön kan ses i V$lock 
 
 
Typen identifierar TM eller TX
 
ID1 och ID2 kan innehålla ytterligare information, men är kontextkänsliga med avseende på köTYP
 
För TM-kö är ID1 OBJECT_ID för objektet som låses, vilket kan refereras till i DBA_OBJECTS, och ID2 är alltid 0
 
För TX Enqueue, ID1 och ID2 innehåller ångra segmentnummer, platsnummer och wrap
 
 
Detaljerat exempel för att förklara orakellåsen som fungerar
 
 
 
Skapa dummy-tabellen
 
 
Skapa tabell från j som välj * från dba_objects där rownum <3;Tabell skapad Skapa tabell från j1 som välj * från dba_objects där rownum <3;Tabell skapad
 
 
Session A
 
 
Välj * från j för uppdatering;
 

 Låt oss se vad som finns i v$lock
 
SQL> välj distinkt sida från v$mystat; SID----------2125SQL> välj * från v$lock där sid=2125;ADDR             KADDR                  SID TY        ID1        ID2      LMODE---------------- --- ------------- ---------- -- ---------- ---------- ----- ----- Begär CTIME-block ---------- ---------- ---------- 00000006B5D9D0D0 00000006B5D9D148 2125 TX 2883613 16425600 60 44 0FFFFFFFFFF7DA4B360 FFFFFFFFF7DA4B3C0 2125 TM 21488781          0          30         44          0
 

 Så vi ser här
 

 DML Oracle-bordlås skapas
 

 TX (transaktionslås) skapas
 
 
Låt oss börja session B
 
 
SQL>Välj * från j1 för uppdatering;SQL> välj distinkt sida från v$mystat; SID----------2302SQL> välj * från v$lock där sid=2302;ADDR             KADDR                  SID TY        ID1        ID2      LMODE---------------- --- ------------- ---------- -- ---------- ---------- ----- ----- Begär CTIME-block ---------- ---------- ---------- 00000006F7FF910 00000006F7FF988 2302 TX 2949148 16884039 60 10 0FFFFFFFF7DA4B360 FFFFFFFFF7DA4B3C0 2302 TM 33544 0 30 10 000000006DC289D60 00000006DC289DB8 2302 AE 15062272 0 40 106 0 
 

 Så vi ser här
 

 DML-tabelllås skapas
 

 TX (transaktionslås) skapas
 

 Nu ska vi försöka göra
 
Välj * från j för uppdatering;
 

 Detta kommer att hänga sig
 
 
Låt starta en ny session för att analysera problemet
 
 

 Om du ser sessionen sid =2032 detaljer i V$lock
 
välj * från v$lock där sid=2302;ADDR             KADDR                   SID TY        ID1        ID2      LMODE---------------- ------------- --- ---------- -- ---------- ---------- ----------BEGÄRAN      CTIME      BLOCKERA-- -------- ---------- ---------- FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0 2302 TM 33544 0 30 47 000000006DC289D60 0000006DC289DB8 2302 AE 150622272 0 40 143 0           6          7          0 FFFFFFFF7DA4B360 FFFFFFFF7DA4B3C0       2302 TM   21488781          0          30          7           0
 

 Den fetstilta raden är begäran 6 (exklusivt lås ) på vissa TX enq
 

 Nu kan vi använda nedanstående fråga för att hitta blockeringssessionen
 
välj l1.sid, ' BLOCKERAR ', l2.sidfrån v$lock l1, v$lock l2där l1.block =1 och l2.request> 0och l1.id1=l2.id1and l1.id2=l2.id2SID 'ISBLOCKAR'         SID------------ -------------- ----------2125  BLOCKERAR        2302
 

 Nu kan vi utföra eller återställa sessionen 2125 för att transaktion B ska fortsätta. Vi kan döda session 2125 genom att använda kommandot nedan också för att släppa låset
 
Ändra systemavbrytningssession '2125,';
 

 Mer ytterligare information 
 

 TX-låsen i v$lock talar inte om för radinformationen var påståendet finns. Vi kan se dessa saker med hjälp av frågorna
 

 Frågan nedan måste köras från sessionen som väntar
 
SQL> välj row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#från v$session där sid=2302ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_-ROW# ---------------- ---------- --------------- -------------21488781            461           81063             0 välj 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älj * från j där rowid =' ABR+SNAHNAAATynAAA';
 

 Relaterade artiklar 
 

 Så fungerar Oracle-låsning
Hur man hittar sessionsdetaljer i Oracle-databasen
Viktig databashälsokontroll
oracle-appar dba intervjufrågor
Frågor för att kontrollera lås i Oracle-databasen
oracle dba intervjufrågor
 
Rekommenderade kurser
 

 Följande är några av de rekommenderade kurserna du kan köpa om du vill ta ett steg längre 
 

 Nedan ges länkarna till några av kurserna 
 

 
Oracle DBA 11g/12c – Databasadministration för Junior DBA  :Den här kursen är bra för personer som börjar som Junior DBA eller strävar efter att bli Oracle DBA. Detta ger en god förståelse för säkerhetskopiering och återställning och allmänna administrationsuppgifter
Oracle Database:Oracle 12C R2 RAC Administration  :Den här kursen täcker installation, administration av Oracle RAC. En bra kurs för Oracle DBA som vill uppgradera sina kunskaper för Oracle RAC
Oracle Data Guard:Database Administration for Oracle 12C R2  :Den här kursen täcker installation, administration av Oracle Dataguard. En bra kurs för Oracle DBA som vill uppgradera sina kunskaper för Oracle Dataguard