| CATEGORII DOCUMENTE |
Arhitectura Oracle include un numar de componente primare:
Oracle server: un numar de fisiere, procese, structuri de memorie folosite pentru a procesa instructiuni SQL, pentru a imbunatatii performanta bazei de date, pentru a asigura recuperarea in cazul unei erori software sau hardware, ori pentru a realiza o serie de alte sarcini necesare pentru a intretine baza de date.
Instanta Oracle: o combinatie intre procesele de fundal si structurile de memorie. Pentru a putea accesa datele din baza instanta Oracle trebuie pornita. De fiecare data cand o instanta este pornita este alocata System Global Area si sunt pornite procesele de fundal. Aceste procese de fundal realizeaza operatii de intrare/iesire si monitorizeaza alte procese Oracle pentru a realiza o mai buna performanta si stabilitate.
Baza de date Oracle: consta in fisiere ale sistemului de operare, cunoscute ca fisierele bazei de date, ce furnizeaza stocarea fizica a informatiilor in baza de date. Aceste fisiere sunt folosite pentru a se asigura ca datele sunt mentinute consistente si pot fi recuperate in eventualitatea unei erori a instantei Oracle.
Fisiere ce nu apartin bazei de date: aceste fisiere sunt folosite la configurarea instantei, la autentificarea utilizatorilor privilegiati sau la recuperarea bazei de date in cazul unei erori a instantei.
Procese server si procese utilizator: aceste procese sunt primele implicate atunci cand este executata o instructiune SQL.
Alte procese: multe alte procese pot fi folosite pentru a deservi alte servicii suplimentare ale server-ului Oracle: Advanced Queuing, Advanced Replication, RAC, Shared Server, etc.
Un server Oracle este un sistem de administrare a bazei de date care ofera o abordare deschisa, integrata si cuprinzatoare a administrarii informatiilor. In general, un server Oracle trebuie sa administreze o mare cantitate de date intr-un mediu multi-utilizator astfel incat mai multi utilizatori pot accesa concurential aceleasi date in conditii de performanta sporita. De asemenea, un server Oracle trebuie sa previna accesele neautorizate si sa furnizeze solutii eficiente pentru recuperarea datelor in cazul unei caderi a instantei.
Componentele server-ului Oracle sunt:
Instanta Oracle
Baza de date Oracle
O instanta Oracle consta intr-o structura de memorie numita System Global Area si procesele de fundal folosite pentru a administra baza de date. O instanta este identificata utilizand metode specifice fiecarui sistem de operare.
O baza de date Oracle are o structura logica si o structura fizica. Structura fizica a bazei de date consta intr-un set de fisiere ale sistemului de operare care sunt de trei tipuri:
Fisiere ce contin datele stocate in baza;
Fisiere redolog ce contin inregistrari ale schimbarilor facute in baza, inregistrari necesare recuperarii in cazul unui esec al instantei.
Fisiere de control ce contin informatii necesare mentinerii si verificarii integritatii bazei de date.
Server-ul Oracle foloseste si alte fisiere care nu fac parte din baza de date:
Fisierul de parametrii ce defineste parametrii unei instante Oracle
Fisierul de parole ceautentifica utilizatorii ce au privilegiul de a porni si opri instanta Oracle.
Fisiere redolog arhivate care sunt copii offline ale fisierelor redolog ce pot fi necesare recuperarii in cazul unei erori media.
Oracle are avantajul unor tipuri variate de procese:
Procese utilizator: acestea sunt pornite in momentul cererii de deschidere a unei conexiuni cu un server Oracle.
Procese server: aceste procese se conecteaza la instanta Oracle si sunt pornite in momentul deschiderii unei sesiuni de catre un utilizator.
Procese de fundal: aceste procese sunt pornite la deschiderea unei instante Oracle.
Un utilizator care are nevoie de a regasi informatii in baza de date trebuie mai intai sa deschida o conexiune cu server-ul Oracle. Conexiunea este ceruta utilizand un utilitar de interfata cu baza (SQL*Plus) si incepe ca proces utilizator. Acest proces utilizator nu interactioneaza direct cu server-ul Oracle. El genereaza o cerere prin programul de interfata, care deschide o sesiune si porneste un proces server.
Odata conexiunea stabilita, un proces server este pornit pentru a prelua cererea procesului utilizator. Intr-un mediu server dedicat, un proces server preia cererile definite de un singur proces utilizator. In momentul deconectarii procesului utilizator procesul server este inchis imediat. Procesul server comunica cu server-ul Oracle folosind Oracle Program Interface.
Inainte de a executa o instructiune SQL un utilizator trebuie sa se conecteze la o instanta. Aplicatia din care este executata instructiunea respectiva (SQL*Plus, Forms, etc) ruleaza ca proces utilizator. In momentul conectarii utilizatorului la server-ul Oracle pe masina ce ruleaza Oracle este pornit un proces numit proces server. Acest proces server interactioneaza cu instanta Oracle in folosul procesului utilizator executand instructiunea SQL transmisa de acesta prin intermediul unei conexiuni.
Conexiunea este o cale de comunicare intre un proces server si un proces utilizator. Conexiunile pot fi de trei feluri:
Locale: utilizatorul se conecteaza la sistemul de operare pe care ruleaza server-ul Oracle si porneste o aplicatie sau un utilitar ce acceseza baza de date de pe acest sistem. Conexiunea este stabilita utilizand un mecanism de comunicare interproces disponibil pe sistemul de operare gazda.
Client-server: utilizatorul porneste o aplicatie sau un utilitar care se conecteaza prin retea pe calculatorul pe care ruleaza instanta Oracle. In acest caz este folosit un protocol la nivelul aplicatie pentru a comunica intre utilizator si procesul server.
Conexiune in trei nivele: utilizatorul se conecteaza prin retea la un server pe care ruleaza o aplicatie care la randul ei se conecteaza prin retea la un server pe care ruleaza o instanta Oracle.
Sesiunea este o conexiune specifica intre un utilizator si un server Oracle. Sesiunea incepe in momentul in care un utilizator este validat de catre un server Oracle si se termina atunci cand utilizatorul se deconecteaza sau atunci conexiunea este intrerupta anormal. Cu exceptia unor utilitare de administrare, pornirea unei sesiuni necesita o instanta Oracle pornita.
Pentru mai multe detalii cu privire la stabilirea unei conexiuni si la deschiderea unei sesiuni in cadrul unui server Oracle vezi exemplu dat pasul 1.27.
Structura memoriei unei instante Oracle consta in doua zone de memorie:
Zona globala de sistem (SGA): este alocata la pornirea instantei, fiind componenta fundamentala a unei instante Oracle.
Zona globala de programe: este alocata atunci cand este pornit un proces server.
Este cea mai mare si mai importanta zona de memorie ce contine o colectie de zone de memorie mai mici ce sunt alocate de catre baza de date atunci cand este pornita. Aceasta este zona de memorie in care au loc toate actiunile din interiorul bazei de date.
Componentele SGA:
database buffer cache
redo log buffer
shared pool
large pool
Java pool
SQL> select * from v$sga;
NAME VALUE
Fixed Size 47252
Variable Size 9736192
Database Buffers 4096000
Redo Buffers 172032
Dupa cum se poate observa componenta SGA este urmatoarea:
SGA = Database buffers (database buffer cache)
Redo buffers (redo log buffer)
Zona de dimensiune variabila (Shared pool + Large pool + Java Pool)
Zona de dimensiune fixa
Zona de dimensiune fixa este foarte mica si nu este configurabila. Ea contine informatii despre baza de date folosite de catre procesele de fundal.
La versiunea Oracle9I componenta SGA este dinamica, dispunand de o infrastructura ce permite configurarea acesteia fara a mai fi necesara repornirea instantei. Aceasta permite dimensionarea dinamica si a zonelor Database Buffer Cache si Shared Pool in limita impusa de dimensiune maxima a SGA prin setarea parametrului SGA_MAX_SIZE.
Unitatile de alocare (granule) sunt unitati de memorie virtuala continua. Dimensiunea unei granule depinde de valorarea setata pentru SGA_MAX_SIZE:
4 MB valoarea estimata pentru SGA < 128 MB
16 MB altfel
Database buffer cache este de obicei cea mai mare zona de memorie din cadru SGA. Aceasta zona de memorie partajabila este folosita pentru a pastra copii ale blocurilor de date citite din fisierele de date de pe disc. Blocurile din aceasta zona de memorie pot fi blocuri din fisierele de date , din indecsi, segmente de rollback, segmente temporare sau din dictionarul de date. Modalitatea de manipulare a acestor date este foarte simpla: atunci cand un utilizator face o cerere catre o zona specificata de date stocate intr-un bloc serverul Oracle va citi in d.b.c pentru a vedea daca o copie curenta nemodificata a acestui bloc se gaseste aici. Daca este gasita o astfel de copie va fi folosita aceasta. In caz contrar, Oracle va aduce de pe disc acel bloc cerut si il va scrie in d.b.c. Odata adus acest bloc in d.b.c. acesta poate fi manipulat pentru a veni in intampinarea cerintelor utilizatorului.
Un bloc aflat in d.b.c. poate fi in una din urmatoarele trei stari: curent, folosit sau pinned. Un bloc este in starea curenta daca este identic cu cel de pe disc. Blocurile folosite sunt acele blocuri ce au fost modificate de catre un proces si trebuiesc scrise pe disc inainte de a fi refolosite. Un bloc este in starea pinned daca este folosit in momentul curent.
Obs. : mai multe copii ale aceluiasi bloc, fiecare in stare diferita, se pot gasi in acelasi moment in database buffer cache. In acest caz, unul este considerat curent ( consistent cu cel de pe disc), iar celelalte sunt pastrate pentru a oferi citiri consistente pentru alti utilizatori.
Pastrarea blocurilor de date necesare server-ului Oracle in buffer cache este o modalitate eficienta de a mari performanta sistemului. De fiecare data cand un utilizator are nevoie de date, blocurile de date necesare vor fi aduse in d.b.c. inainte de a fi accesate. Daca blocurile de date sunt deja in buffer cache procesul utilizatorului poate incepe. Daca blocul cerut nu este in buffer cache server-ul Oracle trebuie sa realizeze o citire costisitoare de pe disc pentru a aduce blocurile necesare si pentru a le plasa in buffer cache. Prin urmare preocuparea principala vis-a-vis de performanta sistemului rezida in dimensionarea corespunzatoare a zonei de memorie buffer cache astfel incat blocurile cele mai des accesate sa fie gasite aici.
Database buffer cache este o zona de memorie finita, astfel incat unele blocuri sunt pastrate aici iar altele sunt scrise pe disc pentru a elibera spatiu. Oracle Realizeaza acest proces folosind un algoritm foarte simplu bazat pe utilizarea a doua liste:
lista blocurilor cel mai putin folosite (LRU List - Least Recently Used List);
lista blocurilor folosite (LRUW list - dirty blocks list);
Lista LRU este o lista inlantuita unde sunt pastrate blocurile. Aceasta lista are doua capete:
MRU (Most Recently Used);
LRU (Least Recently Used);
Pe masura ce noi blocuri sunt plasate in capatul MRU, blocurile mai vechi sunt deplasate catre capatul LRU. In momentul in care zona buffer cache este plina server-ul Oracle va avea nevoie de spatiu liber pentru aducerea de noi blocuri. Mecanismul de eliberare a spatiului este foarte simplu si foarte eficient: blocurile modificate sunt mutate in lista blocurilor folosite, de unde urmeaza a fi scrise pe disc de catre procesul de fundal care se ocupa cu realizarea acestei sarcini (DBWR), iar blocurile consistente (nemodificate) ajunse in capatul LRU al listei sunt efectiv scoase afara din lista, aceste blocuri nefiind necesar a fi scrise pe disc deoarece ele sunt identice cu cele deja existente acolo. Astfel, se obtine spatiul necesar in lista LRU, evitandu-se si niste operatii de scriere costisitoare si implicit ineficiente. In momentul in care unul din blocurile aflate in lista sunt solicitate din nou acestea sunt mutate in capatul MRU al listei acordandu-i-se acestuia mai mult timp de a ramane in lista. Daca blocul necesar nu este aflat in lista acesta este citit de pe disc de catre procesul de fundal corespunzator.
Exista insa si o exceptie de la aceasta regula. Atunci cand are loc o scanare completa a tabelului si intreg tabelul este citit, aceste blocuri sunt plasate la capatul LRU al listei, deoarece aceste blocuri nu sunt folosite pentru o perioada lunga de timp.
Zona de memorie partajata (Shared Pool) actioneaza, din punct de vedere al obtinerii performantei, ca si zona database buffer cache diferenta constand in faptul ca aceasta zona manipuleaza informatii din dictionarul de date al server-ului oracle si analizeaza comenzi SQL in loc de blocuri de date.
Zona de memorie partajata este compusa din doua componente:
data dictionary cache;
library cache;
Niciuna dintre cele doua componente ale zonei de memorie partajate nu pot fi dimensionate direct. Ambele sunt dimensionate impreuna cu parametrul SHARED_POOL_SIZE. In general o dimensionare corecta a zonei de memorie partajate ofera dimensiuni optime pentru Library Cache si pentru Data Dictionary Cache.
Library Cache stocheaza textul blocurilor SQL sau PL SQL , declaratiile SQL si PL SQL interpretate corespunzator, precum si planurile de executie corespunzatoare. Acestea sunt retinute pentru a fi reutilizate ulterior de catre o eventuala interogare a unui utilizator in asa-numita zona SQL partajata.
Pastrarea blocurilor SQL sau PL/SQL parsate prezinta un avantaj esential din punct de vedere al performantei. Inainte de a fi executate, declaratiile SQL sau PL/SQL noi sunt interpretate , creandu-se astfel planele de executie corespunzatoare. Acest process este costisitor din punct de vedere al resurselor si al timpului de executie, mai ales atunci cand o interogare SQL este executata de mai multe ori. Interpretarea o singura data a unei declaratii (interogari) SQL si pastrarea acesteia in aceasta zona de memorie reprezinta o economie substantiala de resurse.
Mecanismul detaliat al acestui process este urmatorul: fiecare declaratie SQL sau PL/SQL noua este interpretata, analizata si stocata in aceasta zona de memorie. Este aplicat un algoritm hash acestei declaratii, iar rezultatul acestuia este salvat. Pe masura ce declaratia este introdusa de catre mai multi utilizatori, acesteia ii este aplicat rapid algoritmul hash si este determinata valoarea acestuia. Server-ul Oracle cauta apoi in zona SQL partajata orice declaratie SQL care sa aiba aceeasi valoare hash. Daca este gasita o valoare identica cele doua declaratii corespund iar etapa de interpretare este sarita. Oracle doar executa vechea instructiune SQL folosind planul de executie deja creat pentru aceasta, returnand rezultatul corespunzator noului proces utilizator. Astfel, codul SQL scris devine reutilizabil.
Optimizarea acestui proces se realizeaza deasemenea folosind algoritmul LRU. Exista insa anumite conditii in care declaratiile SQL din zona SQL partajata sunt sterse sau invalidate. Daca un obiect este analizat cu o comanda de tip ANALYZE, toate declaratiile ce fac referire la acest obiect sunt sterse deoarece vor fi create noi plane de executie reflectand noile statistici. Dealtfel, atunci cind un nou obiect este alterat, toate declaratiile SQL dependente de acel obiect sunt invalidate. Acestea vor fi reinterpretate si se vor genera noi plane de executie imediat ce declaratiile vor fi reutilizate.
Data Dictionary Cache pastreaza informatiile despre obiectele bazei de date cum ar fi definitiile tabelelor, conturile si privilegiile utilizatorilor, numele fisierelor de date, numele segmentelor, locatiile extentilor , etc. Aceste informatii apartin dictionarului de date Oracle si sunt stocate in spatiul-table system. Dupa pornirea instantei Oracle aceasta zona de memorie este goala dar ea se va popula pe masura ce obiectele system vor fi interogate. Mecanismul de management al spatiului in aceasta zona de memorie este identic cu cel folosit de catre database buffer cache, adica lista inlantuita LRU.
Buffer-ele redo log contin inregistrari ale tuturor schimbarilor intervenite in baza de date. Aceasta include orice tip de activitate de inserare, actualizare sau stergere in DML (Data Manipulation Language) sau orice modificari de obiecte (creare sau stergere) in DDL (Data Definition Language). Aceste schimbari sunt inregistrate in buffer-ele log in eventualitatea in care are loc o cadere a bazei de date.
Atunci cand un proces face schimbari asupra unui obiect sau asupra unei linii de date , Oracle scrie (inregistreaza) aceste schimbari intr-un buffer. Daca se va dori a se reveni asupra schimbarilor facute, si acest proces va fi inregistrat. Singura exceptie de la aceasta regula este atunci cand unei operatii ii este specificat parametrul NOLOGGING. Practic, aceat lucru se realizeaza atunci cind sunt incarcate mari cantitati de date, inregistrarea acestor operatii in redo log-uri putand duce la o supraincarcare intensa a server-ului.
In mod normal aceasta zona de memorie este foarte intens folosita, datorita faptului ca aceasta zona este relativ mica in comparatie cu alte componente ale SGA. Datorita acestui motiv buffer-ele redo sunt scrise foarte frecvent pe disc, dar, spre deosebire de database buffer cache acestea sunt golite in totalitate pe disc. Procesul LGWR este responsabil cu golirea acestor buffer-e in fisierele din grupurile redo log active. Buffer-ele redo log sunt dimensionate de parametrul de pornire LOG_BUFFER. Valoarea minima pentru acest parametru este 4 X DB_BLOCK_SIZE.
Aceasta structura de memorie este optionala, ea fiind introdusa pentru prima data in versiunea Oracle 8i pentru a furniza support de memorie pentru activitati ce in mod normal ar fi supraincarcat zona de memorie partajata. Aceasta zona de memorie este folosita pentru a veni in ajutorul urmatoarelor:
sesiunilor User Global Area (UGA) atunci cind este folosit un server MTS;
Arhitectura Extinsa (XA);
Operatii de input/output;
Recovery Manager;
Activitati de restaurare;
Pentru a dimensiona aceasta zona de memorie se foloseste parametrul de pornire LARGE_POOL_SIZE.
Aceata zona de memorie a fost prima data introdusa la versiunea 8i, fiind folosita pentru stocarea obiectelor Java partajabile. Aceasta zona de memorie este folosita mai alea cand se incarca clase java, dar si atunci cand se compileaza astfel de obiecte.
Parametrul de pornire care dimensioneaza in bytes aceasta zona de memorie este JAVA_POOL_SIZE. Dimensiunea implicita a acestei zone este de 24M, dar pentru instalarea masinii virtuale Java (fisierul initjvm.sql) sunt necesari 100M.
Aceasta zona de memorie este referita si ca Zona Globala de Procese. Este alocata cate o astfel de zona pentru fiecare proces server dedicat. PGA contine date, spatiu de stiva, informatii despre starea cursoarelor pentru fiecare din procesele atribuite. Aceasta zona de memorie nu este partajabila intre procese deoarece fiecare dintre ele este specifica fiecarui proces server in parte.
Continutul PGA:
Zona SQL privata: contine date ca informatiile de legatura si memoria de lucru. Fiecare sesiune ce executa o instructiune SQL are o zona SQL privata. Fiecare utilizator ce executa aceeasi instructiune SQL are propria zona SQL privata ce utilizeaza o singura zona SQL partajata. Astfel, mai multe zone SQL private pot fi asociate cu acceasi zona SQL partajata. Fiecare zona SQL privata este impartita la randul ei in doua zone:
o zona persistenta (persistent area): contine informatii de legatura si este eliberata cand cursorul este inchis;
o zona de lucru (runtime area): este creata la primul pas al executarii unei cereri. Pentru INSERT, UPDATE si DELETE, aceasta zona este eliberata dupa ce s-a executat instructiunea. Pentru regasiri (SELECT) aceasta zona este eliberata numai dupa ce fiecare linie a fost adusa sau regasirea a fost anulata.
Memoria de sesiune: consta in memoria alocata pentru a tine variabilele de sesiune si alte informatii legate de sesiune.
Zona de lucru SQL: este utilizata pentru operatii mari consumatoare de memorie (sort, hash-join, creere bitmap, etc). Dimensiunea acestei zone poate fi controlata si eficientizata.
Incepand cu Oracle9I dimensiunea zonei de lucru poate fi administrata automat si global. Aceasta se activeaza prin setarea parametrului WORKAREA_SIZE_POLICY=AUTO si prin initializarea parametrului PGA_AGGREGATE_TARGET. Acest ultim parametru este setat de catre DBA pentru a indica o cantitate totala de memorie PGA disponibila instanei si poate fi modificat dinamic la nivelul instantei de catre DBA. Toti ceilalti parametri *_AREA_SIZE vor fi ignorati.
Procesele de fundal realizeaza mai mult decat legatura dintre structurile de memorie si discuri. Fiecare scriere din memorie pe discuri se realizeaza de catre procesele de fundal. Ca si structurile de memorie, procesele de fundal exista atata timp cat instanta ruleaza. Daca oricare dintre aceste procese moare sau este accidental omorat baza de date va cadea. Instanta nu va putea functiona fara toate aceste procese.
DBWR scrie blocurile modificate din buffer cache pe disc. DBWR realizeaza aceasta operatie periodic pentru a elibera memoria, facand posibil citirea de noi blocuri in buffer cache.
LGWR scrie toate intrarile din redolog buffer in fisierele grupului redolog activ simultan. De asemenea LGWR actualizeaza header-ele fisierelor in timpul checkpoint-ului.
Acest proces Oracle in mod natural este un proces ce doarme. El se trezeste periodic si isi realizeaza sarcinile fara posibilitatea de interventie a administratorului.
SMON realizeaza automat urmatoarele activitati:
Recuperarea instantei dupa prabusire
Compacteaza spatiul liber pe disc in interiorul spatiilor-tabel ce sunt administrate de catre dictionar daca parametrul PCTFREE este mai mare ca 0.
Recupereaza spatiul folosit de catre segmentele temporare.
Sarcina principala a acestui proces este de a curata toate procesele utilizator terminate anormal. Aceasta presupune rollback-ul tranzactiilor derulate in cadrul procesului respectiv si eliberarea resurselor aferente acestuia.
CKPT este procesul care goleste toate buffer-ele si sincronizeaza toate fisierele. In momentul checkpoint-ului toate header-ele fisierelor bazei de date si ale fisierelor de control sunt actualizate cu numarul de secventa al checkpoint-ului (SCN). Acest numar este folosit pentru a sincroniza toate fisierelel bazei de date la un anumit moment dat si intr-o anumita stare.
Exceptia regulei se aplica numai acelor fisiere ale bazei de date care apartin unor spatii-tabel read-only. Header-ele acestor fisiere sunt inghetate atat timp cat ele sunt read_only.
Buffer-ele de memorie sunt de asemenea curatate in timpul unui checkpoint. Toate blocurile modificate (dirty) din buffer cache sunt scrise pe discuri de catre DBWR. De asemenea intreaga zona redolog este scrisa pe disk de catre LGWR. Aceasta garanteaza ca tranzactiile pot fi corect aplicate (commited) sau revocate (rolled back) in cazul unui esec al instantei, deoarece informatiile din memorie pot fi localizate pe discuri, nu in memorie.
ARCH copiaza automat fisierele redolog (care pot fi eventual suprascrise) in locatia definita pentru fisierele redolog arhivate. Aceasta operatie are scopul de a mentine timp indelungat schimbarile efectuate in baza de date in eventualitatea necesitatii unei recuperari a bezei de date. Acest proces este activ numai daca modul ARCHIVELOG este activat.
Oracle dispune de o structura logica ierarhizata astfel:
O baza de date Oracle contine cel putin un spatiu-tabel.
Un spatiu-tabel contine unul sau mai multe segmente.
Un segment este alcatuit din mai multi extenti.
Un extent este alcatuit din mai multe blocuri logice.
Blocul este cea mai mica unitate pentru operatiile de citire si scriere.
Arhitectura bazei de date Oracle include structuri logice si fizice ce alcatuiesc baza de date:
Structura fizica include fisiere de control, fisiere redolog, fisiere de date ce alcatuiesc baza de date.
Structura logica include spatii-tabel, segmente, extenti si blocuri de date.
Datele dintr-o baza de date oracle sunt stocate in spatii-tabele:
O baza de date Oracle poate fi impartita logic in mici unitati logice de stocare cunoscute ca spatii-tabele.
Fiecare spatiu tabel poate apartine unei singure baze de date la un moment dat.
Fiecare spatiu-tabel consta intr-unul sau mai multe fisiere de date
Un spatiu-tabel poate contine unul sau mai multe segmente.
Spatiile-tabel pot fi facute online in timp ce baza de date ruleaza.
Cu exceptia spatiului-tabel system sau a spatiului-tabel Undo, spatiile-tabel pot fi facute offline in timp ce baza de date ruleaza.
Spatiile-tabel isi pot schimba starea intre read-only si read-write.
Fisierele de date:
Fiecare spatiu-tabel cotine unul sau mai multe fisiere de date.
Un fisiere de date poate apartine unui singur spatiu-tabel.
Oracle server creaza fisierele de date pentru un spatiu-tabel alocand spatiu corespunzator pe disc.
Administratorul bazei de date poate schimba dimensiunea fisierului dupa creare sau poate specifica cresterea dinamica a dimensiunii acesteia.
Segment:
Un segmentul reprezinta spatiu alocat pentru o structura logica de stocare din interiorul unui spatiu tabel.
Un spatiu-tabel poate contine unul sau mai multe segmente.
Un segment nu poate acoperi mai multe spatii-tabel, dar poate acoperi mai multe fisiere de date apartinand aceluiasi spatiu-tabel.
Fiecare segment este alcatuit din unul sau mai multi extenti.
Extenti:
Unul sau mai multi extenti alcatuies un segment.
cand este creat un segment, acesta contine cel pitin un segment.
Pe masura ce un segment creste, acestuia ii sunt alocati extenti.
Administratorul poate adauga manual extenti unui segment.
Un extent este un set continuu de blocuri Oracle.
Un extent nu poate acoperi mai multe fisiere, el putand fi localizat intr-un singur fisier.
Blocurile de date Oracle:
Blocul de date reprezinta cea mai mica unitate de stocare pe care server-ul Oracle o poate aloca, citi sau scrie.
Un bloc de date corespunde unuia sau mai multor blocuri ale sistemului de operare.
Blocul de date standard este specificat de catre parametrul DB_BLOCK_SIZE la crearea bazei de date.
Blocul de date Oracle trebuie sa fie multiplu de blocul sistemului de operare pentru a evita operatii de I/O suplimentare.
Dimensiunea maxima a blocului de date este dependenta de sistemul de operare.
Presupunand cunoscute functiile fiecarui proces de fundal al unei instante Oracle, o tranzactie Oracle poate fi ilustrata de urmatorul scenariu:
un utilizator porneste SQL*Plus si introduce numele, parola si stringul de conectare. Clientul Oracle cauta in fisierul tnsnames.ora numele bazei de date. Utilizand adresa IP specificata, stringul de conectare si numarul portului procesul utilizator stabileste o conexiune cu serverul bazei de date.
procesul listener (ascultator) al server-ului Oracle primeste cererea de conexiune cu procesul utilizator client. Listener-ul citeste fisierul listener.ora gaseste baza solicitata si ruteaza procesul client (utilizator) catre baza de date specificata.
un nou proces server este pornit in interiorul bazei de date si se stabileste contactul cu procesul utilizatorului. Dupa autentificarea cu parola se stabileste conexiunea intre cele doua procese.
procesul utilizator da o comanda SQL prin care se cere actualizarea unei lini de date dintr-un tabel. Aceasta comanda este plasata peste retea procesului server dedicat.
informatiile din interiorul zonei PGA pentru procesul server dedicat sunt actualizate pentru a reflecta noua comanda SQL.
procesul server ruleaza un algoritm de hash rapid asupra declaratiei (comenzii) si receptioneaza o valoare. Scaneaza apoi zona SQL partajata pentru a gasi orice alta declaratie cu aceeasi valoare hash. Presupunem ca nu s-a gasit nici o astfel de valoare.
procesul server cauta si gaseste in interiorul zonei SQL partajate o zona de memorie de lucru. Se analizeaza declaratia (comanda) SQL si se verifica sintaxa. Oracle verifica daca obiectele referite in comanda utilizatorului fac parte din dictionarul de date precum si drepturile la nivel de obiect pe care utilizatorul le are asupra acestor obiecte. Daca permisiunile sunt indeplinite Oracle analizeaza declaratia si statisticile stocate pentru obiectele respective, urmand a se realiza un plan de executie pentru comanda respectiva. Oracle realizeaza apoi o blocare exclusiva a liniei de date si se pregateste sa execute comanda. De asemenea, se citeste SCN (Sistem Change Number) curent si se utilizeaza aceasta valoare pentru a amentine consistenta tranzactiei.
Procesul server scaneaza database buffer cache-ul pentru a vedea daca o copie a blocului de date este incarcat in memorie. Presupunem ca blocul nu este incarcat in memorie se realizeaza o citire a acestuia si incarcarea in memorie.
Odata blocul de date gasit in d.b.c. procesul server urmeaza planul de executie prestabilit si actioneaza asupra blocului de date ce contine linia de date ce trebuie modificata. In acest moment se realizeaza suprascrierea blocului de date in d.b.c., marcarea acestuia ca fiind folosit, precum si plasarea acestuia in capatul MRU al listei LRU.
Este solicitat un slot in header-ul segmentului de rollback, precum si spatiu intr-un extent al acestuia. Blocul liber astfel obtinut este adus in buffer cache, intr-o maniera similara pasului 8. O comanda SQL care sa realizeze exact reversul comenzii SQL introduse este generata si plasata in segmentul de revenire. De asemenea este plasata in segmentul de revenire, daca este cazul, si comanda de revenire a indexului ce contine o referinta la datele modificate de comanda SQL introdusa.
In acest moment blocul ce contine datele modificate este in buffer cache, deasemenea blocurile indexului si al segmentului de rollback asociat.
Procesul server cauta spatiu si scrie modificarile in buffer-ele redo log. Aceasta scriere contine datele modificate precum si continutul segmentului de rollback asociat acestor schimbari.
In acest moment utilizatorul ce a introdus comanda SQL poate vizualiza schimbarile realizate cu ajutorul unei comenzi SELECT. Orice alt utilizator ce va folosi o comanda SELECT va putea vizualiza datele exact in starea in care erau inaintea introducerii comenzii SQL initiale (pasul 4). Cu alte cuvinte, modificarile sunt vizibile doar pentru utilizatorul ce a initiat tranzactia si numai in sesiunea ce a generat comanda SQL in discutie. Blocurile ce contin linii de date modificate sunt acum considerate murdare (dirty - modificate) dar nu sunt inca salvate (commited). Orice alt utilizator ce va incerca sa modifice aceleasi linie de date sesiunea respectiva va parea blocata deoarece se asteapta invalidarea lock-ului realizat de catre primul utilizator (pasul 7).
Utilizatorul introduce comanda COMMIT. Acesta este considerat un commit explicit, ceea ce face ca Oracle sa faca permanente toate schimbarile realizate de catre utilizator in cadrul sesiunii respective. Daca utilizatorul introduce comanda EXIT se realizeaza un comit implicit, deoarece acesta paraseste normal sesiunea. Schimbarile asupra datelor vor fi permanente.
Procesul server primeste instructiunea de a salva (commit) linia respectiva. Un SCN unic este asignat tranzactiei in segmentul rollback corespunzator, precum si in buffer-ele redo log. LGWR descarca intreg continutul buffer-elor redo log in grupul de fisiere redo log activ. In momentul in care datele au fost scrise in fisierele redo log , iar sistemul de operare a primit confirmarea scrierii pe disc, Oracle considera tranzactia completa si permanenta. Daca in acest moment baza de date cade schimbarile realizate asupra datelor vor putea fi recuperate.
Procesul DBWR va scrie eventual fiecare bloc modificat (dirty) din buffer cache pe disc, dar acest lucru nu este neaparat necesar inca. De fapt, blocurile modificate pot fi deja scrise pe disc de catre DBWR la momentul de timp pe care acesta il avea asignat. Un commit realizat de catre utilizator nu forteaza procesul DBWR sa scrie blocurile modificate pe disc. Aceste blocuri pot ramane in lista LRUW din buffer cache, dar Oracle va considera tranzactia incheiata, deoarece procesul LGWR a realizat deja scrierea in fisierele grupului redo log activ. Chiar daca se inregistreaza intr-un astfel de moment un esec al instantei, iar blocurile modificate nu au ajuns sa fie scrise pe disc cu confirmare din partea sistemului de operare, informatia va fi refacuta la repornirea instantei pe baza fisierelor redo log. Acest mecanism de scriere oarecum intarziata a blocurilor modificate are un aspect pozitiv, deoarece reduce incarcarea benzii la operatiile de input-output pe disc.
Are loc deblocarea la nivel de linie introdusa de catre utilizator. Utilizatorul primeste un mesaj prin care este anuntat ca operatia de commit s-a realizat cu succes.
Cealalta comanda ce asteapta accesul la blocul de date primeste in acest moment o blocare exclusiva. Din acest moment tranzactia respectiva urmeaza acelasi curs ca si tranzactia curenta.
Primul utilizator introduce comanda EXIT. Acest fapt forteaza operatia de commit la orice noua comanda DML. Apoi procesul server Oracle si procesul utilizator asociat sunt terminate. Resursele de memorie si orice alte blocari tinute in zona PGA UGA sunt eliberate si returnate sistemului.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 2053
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
