Oglinzi de răsturnare Oracle
segmente rollback (segmente rollback), de asemenea, numite segmente de undo concepute pentru a îndeplini trei obiective principale (de exemplu, USN Anulare numărul segmentului.):- Rularea comenzii de redirecționare.
- Restaurați instanța după eșec (recuperarea instanței).
- Asigurarea consistenței citite din baza de date (citiți coerența) [nota 1].
Primul și cel de-al doilea punct sunt acoperite în literatura de specialitate, în mod suficient de detaliat și în mod rațional, ci o descriere completă a funcționalității Oracle la punctul 3 nu am văzut.
De asemenea, în literatura de specialitate, nu am văzut o descriere clară a mecanismului segmentelor de retragere. Foarte bine descrierea a fost, destul de ciudat, în documentația veche pentru versiunile Oracle 3, 4 și 5. Cu toate acestea, în timp ce a existat încă un rollback segmente, dar în schimb au avut înainte de fișier imagine, dar conceptele rămân aceleași. Conceptul de cap și coadă. în opinia mea, mai bine ajută la înțelegerea schemei de segmente rollback.
Să vorbim mai întâi despre consecvență și apoi despre organizarea segmentelor de revoluție. Desigur, aceste subiecte nu acoperă toate aspectele legate de administrarea segmentelor rollback, dar sunt foarte utile pentru înțelegerea structurii și funcționării lor.
Coerența datelor citite
Coerența citirilor este legată de "înghețarea"? date în DBMS în orice moment și utilizatorul primește un raport cu privire la aceste date. La momentul primirii raportului oricărui utilizator altor utilizatori ar trebui să li se permită să modifice simultan aceleași date (competitivitate în caz contrar, datele se reduce drastic), astfel încât conținutul bazei de date este în continuă schimbare la fel de bine? Frozen? Datele sunt un instantaneu al bazei de date la un moment dat. Mecanismul de astfel de imagini în Oracle RDBMS prin segmente rollback (segmente rollback sau undo segmente), în care sunt stocate versiunile vechi ale datelor. În cazul în care otchetet încearcă să citească datele modificate de către alți utilizatori în timpul mandatului său, versiunea veche a datelor de la începutul raportului este citit din segmentele rollback. Oracle nu oferă versiunile anterioare garantate o citire a datelor datorită potențialului de frecare în segmentele rollback de către alți utilizatori. În cazul zdrobire în versiunile mai vechi ale segmentelor rollback de date, utilizatorul execută raportul, o eroare? ORA-1555 Instantaneu prea vechi, segment rollback prea mic. Cu cât este mai lung raportul, cu atât este mai probabil să înlocuiți versiunile vechi ale datelor. Dezvoltat în sistemul Forsyth GRC este conceput pentru a garanta stocarea datelor moștenite pe durata raportului.
Oracle asigură coerența la nivel de operator și la nivel de tranzacție.
Coerență la nivelul operatorului.
Instrucțiunea selectare a limbajului SQL citește întotdeauna date coerente. Aceasta înseamnă că, dacă la un moment dat operatorul selectează un rând al tabelului și după un timp citește din nou aceeași linie [nota 2]. atunci Oracle emite fie aceleași informații, fie eroarea ORA-1555.
Coerență la nivelul tranzacției.
Oracle acceptă următoarele tipuri de tranzacții:- O tranzacție care citește datele efectuate de alte tranzacții în timpul funcționării. Utilizatorul poate să pornească în mod explicit o astfel de tranzacție utilizând instrucțiunea de scriere a tranzacției cu tranzacție stabilită. tranzacție implicită (de la începutul sesiunii, până când prima comite / comanda de derulare înapoi. de comiterea / rollback la următoarea sesiune comite rollback / sau la sfârșitul anului) este o tranzacție de acest tip. Înainte de începerea oricărei tranzacții, în mod implicit, executarea implicită a instrucțiunii de scriere a tranzacției setate este implicită. Dacă doi dintre select în diferite părți ale unei tranzacții de acest tip sunt de cotitură la același rând din tabelul de baze de date, este posibil să se obțină rezultate diferite (contradictorii). Contradicția va apărea în cazul în care orice utilizator a modificat și a dat modificările acestor linii pe un interval de timp între cele de mai sus doi operatori selectați. Aceasta este, într-o singură tranzacție poate citi date, modificate și înregistrate (comise) de către alți utilizatori [Nota 3]. Trebuie remarcat faptul că apariția erorii ORA-1555 poate fi cazul, în cazul în care Oracle nu poate oferi consistență pentru a selecta nivelul operatorului. care este inclus în această tranzacție.
- Tranzacția este numai pentru citire. Utilizatorul poate începe o tranzacție cu tranzacția operatorul stabilit numai citire, și să completeze declarația comite / derulare înapoi. În cadrul unei astfel de tranzacții, puteți utiliza numai instrucțiuni selectate. Declarațiile DML nu sunt permise. Operatorii de strunjire selectați din diferite părți ale unei tranzacții la aceleași linii de date Oracle oferă fie aceleași date coerente, care au fost prezente în baza de date a început la momentul tranzacției (tranzacția set numai pentru citire), sau o eroare ORA-1555.
- O tranzacție serializabilă. Această tranzacție începe cu nivelul de izolare al tranzacției de tranzacționare serializabil. Astfel de tranzacții sunt concepute pentru a serializa actualizările atunci când mai mulți utilizatori concurează cu aceleași date. Cu aceste tranzacții, în același timp, emise de către diferiți utilizatori, rezultatul modificării datelor în baza de date, cum ar fi în cazul în care secvența observată, adică prima un utilizator a început și a terminat tranzacția, după ce a avut loc a doua tranzacție sa, apoi a treia, etc. În general vorbind, procesul de serializare a tranzacției este foarte complexă și nu este întotdeauna posibil să serializa efectuate ambele utilizatori de mai multe tranzacții. Rețineți că dacă înregistrarea din orice tabel sau tabel este menținută de un singur utilizator, este eliminată necesitatea serializării. tranzacțiile serializabilă sunt întotdeauna coerente, adică toate probele de a primi date de la un? instantaneu? bază, realizată în momentul emiterii nivelului de izolare al tranzacției setat serializabil. Cu condiția ca înregistrarea se efectuează numai în tabelul de lucru al utilizatorului, pot fi tratate tranzacții serializabile: tranzacții pentru ambele read-only (numai citire) la ieșire declarații DML (insera, șterge și actualiza). Acest lucru este convenabil atunci când programul pentru obținerea unui raport complex păstrează rezultatele în foile de lucru intermediare [nota 4]. din care este apoi tipărit raportul.
Mecanismul segmentelor de retragere
La crearea unui segment de minextents alocate rollback încă goale extensii, a declarat că prima măsură, primul bloc oraklovsky este rezervat pentru tabela de tranzacție sau segmentul de antet rollback. Noi spunem că capul și coada [prim.5] segment rollback sunt la începutul celui de al doilea bloc al primei măsură imediat după antetul (vezi. Fig. 1). Atunci când se atribuie această tranzacție rollback informații segment rollback este înregistrat, de al doilea bloc, în care fiecare tranzacție activă există ca cap și coadă în segmentul rollback. Atunci când datele modificarea și tranzacția rollback se mută cap tranzacție segment intrare, umplerea primul bloc și, eventual, următoarele extinderile. Coada tranzacției coincide cu coada segmentului rollback (a se vedea figura 2). A se vedea, în cazul în segmentele capului rollback de până în măsura în care este posibil și unitatea în tabelul V $ ROLLSTAT în coloane și Curext Curblk respectiv (prima măsură este numărul 0).
După ce tranzacția este comisă de declarația de comitet, coada segmentului de revizuire se va muta în cap (vezi Figura 3). Aici, capul și coada vor indica primul octet al tranzacției ulterioare a blocului de coadă. Informațiile de revenire din următoarea tranzacție atribuită acestui segment vor fi plasate în blocuri de extensie, deplasând capul segmentului și tranzacțiile mai departe de coadă în sensul acelor de ceasornic. După ce tranzacția este angajată, informațiile de revizuire înregistrate în extensiile 1 și 2 devin "inactive"? și poate fi folosit pentru a prelua versiuni vechi de date, adică pentru a asigura coerența.
O tranzacție lungă în timpul înregistrării informațiilor mișcă capul segmentului rollback. Când întinderea este umplută, capul se deplasează în următoarea măsură, apoi în următoarea măsură și așa mai departe - într-un cerc. Se spune că segmentele de răsturnare au o structură inelară (șarpe). Aceasta înseamnă că, după completarea a patra măsură, înregistrarea continuă cu prima sau. care este aceeași, capul se mută în prima măsură [nota 6]. În acest sens, importantă regulă: coada segmentului rollback nu se poate deplasa în măsura în care capul este. Astfel, în cazul în care segmentul de cap rollback este în măsura 4, ultimul bloc este plin (coada sa mutat la extinderile de capăt), și pentru a continua tranzacția mișcarea ulterioară a cozii necesită în sens orar, segmentul rollback cincea măsură adăugat (șarpe întins), iar capul se mută la primul său bloc (Figura 4). Numărul de extensii de la pornirea bazei de date este înregistrat în coloana Extends din vizualizarea V $ ROLLSTAT.
În cazul în care numărul de tranzacții înregistrate în informațiile segmentul rollback, în același timp, segmentul de coada coincide cu coada primul atribuit segmentul rollback tranzacție activă, iar segmentul capului. cu capul ultimei informații despre înregistrarea înapoi a tranzacției active. Întrucât operațiunile sunt comise de operator, coada segmentului rollback încearcă să ajungă la cap. În cazul în care toate tranzacțiile sunt fixe și în acest segment, nici o tranzacție rollback activă, același segment al cozii cu capul [prim.7] (fig. 3). O măsură poate fi utilizată pentru a scrie informații despre returnare din mai multe tranzacții, dar fiecare blocare stochează informații dintr-o singură tranzacție.
Mai sus, am considerat cazul când extensiile sunt adăugate la segmente de rollback. Acum, ia în considerare mecanismul de eliminare a extensiilor (șarpele se micsorează) din segmentele rollback. Toată lumea știe că extensiile pot fi eliminate (returnate pe lista de extensii gratuite FET $) în două moduri: prin emiterea segmentului de modificare a operatorului. reduce automat și prin specificarea optimă în fraza de stocare atunci când creați sau modificați segmentul rollback. Prima metodă, deși are mai multe "recife". de obicei, nu provoacă întrebări. Dar cea de-a doua cale încă o provoacă. O întrebare comună în astfel de cazuri. Și de ce segmentul de rollback a crescut la 20 megaocteți și nu dorește să se micșoreze, deși optim este setat la 5 megabytes. Ideea este că pentru a începe procedura de eliminare a extensiilor din segmentul rollback este necesar să se creeze un anumit eveniment, și anume, verificarea optimă și îndepărtarea extensiilor se efectuează atunci când capul segmentului se mișcă în următoarea măsură. Astfel, segmentul răsturnat nu se micșorează imediat după ce tranzacția a provocat expansiunea segmentului rollback. Compresia are loc atunci când alte tranzacții atribuite acestui segment de revizuire completează mărimea actuală până la sfârșit. Numărul de compresie de la începutul bazei de date este înregistrat în coloana Shrinks din vizualizarea V $ ROLLSTAT.
Acum, ia în considerare una dintre problemele, problema blocării tranzacțiilor. care pot apărea la administratorul unui sistem multi-utilizator. Să presupunem că un utilizator sau un operator nesupus a pornit o tranzacție (de exemplu, a introdus o linie în orice tabel), nu a completat-o cu ajutorul declarației de angajament și a plecat de mult timp pentru propria afacere. Informațiile de revizuire pentru această tranzacție sunt înregistrate în anumite segmente de redirecționare, adică capul segmentului a avansat la o anumită distanță și tranzacția a rămas activă. Coada acestei tranzacții se află lângă cap, posibil în același bloc. Utilizatorul care a părăsit tranzacția a plecat și mulți alți utilizatori continuă să modifice datele. Informațiile de revizuire din diferite tranzacții sunt înregistrate în segmentele de revocare operațională, inclusiv în cazul în care a fost atribuită tranzacția utilizatorului decedat. Capul acestui segment avansează în direcția acelor de ceasornic și se apropie de măsura în care se află coada tranzacției active a utilizatorului decedat. În acest timp, coada acestei tranzacții active de blocare a devenit coada întregului segment de revocare. Deoarece capul nu se poate deplasa în măsura în care coada este localizată, se adaugă o nouă măsură și capul se deplasează la ea. Apoi altul, etc. în ciuda faptului că toate blocurile de toate extensiile sunt inactive între cap și coadă (toate tranzacțiile au fost comise de operatori de comitet). Acest lucru poate duce la depășirea spațiului de masă al segmentelor de redirecționare. De aici moralul. administratorul trebuie să vină cu un sistem pentru împușcarea unor utilizatori nedisciplinați, de exemplu, folosind timpul inactiv în profil. deși acest lucru nu este întotdeauna posibil. Pentru a afla care utilizatori blochează segmente de revocare, puteți rula următorul script:
Cu cât numărul de extensii din segment este mai mare, cu atât este mai puțin probabil să se adauge o parte a segmentului de revizuire. Din acest punct de vedere, douăzeci de dimensiuni mici în segmentul rollback sunt mai bune decât două extensii mari care ocupă același loc.
Acum, un pic despre mecanismul care susține coerența datelor. După ce capul segmentului de revizuire completează o revoluție completă, informațiile de revocare din tranzacțiile inactive încep să fie suprascrise cu cea nouă. Numărul de astfel de suprascrieri (întreruperi complete) de la începutul demarării DBMS se reflectă în coloana Wraps din vizualizarea V $ ROLLSTAT. Astfel, teoretic este posibil ca toate segmentele de retrogradare să fie atât de mari încât tranzacțiile curente nu vor determina capetele tuturor segmentelor de revenire să facă o cifră de afaceri completă pentru un timp acceptabil de muncă, de exemplu, pentru câteva ore. Dar este practic imposibil să se facă acest lucru din mai multe motive evidente, dintre care principalul. Este imposibil să se prevadă în avans cantitatea de actualizări a bazei de date prin alte tranzacții. Astfel, este imposibil să asigurăm o consistență garantată a citirilor, adică o lipsă garantată a unei erori ORA-1555 atunci când lucrăm, de exemplu, un raport lung (tranzacție numai citire), care afectează în mod semnificativ funcționalitatea. Dar, din fericire, puteți garanta coerența citirilor. Pentru a face acest lucru, trebuie doar să blocați în mod artificial fiecare segment de revocare operațională cu tranzacții scurte înainte ca raportul să înceapă [nota 8] și să deblocheze, adică să comită aceste tranzacții după executare. Prin urmare, puteți deschide mai multe sesiuni suplimentare pentru numărul de segmente de revocare, în fiecare dintre acestea, blocați segmentul de redirecționare cu o tranzacție scurtă, utilizând operatorul de segmentare a segmentului de utilizare a tranzacției și efectuați raportul. În acest caz, modificarea sesiunilor poate primi un mesaj de eroare de la Oracle din cauza imposibilității de a extinde segmentul răsturnat blocat, dar sesiunea de raportare nu va primi niciodată ORA-1555.
1. Uneori, în literatura de limbă rusă bazată pe baze de date, termenul consistență este tradus ca "integritate". care, în opinia mea, este greșită, deoarece cuvântul rus? Integritate? rezervat pentru traducerea integrității cuvântului englez.
2. Se presupune că, într-un interval de timp între citiri, această linie poate fi modificată de alți utilizatori cu comitere de fixare de câte ori.
3. În standardul SQL, tranzacțiile de acest tip sunt numite: read committed. Începând cu Oracle 8.1.5, scrierea tranzacției de tranzacție setată este un sinonim. setați tranzacția.
4. Apropo, incepand cu versiunea Oracle 8.1.5, sunt implementate tabele de lucru speciale care functioneaza in cadrul sesiunii sau tranzactiilor utilizatorului, cu care operatiile DML sunt executate mult mai repede decat cu tabelele obisnuite, deoarece inregistrarile de actualizari ale jurnalelor bușteni) este blocată. De asemenea, aceasta are ca rezultat salvarea memoriei de disc în registrele de redo.
5. Un animal care ar trebui să-și imagineze atunci când folosește termenii? și "coada"? - șarpele. Șarpele are tendința să se îndoaie și să-și muște coada. Șarpele este cauciuc, se întinde și se contractează.
6. Numerotarea extensiilor nu are prea mult sens și este dată aici numai pentru claritate. Dintre toate extensiile segmentului rollback, numai extinderea are un statut special, în primul bloc al căruia se află tabela de tranzacții. Numărul acestei dimensiuni în vizualizarea DBA_EXTENTS. 0 și nu poate fi eliminat din segmentul rollback
7. Șarpele își bătea coada și se liniștea.
8. De fapt, realitatea este mai complicată decât descrierea dată de mine, deoarece informațiile despre tranzacțiile angajate pot fi suprascrise de o nouă tranzacție în tabelul tranzacțiilor, dar, din fericire, Oracle poate înțelege acest lucru.
Articole similare
Trimiteți-le prietenilor: