Structura bazei de date Oracle

Structura instanței Oracle Pool partajat Pool Java SGA Fluxuri pool Baza de date cache cache Pool mare Reface jurnal buffer F O L Y A M A T O K Monitor System SMON Check point CKPT Process Monitor PMON Database Writer DBW0 Log Writer LGWR Archiver ARC0

Procesul Oracle Memory Management Server 1 Procesul PGA Server 2 PGA Procesul de fundal PGA SGA Pool partajat Fluxuri Pool mare Pool Java Bază de date cache buffer Refaceți buffer jurnal

O structură de memorie Oracle pentru o instanță Oracle constă din următoarele părți: System Global Area (SGA): Toate procesele de server și procesele de fundal o partajează Program Global Area (PGA): Fiecare proces de server și proces de fundal are, de asemenea, propria sa zonă de memorie (PGA) ). SGAa poate conține, de asemenea, date și informații de control pentru instanță. SGA este alcătuit din următoarea structură de date: 1. Memoria cache a bazei de date: zona tampon a blocurilor de date citite 2. Refacerea bufferului jurnal: zona tampon a jurnalului de refacere necesară pentru recuperare, de unde este scris jurnalul la fișierele jurnal de refacere stocate pe disc 3. Pool partajat: buffer comun 4. Pool mare: un buffer pentru necesități foarte mari de intrare/ieșire 5. Pool Java: un buffer pentru Java Virtual Machine (JVM) cod și date Java 6. Pool de fluxuri: o zonă tampon pentru Oracle Streams

SGA este dinamic, ceea ce înseamnă că dimensiunea bufferelor poate fi modificată, dacă este necesar, fără a opri instanța. Programul Global Area (PGA) este rezervat proceselor serverului. Dimensiunea și conținutul PGA depind de dacă instanța este configurată în modul server partajat. Un PGA constă de obicei din următoarele: Zona SQL privată: conține structuri de memorie de execuție, date și informații despre atribuire. Fiecare sesiune care emite o instrucțiune SQL își alocă propriul spațiu SQL. Memoria sesiunii: zona necesară stocării informațiilor și variabilelor aparținând sesiunii de lucru.

Oracle Processes Server Processes Server Process Process Server Process Process Server System Global Area SGA System Monitor SMON Process Monitor PMON Database Writer DBW0 Check Point CKPT Log Writer LGWR Archiver ARC0 Procese de fundal

Când pornește o aplicație sau un dispozitiv Oracle (cum ar fi Enterprise Manager), serverul azoracle pornește un proces server care permite aplicației să execute instrucțiuni. Când porniți o instanță, Oracle pornește și procesele de fundal care comunică între ele și cu sistemul de operare. Procesele de fundal gestionează memoria, tampoanele, efectuează operații de scriere și citire pe disc și efectuează întreținere. Cele mai importante procese de fundal sunt: Monitor de sistem (SMON): Efectuează recuperarea după pornirea dezastrului Monitor de proces (PMON): Dacă un proces de utilizator este întrerupt, efectuează curățarea și întreținerea necesară Scriitor de baze de date (DBWn): Scrie din bufferul de date în disc, într-un fișier blocuri modificate Punct de verificare (CKPT): Pornește procesele DBWn pentru puncte de control și actualizează toate fișierele de date și fișierele de control din baza de date Scriere jurnal (LGWR): Scrie intrările de jurnal REDO pe disc Archiver (ARCn): Copii ale jurnalului REDO fișier pentru scriere de rezervă pe discurile selectate atunci când un fișier jurnal este plin sau se scrie în următorul jurnal de refacere online (comutator jurnal)

Fișiere care nu aparțin bazei de date Fișier parametru Fișier parolă Bază de date Fișiere jurnal arhivate 1. Fișierul parametru specifică caracteristicile instanței Oracle, cum ar fi dimensiunea porțiunilor de memorie ale SGA. 2. Fișierul cu parolă identifică utilizatorii care pot porni sau închide o instanță Oracle. 3. Fișierele jurnal REDO arhivate sunt copii ale unui fișier jurnal care pot fi utilizate pentru recuperare după o defecțiune a discului.

