Retratări în subdata de oracol

Oglinzi de răsturnare Oracle

Dmitri Bezrukov,
FORS-HOLDING CJSC

Segmentele de revinare, denumite și segmente de anulare (de exemplu, USN - Undo Segment Number), sunt concepute pentru a efectua trei sarcini principale:

1. Rularea comenzii de redirecționare.
2. Restaurați instanța după eșec (recuperarea instanței).
3. Asigurarea coerenței citirii din baza de date (citirea consecvenței)

Primul și al doilea element sunt acoperite în literatura de specialitate suficient de detaliat și sensibil, dar nu am văzut o descriere completă a funcționalității Oracle la punctul 3.

De asemenea, în literatura de specialitate, nu am văzut o descriere clară a mecanismului segmentelor de retragere. Cea mai bună descriere a fost destul de ciudat în vechea documentație Oracle pentru versiunile 3, 4 și 5. Adevărat, în acel moment nu existau segmente de revocare, dar în schimb exista un fișier de imagine înainte, dar conceptele rămânând la fel. Conceptul local de "capete și cozi", î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

Problema consecvenței este legată de "înghețarea" datelor din 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 (în caz contrar a redus dramatic de competitivitate a datelor), astfel încât conținutul bazei de date este în continuă schimbare, iar datele „înghețate“ este un instantaneu (un instantaneu al), baza de date privind la un moment dat. Mecanismul acestor snapshot-uri în Oracle DBMS este implementat prin segmente de răsturnare (anulează segmente), în care sunt stocate versiuni vechi de date. În cazul în care raportul încearcă să citească datele modificate de alți utilizatori în timpul funcționării sale, vechile versiuni ale datelor de la începutul raportului sunt citite din segmentele de redirecționare. Oracle nu oferă o citire garantată a versiunilor anterioare de date din cauza posibilității de a le distruge în segmentele de redirecționare 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, segmentul rollback prea mic“. Cu cât este mai lung raportul, cu atât este mai probabil să înlocuiți versiunile vechi ale datelor. Sistemul GRC dezvoltat în FORCE este conceput pentru a garanta stocarea versiunilor vechi de date 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ă, la un moment dat, instrucțiunea selectare citește un rând din tabel și după un timp citește din nou aceeași linie, Oracle emite fie aceeași informație, fie eroarea ORA-1555.

Coerență la nivelul tranzacției.

Oracle acceptă următoarele tipuri de tranzacții:

1. 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 de tranzacție setată este executată implicit. Dacă două instrucțiuni selectate în diferite părți ale unei tranzacții de acest tip se referă la aceleași rânduri din tabela de baze de date, pot fi obținute rezultate diferite (conflictuale). O contradicție apare dacă orice utilizator modifică și corectează modificările la aceste linii în intervalul de timp dintre cele două instrucțiuni selectate de mai sus. Aceasta este, într-o singură tranzacție poate citi date, modificate și înregistrate (comise) de către alți utilizatori ar trebui remarcat faptul că apariția ORA-1555 de eroare poate fi cazul, în cazul în care Oracle nu poate oferi consistență pentru a selecta nivelul operatorului. care este inclus în această tranzacție.
2. Tranzacția este "numai pentru citire". Utilizatorul poate să înceapă o astfel de tranzacție cu operatorul de tranzacție setat numai cu operațiune de citire și să se încheie cu instrucțiunea de comitere / revocare. Î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.
3. 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, procesul de serializare a tranzacțiilor este foarte complicat și nu este întotdeauna posibilă serializarea simultană a tranzacțiilor efectuate de mai mulți utilizatori. Rețineți că dacă înregistrarea în orice tabel sau tabel este menținută de un singur utilizator, atunci nevoia de serializare este eliminată. Tranzacțiile tranzacționabile sunt întotdeauna consecvente, adică toate eșantioanele primesc date din "instantaneul" bazei de date realizate în momentul stabilirii nivelului de izolare al tranzacției. Cu condiția ca înregistrarea să fie implementată numai în foile de lucru ale utilizatorului, puteți trata tranzacțiile serializate: ca tranzacții cu citire numai cu capacitatea de a emite declarații DML (inserați, ștergeți și actualizați). Acest lucru este convenabil atunci când programul pentru obținerea unui raport complex salvează rezultatele în foi de lucru intermediare, din care este apoi tipărit raportul.

Mecanismul segmentelor de retragere

Atunci când se creează segmentul rollback, se alocă minuscule de extensii goale goale, cu primul bloc Oracle din prima măsură rezervat pentru tabelul de tranzacții sau cu rubrica segmentului rollback. Vom spune că capul și coada evenimentului rollback sunt la începutul celui de-al doilea bloc din prima măsură imediat după antet (vezi Figura 1). Atunci când se atribuie o tranzacție acestui segment de revocare, informațiile de revizuire sunt înregistrate începând cu cel de-al doilea bloc și fiecare tranzacție activă are de asemenea un cap și o coadă în segmentul rollback. Când modificați tranzacția de date și completați segmentul de redirecționare, capul de tranzacție se deplasează înainte, completând prima și eventual următoarea blocare. Coada tranzacției coincide cu coada segmentului rollback (a se vedea figura 2). Puteți vedea unde se află capul segmentelor de răsturnare până la nivelul și blocul din tabelul V $ ROLLSTAT în coloanele Curext și respectiv Curblk (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 redirecționare din următoarea tranzacție atribuită acestui segment vor fi plasate în blocuri de măsură, mișcând capul segmentului și tranzacțiile mai departe de coadă în sensul acelor de ceasornic. După ce tranzacția a fost angajată, informațiile de revizuire înregistrate în extensiile 1 și 2 devin "inactive" și pot fi folosite 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 același, capul se mută în prima măsură. Se observă o regulă importantă: coada segmentului răsturnat nu poate trece niciodată în măsura în care se află capul. 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.

Dacă mai multe tranzacții scriu informații de răsturnare la un segment în același timp, atunci coada segmentului coincide cu coada primului răsturnare a tranzacției active și capul segmentului

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ă extinderile pot fi eliminate (pentru a reveni la lista de extensii gratuite $ FET) în două moduri: prin emiterea operatorului modifica segmentul rollback ... micșora automat prin definirea cuvânt optim în stocarea fraza crearea sau modificarea unui segment rollback. Prima metodă, deși are mai multe "capcane", 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 rollback a crescut la 20 de megaocteți, dar nu vrea să se micșoreze, deși setul optim de 5 MB?“. Faptul că, pentru procedura de pornire a scoate din segmentul extensii rollback necesită producerea unui eveniment specific, și anume, testarea și îndepărtarea optimă a extinderile se face atunci când se deplasează segmentul cap în măsura următoare. 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 revenire 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 poate avea loc într-un administrator de sistem multi-utilizator. Să presupunem că un anumit utilizator sau un operator nedisciplinat a început să efectueze o tranzacție (de exemplu, a pus în aplicare în orice tabel) nu-l completeze folosind operatorul commit, și a mers cu privire la afacerea lor pentru o lungă perioadă de timp. Informații pentru derulare înapoi această tranzacție înscriși în un fel de segmentul rollback, adică segmentul capului sa mutat pentru o anumită distanță, iar tranzacția rămâne activă. Coada acestei tranzacții este adiacent capului, eventual în același bloc. Nu finaliza tranzacția utilizatorul este plecat, și multe alte persoane sunt încă actualizarea datelor. Informații retragere a diverselor operațiuni se înregistrează în care funcționează segmentele rollback, inclusiv cea în care tranzacția a fost numit membru al trecutului. Capul acestui segment este în mișcare sensul acelor de ceasornic și în continuare vine la extinderile la care coada este o tranzacție de utilizator activ a plecat. În acest moment, coada acestei activități este blocată de tranzacție a devenit coada tot segmentul rollback. Deoarece capul nu se poate deplasa în măsura în care coada, se adaugă o nouă măsură, iar capul este mutat la ea. Apoi o alta, etc. în ciuda faptului că între cap și coadă, toate blocurile din toate extensiile inactive (au fost înregistrate toate tranzacțiile se angajeze operatori). Acest lucru poate cauza segmente rollback preaplin tablespace. Prin urmare, moralitatea - administratorul trebuie să vină cu sistemul de tragere de utilizatori nedisciplinați, de exemplu, pentru a folosi timpul de inactivitate în profil. cu toate că acest lucru nu este întotdeauna posibil. Pentru a afla care utilizatorii blochează segmentele rollback pot fi rulate folosind 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, practic, acest lucru este imposibil din mai multe motive evidente, cea mai importantă fiind imposibilitatea de a anticipa în avans cantitatea de actualizări de baze 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 operare de răsturnare cu tranzacții scurte înainte ca raportul să înceapă ș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 recuperare a utilizării tranzacției și executaț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 limba rusă consistența bazei de date literatura de specialitate, termenul tradus ca „integritate“, care, în opinia mea, greșit, deoarece cuvântul rusesc „integritate“ este rezervată pentru traducerea cuvântului englezesc „integritate“.

2. Se presupune că, într-un interval de timp între citiri, această linie poate fi modificată de alți utilizatori cu comiterea fixării de câte ori.

3. În standardul SQL, tranzacțiile de acest tip sunt numite: read committed. Începând cu Oracle 8.1.5, instrucțiunea de scriere a tranzacției de scriere a tranzacției setată are un nivel de izolare al tranzacției de tranzacție sinonim citit angajat.

4. Prin modul în care, începând cu versiunea Oracle 8.1.5 Server, implementat mese speciale de lucru, care lucrează într-un utilizator sesiune sau o tranzacție, care operațiunile de LMD sunt efectuate mult mai rapid decât cu tabele convenționale, deoarece, care se actualizează un record în jurnalele (reface bușteni) este blocat. Datorită acestui fapt, realizat, de asemenea, economii de stocare pe disc în jurnalele de redo.

5. Animale, care ar trebui să fie imaginate atunci când se utilizează termenii "cap" și "coada" - un șarpe. Ș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 este 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.

Trimiteți-le prietenilor: