1.
Introducere in Oracle
Server
O bază de date Oracle este o colecţie de date
tratată ca o unitate. Scopul unei baze de date este de a stoca şi de
a furniza informaţia. Un server de baze de date este cheia care
rezolvă problemele de management al informaţiei. În general, un
server se descurcă în siguranţă cu mari cantităţi de
date într-un mediu multiuser, astfel că mai mulţi utilizatori pot
accesa concurent aceeaşi dată, toate acestea fiind îndeplinite la
performanţe ridicate. Un server de baze de date, de asemenea, previne
accesele neautorizate şi asigură soluţii eficiente pentru
recuperarea datelor în caz de accidente.
Baza de date are o structură logică şi una fizică.
Deoarece acestea sunt separate, memorarea fizică a datelor poate fi
realizată fără a afecta accesul la structurile logice.
Structura
logică a unei baze de date Oracle include obiecte schemă, bloc de date, extent, segment şi tablespace.
O schemă
e o colecţie de obiecte
bază de date. O schemă este proprietatea unui utilizator şi are
acelaşi nume ca al utilizatorului. Obiectele
schemă sunt structurile logice care fac referire directă la
datele din baza de date. Obiectele schemă includ structuri ca tabele, vederi sau indecşi. (Nu există nici o legătură între
tablespace şi schemă. Obiecte din aceeaşi schemă pot fi
diferite tablespace-uri şi un tablespace poate ţine obiecte din
scheme diferite.)
Unele dintre cele mai obişnuite obiecte
schemă sunt definite în următoarea secţiune.
Tabelele sunt unitatea de bază pentru memorarea datelor într-o
bază de date. Tabelele bazei de date păstrează toată
informaţia accesibilă de utilizator. Fiecare tabel are linii şi coloane. Oracle memorează fiecare linie a tabelului în bucăţi
de linie ce reprezintă coloanele (până la 256). De exemplu, un tabel
cu angajaţi poate conţine o coloană ce reprezintă
numărul angajatului, şi fiecare linie din acea coloană
reprezintă câte un număr de angajat.
Vederile sunt prezentări particularizate ale datelor din diferite
tabele sau vederi. O vedere poate fi considerată şi o întrebare
memorată. Vederile nu conţin date, ci şi le procură din
tabelele pe care se bazează, care se şi numesc tabele de bază
ale vederilor.
Ca şi tabelele, vederile pot fi interogate, actualizate, se pot face
inserări, ştergeri, cu anumite
restricţii. Toate operaţiile efectuate asupra vederilor
afectează de fapt tabelele de bază ale vederilor.
Vederile asigură un nivel adiţional de securitate prin
restricţionarea accesului la un set predeterminat de linii şi coloane
ale tabelului. De asemenea, ele ascund complexitatea datelor şi
stochează interogări complexe.
Indecşi
Indecşii sunt
structuri opţionale asociate cu tabelele. Ei au fost creaţi pentru a
mări performanţa furnizării datelor. Un index Oracle
asigură o cale de acces către datele din tabele.
La procesarea unei interogări, Oracle poate folosi unii sau toţi
indecşii disponibili pentru a localiza eficient liniile solicitate.
Indecşii sunt folositori când aplicaţiile cer un tabel doar cu
anumite linii sau linie.
Indecşii sunt creaţi pe baza uneia sau mai multor coloane din
tabel. După ce a fost creat, un index este automat menţinut şi
utilizat de către Oracle. Schimbările din tabele (adăugarea de
linii noi, actualizarea liniilor, ştergerea liniilor) sunt automat
încorporate în toţi indecşii relevanţi cu transparenţa
completă către utilizator.
Clustere
Clusterele sunt grupuri
de unul sau mai multe tabele fizic memorate împreună deoarece împart
coloane comune şi sunt adesea folosite împreună. Deoarece liniile cu
legături între ele sunt memorate împreună fizic se
îmbunătăţeşte timpul de acces la disc.
Ca şi indecşii, clusterele nu afectează design-ul aplicaţiilor.
Data stocată într-un tabel cluster-izat e accesată de SQL în
acelaşi mod ca una dintr-un tabel neclusterizat.
Blocuri
de date, extent-uri şi segmente
Structurile logice de memorare, incluzând
şi blocurile de date, extent-urile şi segmentele permit ca Oracle
să aibă control în amănunt asupra spaţiului de pe disc.
Blocuri de date
Oracle
La cel mai fin nivel de granularitate, datele în Oracle sunt stocate în
blocuri de date. Un bloc de date corespunde unui anumit număr de bytes de
spaţiu fizic pe disc. Dimensiunea standard a blocului e specificată
de parametrul de iniţializare DB_BLOCK_SIZE. În plus, se mai pot specifica
până la cinci alte dimensiuni de bloc. O bază de date foloseşte
şi alocă spaţiu liber în blocuri de date Oracle.
Extent-uri
Următorul nivel al spaţiului bazei de date logice este un extent.
Aceasta reprezintă un număr specificat de blocuri de date continue,
obţinute la o singură alocare, folosite pentru a stoca un anumit tip
de informaţie.
Segmente
Deasupra extent-urilor, nivelul logic de stocare al bazei de date este
segmentul. Acesta este un set de extent-uri alocate pentru o anumită
structură logică. Următorul tabel descrie diferite tipuri de
segmente.
Segment |
Descriere |
Segment de date |
Fiecare tabel neclusterizat posedă
un segment de date. Toate datele tabelului sunt memorate în extent-urile
segmentului de date. Pentru un tabel
partiţionat, fiecare partiţie are un segment de date. Fiecare cluster are un segment
de date. Datele fiecărui tabel din cluster sunt memorate în segmentul de
date al cluster-ului. |
Segment de index |
Fiecare index are un segment de
index ce memorează toate datele sale. Pentru un index
partiţionat, fiecare partiţie are un segment de index. |
Segment temporar |
Segmentele temporare sunt create
de Oracle când o declaraţie SQL necesită un spaţiu de lucru
temporar pentru a-şi îndeplini sarcina. Când execuţia sa se
încheie, extent-urile din segmentul temporar sunt returnate sistemului pentru
a fi utilizate în viitor. |
Segmentul de restaurare |
Informaţia dintr-un segment
de restaurare e folosită în procesul de recuperare al bazei de date: -
pentru generarea
informaţiei din baza de date consistentă la citire. -
pentru a derula
înapoi tranzacţiile neterminate. |
Oracle alocă dinamic spaţiu atunci când extenturile unui segment
devin pline. Cu alte cuvinte, când extent-urile unui segment sunt pline, Oracle
alocă alt extent pentru acel segment. Din cauză că extent-urile
sunt alocate după necesitate, extent-urile unui segment pot sau nu pot fi
continue pe disc.
Tabele
(tablespaces)
O bază de date e împărţită în unităţi logice
de stocare, numite tabele (tablespaces), care grupează structurile
înrudite logic. De exemplu, tabelele, în mod uzual, grupează toate
obiectele aplicaţie pentru a simplifica unele operaţii
administrative.
Baze de date,
tablespaces (tabele) şi fişiere de date
Relaţia dintre baze de date, tablespace-uri şi fişiere de
date e ilustrată în figura 1.1
Fig
1.1 Relaţii dintre baze de date, tablespace-uri şi fişiere de date
Această figură arată următoarele:
-
fiecare bază
de date e împărţită logic într-unul sau mai multe tabele
(tablespaces)
-
unul sau mai multe
fişiere de date sunt create explicit pentru fiecare tabel pentru a stoca
fizic datele tuturor structurilor logice dintr-un tabel.
-
dimensiunea
tuturor fişierelor de date dintr-un tabel este capacitatea totală de
memorare a tabelului (tabelul SYSTEM are 2 Mbiţi capacitate, iar tabelele
USER au câte 4 Mb)
-
capacitatea de
stocare a tuturor tabelelor unei baze de date este capacitatea totală de
stocare a bazei de date (6 Mb).
Un tabel poate fi online (accesibil) sau offline (inaccesibil). Un tabel
este în general online, astfel încât utilizatorii să poată accesa
informaţia din el. în unele cazuri, tabelele sunt offline pentru a face o
porţiune a bazei de date nedisponibilă,restul rămânând
disponibil. Acest lucru face ca sarcinile administrative să fie mai
uşoare.
1.1.2. Structura
fizică a bazei de date
Fiecare bază de date Oracle posedă unul sau mai multe
fişiere de date fizice. Acestea conţin toate datele bazei de date.
Datele structurii logice a bazei de date, cum ar fi tabelele şi
indecşii, sunt stocate fizic în fişierele de date alocate bazei de
date.
Caracteristicile unui fişier de date sunt:
-
un fişier de
date poate fi asociat cu o singură bază de date.
-
un fişier da
date poate fi setat pentru a-şi aloca singur spaţiu când bază de
date nu mai are spaţiu.
-
unul sau mai multe
fişiere de date formează o unitate de stocare a bazei de date
numită tablespace.
Date din fişierul de date sunt citite, la nevoie, în timpul
operării normale cu baza de date şi stocate în memoria cache a
Oracle. De exemplu, să presupunem că un utilizator doreşte
să acceseze nişte date dintr-un tabel al bazei de date. Dacă
informaţia cerută nu se află deja în memoria cache a bazei de
date, este citită din fişierele de date potrivite şi stocate în
memorie. Datele noi sau modificate nu sunt neapărat scrise în
fişierele de date imediat. Pentru a reduce numărul de accesări
la memorie şi pentru a creşte performanţa, datele sunt puse în
comun în memorie şi scrise în fişiere de memorie potrivite toate
deodată.
Fiecare bază de date Oracle are un set de două sau mai multe
fişiere redo log. Acest set e cunoscut sub numele de redo log pentru baza
de date. Un redo log este alcătuit din intrări redo
(înregistrări redo).
Funcţia principală a unui redo log este de a memora toate
schimbările aplicate datelor. Dacă o cădere de sistem
împiedică memorarea datelor modificate în fişierele de date, atunci
aceste modificări pot fi obţinute din redo log, deci nu se pierde
nimic.
Pentru protejarea unei căderi
ce implică însuşi fişierul redo log, Oracle permite un
fişier redo log multiplexat astfel încât două sau mai multe copii de
fişier redo log să fie menţinute pe discuri diferite.
Informaţia dintr-un fişier redo log este folosită doar la
recuperarea bazei de date în cazul unei căderi de sistem sau de mediu ce
împiedică scrierea datelor în fişierul de date. De exemplu, dacă
o pană de curent opreşte operaţiile bazei de date, atunci datele
din memorie nu pot fi scrise în fişierele de date, şi astfel datele
sunt pierdute. În orice caz, datele pot fi recuperate la deschiderea bazei de
date, după revenirea curentului. Aplicând informaţia din cele mai
recente fişiere redo log asupra fişierelor de date, Oracle
restaurează baza de date până la momentul în care a apărut pana
de curent.
Procesul aplicării informaţiei redo log în timpul operaţiei
de recuperare se numeşte de rulare înainte.
Fiecare bază de date Oracle are un fişier de control. Acesta
conţine înregistrări ce specifică structura fizică a bazei
de date. De exemplu, conţine următoarele informaţii:
-
numele bazei de
date.
-
nume şi
locaţii ale fişierelor de date şi redo log.
-
momentul de timp
al creării bazei de date.
De fiecare dată când o instanţă a unei baze de date Oracle e
pornită, fişierul său de control identifică baza de date
şi fişierele redo log ce trebuie deschise pentru a se trece la
operaţiile cu baza de date. Dacă aspectul fizic al bazei de date este
alterat (de exemplu dacă este creat un nou fişier de date sau redo
log), atunci fişierul de control este modificat automat de Oracle astfel
încât să reflecte schimbarea. Fişierul de control este folosit, de
asemenea, în recuperarea bazei de date.
Cele trei utilităţi pentru mutarea unui subset al unei baze de
date Oracle dintr-o bază de date în alta sunt: Exportul, Importul şi
Încărcarea SQL*.
Utilitatea Export
Aceasta transferă obiecte de date între baza de date Oracle, chiar
dacă acestea sunt rezidente pe platforme cu hardware şi software
diferit. Export extrage definiţiile obiectelor şi datele tabelelor
dintr-o bază de date Oracle şi le stochează într-un fişier
binar, fişier Export localizat tipic pe disc sau bandă (casetă).
Aceste fişiere pot fi apoi copiate utilizând Protocolul de Transfer al
Fişierelor (FTP) sau transportate fizic (în cazul casetelor) către
altă locaţie. Pot fi utilizate cu utilitatea Import pentru a
transfera date între baze de date ce se află pe sisteme neconectate
printr-o reţea sau ca backup, în plus faţă de procedurile
normale de backup.
Utilitatea Import
Această utilitate inserează obiecte de date extrase dintr-o bază
de date. Oracle de utilitatea Export, într-o altă bază de date.
Fişierele Export pot fi citite doar de Import. Import citeşte
definiţiile obiectelor şi datele din tabele pe care utilitatea Export
le-a extras dintr-o bază de date.
Utilitatea SQL* Loader
Fişierele Export pot fi citite doar de utilitatea Oracle Import.
Dacă este necesară citirea de date din fişiere ASCII sau
fişiere delimitate, se poate folosi utilitatea SQL* Loader. Aceasta
încarcă datele din fişiere externe în tabelele unei baze de date.
SQL* Loader acceptă date de intrare într-o varietate de formate,
realizează filtrări şi încarcă date în mai multe tabele ale
bazei de date în timpul aceleiaşi sesiuni de încărcare.
1.1.3.
Dicţionarul de date
Fiecare bază de date posedă un dicţionar de date. Acesta
reprezintă un set de tabele şi vederi folosite drept
referinţă read-only despre baza de date. De exepmlu, un
dicţionar de date stochează atât despre structura logică cât
şi despre cea fizică a bazei de date. Un dicţionar de date
stochează şi urmăreşte informaţiile:
-
utilizatorii
valizi ai bazei de date.
-
informaţii
despre constrângerile de integritate definite pentru tabelele din baza de date.
-
cantitatea de
spaţiu alocat pentru un obiect schemă şi cât din el este
folosit.
Un dicţionar de date este creat când e creată baza de date.
Pentru a reflecta cu acurateţe starea bazei de date în fiecare moment,
dicţionarul de date este actualizat automat de Oracle ca răspuns la
diferitele acţiuni, cum ar fi de exemplu modificarea structurii bazei de
date. Baza de date se bazează pe dicţionarul de date pentru a
înregistra, verifica şi dirija procesele exterioare.
1.2. Accesul la
Date
1.2.1. SQL
SQL (pronunţat SEQUEL) este limbajul de programare ce defineşte
şi manipulează baza de date. Bazele de date SQL sunt
relaţionale, ceea ce înseamnă că datele sunt stocate într-un set
de relaţii simple.
Declaraţii
SQL
Toate operaţiile asupra informaţiei dintr-o bază de date
Oracle sunt executate folosind declaraţii SQL (interogări SQL). O
declaraţie SQL este un şir de text SQL. O declaraţie trebuie
să fie echivalentul unei propoziţii SQL complete, ca în:
SELECT last_name,departement_id FROM employees;
Doar o declaraţie SQL completă poate rula cu succes. Un fragment
de propoziţie generează o eroare indicând necesitatea
completării acesteia:
SELECT last_name
Declaraţiile SQL sunt împărţite în următoarele
categorii:
-
Declaraţii
DDL (Data Definition Language – Limbaj de definire al datelor)
-
Declaraţii
DML (Date Manipulation Language – Limbaj de manipulare al datelor)
-
Declaraţii de
control al tranzacţiilor
-
Declaraţii de
control al sesiunii
-
Declaraţii de
control al sistemului
-
Declaraţii
SQL Embedded
Aceste declaraţii creează, modifică, menţin şi
şterg schemele. Declaraţiile DDL permit de asemenea acordarea de
privilegii altor utilizatori asupra bazei de date.
Aceste declaraţii manipulează datele. De exemplu, interogarea,
inserarea, actualizarea şi ştergerea liniilor unui tabel sunt toate
operaţii DML. Cea mai obişnuită declaraţie SQL este SELECT,
care preia date din baza de date. Blocarea unei tabele sau vederi şi
examinarea unui plan de execuţie al unei declaraţii SQL sunt de
asemenea, operaţii SQL.
Aceste declaraţii se ocupă de schimbările făcute de
declaraţiile DML. Ele permit utilizatorului să grupeze
modificările în tranzacţii logice. Exemplele includ COMMIT, ROLLBACK
şi SAVEPOINT.
Declaraţiile de control al sesiunii
Aceste declaraţii permit
utilizatorului să controleze proprietăţile sesiunii curente.
Cele două declaraţii de control al sesiunii sunt ALTER SESSION
şi SET ROLE.
Declaraţii
de control al sistemului
Aceste
declaraţii modifică proprietăţile instanţei curente de
Oracle Server. Unica declaraţie de acest tip este ALTER SYSTEM. Ea permite
utilizatorului să modifice setările, de exemplu numărul minim de
shared servers, termină o sesiune şi execută alte cerinţe.
Aceste declaraţii încorporează
DDL, DML, declaraţii de control al tranzacţiilor într-un program în
limbaj procedural, ca cele folosite cu precompilatoarele Oracle. Exemplele
includ OPEN, CLOSE, FETCH şi EXECUTE.
1.2.2. Obiecte
Tehnologia obiectelor Oracle este un
domeniu construit pe baza tehnologiei relaţionale Oracle. Noi tipuri de
obiecte pot fi create pornind de la tipuri predefinite sau construite anterior,
referinţe către obiecte sau tipuri colecţie. Metadatele pentru
tipuri definite de utilizator sunt stocate într-o schemă disponibilă
către SQL, PL / SQL , JAVA şi alte interfeţe.
Un tip obiect diferă de tipurile SQL
originale prin faptul că e definit de utilizator şi specifică
atât datele (atributele) cât şi comportamentele asociate (metode).
Tipurile obiect sunt abstractizări ale entităţilor din lumea
reală.
Tipurile obiect şi facilităţile
orientate pe obiect asociate asigură posibilităţi de nivel mai
înalt pentru organizarea şi accesarea datelor în bazele de date. Deşi
datele sunt stocate tot în coloane şi tabele, se poate lucra cu datele în
termeni de entităţi din lumea reală – clienţi şi
comenzi, de exemplu – ceea ce face datele mai pline de înţeles. În loc
să gândim în termeni de coloane şi tabele când interogăm o
bază de date, putem selecta simplu un client.
Avantaje
ale obiectelor
În general,
modelul cu tipul obiect este similar mecanismului cu clase din C++ şi
Java. Ca şi clasele, obiectele fac mai uşoară modelarea
entităţilor complexe din lumea reală, şi mai logică,
şi posibilitatea reutilizării obiectelor permite dezvoltarea
aplicaţiile bază de date mai rapid şi mai eficient. Suportând
din faza de proiectare tipurile obiect, Oracle permite proiectanţilor de
aplicaţii să acceseze direct structurile de date folosite de
aplicaţiile lor. Nici un nivel de mapare nu este necesar între obiectele
client şi coloanele şi tabelele bază de date relaţionale,
ce conţin datele. Abstractizarea obiect şi încapsularea
comportamentelor obiectelor fac, de asemenea, aplicaţiile mai uşor de
înţeles şi menţinut.
1.2.3.
PL / SQL
PL / SQL este extensia SQL a limbajului
procedural Oracle. PL / SQL combină uşurinţa şi
flexibilitatea lui SQL cu funcţionalitatea procedurală a unui limbaj
de programare structurat, cum ar fi IF … THEN, WHILE şi LOOP.
La proiectarea unei aplicaţii cu baze
de date, se vor lua în considerare următoarele avantaje ale folosirii lui
PL / SQL:
-
Codul PL / SQL
poate fi memorat central în baza de date. Traficul prin reţea dintre
aplicaţii şi baza de date este redus, deci performanţele
aplicaţiilor şi sistemului cresc. Chiar şi când PL / SQL ne este
memorat în baza de date, aplicaţiile pot trimite mai degrabă blocuri
de PL / SQL către baza de date, decât declaraţii SQL individuale,
reducându-se astfel traficul în reţea.
-
Accesul la date
poate fi controlat prin codul PL / SQL stocat. În acest caz utilizatorii PL /
SQL pot accesa datele doar după cum doreşte proiectantul
aplicaţiei, doar dacă este acordată altă rută de
acces.
-
Blocurile PL / SQL
pot fi trimise de o aplicaţie către baza de date, rulând
operaţii complexe fără un trafic în reţea excesiv.
Unităţile program PL / SQL
Unităţile program sunt proceduri stocate, funcţii, pachete,
declanşatoare şi tranzacţii anonime.
Proceduri şi
funcţii: Procedurile şi funcţiile sunt seturi de
declaraţii SQL şi PL / SQL grupate spre a rezolva o problemă
specifică sau pentru a realiza un set de cerinţe înrudite. Ele sunt
create şi memorate într-o formă compilată în baza de date
şi pot fi rulate de un utilizator al aplicaţiei.
Procedurile şi funcţiile sunt identice, cu excepţia faptului
că funcţiile returnează întotdeauna o singură valoare utilizatorului.
Procedurile nu returnează valori.
Pachete: Pachetele încapsulează sau stochează proceduri înrudite,
funcţii, variabile şi alte construcţii, împreună ca o
unitate în baza de date. Ele oferă funcţionalitate crescută (de
exemplu, variabilele slabe ale pachetelor pot fi declarate şi folosite de
orice procedură din pachet). Ele îmbunătăţesc, de asemenea,
performanţa (toate obiectele unui pachet sunt analizate, compilate şi
încărcate în memorie deodată).
Declanşatoarele(Trigger-ele): Acestea sunt proceduri PL / SQL, Java sau C care rulează implicit ori
de câte ori este modificată o vedere sau un tabel sau când apar unele
acţiuni ale utilizatorilor sau ale sistemului. Trigger-ele pot fi folosite
într-o varietate de moduri pentru management-ul bazei de date. De exemplu, se
pot genera automat date, se pot face monitorizări ale modificărilor
datelor, forţa constrângerile de integritate complexe şi furniza
autorizaţii complexe de securitate.
Blocuri autonome: Se pot apela tranzacţii autonome din interiorul unui bloc PL / SQL.
Când un bloc PL / SQL autonom este introdus, contextul tranzacţiei
apelantului este suspendat. Acesta asigură că operaţiile SQL
executate în acest bloc (sau alte blocuri apelate din el) nu au nici o dependenţă
sau efect asupra stării tranzacţiei apelantului.
1.2.4. Java
Java e un limbaj de programare orientat pe obiect, eficient pentru programe
la nivel aplicaţie. Java posedă facilităţi cheie care în
fac ideal pentru dezvoltarea aplicaţiilor server.
Aceste facilităţi includ:
-
simplitate -- Java
e un limbaj mai simplu ca altele folosite pentru aplicaţii de server
datorită modelului obiect. Setul standard cuprinzător de biblioteci
de clase aduce instrumente puternice proiectanţilor în Java, pe toate
platformele.
-
portabilitate -- Java e portabilă pe diferite
platforme.
-
managementul
pentru stocare automată.
-
tipuri puternice
de date.
-
nu există
pointeri.
-
tratarea
excepţiilor.
-
securitate.
-
standard pentru
conectivitate la baze de date relaţionale.
1.2.5. XML
XML, eXtensible Markup Language, este modul standarde de identificare
şi descriere a datelor pe Web. Este o sintaxă generală
interpretabilă atât de către om cât şi de către
maşină, pentru descrierea ierarhică a datelor, aplicabilă unei
largi plaje de aplicaţii, baze de date, comerţ electronic, Java
proiectare Web, căutări, ş. a.
Serverul Oracle include Oracle XML DB, un set de tehnologii XML de momorare
şi recuperare incorporate, de înaltă performanţă.
Aspectele cheie ale bazei de date XML sunt:
-
un tip de
dată original (nativ) – XML Type – pentru stocare şi manipulare XML;
-
generaţia XML
originală asigură operatori SQL incorporaţi şi pachete PL /
SQL pentru returnarea rezultatelor înregistrărilor SQL în format XML;
-
un depozit XML
asigură „îndosarierea”, controlul accesuli, suport pentru protocoalele FTP
şi WebDAV.
1.2.6.
Tranzacţii
O tranzacţie e o unitate de lucru logică ce cuprinde una sau mai
multe declaraţii SQL rulate de un singur utilizator. Conform standardului
SQL ANSI / ISO, cu care Oracle e compatibil, o tranzacţie începe cu prima
declaraţie SQL executabilă a utilizatorului. O tranzacţie se
încheie când este validată în mod explicit sau rulată înapoi de acel
utilizator.
Să considerăm o bază de date a unei bănci. Când un
client transferă bani dintr-un cont în altul, tranzacţia constă
din trei operaţii: scade valoarea primului cont, creşte valoarea
celui de-al doilea şi înregistrează tranzacţia în jurnalul de
tranzacţii.
Oracle trebuie să garanteze că toate cele trei operaţii sunt
executate pentru a menţine contul într-o stare bună. Când ceva
împiedică rularea uneia din declaraţiile tranzacţiei (cum ar fi
o cădere hardware), atunci şi celelalte declaraţii trebuie
anulate. Aceasta se numeşte derulare înapoi (anulare).
Fig
1.2 Tranzacţii
Modificările realizate declaraţiile SQL ce constituie o
tranzacţie pot fi validate sau anulate, derulate înapoi. După ce o
tranzacţie e validată sau anulată, începe următoarea
tranzacţie, ce următoarea declaraţie SQL.
Validarea unei tranzacţii permanentizează modificările
realizate de toate propoziţiile SQL din tranzacţie. Aceste
modificări devin vizibile altor tranzacţii, care pornesc doar
după validarea acestei tranzacţii.
Anularea (derularea înapoi) unei tranzacţii retrage orice schimbare
rezultată din propoziţiile SQL ale tranzacţiei. După ce o
tranzacţie este derulată înapoi, datele afectate rămân
nemodificate, ca şi cum acele declaraţii SQL nici nu s-ar fi
efectuat.
Puncte de salvare
(de rulare)
Acestea împart o tranzacţie lungă, cu multe propoziţii SQL,
în părţi mai mici. Cu ajutorul punctelor de salvare se poate marca
arbitrar procesul în orice punct de-a lungul tranzacţiei. Acesta permite
mai târziu rularea înapoi a procesului realizat, din punctul curent până
la un punct de salvare declarat, din tranzacţie.
Tranzacţiile furnizează utilizatorilor garanţia
modificărilor consistente ale datelor, câtă vreme declaraţiile
SQL din tranzacţii sunt ocupate logic. Datele din toate tabelele referite
sunt într-o stare consistentă înainte de începerea tranzacţiei
şi după finalizarea acesteia, tranzacţiile trebuie să
constea din declaraţii SQL ce produc o modificare consistentă a
datelor.
1.2.7.
Integritatea datelor
Datele trebuie să adere la anumite reguli de afaceri, determinate de
administratorul de baze de date sau proiectantul aplicaţiei. De exemplu,
să presupunem că o regulă de afacere spune că nici o linie
din tabelul inventat nu poate conţine o valoare numerică mai mare ca
nouă în coloana sale_discount. Dacă o declaraţie INSERT sau
UPDATE încearcă să violeze această regulă de integritate,
Oracle trebuie să ruleze înapoi (anuleze) declaraţia invalidă
şi să returneze o eroare aplicaţiei. Oracle asigură
constrângeri de integritate şi triggere de baze de date pentru a manevra
regulile de integritate a datelor.
O constrângere de integritate este un mod declarativ de a defini o
regulă de afacere pentru o anumită coloană a unui tabel. O
constrângere de integritate este o declaraţie despre datele tabelului care
e întotdeauna adevărată şi care respectă aceste reguli:
- dacă o constrângere de integritate e creată
pentru un tabel şi unele date deja existente în tabel nu satisfac
această constrângere, atunci constrângerea nu poate fi impusă cu
forţa;
- după definirea unei constrângeri, dacă
oricare din rezultatele unei declaraţii DML violează constrângerea de
integritate, această declaraţie e rulată înapoi şi este
returnată o eroare.
Constrângerile de integritate sunt definite împreună cu un tabel
şi memorate ca parte din definiţia tabelului în dicţionarul de
date, astfel încât toate aplicaţiile să adere la acelaşi set de
reguli. Când este modificată o regulă, aceasta este modificată o
singură dată, la nivelul bazei de date, şi nu de mai multe ori
pentru fiecare aplicaţie.
Următoarele constrângeri de integritate sunt suportate de Oracle:
-
NOT NULL – nu
permite intrările nule (vide) în coloanele unui tabel;
-
UNIQUE KEY – nu
permite valorile duplicat într-o coloană sau un set de coloane;
-
PRIMARY KEY – nu
permite valorile duplicat sau nule într-o coloană sau un set de coloane;
-
FOREIGN KEY –
necesită ca fiecare valoare dintr-o coloană sau set de coloane
să corespundă unei valori asociate, UNIQUE sau PRIMARY KEY, din alt
tabel;
-
CHECK – nu permite
valori ce nu satisfac expresia logică a constrângerii.
Cheia este folosită în definirea mai multor tipuri de constrângeri de
integritate. O cheie este coloana sau setul de coloane inclusă în
definiţia unui anumit tip de constrângere de integritate. Cheile descriu
relaţiile dintre diferitele tabele şi coloane ale unei baze de date
relaţionale. Valorile individuale dintr-o cheie se numesc valori cheie.
Tipuri de chei:
-
cheie primară
– coloana sau setul de coloane incluse în definiţia unei constrângeri de tip
PRIMARY KEY asupra unui tabel. Valoarea unei chei primare identifică în
mod unic liniile dintr-un tabel. Poate fi definită o singură cheie
primară pentru fiecare tabel;
-
cheie unică –
coloana sau setul de coloane incluse în definiţia unei constrângeri UNUIQUE;
-
cheia
străină - coloana sau setul de coloane incluse în definiţia unei
constrângeri de integritate referenţială;
-
cheie
referită – cheia unică sau primară a aceleiaşi sau a unui
tabel diferit, referită de o cheie străină.
1.2.8. SQL*PLUS
SQL*PLUS este un instrument pentru introducerea şi rularea
declaraţiilor de baze de date ad-hoc. Permite rularea declaraţiilor
SQL şi blocurilor PL / SQL şi execută alte numeroase
sarcini.Prin SQL * PLUS se poate:
-
introduce, edita,
stoca, regăsi şi rula declaraţii SQL sau blocuri PL / SQL;
-
formata, realiza
calcule, stoca, tipări şi crea ieşiri de tip Web a rezultatelor
interogărilor;
-
lista
definiţii de coloane, copia date între baze de date SQL;
-
trimite mesaje
către / primi răspuns de la un utilizator final;
-
realiza
administrarea bazei de date.
1.3. Structura
memoriei şi procese
Un server Oracle foloseşte structuri de memorie şi procese pentru
a manevra şi accesa baza de date. Toate structurile de memorie se
află în memoria principală. Procesele sunt funcţii ce
lucrează în memoria computerelor ce constituie sistemul bază de date.
Fig
1.3
1.3.1.
Instanţa Oracle
Un server Oracle constă dintr-o bază de date Oracle şi o
instanţă Oracle server. De fiecare dată când este pornită o
bază de date, o zonă SGA (System global area) este alocată
şi procesele din fundal şi buffer-ele de memorie e numită
instanţă Oracle.
Unele arhitecturi hardware (de exemplu, sistemele cu disk-uri partajate)
permit mai multor computere să partajeze accesul la date, software sau
dispozitive periferice. Pachetele profită de aceste arhitecturi rulând
instanţe multiple ce partajează o singură bază de date
fizică. În majoritatea aplicaţiilor, grupurile de aplicaţii
reale permit accesul la o singură bază de date de către
utilizatori pe multiple maşini cu performanţe crescute.
Un server Oracle foloseşte structuri de memorie şi procese pentru
a manevra şi accesa baza de date. Toate structurile de memorie se
află în memoria principală a componentelor ce constituie sistemul
bază de date. Procesele sunt funcţii (sarcini) ce lucrează în
memoria acestor computere.
1.3.2. Structuri
de memorie
Oracle creează şi foloseşte structuri de memorie pentru a
executa diferite sarcini. De exemplu, memoria stochează codul programului
ce rulează şi datele partajate de utilizatori. Două structuri de
memorie de bază sunt asociate cu Oracle: aria globală sistem şi
aria globală program.
SGA este o zonă de memorie partajată ce conţine date şi
informaţii de control pentru o instanţă Oracle. Oracle
alocă SGA când este pornită o instanţă şi o
dealocă când instanţa este oprită. Fiecare instanţă
are propria SGA.
Utilizatorii conectaţi la serverul Oracle partajează datele din
SGA. Pentru performanţe optime, întreaga SGA ar trebui să fie cât mai
mare posibil (dar să nu depăşească memoria reală),
astfel încât să stocheze cât mai multe date în memorie pentru a minimiza
operaţiile de intrare / ieşire la disc.
Informaţia stocată în SGA se împarte în mai multe tipuri de
structuri de memorie, ce includ buffer-ele bazei de date, buffer-ul redo log
şi zona partajată (shared pool).
Zona cache a buffer-ului bazei de date stochează cele mai recente
folosite blocuri de date. setul de buffer-e dintr-o instanţă
alcătuiesc buffer-ul cache. Buffer-ul cache conţine date modificate
sau nemodificate. Deoarece cele mai recent (şi adesea, mai frecvent)
folosite date sunt păstrate în memorie, mai puţine operaţii
intrare / ieşire la disc sunt necesare şi creşte
performanţa.
Buffer-ul redo log stochează intrări redo – un jurnal cu
modificări făcute asupra bazei de date. Intrările redo stocate
în buffer-ele redo log sunt scrise într-un jurnal redo online, folosit la
recuperarea bazei de date, când e necesar. Dimensiunea jurnalului redo este
statică.
Zona Shared Pool conţine construcţii partajate de memorie, cum ar
fi zonele SQL. O zonă SQL partajată conţine informaţii cum
ar fi arborele de analiză şi planul de execuţie al
declaraţiei corespunzătoare. O singură zonă SQL
partajată este folosită de mai multe aplicaţii ce emit
aceleaşi declaraţii, lăsând liberă mai multă memorie
partajată pentru utilizatori.
PGA este un buffer de memorie ce conţine date şi informaţii
de control despre procesul server. PGA este creată de Oracle când un
proces server este lansat. Informaţia din PGA depinde de configuraţia
Oracle.
1.3.3. Arhitectura
Procesului
Un proces este un „fir de control” sau un mecanism dintr-un sistem de
operare ce poate executa o serie de paşi. În general, un proces are
propria sa zonă de memorie în care rulează.
Un server Oracle are două tipuri generale de procese: procese
utilizator şi procese Oracle.
Procese
Utilizator(Client)
Procesele utilizator sunt create şi menţinute pentru a rula codul
unor aplicaţii (cum ar fi Pro*C / C++) sau un instrument Oracle (cum ar fi
Enterprise Manager). Procesele utilizator se ocupă şi de
comunicaţia cu procesul server prin interfaţa programului.
Procesele Oracle sunt apelate de alte procese pentru a executa funcţii
în favoarea procesului apelant.
Procese Server. Oracle creează procese server pentru a manipula cerinţele
proceselor utilizator conectate. Un proces server comunică cu procesul
utilizator şi interacţionează cu Oracle pentru a rezolva
cerinţele din partea procesului utilizator asociat.
Oracle poate fi configurat astfel încât să modifice numărul de
procese utilizator pentru fiecare proces server. Într-o configuraţie server dedicată, un proces server se
ocupă de cerinţele unui singur proces utilizator. O configuraţie server partajată
permite mai multor procese utilizator să poartă un mic număr de
procese server, minimizând numărul de procese server şi maximizând
utilizarea resurselor disponibile ale sistemului.
Pe unele sisteme, procesele utilizator şi server sunt separate, în
timp ce pe altele ele sunt combinate într-un singur proces. Dacă un sistem
foloseşte serverul partajat sau dacă procesele user şi server
rulează pe staţii diferite, atunci procesele utilizator şi
server trebuie să fie separate. Sistemele client / server separă
procesele utilizator şi server şi le rulează pe staţii
diferite.
Procese
Background: Oracle creează un set de procese background pentru
fiecare instanţă. Procesele background consolidează funcţii
care altfel ar fi fost preluate de mai multe programe Oracle rulând pentru
fiecare proces utilizator. Ele execută operaţii de intrare
ieşire asincrone şi monitorizează alte procese Oracle pentru a
furniza un paralelism crescut pentru performanţe şi fiabilitate mai
bune.
DatabaseWriter
(DBWn) scrie blocurile modificate din zona cache a buffer-ului
bazei de date în fişierele de date. Cu toate că un proces database
writer este suficient pentru majoritatea sistemelor se pot configura procese
adiţionale pentru a mări performanţa la scriere care
modifică date foarte des. Parametrul de iniţializare
DB_WRITER_PROCESSES specifică numărul de procese DBWn.
Log Writer (LGWR) scrie intrări redo log pe disc. Intrările redo log sunt generate
în buffer-ul redo log al SGA, iar LGWR scrie intrările redo log
secvenţial într-un jurnal redo online. Dacă baza de date posedă
un jurnal redo multiplexat, atunci LGWR scrie intrările redo log într-un
grup de fişiere redo log online.
Checkpoint (CKPT) La intervale specificate de timp toate bufferele bazei de date din SGA
modificate sunt scrise către fişierele de date de DBWn. Acest
eveniment se numeşte checkpoint. Procesul checkpoint e responsabil cu
semnalizarea unui checkpoint către DBWn şi actualizarea tuturor
fişierelor de date şi de control ale bazei de date indicând cele mai
recente checkpoint-uri.
System Monitor
(SMON) realizează refacerea bazei de date când o
instanţă nefinalizată este iniţializată din nou.
Procesele SMON ale unei instanţe pot realiza refacerea altor instanţe
care au picat.
Process Monitor
(PMON) realizează refacerea procesului când pică un
proces utilizator. PMON este responsabil de ştergerea memoriei cache
şi eliberarea resurselor pe care le utiliza procesul.
Arhivatorul
(ARCn) copie fişierele redo log într-un depozit arhivat
după ce a apărut o schimbare de jurnal. Cu toate că un singur
proces ARCn (ARC0) este suficient majorităţii sistemelor, se pot
specifica până la zece procese ARCn folosind parametrul dinamic de
iniţializare LOG_ARCHIVE_MAX_PROCESSES.
Recuperatorul
(RECO) este folsit pentru rezolvarea tranzacţiilor
distribuite ce aşteaptă din cauza unei căderi de sistem sau
reţea într-o bază de date distribuită. La intervale de timp,
recuperatorul local încearcă să se conecteze la bazele de date
şi să realizeze automat validarea sau anularea porţiunii locale
a oricărei tranzacţii distribuite ce aşteaptă.
Procesele Job
Queue (Jnnn) sunt folosite pentru procesarea la grămadă.
Aceste procese sunt manipulate dinamic ceea ce permite utilizatorilor să
folosească mai multe procese de acest gen dacă au nevoie.
Expeditoarele
(Dnnn) sunt procese background opţionale prezente doar
atunci când este folosită o configuraţie de server partajat. Cel
puţin un proces expeditor este creat pentru fiecare protocol de comunicare
aflat în uz (D000, …, Dnnn). Fiecare proces expeditor este responsabil de
rootarea cererilor de la procesele user conectate către procesele server
partajate disponibile şi returnarea răspunsului către procesele
utilizator corespunzătoare.
Lock Manager
Server (LMS) acest proces este folosit pentru blocare
inter-instanţă.
Queue Monitor
(QMNn) acestea sunt procese background opţionale ce
monitorizează cozile de mesaje. Se pot configura până la zece procese
de acest tip.
1.3.4. Mecanismul
interfeţei programului
Interfaţa programului este mecanismul prin care un proces utilizator
comunică cu un proces server. El serveşte drept metodă de
comunicaţie standard între orice instrument client sau aplicaţie (cum
ar fi formele Oracle) şi software-ul Oracle. Funcţiile sale sunt:
-
se comportă
ca un mecanism de comunicaţie prin formatarea cererilor de date,
transmiterea datelor şi capturarea şi returnarea erorilor;
-
realizează conversii şi
translaţii de date, mai ales între diferite tipuri de computere sau
către tipuri de date ale programelor utilizatorilor externi.
Dacă procesele utilizator şi server sunt pe calculatoare diferite
ale unei reţele, sau dacă procesele utilizator se conectează la
procese server partajate prin procese dispatcher (expeditor), atunci procesele
utilizator şi server comunică folosind serviciile de reţea
Oracle.
Procesele
dispatcher sunt procese background opţionale prezente doar în
configuraţiile de server partajat.
Serviciile de
reţea Oracle reprezintă mecanismul Oracle de interfaţare cu
protocoalele de comunicaţie folosite de reţele ce facilitează
procesarea distribuită şi bazele de date distribuite. Protocoalele de
comunicaţie definesc modul în care datele sunt transmise şi primite
într-o reţea. Într-o reţea, un server de baze de date Oracle
comunică cu staţiile client şi alte servere de baze de date
Oracle folosind software-ul de servicii de reţea Oracle.
Serviciile de reţea Oracle suportă comunicaţii cu toate
protocoalele de reţea importante, de la cele suportate de PC LANs
până la cele cu computere de tip mainframe.
Folosind serviciile de reţea Oracle, proiectanţii de
aplicaţii nu trebuie să se ocupe de comunicaţia prin reţea.
Dacă un protocol nu este folosit, atunci administratorul de baze de date
face unele schimbări minore, în timp ce aplicaţiile nu necesită
nici o modificare şi continuă să funcţioneze.
1.3.5. Un exemplu
de cum funcţionează Oracle
Următorul exemplu descrie cel mai de bază nivel al
operaţiilor pe care le realizează Oracle. El ilustrează o configuraţie
Oracle unde procesul utilizator şi procesul server asociat sunt pe
maşini separate (conectate prin intermediul unei reţele).
1.
Se
iniţializează o instanţă pe computerul pe care rulează
Oracle (adesea denumit gazdă sau server de baze de date).
2.
Un computer ce
rulează o aplicaţie (o maşină locală sau o staţie
client) rulează aplicaţia într-un proces utilizator. Aplicaţia
client încearcă să realizeze o conexiune cu serverul folosind
driverul de reţea Oracle corespunzător.
3.
Serverul
rulează driverul de reţea corespunzător. Serverul
detectează cererea de conectare din partea aplicaţiei şi
creează un proces server dedicat în favoarea procesului utilizator.
4.
Utilizatorul
rulează o declaraţie SQL şi validează tranzacţiile. De
exemplu, utilizatorul schimbă numele unei linii dintr-un tabel.
5.
Procesul server
primeşte declaraţia şi verifică dacă există în
zona de date comune o arie SQL partajată ce conţine o declaraţie
SQL similară. Dacă este găsită o asemenea arie, atunci
procesul server verifică privilegiile de acces ale utilizatorului la
datele cerute, apoi este folosită la procesarea declaraţiilor.
Dacă nu a fost găsită asemenea arie, atunci se alocă o
nouă arie SQL partajată, care poate fi analizată şi
procesată.
6.
Procesul server
îşi găseşte datele necesare din fişierul de date actual sau
din cele stocate în SGA.
7.
Procesul server
modifică datele din SGA. Procesul DBWn scrie pe disc blocurile modificate
permanent atunci când este eficient. Deoarece tranzacţia este
validată, procesul LGWR înregistrează imediat tranzacţia în
jurnalul redo.
8.
Dacă
tranzacţia s-a efectuat cu succes, procesul server trimite un mesaj prin
reţea către aplicaţie. Dacă nu s-a efectuat cu succes,
atunci este transmis un mesaj de eroare.
9.
Pe durata acestei
proceduri celelalte procese de background rulează, urmărind
apariţia unor condiţii ce necesită intervenţie. În plus,
serverul da baze de date se ocupă cu tranzacţii ale altor utilizatori
şi previne conflictele dintre tranzacţii ce necesită aceleaşi
date.
1.4. Arhitectura
aplicaţiilor
Există două moduri uzuale de proiectare a unei baze de date:
client / server sau multistrat.
1.4.1. Arhitectura
client / server
Multiprocesarea foloseşte mai mult de un procesor pentru un set de
sarcini înrudite. Procesarea distribuită reduce încărcarea unui
singur procesor prin faptul că permite diferitor procesoare să se
concentreze asupra unui subset de sarcini înrudite, acest lucru
îmbunătăţind performanţa şi capacităţile
unui sistem ca un întreg.
Un sistem de baze de date Oracle poate profita cu uşurinţă
de procesarea distribuită folosind arhitectura sa client / server. În
această arhitectură, sistemul de baze de date este divizat în
două părţi: un client şi un server.
Clientul este capătul din faţă al aplicaţiei, accesat
de un utilizator prin intermediul tastaturii, monitorului şi a mouse-ului.
Clientul nu are nici o responsabilitate asupra accesului la date. El cere,
procesează şi prezintă date manevrate de server. Staţia
client poate fi optimizată pentru sarcina ei. De exemplu, ar putea să
nu aibă nevoie de capacitate mare de stocare, dar ar putea beneficia de
capacităţi grafice.
Adesea, clientul rulează pe un computer diferit decât serverul de baze
de date, în general un PC. Mai mulţi clienţi pot rula simultan
legaţi cu acelaşi server.
Serverul rulează software Oracle şi se ocupă de
funcţiile necesare pentru accesul concurent, partajat la date. serverul
primeşte şi procesează declaraţii SQL şi PL / SQL care
provin din aplicaţiile client. Computerul server poate fi optimizat pentru
sarcinile sale. De exemplu, poate avea capacitate de memorare mare şi
procesoare rapide.
1.4.2. Arhitectura
multistrat: Server-ele de aplicaţii
O arhitectură multistrat are următoarele componente:
-
un proces client
sau iniţiator care porneşte o operaţie;
-
unul sau mai multe
servere de aplicaţii ce execută părţi ale operaţiei.
Un server de aplicaţii asigură accesul clientului la date şi
realizează o parte din procesarea interogărilor, în acest fel
eliminând o parte din munca serverului de baze de date. El poate servi drept
interfaţă între clienţi şi mai multe servere de baze de
date, inclusiv asigurarea unui nivel adiţional de securitate;
-
un capăt sau
un server de baze de date ce stochează majoritatea datelor folosite în
operaţii.
Această arhitectură permite serverul de
aplicaţii să:
-
valideze
formularele de acreditare ale unui client, cum ar fi un browser Web;
-
se conecteze la un
server de baze de date Oracle;
-
execute
operaţiile cerute în folosul clientului.
Identitatea clientului este menţinută de-a lungul tuturor
straturilor conexiunii.
1.5. Baze de date
distribuite
O bază de date distribuită este o reţea de baze de date
manipulate de mai multe servere de baze de date folosite împreună. În mod
normal ele nu sunt văzute ca o singură bază de date logică.
Datele din toate bazele de date din baza de date distribuită pot fi
accesate şi modificate simultan. Beneficiul principal al unei baze de date
distribuită constă prin faptul că datele din baze de date
separate fizic pot fi combinate logic şi potenţial făcute
accesibile tuturor utilizatorilor din reţea.
Fiecare computer ce se ocupă cu o bază de date în baza de date
distribuită se numeşte nod. Baza
de date la care un utilizator este conectat direct se numeşte bază de date locală. Orice
altă bază de date accesată de utilizator se numeşte bază de date îndepărtată.
Când o bază de date locală accesează o bază de date
îndepărtată pentru informaţii, baza de date locală este un
client al serverului îndepărtat. Acesta este un exemplu de
arhitectură client / server.
O legătură între baze de
date descrie o cale de la o bază de date la alta. Legăturile de
baze de date sunt folosite implicit când este făcută o
referinţă către un anumit obiect dintr-o bază de date
distribuită.
În timp ce baza de date distribuită permite accesul mărit
către o cantitate mare de date de-a lungul unei reţele, ea trebuie de
asemenea să ascundă locaţia datelor şi complexitatea
accesării acestora de-a lungul reţelei. Sistemul de management al
bazei de date distribuite trebuie de asemenea să menţină
avantajul administrării fiecărei baze de date locale ca şi cum
acestea nu ar fi fost distribuite.
Transparenţa locaţiei apare atunci când locaţia fizică
a datelor este transparentă aplicaţilor şi utilizatorilor
sistemului de baze de date. Mai multe
facilităţi Oracle, cum ar fi de exemplu vederile, procedurile şi
sinonimele pot asigura transparenţa locaţiei. De exemplu, o vedere
care realizează o joncţiune între mai multe baze de date asigură
transparenţa locaţiei deoarece utilizatorul vederii nu are nevoie
să ştie de unde provin datele.
Autonomia locaţiei reprezintă faptul că fiecare bază de
date participantă într-o bază de date distribuită este
administrată separat şi independent de celelalte baze de date, ca
şi cum fiecare bază de date nu ar fi fost în reţea. Cu toate
că fiecare bază de date poate lucra cu celelalte, acestea sunt
sisteme distincte, separate.
Arhitectura Oracle cu baze de date distribuite suportă toate tipurile
de operaţii DML, inclusiv interogări, inserări, actualizări
şi ştergeri de date din tabelele îndepărtate. Pentru a accesa
tabelele îndepărtate, se face o referinţă către numele
obiectului îndepărtat. Nu este necesară nici o sintaxă
codată sau complexă pentru a accesa datele îndepărtate.
SELECT * FROM
employees@sales;
Oracle asigură aceeaşi
consistenţă a datelor într-un mediu distribuit ca şi într-un
mediu nedistribuit. El realizează acest lucru folosind modelul
tranzacţiilor şi mecanismul de validare în două faze.
1.5.1. Duplicare
Duplicarea este procesul de copiere şi menţinere a obiectelor
bazei de date cum ar fi tabelele, în mai multe baze de date ce compun un sistem
de baze de date distribuite. Schimbările aplicate unei locaţii sunt
preluate şi stocate local înainte să fie transmise mai departe
şi aplicate fiecărei locaţii îndepărtate. Duplicarea este o
facilitate integrată a serverului Oracle. Ea nu este un server separt.
Duplicarea foloseşte tehnologia bazelor de date distribuite pentru a
partaja date între mai multe locaţii, dar o bază de date duplicat
şi o bază de date distribuită nu sunt acelaşi lucru. Într-o
bază de date distribuită datele sunt disponibile la mai multe
locaţii, dar un anumit tabel este rezident la o singură locaţie.
Sistemele de baze de date distribuite realizează adesea replici locale
ale tabelelor îndepărtate ce sunt interogate des de utilizatorii locali.
Având copii ale datelor din diferite noduri, accesate foarte des, baza de date
distribuită nu trebuie să trimită în mod repetat informaţii
de-a lungul reţelei, maximizând astfel performanţele
aplicaţiilor.
Datele pot fi duplicate utilizând vederi materializate.
Oracle suportă vederi materializate ce sunt ierarhice şi
actualizabile. Duplicarea multistrat asigură o flexibilitate
mărită a proiectării a aplicaţiilor distribuite. Utilizând
vederi multistrat materializate aplicaţiile pot manipula seturi de date
multinivel fără nici o conexiune directă între nivele.
O vedere materializată actualizabilă permite inserarea,
actualizarea şi ştergerea liniilor din vedere şi propagă
aceste schimbări către tabelul ţintă. Este suportată
duplicarea sincronă şi asincronă.
Fig
1.4 Arhitectură multistrat
În Oracle9i rutinele de rezolvare a conflictelor sunt definite la nivelul
cel mai înalt, locaţia master, şi sunt transmise la nevoie către
locaţiile vederilor materializate actualizabile. Acest lucru face
posibilă existenţa vederilor materializate multistrat. Există
metode de rezolvare a conflictelor definite de sistem.
În plus, utilizatorii pot scrie propriile lor rutine de rezolvare a
conflictelor. O metodă de rezolvare a conflictelor definită de
utilizator este o funcţie PL / SQL ce returnează true sau false. True
indică faptul că metoda a fost capabilă să rezolve cu
succes toate modificările conflictuale pentru un grup de coloane.
1.5.2. Şiruri
Şirurile Oracle permit partajarea datelor
şi evenimentelor într-un şir de date, fie în interiorul unei baze de
date, fie de la o bază de date la alta. Şirul direcţionează
o anumită informaţie către destinaţii specificate.
Şirurile Oracle asigură capacităţile necesare
construcţiei şi operării aplicaţiilor distribuite,
depozitelor de date şi soluţii de înaltă disponibilitate. Se pot
folosi toate facilităţile şirurilor Oracle în acelaşi timp.
Dacă necesităţile sunt schimbate, pot fi implementate noi
facilităţi ale şirurilor fără a le sacrifica pe cele
existente.
Se pot folosi şirurile pentru:
-
preluarea
schimbărilor într-o bază de date;
-
aşezarea
într-o coadă a evenimentelor. Două tipuri de evenimente se pot afla
într-o coadă a unui şir: LCR-uri şi mesaje utilizator;
-
propagarea
evenimentelor dintr-o coadă în alta. Aceste cozi se pot afla în
aceeaşi bază de date sau în baze de date diferite;
-
eliminarea din
coadă a evenimentelor;
-
aplicarea
evenimentelor unei baze de date.
Alte facilităţi ale şirurilor:
-
tag-uri în
capturarea LCR-urilor;
-
reţele
adresate;
-
detecţia
şi rezolvarea automată a conflictelor;
-
transformări;
-
partajarea
informaţiilor eterogene.
1.5.3.
Metode avansate de aşezare în coadă
Aceste metode asigura o infrastructură pentru aplicaţii
distribuite pentru a comunica asincron folosind mesaje.
Mesajele circulă între clienţi şi servere cât şi între
procese pe servere diferite. Un sistem de transmitere a mesajelor eficient
implementează rutarea bazată pe conţinut, subscrierea şi
interogarea.
Un sistem de mesaje poate fi de două tipuri:
-
comunicaţie
sincronă
-
comunicaţie
asincronă
Comunicaţia sincronă este bazată pe paradigma cerere /
răspuns – un program trimite o cerere unui alt program şi
aşteaptă până la sosirea răspunsului.
Acest model de comunicaţie (denumit de asemenea online sau conectat)
este nimerit programelor ce necesită primirea răspunsului înainte ca
ele să-şi pornească activitatea. Arhitecturile tradiţionale
client / server se bazează pe acest model.
În modelul asincron programele comunică plasând cereri în coadă
şi apoi trecând la executarea sarcinilor lor.
De exemplu, o aplicaţie ar putea cere intrări de date sau
execuţia unei operaţii după ce sunt întrunite anumite
condiţii. Programul căruia i-a fost adresată cererea opreia din
coadă şi o tratează. Acest model este potrivit aplicaţiilor
ce î-şi pot continua munca după plasarea unei cereri în coadă –
ele nu sunt blocate în aşteptarea unui răspuns.
1.5.4.
Servicii eterogene
Serviciile eterogene sunt necesare pentru accesarea unui sistem de baze de
date non-Oracle. Termenul de „sistem de bază de date non-Oracle” se
referă la următoarele:
-
orice sistem
accesat de proceduri PL / SQL scrise în C (deci de proceduri externe);
-
orice sistem
accesat prin intermediul SQL;
-
orice sistem
accesat procedural.
Serviciile eterogene permit utilizatorilor următoarele:
-
folosirea
declaraţiilor SQL Oracle pentru a prelua date stocate în sisteme
non-Oracle;
-
folosirea
apelurilor de procedură Oracle pentru a accesa servicii non-Oracle,
sisteme non-Oracle sau interfeţe de programare a aplicaţiilor (APIs)
în interiorul unui mediu Oracle distribuit.
Serviciile eterogene sunt aplicate în general într-unul din
următoarele două moduri:
-
Oracle Transparent
Gateway este folosit în conjuncţie cu serviciile eterogene pentru a accesa
un anumit sistem non-Oracle;
-
Este folosită
conectivitatea generică a serviciilor eterogene pentru a accesa o
bază de date non-Oracle prin intermediul interfeţelor ODBC sau OLE
DB.
1.6.
Concurenţa şi consistenţa datelor
Cerinţe:
-
datele trebuie
citite şi modificate într-un mod consistent;
-
concurenţa
datelor într-un sistem multiuser trebuie maximizată;
-
înaltă
performanţă pentru productivitate maximă din partea multiplilor
utilizatori ai sistemului de baze de date.
1.6.1
Concurenţa
O preocupare principală a sistemului de management a unei baze de date
multiuser este controlul concurenţei, concurenţă ce
înseamnă accesarea simultană a aceleiaşi date de către mai
mulţi utilizatori. Fără controlul adecvat al concurenţei
datele pot fi actualizate sau modificate într-un mod impropriu
compromiţând integritatea datelor.
Dacă mai mulţi oameni accesează aceeaşi dată, o
modalitate de a controla concurenţa datelor constă în aşteptarea
rândului de către fiecare utilizator. Scopul unui sistem de management al
bazei de date este de a reduce această aşteptare astfel încât să
fie ori inexistentă ori neglijabilă pentru fiecare utilizator. Toate
declaraţiile în limbaj de manipulare a datelor trebuie executate
interferând cât mai puţin posibil, şi interacţiunile distructive
între tranzacţii concurente trebuie prevenite. O interacţiune
distructivă este o interacţiune care actualizează incorect
datele sau modifică incorect structurile de date. nici performanţa
nici integritatea datelor nu pot fi sacrificate.
Oracle rezolvă aceste probleme utilizând diferite tipuri de
blocări şi un model de consistenţă variată.
1.6.2. Consistenta
la citire
Consistenţa la citire în Oracle realizează următoarele
lucruri:
-
garantează
faptul că setul de date văzute de o declaraţie este consistent
relativ la un anumit moment în timp şi nu se schimbă în timpul
execuţiei declaraţiei (consistenţa la citire la nivelul
declaraţiei);
-
asigură
faptul că cititorii datelor din baza de date nu aşteaptă
alţi utilizatori ce scriu sau citesc aceleaşi date;
-
asigură
faptul că utilizatorii ce scriu în baza de date nu aşteaptă
cititorii aceloraşi date;
-
asigură
faptul că utilizatorii care scriu în baza de date aşteaptă doar
alţi utilizatori ce scriu în baza de date dacă aceştia
încearcă să actualizeze linii identice în tranzacţii concurente.
Pentru a manipula un model de consistenţă multiplă, Oracle
trebuie să creeze un set de date consistent la citire când un tabel este
interogat (citire) şi în acelaşi timp actualizat (scriere). Când
apare o actualizare datele originale modificate sunt memorate în
înregistrările undo ale bazei de date. cât timp această actualizare
face parte dintr-o tranzacţie nevalidată, orice utilizator care
interoghează mai târziu datele modificate vede valorile originale ale
datelor.
Doar atunci când tranzacţia este validată modificările
realizate în tranzacţie sunt făcute permanente. Declaraţiile ce
sunt pornite după ce tranzacţia este validată văd doar
modificările realizate de aceasta.
Oracle oferă implicit garanţia consistenţei la citire la
nivelul declaraţiei. Setul de date returnate de o singură interogare
este consistent relativ la un singur moment din timp. În unele situaţii
însă este necesară o consistenţă la citire la nivelul
tranzacţiei. Aceasta este abilitatea de a rula mai multe interogări
într-o singură tranzacţie, interogări consistente la citire
relativ la acelaşi moment din timp, astfel încât interogările din
acestă tranzacţie nu văd efectele intervenţiei
tranzacţiilor validate.
În cazul executării mai multor interogări asupra mai multor
tabele şi nu se realizează nici o actualizare, este preferată o
tranzacţie read-only. După indicarea faptului că această
tranzacţie este read-only, este posibilă rularea oricâtor interogări
asupra oricărui tabel, ştiind că rezultatele fiecărei
interogări sunt consistente relativ la acelaşi moment din timp.
1.6.3.
Mecanismul blocărilor
Oracle foloseşte de asemenea blocări pentru a controla accesul
concurent al datelor. Blocările sunt mecanisme create pentru a preveni
interacţiunile distructive dintre utilizatori.
Blocările sunt folosite pentru a asigura consistenţă şi
integritate. Consistenţa înseamnă că datele pe care un
utilizator le vede sau le modifică nu sunt modificate (de către alt utilizator)
până în momentul în care primul utilizator nu a terminat. Integritatea
înseamnă faptul că datele şi structurile din baza de date
reflectă toate modificările făcute asupra lor în ordinea
corectă.
Blocările oferă garanţia integrităţii datelor
şi în acelaşi timp acces concurent maxim la date de către un
număr nelimitat de utilizatori.
Blocarea în Oracle este realizată automat şi nu necesită
acţiuni ale utilizatorului. Blocarea implicită se realizează
pentru declaraţii SQL atunci când este necesar în funcţie de
acţiunea solicitată.
Blocările sunt realizate automat de către lock manager-ul Oracle.
Acesta blochează automat tabelele la nivelul liniilor. Blocând datele din
tabel la nivelul liniilor, concurenţa la aceleaşi date este
minimizată.
Lock manager-ul menţine tipuri diferite de blocări, în
funcţie de tipul operaţiei care a determinat blocarea. Cele două
tipuri generale de blocări sunt blocarea
exclusivă şi blocarea
partajată. Doar o blocare exclusivă poate fi aplicată asupra
unei resurse (cum ar fi o linie sau un tabel); în orice caz, mai multe
blocări partajate pot fi plasate asupra unei singure resurse. Atât
blocarea exclusivă cât şi cea partajată permit interogarea
resurselor blocate dar interzic alte operaţii asupra resursei (cum ar fi
actualizări şi ştergeri).
În anumite circumstanţe, un utilizator ar putea dori să
suprascrie o anumită blocare implicită. Oracle permite suprascrierea
manuală a blocării automate, atât la nivelul liniei (interogând mai
întâi care linii vor fi actualizate într-o subinterogare) cât şi la
nivelul tabelului.
1.7.
Securitatea bazelor de date
Oracle include facilităţi de securitate ce controlează modul
în care baza de date este accesată sau utilizată. De exemplu,
mecanismele de securitate:
-
previn accesul
neautorizat la baza de date;
-
previn accesul
neautorizat la obiectele schemă;
-
realizează
monitorizări asupra acţiunilor utilizatorilor.
Fiecărui utilizator de baze de date îi este asociată o
schemă cu acelaşi nume. Fiecare utilizator de baze de date
creează şi are acces în mod implicit la toate obiectele din schema ce
îi corespunde.
Securitatea bazelor de date poate fi clasificată în: securitatea sistemului şi securitatea datelor.
Securitatea sistemului include mecanismele ce controlează accesul
şi utilizarea bazei de date la nivelul sistem. De exemplu, securitatea
sistem include:
-
combinaţii
valide nume utilizator / parolă;
-
spaţiul de
memorie disponibil pentru obiectele schemă ale unui utilizator;
-
limitele de
resurse pentru un utilizator.
Mecanismele de securitate a sistemului verifică dacă un
utilizator este autorizat să se conecteze la o bază de date,
dacă mecanismul de revizie a bazei de date este activ şi ce
operaţii sistem pot fi executate de către un utilizator.
Securitatea datelor include mecanisme de control al accesului şi
utilizării bazei de date la nivelul obiectelor schemă. De exemplu,
securitatea datelor include:
-
care utilizatori
au acces lan o anumită schemă obiect şi tipurile specifice de
acţiuni permise pentru fiecare utilizator al obiectului schemă (de
exemplu, utilizatorul SCOTT poate executa SELECT şi INSERT dar nu şi
DELETE asupra tabelului employees);
-
acţiunile,
dacă există vreuna, ce sunt luate în calcul pentru fiecare obiect
schemă;
-
codarea datelor
pentru a preveni utilizatorii neautorizaţi să acceseze datele din
Oracle.
Serverul Oracle asigură un control discret al accesului, care
reprezintă un acces restricţionat la informaţie bazat pe
privilegii. Un privilegiu potrivit trebuie asociat unui utilizator pentru ca
acesta să poată accesa un obiect schemă. Utilizatorii care au
privilegii pot de asemenea acorda privilegii altor utilizatori.
Oracle manipulează securitatea bazelor de date folosind diferite
facilităţi:
-
utilizatori de
baze de date şi scheme;
-
privilegii;
-
roluri;
-
setări
şi limite de stocare;
-
profiluri şi
limite de resurse;
-
monitorizare
selectivă a acţiunilor utilizatorilor;
-
monitorizare de
granularitate fină.
Fig 1.5
Facilităţi de securitate Oracle
Fiecare bază de date Oracle are propria listă de utilizatori.
Pentru a accesa o bază de date, un utilizator trebuie să
folosească o aplicaţie cu baze de date şi să încerce
să se conecteze cu un nume de utilizator valid al bazei de date. Fiecare nume
de utilizator are asociată o parolă pentru a preveni utilizarea
neautorizată.
Fiecare utilizator are un domeniu de securitate, domeniu ce reprezintă
un set de proprietăţi ce determină:
-
acţiunile
(privilegii şi roluri) disponibile utilizatorului;
-
spaţiul
disponibil pe disc pentru utilizatori;
-
limita resurselor
sistem (de exemplu, timpul de procesare CPU) pentru utilizatori.
Un privilegiu este dreptul de a rula un anume tip de declaraţie SQL.
Exemple de privilegii:
-
conectarea la baza
de date (crearea unei sesiuni);
-
crearea unui tabel
în schemă;
-
selectarea
liniilor din tabelul altui utilizator;
-
executarea unei
proceduri ce aparţine altui utilizator.
Privilegiile într-o bază de date Oracle se împart în privilegii sistem şi privilegii asupra obiectelor schemă.
Privilegiile sistem permit utilizatorilor să realizeze o anumită
acţiune generală asupra sistemului sau o anumită acţiune
asupra unui anumit tip de obiect schemă. De exemplu, privilegiile de a crea
tabele sau de a şterge linii din orice tabel din baza de date sunt
privilegii sistem. Multe din privilegiile sistem sunt disponibile doar
administratorilor şi proiectanţilor de aplicaţii deoarece sunt
foarte puternice.
Privilegiile asupra obiectelor schemă permit utilizatorilor să
realizeze o anumită acţiune asupra unui obiect schemă
specificat. De exemplu, privilegiul de a şterge linii dintr-un tabel
specificat este un privilegiu obiect. Privilegiile obiect sunt acordate
(asociate) utilizatorilor astfel încât aceştia să poată folosi o
aplicaţie pentru a realiza anumite sarcini.
Privilegiile sunt acordate utilizatorilor astfel încât aceştia să
poată accesa şi modifica datele din baza de date. Un utilizator poate
primi un privilegiu în două moduri diferite:
-
privilegiile pot
fi acordate utilizatorilor explicit. De exemplu, privilegiul de a insera
înregistrări în tabelul employees poate fi acordat explicit utilizatorului
SCOTT;
-
privilegiile pot
fi acordate anumitor roluri (grupuri de privilegii) şi apoi rolul poate fi
acordat unuia sau mai multor utilizatori. De exemplu, privilegiul de a insera
înregistrări în tabelul employees poate fi acordat rolului numit CLERK,
care la rândul său poate fi acordat utilizatorilor SCOTT şi BRIAN.
Deoarece rolurile permit o manipulare mai uşoară şi mai
bună a privilegiilor, privilegiile sunt în mod normal acordate rolurilor
şi nu utilizatorilor.
Roluri
Rolurile sunt grupuri (ce poartă un nume) de privilegii înrudite ce
pot fi acordate utilizatorilor sau altor roluri.
Oracle asigură un mod de a limita şi asocia folosirea
spaţiului de memorie alocat fiecărui utilizator de baze de date,
incluzând tabele temporare şi implicite şi partiţionarea
tabelelor.
Fiecărui utilizator îi este asociat un profil ce specifică
limitările asupra mai multor resurse sistem disponibile utilizatorului,
incluzând următoarele:
-
numărul de
sesiuni concurente pe care le poate deschide utilizatorul;
-
timpul de
procesare CPU disponibil pentru:
o
sesiunea
utilizator;
o
un singur apel
către Oracle realizat de o declaraţie SQL.
-
numărul de
intrări / ieşiri logice disponibile pentru:
o
sesiunea
utilizator;
o
un singur apel
către Oracle realizat de o declaraţie SQL.
-
timpul disponibil
pentru o sesiune utilizator;
-
timpul de
conectare disponibil pentru sesiune utilizator;
-
restricţii cu
parole:
o
blocarea contului
după mai multe încercări de conectare eşuate;
o
expirarea parolei
şi perioadei de graţie;
o
reutilizarea
parolei şi restricţiei de complexitate.
Pot fi create profiluri diferite şi asociate individual fiecărui
utilizator al bazei de date. Există un profil implicit pentru toţi
utilizatorii care nu au asociat un profil explicit. Facilităţile de
limitare a resurselor previn consumul excesiv de resurse sistem ale bazei de
date.
Oracle permite monitorizarea (monitorizarea înregistrată)
selectivă a acţiunilor utilizatorilor pentru a o folosi la investigarea
utilizării suspecte a bazelor de date. Monitorizarea poate fi
realizată pe trei nivele diferite:
-
Monitorizarea
declaraţiilor;
-
Monitorizarea
privilegiilor;
-
Monitorizarea
obiectelor schemă.
Monitorizarea de granularitate fină permite supravegherea accesului la
date bazată pe conţinut. În general, aceasta constă în predicate
SQL simple definite de utilizator asupra tabelelor ca şi condiţii de
monitorizare selectivă.
1.8. Administrarea
bazelor de date
Persoanele care administrează operaţiile într-un sistem de baze
de date Oracle, cunoscute sub numele de administratori de baze de date (DBAs),
sunt responsabile de crearea bazelor de date Oracle, asigurarea operării
în condiţii optime şi monitorizarea folosirii acestora.
1.8.1 Enterprise
Manager
Enterprise Manager este un instrument de management al sistemului ce
asigură o soluţie integrată pentru manipularea centralizată
a unui mediu eterogen. Combinând o consolă grafică, server-ele de
management Oracle, agenţii inteligenţi Oracle, serviciile
obişnuite şi instrumentele de administrare, Enterprise Manager
asigură o interfaţă lejeră pentru manipularea produselor
Oracle.
De la interfaţa client, consola Enterprise Manager, se pot realiza
următoarele acţiuni:
-
administrarea mediului
Oracle, incluzând bazele de date, servere iAS, aplicaţii şi servicii;
-
diagnosticarea,
modificarea şi acordarea mai multor baze de date;
-
programarea
sarcinilor pe mai multe sisteme la diferite intervale de timp;
-
monitorizarea
condiţiile bazei de date de-a lungul reţelei;
-
administrarea mai
multor noduri de reţele şi serviciilor din mai multe locaţii;
-
partajarea
sarcinilor cu alţi administratori;
-
gruparea
scopurilor înrudite pentru a facilita cerinţele de administrare;
-
lansarea
obiectelor Oracle integrate şi instrumentelor third-party;
-
personalizarea
afişajului unui administrator Enterprise Manager.
1.8.2. Copii de siguranţă şi
recuperarea bazei de date
Structurile şi mecanismele folosite de Oracle permit:
-
recuperarea bazei
de date în cazul apariţiei diferitor tipuri de defecţiuni;
-
operaţii
flexibile de recuperare potrivite oricăror situaţii;
-
disponibilitatea
datelor în timpul operaţiilor de recuperare şi creare a copiilor de
siguranţă astfel încât utilizatorii sistemului să-şi
poată continua munca.
În fiecare sistem de baze de date, există întotdeauna posibilitatea
unei defecţiuni a sistemului sau unei defecţiuni hardware. Dacă
apare o defecţiune ce afectează baza de date, aceasta trebuie
recuperată. Scopurile care trebuie urmărite după apariţia
unei defecţiuni sunt de asigurare că efectele tuturor
tranzacţiilor validate sunt reflectate în baza de date recuperată
şi de returnare la operare normală cât mai rapid posibil, separând
utilizatorii de problemele cauzate de defecţiune.
Diferite circumstanţe pot întrerupe operarea într-o bază de date
Oracle. Cele mai obişnuite tipuri de defecţiuni sunt descrise în
tabelul următor:
Defecţiune |
Descriere |
Eroare
utilizator |
Necesită ca baza de date să fie refăcută până la
un punct din timp înaintea apariţiei erorii. De exemplu, un utilizator
ar putea şterge accidental un tabel. Pentru a permite refacerea în cazul
apariţiei erorilor utilizatorilor şi pentru a acomoda alte
cerinţe de refacere unice, Oracle asigură o refacere de exactitate
mare raportat la momente de timp. De exemplu, dacă un utilizator
şterge accidental un tabel, baza de date poate fi refăcută
până în momentul imediat anterior ştergerii tabelului. |
Eroare de declaraţie |
Această eroare apare atunci când există o defecţiune
logică în manipularea declaraţiilor dintr-un program Oracle. Când
apare o eroare de declaraţie orice efecte ale declaraţiei sunt
automat anulate de către Oracle şi controlul este returnat
utilizatorului. |
Eroare de proces |
Rezultă dintr-o eroare de acces la Oracle a unui proces utilizator,
cum ar fi o deconectare anormală sau terminarea unui proces. Procesul de
background PMON detectează automat procesele utilizator eşuate,
derulează înapoi tranzacţia nevalidată a procesului utilizator
şi eliberează orice resurse pe care le folosea procesul. |
Eroare de instanţă |
Această eroare apare atunci când există o problemă ce
împiedică o instanţă să-şi continue activitatea.
Eroarea de instanţă poate rezulta dintr-o problemă hardware,
cum ar fi o cădere de tensiune, sau o problemă software, cum ar fi
o eroare a sistemului de operare. Atunci când apare o eroare de
instanţă, datele din buffer-ele SGA nu sunt scrise în
fişierele de date. După o eroare de instanţă, Oracle realizează automat
o refacere a instanţei. |
Defecţiune a suportului de memorare |
Există posibilitatea apariţiei unei erori atunci când se
încearcă scrierea sau citirea unui fişier pe / de pe disc care
trebuie să realizeze operaţii asupra bazei de date. un exemplu
uzual este defecţiunea capului de citire a discului, ce cauzează
pierderea tuturor fişierelor de pe acel disc. Fişiere diferite pot fi
afectate de acest tip de defecţiune, inclusiv cele de date,
fişierele jurnal de refacere şi fişierele de control. În plus,
deoarece instanţa bazei de date nu poate continua să
funcţioneze corect, datele din buffer-ele SGA nu pot fi scrise în
fişierele de date. O eroare a suportului de memorare necesită restaurarea
fişierelor pierdute. Spre deosebire de refacerea instanţei,
refacerea datelor de pe disc trebuie iniţiată de către
utilizator. Recuperarea datelor de pe disc actualizează fişierele
de date restaurate astfel încât informaţia din ele să
corespundă celui mai recent moment de timp marcat înaintea
defectării suportului de memorare, inclusi datele din memorie validate
ce au fost pierdute din cauza defecţiunii. |
Oracle asigură recuperarea completă a datelor de pe suportul de
memorare in toate cazurile de defecţiuni hardware posibile, inclusiv
defecţiuni ale discului. Opţiunile permit recuperarea
parţială sau completă până într-un anumit moment din timp.
Dacă unele fişiere de date sunt afectate de defecţiunea
suportului de memorare dar cea mai mare parte a bazei de date este intactă
şi operaţională, baza de date poate rămâne deschisă în
timp ce tabelele sunt recuperate individual. Din acest motiv, porţiunile
neafectate de defecţiuni ale unei baze de date sunt disponibile pentru
utilizare normală în timp ce porţiunile defecte sunt refăcute.
Oracle utilizează mai multe structuri pentru a asigura recuperarea
completă în cazul unei erori de instanţă sau chiar a suportului
de memorare: jurnalul de recuperare, înregistrările undo si copiile de
siguranţă ale bazei de date.
Jurnalul de recuperare este un set de fişiere ce protejează
datele din memoria interna modificate şi care încă nu au fost scrise
în fişierele de date. Jurnalul constă din două părţi:
jurnalul de recuperare online şi jurnalul de recuperare arhivat.
Jurnalul de recuperare online este un set de două sau mai multe
fişiere redo log online care înregistrează toate modificările
făcute asupra bazei de date, atât cele validate cât şi cele
nevalidate. Intrările redo sunt stocate temporar în buffer-ele redo log
ale SGA, iar procesul LGWR scrie intrările redo secvenţial într-un
fişier red log online. LGWR scrie aceste intrări secvenţial
şi de asemenea scrie înregistrările validate de fiecare dată
când un proces utilizator validează o tranzacţie.
Opţional, fişierele redo online pline pot fi arhivate manual sau
automat înainte să fie refolosite, creându-se astfel jurnalele de
recuperare arhivate.
Pentru activarea sau dezactivarea opţiunii de arhivare, baza de date trebuie setată într-unul din
modurile:
-
ARCHIVELOG
-
NONARHIVELOG
În modul ARHIVELOG baza de date
poate fi recuperată atât în cazulş erorilor de instanţă cât
şi în cazul erorilor suportului de memorare. De asemenea, pot fi
făcute copii de siguranţă ale bazei de date in timp ce aceasta
este deschisă şi disponibilă pentru utilizare.
Dacă jurnalul de recuperare a bazei de
date operează în modul NONARHIVELOG, baza de date poate fi recuperată
complet în cazul unei erori de instanţă dar nu şi în cazul unei
erori a suportului de memorare. De asemenea, copiile de siguranţă ale
bazei de date pot fi făcute doar în timp ce aceasta este complet
închisă.
Aceste înregistrări pot fi stocate fie
în tabele undo fie în segmente rollback. Oracle utilizează
informaţiile undo dintr-o varietate de motive, inclusiv accesarea imaginii
– înainte a blocurilor modificate în cadrul tranzacţiilor nevalidate. În
timpul refacerii bazei de date, Oracle aplică toate modificările
memorate în jurnalul de recuperare şi apoi foloseşte informaţia
undo pentru a derula înapoi orice tranzacţie nevalidată.
Aceste fişiere ale bazei de date
păstrează, printre altele, informaţii despre structura
fişierelor bazei de date şi numărul secvenţei de jurnal
care este scrisă curent de către LGWR. În timpul procedurilor normale
de recuperare, informaţia dintr-un fişier de control este
folosită la ghidarea avansării automate în operaţia de
recuperare. Oracle poate multiplexa fişierele de control adică
să menţină simultan un anumit număr de fişiere de
control identice.
Deoarece unul sau mai multe fişiere
pot fi afectate fizic de defecţiunile apărute la disc, recuperarea în
astfel de cazuri necesită restaurarea fişierelor stricate după
la cea mai recentă copie de siguranţă a bazei de date.
Se pot face aceste copii fie cu ajutorul
lui Recovery Manager, care este recomandat, fie folosind utilitarele sistemului
de operare. Recovery Manager (RMAN) este o utilitate Oracle care se ocupă
cu crearea copiilor de siguranţă şi cu refacerea bazei de date.
1.9.
Depozitarea datelor
Un depozit de date
este o bază de date relaţională proiectată pentru
interogare şi analiză mai degrabă decât pentru procesarea
tranzacţiilor. De obicei conţine date istorice derivate din datele
tranzacţiilor, dar pot include şi date din alte surse. Ea separă
analiza de tranzacţie şi permite o organizare ce consolidează
date din mai multe surse.
În plus faţă de baza de date relaţională, un depozit de
date include soluţii de extragere, transport, transformare şi
încărcare (ETL), un motor de procesare analitică online (OLAP),
obiecte de analiză a clientului şi alte aplicaţii care să
se descurce cu procesul de adunare a datelor şi de trimitere a lor spre
utilizatorii care se ocupă cu acestea.
1.9.1.
Arhitectura depozitelor de date
Depozitele de date şi arhitecturile lor variază în funcţie
de situaţiile specifice anumitor organizaţii. Trei arhitecturi uzuale
sunt:
-
Arhitectura Data
Warehouse (de bază);
-
Arhitectura Data
Warehouse (cu Staging Area);
-
Arhitectura Data
Warehouse (cu Staging Area şi Data Marts).
Arhitectura Data
Warehouse (de bază)
Figura 1.6 prezintă o arhitectură simplă pentru un depozit
de date.
Fig.
1.6 Arhitectura depozitului de date
Arhitectura Data
Warehouse (cu Staging Area)
Figura 1.7 prezintă acestă arhitectură pentru un depozit de
date.
Fig
1.7. Arhitectură DataWarehouse cu Staging Area
Arhitectura Data
Warehouse (cu Staging Area şi Data Marts)
Figura 1.8 prezintă acestă arhitectură pentru un depozit de
date.
Fig
1.8. Arhitectură DataWarehouse cu Staging Area şi Data Marts
1.9.2.
Vederi materializate
O vedere materializată asigură accesul indirect la datele din
tabele stocând rezultatele unei interogări în obiecte schemă
separate. Spre deosebire de o vedere obişnuită, ce nu ocupă nici
un spaţiu de stocare şi nu conţine nici o dată, o vedere
materializată conţine liniile rezultate dintr-o interogare asupra
unuia sau mai multor tabele sau vederi. O vedere materializată poate fi
stocată în aceeaşi bază de date cu a tabelelor sale de bază
sau într-o bază de date diferită.
Vederile materializate stocate în aceeaşi bază de date cu
tabelele lor de bază pot îmbunătăţi performanţa
interogărilor prin rescrieri de interogări. Rescrierile de
interogări sunt folositoare mai ales în cadrul depozitelor de date.
1.9.3.
OLAP
Oracle integrează procesare analitică online (OLAP) în interiorul
bazei de date pentru a suporta aşa-zisa inteligenţă a
afacerilor. Această integrare asigură puterea unei baze de date
multidimensionale în timp ce menţine şi manevrabilitatea, scalabilitatea
şi fiabilitatea bazei de date Oracle şi accesibilitatea SQL.
Sistemul de management relaţional şi analiza OLAP asigură
funcţionalitatea complementară necesară pentru a suporta un
întreg set de aplicaţii analitice. OLAP poate fi folosit pentru a furniza
capacităţi cum ar fi calcule multidimensionale, forecasting, modeling
şi scenarii what-if. Aceste calcule permit proiectanţilor să
construiască aplicaţii de planificare sofisticate din punct de vedere
analitic cum ar fi analize de vânzări şi marketing, financiare.
Datele pot fi stocate fie în tabele relaţionale, fie în obiecte
multidimensionale, oricare ar fi mai potrivite din punct de vedere al
performanţei şi resurselor. Indiferent de modul de stocare, datele
pot fi manipulate în cadrul motorului OLAP folosind fie Java, fie SQL.
Oracle OLAP constă în următoarele componente:
-
motor de calcul
optimizat pentru calcule rapide;
-
spaţiu de
lucru analitic ce stochează date multidimensionale atât temporar cât
şi permanent;
-
limbajul de
manipulare al datelor OLAP de realizare a modelării matematice, statistice
şi realizare a altor transformări asupra datelor multidimensionale;
-
o
interfaţă SQL către Oracle OLAP care face datele
multidimensionale disponibile către SQL;
-
QLAP API pentru
proiectarea aplicaţiilor Java în inteligenţa afacerilor;
-
depozit de
metadate OLAP ce conţine date multidimensionale pentru OLAP API.
1.9.4. Capturarea
modificării datelor
Capturarea modificărilor datelor constă în identificarea şi
capturarea datelor ce au fost adăugate, actualizate sau şterse din
tabelele relaţionale Oracle şi facerea acestor modificări a
datelor disponibilă pentru utilizare în aplicaţii.
Adesea, depozitarea datelor implică extragerea şi transportul
datelor relaţionale dintr-una sau mai multe baze de date sursă în depozitul
de date pentru analiză. Mecanismul de capturare a modificării datelor
identifică rapid şi procesează doar datele care au fost
modificate, nu întregul tabel, şi face schimbarea datelor disponibilă
pentru o utilizare viitoare.
1.10. Disponibilitate
crescută
Mediile de calcul configurate pentru a fi disponibile full-time sunt
cunoscute cu sub numele de sisteme cu disponibilitate crescută. Asemenea
sisteme au în mod tipic hardware şi software redundant ce fac sistemul
disponibil în ciuda defecţiunilor.
Orice componentă hardware sau software ce poate fi avariată are o
componentă redundantă de acelaşi tip.
Când apare o defecţiune, procesul
remedierii a defecţiunilor transferă procesarea executată de
componenta defectă către componenta ce o acoperă. Acest proces
recuperează tranzacţiile parţial realizate sau eşuate
şi readuce sistemul la normal, de preferinţă într-un interval de
câteva microsecunde. Cu cât procesul remedierii defecţiunilor este mai
transparent utilizatorilor, cu atât este mai mare disponibilitatea sistemului.
1.10.1.
Transparent Aplication Failover
Transparent Aplication Failover (TAF) permite unui utilizator de
aplicaţii să se reconecteze automat la o bază de date dacă
conexiunea eşuează. Tranzacţiile active sunt anulate, dat noua
conexiune la baza de date, realizată prin intermediul unui nod diferit
este identică cu cea originală.
Cu ajutorul TAF, un client nu observă pierderea conexiunii câtă
vreme există o instanţă care serveşte aplicaţia.
Administratorul de baze de date controlează care aplicaţii
rulează şi la ce instanţe şi de asemenea creează o
ordine de aplicare a mecanismului de trecere peste defecţiuni pentru
fiecare aplicaţie.
Există mai multe elemente asociate cu conexiuni active la baza de
date. Acestea includ:
-
conexiuni client /
server;
-
sesiuni de baze de
date ale utilizatorilor, ce execută comenzi;
-
cursoare folosite
pentru fatching;
-
tranzacţii
active;
-
variabile de
program server.
1.10.2.
Reorganizarea online a arhitecturii
Această arhitectură online furnizează următoarele
posibilităţi:
-
orice atribut
fizic al unui tabel poate fi schimbat online. Tabelul poate fi mutat la o
locaţie nouă. Tabelul poate fi partiţionat. Tabelul poate fi
convertit de la un tip de organizare (cum ar fi organizarea heap) către
alt tip (cum ar fi organizarea index);
-
mai multe atribute
logice pot de asemenea fi schimbate. Numele coloanelor, tipurile şi
dimensiunile pot fi schimbate. Pot fi adăugate coloane, şterse sau
îmbinate. O restricţie constă în faptul că cheia primară a
unui tabel nu poate fi modificată;
-
crearea şi
reconstruirea online a indecşilor secundari în tabele organizate pe index
(IOTs);
-
indecşii pot
fi creaţi online şi analizaţi în acelaşi timp;
1.10.3. Protejarea
datelor
Mecanismul de protejare a datelor în Oracle menţine până la nouă baze de date standby, fiecare din ele este o copie în timp real a bazei de date originale, pentru protecţia împotriva tuturor erorilor umane sau non-umane şi împotriva dezastrelor. Dacă apare o defecţiune în baza de date principală, se poate trece la una din bazele de date standby care devine baza de date principală. În plus, timpul necesar menţinerii poate fi redus deoarece se poate trece uşor şi rapid de la baza de date principală curentă la baza de date standby şi înapoi.
O astfel de configuraţie este o colecţie de sisteme liber
conectate, constând dintr-o singură bază de date principală
şi până la nouă baze de date standby ce pot include un amestec
de baze de date standby atât fizice cât şi logice. Aceste baze de date pot
fi conectate printr-o reţea LAN la acelaşi centru de date, sau –
pentru protecţie maximă la dezastre – dispersate geografic sub forma
unor reţele WAN şi conectate prin serviciile de reţea Oracle.
Pe măsură ce tranzacţiile produc modificări în baza de
date principală, aceste modificări sunt stocate local în jurnale de
recuperare, ce sunt trimise către bazele de date standby prin serviciile log transport şi aplicate prin
serviciile log apply.
O bază de date standby fizică este identică fizic cu baza de
date principală. În timp ce baza de date principală este
deschisă şi activă, o bază de date standby fizică fie
realizează recuperare (aplicând jurnale), fie deschisă pentru acces.
O bază de date standby logică preia jurnalele standard de
recuperare arhivate, transformă înregistrările redo pe care le
conţin în tranzacţii SQL şi apoi le aplică unei baze de
date standby deschisă.
Broker-ul mecanismului de protejare a datelor automatizează sarcinile
complexe de creare şi menţinere şi asigură monitorizare
sporită dramatic, alertare şi mecanisme de control.
1.10.4. LogMiner
LogMiner este un instrument relaţional ce permite administratorilor
să folosească SQL pentru a citi, a analiza şi interpreta
fişierele jurnal. LogMiner poate vedea atât jurnalele online cât şi
cele arhivate.
Abilitatea acestui instrument de a accesa datele stocete în jurnalele de
recuperare ajută la realizarea mai multor sarcini de management. De
exemplu, pot fi realizate următoarele:
-
urmărirea
seturilor specifice de schimbări bazate pe tranzacţii, utilizator,
tabel, timp ş.a.m.d.;
-
indicarea faptului
că a fost introdus o modificare incorectă în baza de date;
-
asigurarea
informaţiilor suplimentare pentru acordare şi planificarea
capacităţii;
-
obţinerea
informaţiilor critice pentru depanarea aplicaţiilor complexe.
1.10.5. Grupuri de
aplicaţii reale
Grupurile de aplicaţii reale sunt sisteme de mare disponibilitate.
Aceste medii asigură servicii continue atât pentru ieşiri planificate
cât şi neplanificate.
Grupurile de aplicaţii reale construiesc nivele înalte de
disponibilitate pe baza facilităţilor Oracle standard. Utilizatorii
au acces la toate datele cât timp există un nod disponibil în grup.
1.10.6. Protejarea
grupurilor de aplicaţii reale
Mecanismul de protejare a grupurilor de aplicaţii reale Oracle este o
componentă integrată a grupului de aplicaţii reale şi furnizează
următoarele funcţii:
-
recuperarea
automată, rapidă şi timp limitat de recuperare în cazul
defecţiunilor ce opresc o instanţă Oracle;
-
captura
automată a datelor atunci când anumite tipuri de defecţiuni apar;
-
configuraţie
primară / secundară forţată. Clienţii care se
conectează la Oracle cu ajutorul serviciilor de reţea sunt
rutaţi către nodul principal chiar dacă sunt conectaţi la
alt nod din grup;
-
eliminarea
întârzierilor pe care le resimt clienţii la restabilirea conexiunilor
după o defecţiune.
Un server de baze de date ce rulează grupuri de aplicaţii reale
constă dintr-o bază de date Oracle, software pentru grupuri de
aplicaţii reale şi ascultătorii de reţea ce acceptă
cererile clienţilor. Aceste componente software rulează pe fiecare
nod al grupului.
1.11. Managementul
conţinutului
Oracle asigură o singură platformă pentru crearea,
manipularea şi livrarea de conţinuturi bogate, personalizate
către orice dispozitiv.
Facilităţile pentru managementul conţinutului includ:
-
sistemul de
fişiere internet Oracle (9iFS) asigură atât un sistem de fişiere
out-of-the-box pentru stocarea şi manipularea conţinutului din baza
de date cât şi o platformă robustă pentru proiectarea
aplicaţiilor de management al conţinutului;
-
Oracle interMedia
extrage metadatele din fişiere media (imagini, audio, video) şi
permite manipularea acestor fişiere în baza de date Oracle;
-
Oracle Text
indexează conţinutul textual stocat în baza de date şi permite
realizarea interogărilor sofisticate bazate pe conţinut asupra
acestor indecşi. Baza de date Oracle indexează mai mult de 150n de
tipuri de fişiere document, inclusiv MS Office, Adobe PDF, HTML şi
XML şi suportă peste 40 de limbi;
-
Oracle Ultra
Search asigură cu ajutorul lui Oracle Text un index de conţinuturi
unificat, interogabil stocat în baze de date, fişiere sistem şi
site-uri Web;
-
Oracle eLocation
permite adăugarea de metadate locale şi realizează
căutări spaţiale;
-
Dinamic Services
şi Syndication Server fac mai uşoară agregarea conţinutului
şi îl trimit către subscrişi;
-
serviciile XML
permit analiza şi randarea conţinutului XML;
-
Oracle Portal
simplifică procesul livrării conţinutului către intranet
şi internet şi asigură spaţiu de lucru pentru furnizorii de
conţinuturi;
-
Wireless Edition
of Oracle9i plasează conţinutul bazei de date către dispozitive
fără fir.