Procesul pentru executarea unei instrucțiuni SQL Pentru a vă conecta la o instanță (Conectare), aveți nevoie de: Procesul utilizatorului Procesul serverului În funcție de tipul instrucțiunii SQL, componentele serverului Oracle care vor fi necesare: Interogările încep procesele necesare pentru a obține dorința dorită. rânduri Instrucțiunile Data Modifier (DML) încep și procesele de înregistrare pentru a salva modificările Commit asigură recuperabilitatea tranzacțiilor Nu toate componentele serverului Oracle sunt implicate în executarea unei instrucțiuni SQL.

Conectați-vă la o instanță Server utilizator Oracle Server Utilizator server Client Aplicație Server Server utilizator server browser Browser

Înainte ca un utilizator să poată trimite o instrucțiune SQL către serverul ORACLE, acesta trebuie să se conecteze mai întâi la o instanță. Când un utilizator se conectează la un server Oracle, se creează un proces numit proces server. Acest proces comunică cu instanța Oracle în numele procesului utilizatorului care rulează pe client. Procesul server execută instrucțiunile SQL ale utilizatorului. Conexiunea este o cale de comunicare între un proces de utilizator și serverul Oracle.

Există trei moduri de conectare la un server Oracle: 1. PRIN SISTEMUL DE OPERARE: Utilizatorul intră în sistemul de operare unde se execută instanța Oracle și lansează o aplicație care accesează baza de date a sistemului respectiv. Calea de comunicare este apoi creată de procesele de comunicare internă ale sistemului de operare. 2. CONEXIUNEA CLIENT-SERVER: Utilizatorul lansează o aplicație pe mașina sa locală care se conectează prin rețea la mașina care rulează instanța Oracle. Software-ul de rețea comunică apoi între utilizator și serverul Oracle. 3. PRIN O CONEXIUNE CU TREI NIVELURI: Mașina utilizatorului comunică prin rețea cu o aplicație sau un server de rețea care este, de asemenea, conectat prin rețea la o mașină care rulează instanța Oracle. De exemplu, un utilizator folosește un browser pentru a accesa o aplicație care rulează pe un server NT care preia date dintr-o bază de date Oracle care rulează pe un sistem UNIX la distanță.

Când sunteți conectat, începe o sesiune. Faza de lucru începe atunci când utilizatorul este validat (validează) și durează până când acesta iese sau o întrerupere anormală. Un utilizator poate deschide mai multe secțiuni de lucru. Acest lucru necesită ca serverul Oracle să fie disponibil și utilizabil. (Unele instrumente administrative nici măcar nu necesită acest lucru). Notă: Dacă există o corespondență unu-la-unu între utilizator și procesul serverului, vorbim despre o conexiune dedicată la server.

Executarea interogărilor Spre deosebire de alte interogări, interogările pot returna un rând sau chiar mii de rânduri ca rezultat. La pasul 3 al executării interogării, procesul serverului efectuează următoarele: 1. Analizare: în buffer-ul SQL partajat, verifică dacă această instrucțiune este inclusă. Verificarea sintaxei pentru obiecte, are drepturile corespunzătoare Blocare obiecte în timpul analizei și stochează planul optim de execuție 2. Executați: generează rândurile căutate 3. Preluare: returnează rândurile procesului utilizatorului

Memoria tampon SQL partajată Cache-ul bibliotecii conține textul instrucțiunii azsql, cod analizat și planul de execuție al acestuia. Dicționarul de date conține definițiile și permisiunile tabelelor, coloanelor și altor obiecte cachea. Dimensiunea sa este setată de parametrul ashared_pool_sizeinitialization. Piscina comună Cache bibliotecă Cache dicționar de date SGA

Componente ale pool-ului partajat În timpul analizei, procesul serverului compilează instrucțiunea SQL din această parte a SGA. Are două componente principale: 1. Cache bibliotecă 2. Cache dicționar de date 1. Cache bibliotecă Conține informații despre ultimele instrucțiuni SQL emise într-o structură de memorie a zonei SQL partajate: Textul instrucțiunii SQL Arborele de analiză: Versiunea tradusă a instrucțiunii Planul de execuție: Ce pași pentru a executa declarația Optimizatorul este partea serverului Oracle care determină planul optim de execuție. Dacă reexecutați o instrucțiune SQL și spațiul SQL comun conține deja planul de execuție, nu este necesar să recompilați instrucțiunea pentru procesul serverului. Acest lucru economisește timp și memorie. Dacă instrucțiunea SQL nu este folosită pentru o lungă perioadă de timp, va fi eliminată din Cashe.

2. Memoria cache a dicționarului de date Conține cele mai recente definiții utilizate ale dicționarului de date. Aceasta include informații despre fișiere de baze de date, tabele, indici, coloane, utilizatori, permisiuni și alte obiecte. În timpul analizei, procesul serverului caută mai întâi informațiile aici pentru a rezolva numele și a stabili permisiunile. Dacă nu o găsiți aici, veți iniția recuperarea informațiilor solicitate din fișierele de date.

Baza de date tampon cache Stochează ultimele blocuri citite. Dimensiunea sa depinde de parametrul de inițializare DB_BLOCK_SIZE. Numărul de buffere este specificat de DB_BLOCK_BUFFERS. Memoria cache a bazei de date Când trebuie executată o interogare, procesul serverului verifică mai întâi dacă blocul pe care îl caută nu este aici. Dacă nu îl găsiți în buffer, citiți doar o copie a blocului din fișierul de date. Dacă nu mai există spațiu în buffer, citiți cel nou în locul celui mai vechi bloc de date folosit.

Zone de memorie exclusive: Program Global Area (PGA) Nu este partajat Numai procesul serverului poate scrie Conține: zona de sortare Informații despre sesiune: permisiuni, statistici Starea cursorului Spațiu stivă Proces server Serverul alocă acest spațiu la începutul unui proces și îl eliberează la Sfârșit. PGA

Executarea instrucțiunilor de modificare a datelor (DML) ACTUALIZARE Procesul de utilizare a angajaților. Proces server 1 4 SGA Baza de date cache buffer Fișiere de date Refaceți jurnalul de memorie 1 2 3 Fișiere de control Pool partajat Refaceți fișiere de jurnal Baza de date

Executarea instrucțiunilor DML Executarea modificării datelor are două faze: Analizarea este aceeași ca și pentru interogare. Implementarea necesită acum procese suplimentare, deoarece schimbarea datelor trebuie făcută în siguranță, recuperabilă. Faza de execuție DML: 1. Dacă blocul de date și blocul de revenire nu se află în buffer, procesul serverului le citește din fișierul de date în buffer. 2. Procesul serverului plasează blocări pe rândurile pe care doriți să le modificați. 3. Procesul server scrie modificările în jurnalul REDO (buffer jurnal de refacere), astfel încât datele să poată fi restaurate, dacă este necesar. 4. Procesul server scrie vechea valoare a datelor în blocul de revenire. 5. Înregistrează noile valori în blocul de date.

Executarea instrucțiunilor DML Procesul serverului înregistrează valori înainte de imagine (UPDATE) și abia apoi modifică blocul de date. Aceste modificări sunt făcute în memoria tampon a bazei de date. În buffer, orice bloc nescris, modificat, primește o intrare referitoare la un bloc murdar, deoarece aceste blocuri sunt diferite de blocurile corespunzătoare de pe disc. Ștergerea sau inserarea constă din pași similari. „Înainte de imagine” șterge valorile coloanei rândului șters, iar INSERT conține adresa locației rândului. Datorită întârzierii scrierii pe disc, aceste modificări pot fi pierdute cu SGA în caz de dezastru.

Dimensiunea bufferului de logare REDO A este definită de parametrul LOG_BUFFER. Înregistrează toate modificările care apar în instanță. Este încărcat într-o ordine continuă. Când se umple, începe din nou. Memoria cache a bazei de date tampon

Tamponul de jurnal REDO Intrarea în jurnal REDO înregistrează blocul care se schimbă, locația modificării și noua valoare. Intrarea REDO nu diferențiază tipurile de blocuri, ci privește doar ce octeți se schimbă în bloc. Bufferul de jurnal REDO este încărcat în mod constant, iar intrările datorate tranzacțiilor diferite se pot suprapune. Dacă este plină, se va șterge de la început, dar numai dacă vechea intrare REDO a fost deja scrisă pe disc.

Segment de revenire valoare veche Segment de revenire valoare nouă Tabel Instrucțiune DML

