1.              Introducere in Oracle Server

 

1.1. Despre structura Bazei de Date şi Managementul Spaţiului de memorie

 

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.

 

1.1.1. Structura logică a bazei de date

 

     Structura logică a unei baze de date Oracle include obiecte schemă, bloc de date, extent, segment şi tablespace.

 

Scheme şi obiecte schemă

    

     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.

 

Tabele

 

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.

 

Vederi

 

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).

 

Tabele Online şi Offline

 

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

 

Fişiere 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ă.

 

Fişierele Redolog

 

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.

 

 

 

Fişiere de control

 

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.

 

Utilizarea fişierelor de control

 

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.

 

Utilităţile datelor

 

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

 

 

Declaraţii DDL

 

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.

 

Declaraţii DML

 

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.

 

Declaraţii de control al tranzacţiilor

 

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.

 

     Declaraţii SQL încorporate

 

     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

 
 
 
 
 
Validarea şi anularea tranzacţiilor

 

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.

 

Consistenţa datelor în utilizarea tranzacţiilor

 

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.

 

Constrângerile de integritate

 

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.

 

 

Chei

 

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.

 

Grupuri de aplicaţii reale: Sisteme cu instanţe multiple

 

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.

 

Aria globală sistem

 

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.

 

Aria globală program

 

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.

 

Procese Oracle

 

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.

 

Software-ul de comunicaţie şi serviciile de reţea Oracle

 

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

 

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

 

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

 

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

 

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.

 

Manipularea bazelor de date distribuite

 

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;

 

Validarea în două faze

 

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.

 

Duplicarea tabelelor

 

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.

 

Vederi multistrat 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

 

Rezolvarea conflictelor

 

Î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ă

 

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.

 

Comunicaţia asincronă

 

Î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.

 

Consistenţa la citire, înregistrările undo şi tranzacţii

 

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.

 

Tranzacţiile read-only

 

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 automată

 

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).

 

Blocarea manuală

 

Î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.

 

Mecanismele de securitate

 

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

 

Utilizator de baze de date şi scheme

 

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ă.

 

Domeniul de securitate

 

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.

 

Privilegii

 

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ă.

 

Privilegii sistem

 

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.

 

Privilegii asupra obiectelor schemă

 

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.

 

Privilegii acordate

 

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.

 

Setări şi limite de stocare

 

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.

 

 

 

Profiluri şi limite de resurse

 

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.

 

Monitorizarea selectivă a acţiunilor utilizatorilor

 

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ă

 

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.

 

De ce recuperarea este importantă

 

Î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.

 

Recuperarea de defecţiuni

 

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.

 

Structuri folosite la recuperare

 

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

 

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ă.

 

     Înregistrările undo

 

     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ă.

 

     Fişiere de control

 

     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.

 

 

     Copii de siguranţă ale bazei de date

 

     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.

 

Elementele afectate de TAF

 

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.

 

Configuraţii de mecanisme de protejare a datelor

 

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.

 

Componentele mecanismului de protejare a datelor

 

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.

 

Bazele de date standby fizice

 

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.

 

Bazele de date standby logică

 

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

 

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.