Segmentul de revenire înainte de fiecare modificare, procesul serverului salvează vechea valoare a datelor într-un segment de revenire. Cu aceasta: Puteți anula modificările (UNDO) prin restabilirea unei tranzacții. Oferă consistență de citire, ceea ce înseamnă că alte tranzacții nu văd efectul declarației DML dacă nu a fost încă comisă. Puteți restabili starea consecventă a unei baze de date după un dezastru. Segmentele de revenire, cum ar fi tabelele și indexurile, sunt stocate în fișiere de date. Blocurile de revenire ar trebui să fie citite în memoria tampon a bazei de date în același mod ca blocurile de date obișnuite atunci când este necesar. Segmentul de revenire este creat de DBA. Modificările segmentelor vor fi înregistrate în memoria tampon REDO.

Executați COMMIT 1 Instanță Server proces 3 4 SGA Baza de date cache buffer Refaceți jurnalul de memorie Pool partajat LGWR Procesul utilizatorului Fișiere de date Fișiere de control Refaceți fișiere de jurnal 2 Baza de date

Comitere rapidă Serverul Oracle utilizează comitere rapidă, ceea ce asigură că modificările finalizate pot fi restaurate dacă o instanță este deteriorată. Număr schimbare sistem Când o tranzacție este finalizată, serverul Oracle atribuie tranzacției un număr de schimbare sistem (SCN). ASCN este ca un timestamp intern, în creștere monotonă și unic în cadrul unei baze de date. SCN poate fi utilizat pentru a rezolva sincronizarea datelor. SCN poate fi utilizat pentru a asigura consistența lecturii. Cu SCN, Oracle Server poate verifica coerența fără a fi nevoie să utilizeze timpul sistemului de operare.

Pași de comitere rapide Pași în procesul de comitere: procesul serverului scrie o intrare COMMIT și un număr SCN în memoria tampon REDO. Procesul de publicare a jurnalelor (LGWR) tipărește simultan întregul conținut al tamponului de jurnal REDO, inclusiv intrarea de validare în fișierele jurnal REDO. Este sigur că modificarea nu se va pierde chiar dacă copia este deteriorată. Utilizatorul este notificat că COMMIT a fost executat. Procesul serverului înregistrează că tranzacția s-a finalizat cu succes și eliberează blocările emise de tranzacție. Scrie toate tampoanele murdare într-un fișier de date. Acest lucru este independent de procesul DBW0 și nu contează înainte sau după COMMIT.

Comitere rapidă Avantajele comiterii rapide: Scrierea secvențială a unui fișier jurnal este mai rapidă decât scrierea pe diferite blocuri ale unui fișier de date. Scriem doar informațiile minime necesare pentru a înregistra modificările în fișierul jurnal, în timp ce dacă scriem în fișierele de date, ar trebui să fie blocate blocuri complete de date. Dacă mai multe tranzacții doresc să emită un COMMIT în același timp, instanța poate executa toate înregistrările de jurnal REDO într-o singură scriere. Dacă memoria tampon REDO nu este foarte plină, atunci este suficientă o singură scriere sincronizată pentru fiecare tranzacție. În plus, dacă tranzacțiile vor fi finalizate aproximativ în același timp, în medie mai puțin de o scriere sincronizată este suficientă pentru fiecare tranzacție. Deoarece conținutul bufferului de jurnal REDO poate fi scris înainte de COMMIT, nu este necesar să așteptați COMMIT dacă tranzacția durează mult. Când reveniți la o tranzacție, procesul de jurnalizare (LGWR) nu va începe, astfel încât jurnalul nu va fi scris pe disc. Oracle Server distruge efectul tranzacțiilor care nu au fost finalizate cu COMMIT în timpul recuperării. Dacă apare o eroare după revenire, dar intrarea de revenire nu a fost încă scrisă pe disc, absența COMMIT indică faptul că o tranzacție nu a fost finalizată și a fost anulată.

Rezumat Am făcut cunoștință cu fișierele bazei de date: fișiere de date, fișiere de control, jurnale REDO online Am făcut cunoștință cu structura de memorie a azsga: cache tampon DB, pool SQL partajat, buffer jurnal refacere Ne-am familiarizat cu cele mai importante procese de fundal: DBW0, LGWR, CKPT, PMON, SMON, ARC0 pași: compilați (analizați), executați (executați), returnați rezultatul (preluați)