Vezi ce este „ACID” în alte dicționare. Proprietăți ale tranzacției ACID

Caracteristicile tranzacției sunt descrise în termeni ACID (atomicitate, consistență, izolare, durabilitate).

· O tranzacție este indivizibilă în sensul că este un întreg unic. Toate componentele sale au loc sau nu. Nu există o tranzacție parțială. Dacă doar o parte a tranzacției poate fi finalizată, aceasta este respinsă.

· Tranzacția este consecventă deoarece nu încalcă logica de afaceri și relațiile dintre elementele de date. Această proprietate este foarte importantă atunci când se dezvoltă sisteme client-server, deoarece depozitul de date primește un număr mare de tranzacții de la diferite sisteme și obiecte. Dacă cel puțin unul dintre ele încalcă integritatea datelor, atunci toate celelalte pot produce rezultate incorecte.

· O tranzacție este întotdeauna izolată deoarece rezultatele sale sunt autonome. Sunt independente de tranzacțiile anterioare sau ulterioare - această proprietate se numește serializare și înseamnă că tranzacțiile dintr-o secvență sunt independente.

· Tranzacția este stabilă. După finalizarea sa, acesta este stocat în sistem, pe care nimic nu poate reveni la starea inițială (înainte de începerea tranzacției), adică. Tranzacția este comisă, ceea ce înseamnă că acțiunea sa este permanentă chiar dacă sistemul eșuează. Aceasta implică o formă de stocare a informațiilor în memorie permanentă ca parte a tranzacției.

Niveluri de izolare a tranzacțiilor

În mod ideal, tranzacțiile între diferiți utilizatori ar trebui să fie efectuate în așa fel încât să se creeze iluzia că utilizatorul tranzacției curente este singurul. Cu toate acestea, în realitate, din motive de performanță și pentru a îndeplini unele sarcini speciale, SGBD-urile oferă diferite niveluri izolarea tranzacției. Nivelurile sunt descrise în ordinea creșterii izolării tranzacțiilor și a fiabilității datelor

0 - Citire neangajată (Citire neangajată, Citire murdară, citire murdară) - Citirea modificărilor necommitate ale tranzacției dvs. și ale tranzacțiilor concurente, citirile necurate, nerepetabile și fantomele sunt posibile

1 - Citirea confirmată (Read Committed) - citirea tuturor modificărilor în propria tranzacție și a modificărilor comise în tranzacțiile concurente, citirile necurate sunt imposibile, citirile nerepetabile și fantomele sunt posibile

2 - Citire repetabilă (Citire repetabilă, instantaneu) - citirea tuturor modificărilor aduse tranzacției dvs., orice modificări făcute de tranzacțiile concurente după începerea propriei dvs. nu sunt disponibile, citirile necurate și nerepetabile sunt imposibile, sunt posibile fantomele

3 - Ordered - (Serializable, serializable) - tranzacții ordonate (serializabile). Identic cu situatia in care tranzactiile sunt executate strict secvential una dupa alta. Adică tranzacții al căror rezultat nu depinde de ordinea în care sunt executați pașii tranzacției (este interzisă citirea tuturor datelor modificate de la începutul tranzacției, inclusiv prin tranzacția proprie). Fantomele sunt imposibile.

Cu cât nivelul de izolare este mai mare, cu atât sunt necesare mai multe resurse pentru a le menține.

Într-un SGBD, nivelul de izolare a tranzacțiilor poate fi selectat atât pentru toate tranzacțiile simultan, cât și pentru o anumită tranzacție. În mod implicit, majoritatea bazelor de date folosesc nivelul 1 (Read Committed). Nivelul 0 este folosit în primul rând pentru a urmări modificările aduse tranzacțiilor de lungă durată sau pentru a citi date care se modifică rar. Nivelurile 2 și 3 sunt utilizate pentru cerințe sporite pentru izolarea tranzacțiilor.

Atomicity - Atomicity

Articolul principal: Atomicitate

Atomicitatea asigură că nicio tranzacție nu este parțial angajată în sistem. Fie vor fi efectuate toate suboperațiunile sale, fie niciuna nu va fi efectuată. Deoarece în practică este imposibil să se efectueze simultan și atomic întreaga secvență de operațiuni în cadrul unei tranzacții, se introduce conceptul de „retroducere”: dacă o tranzacție nu poate fi finalizată complet, rezultatele tuturor acțiunilor efectuate anterior vor fi anulate și sistemul va reveni la starea inițială.

[Editați | ×]

Consistență - Consistență

Articolul principal: consistența datelor

Una dintre cele mai complexe și ambigue proprietăți ale celor patru ACIDI. Conform acestei cerințe, sistemul este într-o stare consecventă înainte de începerea tranzacției și trebuie să rămână într-o stare consecventă după finalizarea tranzacției. Cerința de consecvență nu trebuie confundată cu cerința de integritate. Ultimele reguli sunt mai înguste și, în multe privințe, specifice SGBD-urilor relaționale: există cerințe pentru integritatea tipului, integritatea referențială și integritatea entității, care nu pot fi încălcate fizic din cauza specificului implementării sistemului.

Consecvența este un concept mai larg. De exemplu, în sistemul bancar poate exista o cerință ca suma debitată dintr-un cont să fie egală cu suma creditată pe altul. Aceasta este o regulă de afaceri și nu poate fi garantată numai prin verificări de integritate, dar trebuie urmată de programatori atunci când scriu codul tranzacției. Dacă orice tranzacție debitează, dar nu debitează, sistemul va rămâne într-o stare incorectă și proprietatea de consistență va fi încălcată.

În cele din urmă, o altă notă este că consistența nu este necesară în timpul execuției tranzacției. În exemplul nostru, debitarea și creditarea vor fi cel mai probabil două sub-operațiuni diferite, iar o stare inconsecventă a sistemului va fi vizibilă între execuția lor în cadrul tranzacției. Totuși, nu trebuie să uităm că dacă cerința de izolare este îndeplinită, această inconsecvență nu va fi vizibilă pentru nicio altă tranzacție. Iar atomicitatea garantează că tranzacția fie va fi complet finalizată, fie că nici una dintre operațiunile tranzacțiilor nu va fi efectuată. Astfel, această inconsecvență intermediară este ascunsă.

Izolare - Izolare

În timp ce o tranzacție este în curs, alte procese nu ar trebui să vadă datele în stare intermediară. De exemplu, dacă o tranzacție modifică simultan mai multe câmpuri dintr-o bază de date, o altă interogare executată în timp ce tranzacția este în curs nu ar trebui să returneze unele dintre acele câmpuri cu valori noi, iar altele cu valorile lor originale.

Durabilitate - Durabilitate

Indiferent de probleme niveluri inferioare(de exemplu, o întrerupere a sistemului sau o defecțiune hardware), modificările efectuate printr-o tranzacție finalizată cu succes ar trebui să rămână salvate după ce sistemul este readus în funcțiune. Cu alte cuvinte, dacă utilizatorul a primit confirmarea din partea sistemului că tranzacția a fost finalizată, poate fi sigur că modificările pe care le-a făcut nu vor fi anulate din cauza unor eșecuri.

7.1 Proprietăţile ACIDE

7.1.1 În timpul acestei teste de referință, sistemul în curs de testare trebuie să aibă proprietățile ACID (Atomicity, Consistency, Isolation, Durability) care sunt cheie pentru sistemele de procesare a tranzacțiilor.

7.1.2 Scopul acestei secțiuni este de a descrie în mod informal proprietățile ACID și de a specifica seria de teste care trebuie efectuate pentru a demonstra că aceste proprietăți sunt atinse.

7.1.3 Nicio secvență finită de teste nu poate dovedi că proprietățile ACID sunt pe deplin acceptate. Este necesară trecerea testelor prescrise, dar nu condiție suficientă conformitatea cu cerințele de proprietate ACID. Cu toate acestea, de dragul integrității raportării, numai testele specificate aici vor fi considerate necesare și numai acele teste ar trebui raportate în Raport pentru această testare de referință.
Notă: Scopul acestor teste este de a demonstra că principiile ACID sunt susținute de sistemul în curs de testare și sunt aplicate în timpul execuției testului. Ele nu sunt concepute pentru a fi teste cuprinzătoare de asigurare a calității.

7.1.4 În timpul execuției testului, trebuie aplicată configurația necesară pentru a asigura conformitatea deplină cu proprietățile ACID. Acest lucru se aplică atât bazei de date (inclusiv TPC-E și Definit de utilizator obiecte) și la sesiunile de baze de date utilizate pentru a efectua teste ACID și execuție benchmark.
Nota 1: Conceptul „configurare” include toate proprietățile și caracteristicile bazei de date care pot fi definite extern; include, dar nu se limitează la, fișiere de configurare și inițializare, setări de mediu, comenzi SQL și proceduri stocate, module încărcate și suplimente. De exemplu, dacă SUT se bazează pe jurnalele de anulare/returnare, atunci înregistrarea trebuie menținută pentru toate tranzacțiile, inclusiv pentru cele care nu conțin o opțiune de rollback în profilul tranzacției.
Nota 2: În cazurile în care această testare de referință este implementată pe un sistem distribuit, trebuie efectuate teste pentru a verifica dacă Tranzacțiile procesate pe două sau mai multe noduri respectă proprietățile ACID.

7.1.5 Deși testele ACID nu testează toate tipurile de Tranzacții din acest domeniu de activitate, proprietățile ACID trebuie îndeplinite pentru toate Tranzacțiile.

7.1.6 Organizatorii care trimit rezultate TPC trebuie să efectueze teste ACID pe unul dintre sistemele pentru care este furnizat rezultatul, cu condiția să utilizeze același software implementări (de exemplu, sisteme de operare, DBMS, programe de tranzacții). De exemplu, conținutul acestui paragraf ar fi adecvat atunci când Rezultatele sunt furnizate pentru mai multe sisteme din aceeași linie de produse. Cu toate acestea, testele de rezistență descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5.2.4 trebuie să fie trecute pe toate sistemele evaluate. Toate FDR-urile trebuie să afișeze sistemele utilizate pentru a verifica cerințele ACID, precum și Descriere completa testele ACID aplicate și rezultatele obținute la acestea..

7.2 Cerințe de atomicitate

7.2.1 Definirea proprietății de atomicitate

Sistemul testat trebuie să se asigure că Tranzacțiile cu baze de date sunt atomice; sistemul fie va finaliza toate operațiunile individuale asupra datelor, fie se va asigura că niciuna dintre operațiunile finalizate parțial nu are vreun efect asupra datelor în vreun fel.

7.2.2 Teste de atomicitate

Execută tranzacția de tranzacționare pe piață prin setarea indicatorului roll_it_back la 0. Verificați dacă au fost adăugate rândurile corespunzătoare la tabelele TRADE și TRADE_HISTORY.
Executați tranzacția de tranzacționare cu comandă de piață setând indicatorul roll_it_back la 1. Verificați dacă nu au fost adăugate rânduri asociate cu tranzacția de comandă de tranzacționare la tabelele TRADE și TRADE_HISTORY.

7.3 Cerințe de secvență

7.3.1 Definirea proprietății Sequence

Consistența este o proprietate a Aplicației care asigură că orice execuție a unei Tranzacții cu baze de date va duce la tranziția acesteia de la o stare la alta.

7.3.1.1 Baza de date TPC-E populată prima dată utilizând EgenLoader trebuie să aibă proprietăți de secvență.

7.3.1.2 În cazul în care datele sunt replicate conform prevederilor de la clauza 2.3.3.3, fiecare copie trebuie să respecte stările secvenței descrise în clauza 7.3.2.

7.3.2 Stări de secvență
Următoarele paragrafe definesc cele trei stări de secvență. Fiecare dintre cele trei condiții necesită o demonstrație clară că condițiile sunt îndeplinite.

7.3.2.1 Starea secvenței 1

B_NUM_TRADES = numărare(*)

pentru fiecare broker, definit prin următoarele:

7.3.2.2 Starea secvenței 2

Înregistrările din tabelele BROKER și TRADE trebuie să respecte relația:

B_COMM_TOTAL = suma(T_COMM)

pentru fiecare broker definit de următoarele:

(B_ID = CA_B_ID) și (CA_ID = T_CA_ID) și (T_ST_ID = „CMPT”).

7.3.2.3 Starea secvenței 3

Înregistrările din tabelele HOLDING_SUMMARY și HOLDING trebuie să respecte relația:

HS_QTY = suma(H_QTY)

pentru fiecare grup de active definite de următoarele:

(HS_CA_ID = H_CA_ID) și (HS_S_SYMB = H_S_SYMB).

7.3.3 Teste de secvență
Testarea pâlnie în trei stări ar trebui efectuată atât după însămânțarea inițială a bazei de date, cât și după orice teste de recuperare a afacerii.

7.4 Cerințe de izolare

7.4.1 Determinarea proprietății de izolare

7.4.1.1 Având în vedere Tranzacția T1 și Tranzacția T2 care se execută simultan, pot fi descrise următoarele fenomene (de la P0 la P3) care au loc în T1.

P0 ("Dirty Write") - Tranzacția T2 modifică (sau injectează) elementele de date R. Apoi, înainte de acțiunile de comitere COMMIT ale lui T2, începe Tranzacția T1, care poate modifica (sau șterge) elementele de date R și poate emite apoi un COMMIT.

Notă: T2 poate efectua operații suplimentare de bază de date pe baza stării în care a lăsat elementele lui R, creând o potențială problemă de consistență a datelor.

P1 (Dirty Read) - Tranzacția T2 modifică (sau inserează) elementele de date R. Apoi, înainte ca T2 să emită un COMMIT, Tranzacția T1 începe, citește elementele de date R și este capabil să recupereze starea elementelor de date așa cum a fost după T2 schimbat. Ulterior, T2 poate efectua o operație ROLLBACK.

Notă: T1 poate efectua operațiuni suplimentare de bază de date pe baza stării elementelor de date ale lui R care au fost anulate și se presupune că nu au existat niciodată, creând potenţială problemă secvențe de date.

P2 (“Non-repeatable read”) - Tranzacția T1 citește elementele de date R. Apoi, înainte ca Tranzacția T1 să efectueze un COMMIT, începe Tranzacția T2, care modifică (sau șterge) elementele de date R și emite un COMMIT. T1 repetă apoi citirea elementelor de date R și poate obține starea elementelor de date după ce a fost modificat de Tranzacția T2.

Notă: Înainte de a detecta starea modificată (sau ștearsă) a elementelor de date R, T1 ar putea efectua operațiuni suplimentare de bază de date pe baza stării elementelor de date R care nu mai sunt considerate valide, creând o potențială problemă de consistență a datelor.

P3 („Phantom Read”) - Tranzacția T1 citește un set de elemente de date care corespund cuiva. Apoi, înainte ca Tranzacția T1 să efectueze o operațiune COMMIT, Tranzacția T2 începe și inserează sau șterge unul sau mai multe elemente de date corespunzătoare celei utilizate de T1. T1 repetă apoi citirea inițială pe aceeași și poate obține un set diferit de articole de date decât cel original.

Notă: Înainte de a descoperi un set mai mare sau mai mic de elemente de date, T1 poate efectua operațiuni suplimentare de bază de date pe baza setului de articole de date care nu mai este considerată relevantă, creând o potențială problemă de consistență a datelor.

7.4.1.2 Izolarea este o proprietate a unei Tranzacții care indică gradul în care este izolată de acțiunile altor Tranzacții care rulează simultan cu aceasta. Tabelul de mai jos, care este ordonat de la cel mai mic (L0) la cel mai înalt (L3) nivel de restricție, descrie patru niveluri de izolare pe baza cărora nu ar trebui să apară evenimentul.

7.4.1.3 În timpul executării testului, fiecare Tranzacție TPC-E va oferi un grad de izolare față de Tranzacțiile Arbitrare nu mai puțin decât gradul specificat în următorul tabel:

7.4.1.4 În timpul executării testului, SUT va permite executarea simultană a Tranzacțiilor Arbitrare.

7.4.1.5 În timpul executării testului, datele citite de fiecare Tranzacție TPC-E nu trebuie să fie mai vechi decât cele mai recente Date Verificate la momentul începerii Tranzacției.

7.4.1.6 Sistemele care implementează izolarea Tranzacțiilor folosind tehnici de blocare sau de versiuni trebuie să demonstreze conformitatea cu cerințele de izolare prin trecerea testelor descrise în Clauza 7.4.2.

7.4.1.7 Sistemele care implementează izolarea tranzacțiilor folosind tehnici altele decât blocarea sau versiunea pot necesita alte tehnici pentru a demonstra că cerințele de izolare sunt îndeplinite. Este responsabilitatea Organizatorului testului, împreună cu auditorul, să identifice aceste tehnici, să le implementeze, să le efectueze ca o demonstrație a conformității cu cerințele de izolare și să furnizeze suficiente informații în FDR pentru a susține afirmația că cerințele de izolare au fost întâlnit.

7.4.2 Teste de izolare
Următoarele teste de izolare sunt concepute pentru a verifica dacă configurarea și implementarea Sistemului în curs de testare oferă Tranzacțiilor gradele necesare de izolare, așa cum este descris în clauza 7.4.1.3.

7.4.2.1 P3 Test de citire-scriere

Acest test trebuie să demonstreze că o Tranzacție Citire-Scriere Rezultatele Tranzacției, în timp ce se execută concomitent cu o altă Tranzacție Citire-Scrie Rezultatele Tranzacției, este protejată de Fenomenul Phantom P3. A doua Tranzacție cu rezultat comercial (Sesiunea S4 de mai jos) îndeplinește funcțiile unei Tranzacții aleatoare, care adaugă un rând la tabelul HOLDING_SUMMARY care a fost deja accesat de prima Tranzacție cu rezultat (Sesiunea S3 de mai jos).

În scopul acestei testări, aceste două Tranzacții cu rezultate comerciale trebuie să fie pregătite pentru a executa înregistrarea hs_qty la întoarcerea din Cadrul 1. În plus, Tranzacția cu rezultatul tranzacției executată de S3 trebuie să poată repeta execuția Cadrului 1 și să suspende executarea sa înainte ca Frame-ul să înceapă execuția 2.

1. Din S1, selectați acct_id. După executarea tranzacției specificate în modul doar citire, găsiți valoarea simbolului pentru care nu există niciun rând corespunzător în tabelul HOLDING_SUMMARY pentru parametrul acct_id selectat și commit.

2. De la S1, apelați și finalizați cu succes tranzacția de comandă de tranzacționare pentru act_id și parametrii simbol selectați la pasul 1. Înregistrați trade_id asociat cu aceste tranzacții.

3. Din S2, solicitați și finalizați cu succes o altă tranzacție de comandă comercială pentru parametrii act_id și simbol utilizați la pasul 2. Înregistrați trade_id asociat cu aceste tranzacții.

4. Din S3, interogați trade_id din Trade-Result folosit la pasul 2. Suspendați tranzacția între Frame 1 și Frame 2. Înregistrați hs_qty și verificați dacă este setat la zero.

5. Din S4, interogați trade_id din tranzacția de rezultat al tranzacției utilizată la pasul 3. Verificați dacă tranzacția completează Cadrul 1 și începe să execute Cadrul 2. Înregistrați hs_qty și verificați dacă este setată la zero.

Utilizați cazul A, în cazul în care S4 se oprește în Cadrul 2 și apoi se derulează înapoi în timp ce S3 se termină:
6A. Din S3, repetați execuția Cadrului 1 și faceți o pauză din nou între Cadrul 1 și Cadrul 2. Scrieți hs_qty și verificați dacă valoarea acestuia este setată la zero.
7A. Reluați execuția S3 pe Cadrul 2. Verificați dacă cadrele rămase sunt finalizate cu succes.
8A. Verificați dacă S4 a fost pompat.

6C. Dacă apare o astfel de situație, testul este considerat invalid. Pentru a testa corect protecția la citire fantomă, este necesar ca sesiunea S4 să atingă punctul din Cadrul 2 al Tranzacției de rezultat comercial atunci când un nou rând este adăugat la tabelul HOLDING_SUMMARY. Este posibil ca tranzacția de rezultat al tranzacției utilizată pentru S4 să fie modificată pentru a preveni blocarea acesteia în cadrul 1. De exemplu, poate fi rulată la un nivel mai scăzut de izolare a tranzacției arbitrare.

Nota 1: Testul P3 trece dacă apare cazul A sau B și eșuează dacă apare cazul C. Pot exista alte opțiuni valide (de exemplu, atât S3, cât și S4), scrieți hs_qty = 0. în timpul execuției Cadrului 1, atunci cel mult una dintre aceste Sesiuni se poate finaliza normal și poate comite Tranzacția. Scopul acestui test este de a demonstra că, în orice circumstanțe, dacă S3 recitește tabelul HOLDING_SUMMARY după ce S4 a adăugat (sau a încercat să adauge) un nou rând pentru parametrii acct_id și simbol selectați, un rând care se potrivește tot nu va fi găsit. în S3.
Nota 2: Acest test de izolare creează unul sau mai multe active noi. Execuția ulterioară a testului P2 în citire-scriere (a se vedea paragraful 7.4.2.2) pentru aceiași parametri selectați act_id și simbol poate duce la închiderea poziției create în timpul acestui test.

7.4.2.2 Test P2 în citire-scriere

Acest test arată că o tranzacție de citire-scriere a rezultatelor tranzacției, în timp ce execuția simultană a unei alte tranzacții de citire-scriere a rezultatelor tranzacției, este protejată de fenomenul de citire nerepetabilă P2. A doua Tranzacție cu rezultat comercial (Sesiunea S4 de mai jos) acționează ca o Tranzacție aleatorie care actualizează rândul din tabelul HOLDING_SUMMARY care a fost citit de prima Tranzacție cu rezultat (Sesiunea S3 de mai jos).

În scopul acestei testări, aceste două Tranzacții cu rezultate comerciale trebuie să fie pregătite pentru a executa înregistrarea hs_qty la întoarcerea din Cadrul 1. În plus, Tranzacția cu rezultatul tranzacției executată de S3 trebuie să poată repeta execuția Cadrului 1 și să suspende executarea sa înainte ca Frame-ul să înceapă execuția 2.

Folosind cele patru sesiuni de la S1 la S4, următorii pași sunt efectuati în ordinea corespunzătoare.
1. Din S1, selectați acct_id. Cu tranzacția specificată în modul numai citire, găsiți valoarea simbolului pentru care există un rând corespunzător în tabelul HOLDING_SUMMARY pentru acct_id selectat, înregistrați HS_QTY pentru acel activ și comite.

2. Din S1, solicitați și finalizați cu succes o tranzacție de comandă comercială cu parametrii acct_id și simbol selectați la pasul 1. Înregistrați parametrul trade_id asociat acestor tranzacții.

3. Din S2, solicitați și finalizați cu succes o altă tranzacție de comandă comercială cu parametrii acct_id și simbol utilizați la pasul 2. Înregistrați parametrul trade_id asociat cu aceste tranzacții.

4. Din S3, solicitați o Tranzacție Trade-Result cu parametrul trade_id obținut în pasul 2 și suspendați execuția între Frame 1 și Frame 2. Înregistrați hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.

5. Din S4, solicitați o Tranzacție Trade-Result cu parametrul trade_id obținut la pasul 3. Verificați că acesta completează Cadrul 1 și începe execuția Cadrului 2. Scrieți hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.

Utilizați cazul A, dacă S4 se blochează în Cadrul 2, apoi se derulează înapoi în timp ce S3 se finalizează:
6A. Din S3, reapelați Cadrul 1 și întrerupeți din nou între Cadrele 1 și 2. Înregistrați hs_qty și verificați dacă este egal cu HS_QTY obținut la pasul 1.
7A. Reluați execuția S3 apelând Cadrul 2. Verificați dacă cadrele rămase sunt finalizate cu succes.
8A. Verificați dacă S4 a fost pompat.
Utilizați cazul B, în cazul în care S4 se termină (eventual după oprire) și S3 este anulat:
6B. Verificați dacă S4 finalizează execuția Cadrului 2 și a Cadrelor rămase.
7B. Verificați dacă S3 a fost descărcat.
Utilizați cazul C dacă S4 se oprește în cadrul 1 (incorect):
6C. Dacă apare o astfel de situație, testul este considerat invalid. Pentru a testa corect securitatea împotriva evenimentului P2 Non-Repeatable Read, este necesar ca sesiunea S4 să ajungă la momentul din Frame 2 al Tranzacției Trade-Result când unul dintre rânduri este actualizat în tabelul HOLDING_SUMMARY. Este posibil ca tranzacția de rezultat al tranzacției utilizată pentru S4 să fie modificată pentru a preveni blocarea acesteia în cadrul 1. De exemplu, poate fi rulată la un nivel mai scăzut de izolare a tranzacției arbitrare.

Notă: Acest test trece dacă apare cazul A sau B și eșuează dacă apare cazul C. Pot exista alte opțiuni valide (de exemplu, atât S3, cât și S4), dar dacă atât S3 cât și S4 scrieți aceeași valoare hs_qty. în timpul execuției Cadrului 1, atunci cel mult una dintre aceste Sesiuni se poate finaliza normal și poate comite Tranzacția. Scopul acestui test este de a demonstra că, în orice condiții, atunci când S3 repetă citirea tabelului HOLDING_SUMMARY având în vedere acct_id și simbolul, rândul și valoarea găsite vor fi aceleași ca la pasul 1.

7.4.2.3 Test P1 în citire-scriere

Acest test arată că o tranzacție de citire-scriere a rezultatelor tranzacției, în timp ce o altă tranzacție de citire-scriere a rezultatelor tranzacției se execută concomitent, este protejată de un eveniment de citire murdară P1. Pentru a a acestei testari Tranzacția Trade-Result trebuie configurată pentru a executa înregistrarea se_amount la întoarcerea din Frame 5 și trebuie să poată suspenda execuția în Frame 6 imediat înainte de comitere.

Folosind cele trei sesiuni de la S1 la S3 în ordinea corespunzătoare, se parcurg următorii pași

1. Din S1, apelați Tranzacția Client-Posiție pe parametrul cust_id selectat, finalizați Tranzacția și notați setul de parametri finali acct_id și cash_ball.

2. Din S1, apelați și finalizați cu succes Tranzacția Trade-Order cu parametrul acct_id selectat din setul înregistrat la pasul 1 pentru parametrul simbol dat și cu valoarea type_is_margin egală cu 0. Notați trade_id-ul atribuit acestor tranzacții.

3. Din S1, apelați și finalizați cu succes o altă tranzacție de comandă comercială cu același parametru act_id, dar un parametru simbol diferit de cel folosit la pasul 2 și un parametru type_is_margin setat la 0. Înregistrați ID-ul comercial alocat acestor tranzacții.

4. Din S2, apelați Transaction Trade-Result cu parametrul de intrare trade_id obținut la pasul 2. Înainte de a apela Frame-ul 6, scrieți se_amount, apoi apelați Frame-ul 6 și faceți o pauză înainte de a efectua comiterea.

5. Din S3, apelați Transaction Trade-Result cu parametrul de intrare trade_id obținut la pasul 3. Tranzacția poate fi suspendată, s-ar putea să nu se finalizeze cu succes sau poate fi blocată temporar de la executarea completă. Dacă ajunge la începutul Cadrului 6, scrieți se_amount, apoi apelați Cadrul 6. Dacă ajunge la sfârșitul Cadrului 6, faceți o pauză înainte de a confirma.

6. Din S2, continuați cu confirmarea și finalizarea cu succes a Tranzacției. Înregistrați valoarea rezultată a parametrului acct_bal.

7. Din S3, în funcție de comportamentul tranzacției la sfârșitul pasului 5:
Dacă a ajuns la o suspendare în Cadrul 6, lăsați-o să continue și verificați dacă a fost confirmată și finalizată cu succes.

Dacă a fost blocat înainte de a termina Cadrul 5, verificați dacă a fost deblocat, completat Cadrul 5, a scris se_amount, numit Frame 6, a fost Acknowledged și finalizat cu succes.

Dacă nu s-a finalizat cu succes și a fost derulat înapoi, reapelați tranzacția Trade-Result cu același parametru de intrare trade_id. Verificați dacă Tranzacția cu rezultatul comerțului se execută complet, scrie valoarea se_amount la începutul cadrului 6, se angajează la sfârșitul cadrului 6 și se finalizează cu succes.

8. Din S3, înregistrați cont_bal rezultat și verificați dacă este egal cu valoarea cash_bal de la pasul 1 (folosind acct_id selectat la pasul 2) plus suma sumei se_amount de ieșire pentru aceste două Tranzacții cu rezultate comerciale.

7.4.2.4 Test P1 în citire-scriere

Acest test arată că Tranzacția Citire-Scrie Poziția Clientului în timpul execuției concomitente a Tranzacției Citire-Scriere Rezultatul tranzacției este protejată de evenimentul de citire murdară P1. În scopul acestei testări, Tranzacția cu rezultatul tranzacției trebuie să poată suspenda execuția în Cadrul 6 imediat înainte de confirmare.

Folosind cele patru sesiuni de la S1 la S4, următorii pași sunt efectuati în ordinea corespunzătoare:

1. Din S1, apelați Tranzacția Client-Posiție pe parametrul cust_id selectat, finalizați Tranzacția și notați setul de parametri finali acct_id și cash_ball.

2. De la S1, apelați și finalizați cu succes o tranzacție de comandă de tranzacționare în care parametrul de intrare corespunzător acct_id se potrivește cu unul dintre parametrii acct_id înregistrați la pasul 1 și valoarea tip_is_margin este 0. Înregistrați ID-ul comercial atribuit acestor tranzacții.

3. Din S2, apelați Transaction Trade-Result cu parametrul de intrare trade_id primit la pasul 2 și apoi întrerupeți execuția în Cadrul 6 înainte de comitere.

4. Din S3, apelați Tranzacția Client-Posiție cu parametrul de intrare cust_id selectat la pasul 1. Tranzacția poate reuși sau eșua sau poate fi blocată temporar de la executarea completă.

5. Din S2, continuați cu continuarea și finalizarea cu succes a Tranzacției cu rezultatul comerțului. Înregistrați rezultatul acct_bal.

6. Din S3 în funcție de comportamentul Tranzacției Client-Poziție la sfârșitul pasului 4:

Dacă se completează, înregistrați setul de acct_id și cash_bal rezultate și verificați dacă valorile cash_bal pentru acct_id utilizate la pasul 2 rămân neschimbate de la primul pas.

Dacă a fost blocat, verificați dacă acum s-a finalizat, înregistrați setul de acct_id și cash_bal rezultate și verificați dacă valoarea cash_bal pentru acct_id-ul dat folosit la pasul 2 se potrivește cu acct_bal de la pasul 5.

Dacă nu a fost finalizat, treceți la pasul următor.

7. Din S4, apelați Tranzacția Client-Posiție cu parametrul cust_id selectat la pasul 1, finalizați Tranzacția, înregistrați setul de parametri rezultați acct_id și cash_bal și verificați dacă cash_bal pentru act_id dat utilizat în pasul 2 s-a modificat de la pasul 1 și reflectă volumul tranzacțiilor executate în etapa 5 (în comparație cu acct_bal din etapa 5).

7.5 Cerințe de stabilitate

Sistemul testat trebuie configurat pentru a îndeplini cerințele de robustețe prevăzute în această clauză. Sistemul testat demonstrează proprietăți de stabilitate în cazul salvării Tranzacțiilor confirmate și al menținerii structurii bazei de date după defecțiunile enumerate în clauza 7.5.2. Testarea rezistenței este efectuată prin apelarea defecțiunilor catastrofale și non-catastrofale pe componentele SUT. Eșecurile necatastrofale, descrise în clauza 7.5.5, testează capacitatea SUT de a menține capacitatea de a accesa date. Eșecurile catastrofale descrise în clauza 7.5.6 testează capacitatea SUT de a păstra efectele Tranzacțiilor Confirmate. Durata efectelor unei Eșecuri catastrofale este descrisă în Raportul de testare ca Timp de recuperare a afacerii. Niciunul dintre sistemele existente nu oferă stabilitate absolută (adică stabilitate în orice scenarii de defecțiune). Setul specific de defecțiuni individuale enumerate în Clauza 7.5.2 este considerat suficient de indicativ pentru a afirma prezența Rezilienței în cazurile de astfel de defecțiuni. Cu toate acestea, natura limitată a testelor prezentate nu ar trebui interpretată ca permițând existența altor cazuri irecuperabile de defecțiuni unice.

7.5.1 Definiția conceptelor

Disponibilitate: Capacitatea de a efectua operațiuni de bază de date cu acces complet la date după un accident permanent irecuperabil al oricăruia Transportator permanent care conțin tabele de baze de date, date din jurnalul de recuperare sau Metadatele bazei de date. A se vedea clauza 7.5.2.1.

7.5.1.1 Restaurarea aplicației Catastrofal

7.5.1.2 Timp de recuperare aplicații: Timpul scurs de la începutul Recuperării aplicației până la sfârșit (a se vedea punctul 0).

7.5.1.3 Redresarea afacerii: Procesul de restaurare a unei aplicații de afaceri după Catastrofal defectarea sistemului și atingerea unui punct în care afacerea atinge anumite criterii operaționale.

7.5.1.4 Timp de recuperare a afacerii: Timpul scurs de la începutul Recuperării aplicației până la sfârșit (a se vedea Clauza 7.5.6.8).

7.5.1.5 Catastrofal: Un tip de eroare în care procesarea este întreruptă fără avertisment dat de SUT. După această eroare, numai pentru baza de date prăbușită, toată memoria este ștearsă și tot contextul activ al aplicației este pierdut.

7.5.1.6 Confirmat: O tranzacție este confirmată atunci când acțiunile sale (Adăugați, Eliminați, Modificați) sunt permanente și vizibile pentru alte Tranzacții

7.5.1.7 Notă: Tranzacțiile pot fi efectuate fără ca șoferul să fie vreodată notificat despre acest fapt, deoarece integritatea mesajului nu este necesară.

7.5.1.8.Recuperarea bazei de date: Procesul de recuperare a unei baze de date după o defecțiune catastrofală a sistemului.

7.5.1.9 Timp de recuperare a bazei de date: Durata de la început Recuperarea bazei de date până când fișierele bazei de date sunt complet restaurate.

Cerințe de evaluare a durabilității: condiții pe care SUT trebuie să le îndeplinească în timpul tuturor testelor de stabilitate (a se vedea clauza 7.5.3)

7.5.1.10 Robust: O stare care poate rezista la eșecuri (așa cum este descris în Clauza 7.5.2) și care are semantică de actualizare tranzacțională.

7.5.1.11 Transportator permanent: stocare de date nevolatilă, persistentă, cum ar fi disc magnetic sau bandă.

7.5.1.12 Concept Necatastrofale se referă la o singură defecțiune care nu întrerupe procesarea, dar poate provoca degradarea performanței și SUT-ul nu mai poate fi într-o stare de echilibru până când își revine din defecțiune.

7.5.2 Puncte unice de eșec
Următoarele clauze descriu componentele individuale SUT testate prin defecțiuni non-catastrofale și catastrofale descrise în clauzele 7.5.5 și 7.5.6. Punctele unice de defecțiune se aplică componentelor SUT necesare pentru a îndeplini cerințele de Reziliență.

Organizatorul testului poate aplica un singur test pentru a efectua testarea de reziliență pe mai multe puncte unice de defecțiune (de exemplu, un singur „test de defecțiune totală a sistemului” poate fi aplicat celor trei puncte de defecțiune descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5. .2.4).

7.5.2.1 Eroare permanentă irecuperabilă a unuia dintre mediile persistente.

7.5.2.2 Pauza instantanee(defecțiune de sistem/blocarea sistemului) în procesul de procesare, care necesită o repornire a sistemului pentru a se recupera.
Notă: Aceasta include și o închidere incorectă, care necesită descărcarea unei noi copii. Sistem de operare Cu Dispozitiv de pornire. Nu înseamnă neapărat pierderea datelor din memoria nevolatilă. Un exemplu de mecanism pentru a depăși un eveniment de întrerupere instantanee în procesare este jurnalul de anulare/refacere.

7.5.2.3 Eșecul întregului spațiu de memorie(pierderea conținutului).
Notă: Aceasta presupune că tot spațiul de memorie a eșuat. Acest lucru poate fi cauzat de o pierdere a aprovizionării alimentare externă sau defecțiune permanentă a plăcii de memorie.

7.5.2.4 Încetarea alimentării externe a SUT pentru o perioadă nedeterminată (pentru de curent). Aceasta ar trebui să includă cel puțin toate părțile SUT care sunt implicate în etapele de lucru ale Tranzacției cu baze de date.

Notă: Cerințele de protecție împotriva căderii de curent pot fi îndeplinite prin utilizarea unui număr suficient de UPS pentru a asigura disponibilitatea la nivel de sistem a tuturor componentelor care se confruntă cu o întrerupere a curentului în 30 de minute. Utilizarea unei configurații protejate UPS nu ar trebui să introducă noi puncte unice de defecțiune care nu sunt protejate de alte părți ale configurației. Această afirmație poate fi dovedită fie prin măsurarea, fie prin calculul consumului electric de 30 de minute (în wați) al porțiunii protejate a SUT, înmulțit cu 1,4.

7.5.3 Cerințe pentru evaluarea stabilității.

Toate testele de stabilitate trebuie să îndeplinească următoarele cerințe:

în timpul unui Interval de măsurare să fie efectuat cu același număr de utilizatori configurați și încărcare de șofer
apar într-o stare stabilă
să îndeplinească restricțiile privind timpul de răspuns stabilite în clauza 6.5.1.7.
să îndeplinească cerințele pentru o Combinație de Tranzacții enumerate în clauza 6.3.1.
să fie executat la o valoare de performanță de 95% sau mai mare din Raportat fără erori
potriviți toate setările de configurare Driver și SUT aplicate în timpul intervalului de măsurare.

7.5.4 Instanțe multiple ale sistemului de operare

7.5.4.1 În configurațiile în care funcții similare de analiză comparativă sunt efectuate de mai mult de o instanță a sistemului de operare, testele de defecțiune enumerate în clauza 7.5.2 trebuie efectuate pe cel puțin una dintre acele instanțe.

7.5.4.2 Dacă mai multe instanțe ale Sistemului de operare gestionează date care sunt procesate ca o singură imagine din punctul de vedere al aplicațiilor de evaluare comparativă (de exemplu, un cluster de baze de date), atunci testul de întrerupere a alimentării trebuie efectuat și simultan pe toate aceste cazuri.

Notă: Întreruperea de alimentare a mai multor instanțe în SUT trebuie să apară în decurs de 3 secunde pentru a introduce diferențe în rezultatele procedurilor manuale care pot fi utilizate pentru a finaliza testul.

7.5.4.3 Dacă mai mult de o instanță a sistemului de operare gestionează date care sunt procesate într-o aplicație de referință ca o singură imagine și conectate prin medii fiziceîn afară de o magistrală încorporată (de exemplu, un cablu de expansiune de magistrală, o rețea LAN de mare viteză sau altă metodă de furnizare a comunicației între mai multe instanțe ale sistemului de operare care pot fi supuse întreruperii fizice), este inclusă întreruperea instantanee a unei astfel de comunicări. în lista obiectelor care trebuie testate conform clauzei 7.5. Doar una dintre instanțe de conexiune care utilizează redundanță trebuie verificată pentru eșec.

Notă: acest paragraf nu este destinat să stabilească o cerință de a întrerupe conexiunea cu stocarea pe disc sau subsisteme de discuri cu redundanţă.

7.5.5 Eșecuri non-catastrofale

O defecțiune non-catastrofală este orice defecțiune care nu pierde datele stocate în memoria SUT sau necesită o nouă pornire a sistemului de operare de pe dispozitivul de pornire. Eșecurile non-catastrofale descrise în acest paragraf au un impact asupra accesului la datele stocate pe Media Persistent. Aceste cerințe sunt denumite și cerințe de disponibilitate a datelor.

7.5.5.1 SUT va menține accesul la datele de pe suportul persistent în timpul și după o defecțiune identificată în clauza 7.5.2.1 (eșecul permanent nerecuperabil al oricărui mediu persistent care conține tabele baze de date, date jurnal de recuperare sau metadatele bazei de date). Organizatorul testului trebuie, de asemenea, să restabilească mediul Persistent Media la starea anterioară eșecului, menținând în același timp capacitatea de a accesa datele de pe Persistent Media.

7.5.5.2 Mediile persistente pot fi medii volatile sau nevolatile configurate corespunzător pentru a îndeplini cerințele clauzei 7.5.2.1. Mediile nevolatile sunt de obicei discuri magnetice care folosesc replicarea (RAID-1 mirroring) sau alte metode de protecție (RAID-5 etc.) pentru a garanta accesul la date în timpul unei erori persistente de media. Suporturile volatile, cum ar fi memoria, pot fi utilizate acolo unde mediile volatile pot oferi transfer automat de date înainte ca orice date să fie pierdute pe medii nevolatile după o întrerupere a alimentării, indiferent de momentul în care este restabilită alimentarea.

Nota 1: O sursă de alimentare neîntreruptibilă (UPS) configurată și evaluată nu este considerată o sursă de alimentare externă.

Nota 2: Memoria poate fi considerată stocare permanentă dacă poate păstra datele suficient de mult pentru a îndeplini cerințele descrise mai sus, de exemplu dacă este suplimentată cu o sursă de alimentare neîntreruptibilă și conținutul memoriei poate fi redirecționat către stocare nevolatilă la momentul eșecului. Trebuie menționat că nu se face distincție între memoria principală și memoria care îndeplinește funcții similare de stocare permanentă sau temporară a datelor în alte părți ale sistemului (de exemplu, cache-ul controlerului de disc). Dacă memoria principală este utilizată ca mediu persistent, aceasta trebuie considerată ca un potențial punct unic de defecțiune. Un exemplu de soluție pentru o singură eșec media persistentă este oglindirea media persistentă.

Dacă memoria este un mediu permanent, iar oglindirea este folosită pentru a asigura stabilitatea, atunci băncile de memorie în oglindă trebuie să aibă surse de alimentare independente.

7.5.5.3 Testele de disponibilitate a datelor (numite și Teste de eșec non-catastrofal) trebuie să respecte Cerințele de evaluare a rezistenței din clauza 7.5.3.

7.5.5.4 Niveluri de redundanță
Nivelul de redundanță denotă gradul în care disponibilitatea datelor este garantată în cazul unei singure defecțiuni a componentelor de stocare a datelor. SUT trebuie să folosească unul dintre nivelurile următoare Redundanțe:

Redundanță de nivel 1 (redundanță media persistentă): garantează accesul la datele de pe mediile persistente în cazul unei defecțiuni pe unul dintre mediile persistente.

Notă: sarcină acest nivel redundanța este de a testa mediul media persistent pentru a rezista la eșecul unuia dintre mediile persistente și de a continua procesarea solicitărilor din sistemul de operare și/sau DBMS.

Exemplu: Organizatorul de testare a implementat utilizarea RAID-1 (oglindire) pe discurile din stocare. În cazul unei defecțiuni pe unul dintre discuri, Organizatorul trebuie să ofere acces la datele de pe toate discurile rămase.

Redundanță de nivel 2 (redundanța controlerului media persistentă): Activează redundanța de nivel 1 și garantează accesul la datele de pe suportul media persistent atunci când apare o singură defecțiune în controlerul de stocare utilizat pentru atingerea nivelului de redundanță sau în comunicațiile dintre controlerul de stocare și dispozitivul persistent. Mass-media.

Notă: Scopul acestui nivel de redundanță este de a testa capacitatea circuitului implementat de a rezista la defecțiunea controlerului de stocare care implementează redundanța de nivel 1.

Exemplu: Dacă Redundanța de Nivel 1 este atinsă prin implementarea protecției RAID-5 pe disc, atunci Redundanța de Nivel 2 va fi testată folosind o defecțiune a hardware-ului utilizat pentru implementarea protecției RAID-5.

Dacă controlerul care implementează RAID-5 este conținut într-o structură de disc (sau un dispozitiv similar atașat extern), atunci Organizatorul trebuie să demonstreze că este în continuare capabil să acceseze datele stocate în structură.

Dacă controlerul care implementează RAID-5 este situat separat de carcasa care conține discurile și controlerul nu este utilizat ca mediu persistent (de exemplu, un cache de scriere în oglindă), atunci este suficient să rupeți conexiunile dintre controler și structura discului.

Redundanță de nivel 3 (redundanță completă): Activează redundanța de nivel 2 și garantează accesul la datele de pe Media Persistentă atunci când apare o singură defecțiune în sistemul Media Persistent, inclusiv legăturile dintre Stratul B și sistemul Media Persistent.

Nota 1: Sistemul Persistent Media conține toate componentele necesare pentru a îndeplini cerințele de durabilitate descrise mai sus. Aceasta nu include sistemul de nivel B sau magistrala de sistem, dar include adaptorul de magistrală de sistem și toate componentele „de sub” adaptor.

Nota 2: Scopul acestei clauze este de a testa capacitatea sistemului de Nivel B de a rezista defecțiunilor componentelor sale și de a continua să proceseze Tranzacțiile.

Notă: Componentele testate în acest paragraf sunt considerate module care se pot înlocui rapid. Intenția acestei clauze nu este de a solicita Organizatorului să testeze stabilitatea backplane-ului în stocarea Media Persistente sau a componentelor similare care nu pot fi înlocuite. În același timp, sarcinile de testare includ verificarea proprietăților de toleranță la erori ale controlerelor de stocare, inclusiv cache-ul oglindit pe controler și software-ul corespunzător.

7.5.5.5 Procedura de testare a robusteței pentru disponibilitatea datelor

1. Determinați numărul curent de tranzacții finalizate în baza de date, rulând interogarea:
selectați count(*) ca count1 din SETTLEMENT

2. Începeți să trimiteți Tranzacții pentru procesare și să creșteți performanța la nivelul Cerinților de evaluare a rezistenței (așa cum este descris în clauza 7.5.3) și mențineți-le la acest nivel timp de cel puțin 5 minute.

Notă: Odată ce cerințele de evaluare a stabilității sunt îndeplinite:

Orice modificare a configurației driverului este interzisă până la finalizarea etapei 5
Orice modificare a configurației SUT este interzisă, cu excepția celor necesare pentru a parcurge pașii 3 și 4.

3. Nu verificați, după cum este necesar, nivelul de redundanță demonstrat.

4. Începeți procedurile necesare recuperare.

5. Continuați să lucrați cu driverul timp de 20 de minute.

6. Încheiați corect execuția de la Driver.

7. Obțineți noul număr de tranzacții finalizate în baza de date rulând:

8. Comparați numărul de tranzacții cu rezultatul tranzacției finalizate de șofer cu valoarea
(număr 2 - număr 1). Verificați dacă (count2 - count1) este egal cu numărul de intrări ale tranzacțiilor cu rezultate comerciale reușite în fișierul jurnal al driverului.

9. Permiteți ca procedura de recuperare să se termine conform așteptărilor.

7.5.6 Eșecuri catastrofale.

Unele defecțiuni pot fi de natură catastrofală și, în astfel de cazuri, accesul la date se pierde. SUT-ul trebuie să fie capabil să salveze starea bazei de date și să restabilească accesul la date în cel mai scurt timp posibil.
Eșecuri catastrofale sunt de natură bruscă și imprevizibilă, ducând adesea la pierderi neașteptate în procesarea tranzacțiilor. Cerințele din această clauză testează capacitatea SUT de a păstra consecințele Tranzacțiilor Confirmate. Deoarece capacitatea de procesare a tranzacțiilor este esențială într-un mediu OLTP, organizatorul de testare trebuie să măsoare și să raporteze timpul necesar DBMS-ului pentru a se recupera de la eșecurile catastrofale. Acest timp de recuperare se numește Business Recovery Time.
Notă: Eșecurile catastrofale reprezintă o perturbare uriașă a proceselor de afaceri, prin urmare este imperativ ca întreprinderile să-și revină cât mai repede posibil după astfel de eșecuri. Există mulți parametri și practici de configurare a bazei de date care afectează direct performanța DBMS și timpul de recuperare a acestuia după o defecțiune catastrofală. Deși este cunoscut faptul că timpii de încărcare sunt sisteme diferite poate varia într-un interval foarte mare, parametrii de încărcare au un efect extrem de mic asupra performanței DBMS și nu fac parte din timpul de recuperare a afacerii.

7.5.6.1 Testele de eșec catastrofal trebuie să respecte Cerințele de evaluare a rezistenței prevăzute în Clauza 7.5.3.

7.5.6.2 Implementarea unei imagini de recuperare dintr-o copie de rezervă a bazei de date (de exemplu, o copie pre-execuție), folosind datele jurnalului Rollback/Undo nu este acceptabilă ca mecanism de recuperare pentru eșecurile enumerate în 7.5.2.2, 7.5.2.3, și 7.5 .2.4. Trebuie remarcat faptul că punctele de control, punctele de verificare, punctele de secvență (și similare) bazele de date create în timpul rulării unui job nu sunt considerate date arhivate.

7.5.6.3 Dacă mecanismul de recuperare se bazează pe conținutul memoriei volatile înainte de defecțiune, atunci mijloacele utilizate pentru a evita pierderea conținutului memoriei volatile (de exemplu, o sursă de alimentare neîntreruptibilă) vor fi luate în considerare la calcularea costului sistemul (a se vedea clauza 8.3.1.3).

7.5.6.4 Începutul recuperării bazei de date este momentul în care fișierele bazei de date sunt accesate pentru prima dată de un proces care cunoaște conținutul acelor fișiere și intenționează să recupereze baza de date sau să execute Tranzacții care operează pe baza de date.

Notă: acces la fișiere de către procesele sistemului de operare pentru a verifica integritatea Sistemul de fișiere sau volume pentru a corecta erorile din structurile de date nu înseamnă începerea recuperării bazei de date.

7.5.6.5 Finalizarea recuperării bazei de date este punctul în care fișierele bazei de date au fost restaurate.

Notă: De obicei, baza de date va indica această oră în fișierele sale jurnal.

7.5.6.6 Începutul recuperării aplicației este momentul în care prima Tranzacție este trimisă după începerea recuperării bazei de date.

7.5.6.7 Sfârșitul recuperării aplicației este punctul în care SUT începe să funcționeze la o performanță mai mare sau egală cu 95% din Raportat și continuă să facă acest lucru timp de cel puțin 20 de minute.

7.5.6.8 Procedura de testare pentru defecțiuni catastrofale

1. Determinați numărul curent de tranzacții finalizate în baza de date rulând:
selectați count(*) ca count1 din SETTLEMENT.

2. Începeți execuția Tranzacțiilor și creșteți performanța la nivelul cerințelor de evaluare a rezistenței (așa cum este descris în clauza 7.5.3) și respectați aceste cerințe timp de cel puțin 20 de minute.

3. Efectuați una sau mai multe Eșecuri catastrofale de la paragrafele 7.5.2.2, 7.5.2.3 sau 7.5.2.4.

4. Dacă se potrivește configurație de testare, nu mai trimiteți Tranzacții.

5. Dacă este necesar, reporniți SUT (care poate implica o repornire completă).

6. Marcați ora de începere a recuperării bazei de date (vezi paragraful 7.5.6.4), fie automat, fie manual de către operator.

7. Când procedura de recuperare a bazei de date se încheie, notați ora. Acest lucru se poate întâmpla în timpul pasii urmatori(a se vedea paragraful 7.5.6.5).

8. Începeți Executarea Testului 2 sau continuați să trimiteți Tranzacții și marcați acest moment drept începutul Recuperării aplicației (vezi Clauza 7.5.6.6). Creșteți productivitatea la 95% din productivitatea raportată.

Notă: Dacă există un interval de timp între sfârșitul restabilirii bazei de date și începutul restabilirii aplicației și dacă driverele și tranzacțiile trebuie repornite (în loc să continue), atunci o tranzacție de curățare comercială poate fi începută în timpul această perioadă de timp.

9. Marcați sfârșitul Recuperării aplicației, așa cum este descris în paragraful 7.5.6.7.

10. Opriți corect driverul.

11. Verificați dacă driverul nu a raportat nicio eroare la pașii de la 7 la 10. Acest lucru este pentru a vă asigura că Utilizator final nu va asista la niciuna efecte negative(pe lângă disponibilitatea aplicației și performanța potențial redusă) din cauza eșecului SUT și a recuperării ulterioare a afacerii.

12. Obțineți noul număr de tranzacții finalizate în baza de date rulând:
selectați count(*) ca count2 din SETTLEMENT

13. Comparați numărul de tranzacții Trade-Result finalizate de Driver cu valoarea (count2 - count1). Verificați dacă (count2 - count1) este mai mare sau egal cu numărul total de intrări de tranzacție cu rezultat tranzacționat reușit din fișierul jurnal Driver, legate de rulările efectuate în etapa 2 și etapa 7.
Dacă există o inegalitate, atunci tabelul SETTLEMENT trebuie să conțină intrări suplimentare iar diferența trebuie să fie mai mică sau egală cu număr maxim Tranzacții care pot fi simultan în proces de transfer de la șofer la SUT. Acest număr este legat de implementarea driverului și setările de configurare la momentul defecțiunii.

Notă: Această diferență ar trebui să existe numai din cauza Tranzacțiilor efectuate pe sistemul în curs de testare pentru care, în ciuda acestui fapt, nicio ieșire nu a fost returnată driverului înainte de eșec.

14. Verificați condițiile de secvență așa cum sunt specificate în Clauza 7.3.3.

15. Calculați timpul de recuperare a afacerii ca sumă a timpului de recuperare a aplicației și a timpului de recuperare a bazei de date, cu excepția cazului în care aceste perioade de timp se suprapun. Dacă Recuperarea aplicației începe înainte de sfârșitul Recuperării bazei de date, atunci Timpul de recuperare a afacerii este timpul scurs între începerea Recuperării bazei de date și sfârșitul Recuperării aplicației.

7.5.7 Raportarea de durabilitate obligatorie.

7.5.7.1 Organizatorul testului trebuie să descrie nivelul de redundanță și să descrie testul(ele) folosit(e) pentru a demonstra conformitatea în raport.

7.5.7.2 Diagrama de disponibilitate a datelor
Raportul trebuie să prezinte un grafic al Performanței Măsurate în raport cu timpul scurs pentru fragmente de execuție a Testului de Disponibilitate a Datelor, pregătit în conformitate cu următoarele convenții:

Axa X reprezintă timpul scurs pentru testele descrise în Clauza 7.5.5.5, pentru etapele 2 până la 6
Axa Y reprezintă performanța exprimată în tpsE

Notă: Scopul este de a demonstra impactul asupra performanței al procedurii de recuperare.

7.5.7.3 Evaluări raportate
Momentul pentru redresarea afacerii ar trebui să fie indicat în Ordinul executoriu final și în Raport. Dacă defecțiunile descrise în clauzele 7.5.2.2, 7.5.2.3 și 7.5.2.4 nu au fost combinate într-un singur test de rezistență (de obicei prin întreruperea alimentării la serverul bazei de date în timpul execuției), atunci timpul de recuperare a afacerii pentru eșecul descris pentru întrerupere bruscă este - acesta este timpul de recuperare a afacerii care ar trebui inclus în ordinul final de executare. Toate valorile timpului de recuperare a afacerii pentru fiecare test care necesită recuperarea afacerii trebuie raportate în raport.

7.5.7.4Cronologia redresării afacerii
Raportul va include un grafic al performanței măsurate în raport cu timpul scurs pentru segmentele de execuție a testului de redresare a afacerii, pregătit în conformitate cu următoarele convenții:

Axa X afișează timpul maxim scurs pentru cele două runde de testare descrise la punctul 7.5.6.8 pentru etapele 2 și 8
Axa Y reprezintă performanța exprimată în tpsE
Trebuie utilizată o dimensiune a scării grafice de 1 minut.
Datele pe axa Y ar trebui să fie reprezentate grafic pentru ambele curse pe același grafic, cu punctele finale ale fiecărei curse indicate clar.
În scopul creării unui grafic, punctul de referință zero este definit după cum urmează:
Pentru rularea descrisă la pasul 2 din clauza 7.5.6.8, punctul de referință zero este definit ca momentul în timp în care prima Tranzacție este aplicată bazei de date.
Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, punctul de referință zero este definit ca momentul în care începe recuperarea bazei de date.
În scopul creării unui program, sfârșitul unei rulări este determinat după cum urmează:
Pentru rularea descrisă la pasul 2 din clauza 7.5.6.8, sfârșitul rulării este momentul în care are loc defecțiunea (a se vedea pasul 3 din clauza 7.5.6.8)
Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, sfârșitul rulării este momentul la care Recuperarea aplicației s-a finalizat cu succes (consultați pasul 8 din clauza 7.5.6.8)
Pentru rularea descrisă la pasul 8 din clauza 7.5.6.8, dacă există vreo perioadă de timp între sfârșitul recuperării bazei de date și începerea recuperării aplicației, această perioadă trebuie ignorată și cele două perioade ar trebui să fie reprezentate grafic lângă fiecare. alte.

Poate că ați auzit deja termenul ca tranzacţie . Dacă nu sau ați uitat, atunci permiteți-ne să vă reamintim că mai jos tranzacţie se referă la o anumită secvență de operații (acțiuni de inserare, actualizare sau ștergere) din baza de date care trebuie efectuate ca parte a unui singur întreg.

Cu toții folosim serviciile băncilor și cheltuim diverse operatii Cu în numerar. Cum să obțineți fiabilitatea în acest caz? Cerințele de securitate pentru efectuarea operațiunilor în astfel de sisteme sunt crescute. Acum imaginați-vă că transferați fonduri unei persoane cunoscute. Doriți ca fondurile să fie debitate din contul dvs. și transferate în contul destinatarului. Dar ce se întâmplă în cazul unei defecțiuni, de exemplu, sursa de alimentare sau altele situație de urgență? Cine vă garantează că nu vă veți găsi într-o situație în care banii v-au părăsit contul, dar transferul în contul destinatarului nu a avut loc. Ajută la prevenirea unor astfel de situații tranzacții.

Angajarea și retragerea unei tranzacții.

O tranzacție combină mai multe extrase SQL. Dacă apare vreun eșec ca urmare a executării a cel puțin uneia dintre cereri, tranzacția este imediat anulată ( rollback). Dacă totul este în regulă și toate acțiunile din cadrul unei singure tranzacții au fost finalizate cu succes, atunci commit-ul este efectuat ( comite) tranzacții și numai în acest caz modificările corespunzătoare sunt scrise în baza de date.

Acum să demonstrăm un exemplu de utilizare a tranzacțiilor în SGBD MySQL(în cele mai populare SGBD acest mecanism nu este fundamental diferit):

Să avem un tabel de testare conturi, care stochează informații despre conturile de utilizator. Și un domeniu care ne interesează se numește echilibru. Când transferați dintr-un cont în altul, fondurile ar trebui să fie debitate dintr-un cont și creditate în altul (în scopuri practice, puteți crea singur o mică bază de date).

Tranzacția începe cu cuvânt cheie ÎNCEPE. Doi operatori ACTUALIZAȚI tranzacțiile interne fac parte din aceeași tranzacție și pot fi executate fie ambele în același timp, fie niciuna dintre ele (trebuie să aibă loc o derulare). Echipă COMMIT servește pentru a indica încheierea tranzacției și efectuarea modificărilor. Dacă commit-ul are succes, atunci toate modificările din baza de date sursă vor fi afișate.

Pentru a anula o tranzacție, puteți scrie în mod explicit comanda ROLLBACK.

Proprietăți ACIDE.

Deci, ne-am familiarizat cu conceptul de tranzacție, commit și rollback. Acum să ne uităm la patru proprietăți foarte importante ale unei tranzacții despre care oamenii le place adesea să întrebe în interviuri. Cerințe ACID la sfârșitul anilor 70 formulat de Jim Gray (câștigător al Premiului Turing pentru contribuția sa la dezvoltarea bazelor de date). Și așa sună:

Atomicitatea- atomicitate. Despre ce am vorbit mai sus. tranzacția este atomică, adică toate acțiunile efectuate în cadrul unei singure tranzacții sunt un singur întreg.
Consecvență— consistența. Fiecare nouă tranzacție mută baza de date dintr-o stare consistentă în alta. Dacă baza de date este distribuită, atunci toate replicile sale trebuie să conțină aceeași versiune a datelor pentru a asigura disponibilitatea. Această regulă este adesea încălcată de mulți NoSQL baze de date.
Izolare- izolare. Tranzacțiile nu se afectează reciproc. În cazul execuției paralele, actualizarea parțială a datelor nu ar trebui să aibă loc.
Durabilitate- fiabilitate. Doriți ca toate modificările făcute prin această tranzacție să fie salvate în caz de eșec? De aceea în această listă există o proprietate a fiabilității.

Cerințe privind acidul

Atomicity - Atomicity

Consistență - Consistență

Una dintre cele mai complexe și ambigue proprietăți ale celor patru ACIDI. Conform acestei cerințe, sistemul este într-o stare consecventă înainte de începerea tranzacției și trebuie să rămână într-o stare consecventă după finalizarea tranzacției. Cerința de consecvență nu trebuie confundată cu cerința de integritate. Aceste din urmă reguli sunt mai înguste și, în multe privințe, specifice SGBD-urilor relaționale: există cerințe pentru integritatea tipului, integritatea referențială și integritatea entității, care nu pot fi încălcate fizic datorită caracteristicilor de implementare ale sistemului.

În fine, o altă notă se referă la faptul că pe parcursul consecvența execuției tranzacției nu este necesar. În exemplul nostru, debitarea și creditarea vor fi cel mai probabil două sub-operațiuni diferite, iar o stare inconsecventă a sistemului va fi vizibilă între execuția lor în cadrul tranzacției. Totuși, nu trebuie să uităm că dacă cerința de izolare este îndeplinită, această inconsecvență nu va fi vizibilă pentru nicio altă tranzacție. Iar atomicitatea garantează că tranzacția fie va fi complet finalizată, fie că nici una dintre operațiunile tranzacțiilor nu va fi efectuată. Astfel, această inconsecvență intermediară este ascunsă.

Izolare - Izolare

În timp ce o tranzacție se desfășoară, tranzacțiile concurente nu ar trebui să afecteze rezultatul acesteia. Această proprietate nu este respectată la nivelul de izolare Read Committed și mai jos.

Durabilitate - Fiabilitate

Indiferent de problemele de la niveluri inferioare (de exemplu, întreruperea sistemului sau defecțiunile hardware), modificările efectuate printr-o tranzacție finalizată cu succes ar trebui să rămână salvate după ce sistemul este readus în funcțiune. Cu alte cuvinte, dacă utilizatorul a primit confirmarea din partea sistemului că tranzacția a fost finalizată, poate fi sigur că modificările pe care le-a făcut nu vor fi anulate din cauza unor eșecuri.

Literatură

P.A. Bernstein, N. Goodman, V. Hadzilacos. Controlul concurenței și Recuperareîn Sisteme de baze de date. - Addison-Wesley, 1986.

Note

Fundația Wikimedia. 2010.

Vezi ce este „ACID” în alte dicționare:

acid- ACÍD, Ă, acizi, de, s.m., adj. 1. s.m. Substanță chimică, cu gust acru și miros înțepător, care înroșeste hârtia albastră de turnesol și care, în combinație cu o bază, formează o sare. 2.adj. (Adesea fig.) Care are proprietăţile unui acid (1),… … Dicționar Român

Acid- Productions (ACiD) este eine Scene Artgroup welche sich, 1990 gegründet, ursprünglich auf ANSI Art für Mailboxen spezialisiert hat. In den letzten Jahren fand mit dem Niedergang der Mailbox Szene ein Wechsel zu anderen Hauptaktivitäten wie… … Deutsch Wikipedia

acid- Din anii 1960, când acidul a fost folosit pentru prima dată pentru a însemna drogul halucinogen LSD, cuvântul a dezvoltat toate conotațiile unei subculturi. Acele droguri luate au ajuns să fie numite acid heads sau acid freaks; iar modul lor de viață a ajuns să depindă de… … utilizarea engleză modernă

Acid- Productions ACiD Productions (ACiD) este un grup artistic și numeric underground. Fondat în 1990, grupul era de origine specializată în graficul ANSI pentru BBS. Plus recent, ils ont étendu leur domaine d application vers d… … Wikipédia en Français

- (în engleză „acid”): în muzică, acid house, acid techno sunt genuri muzicale. Acid este o trupă rock japoneză. Acid este o trupă belgiană de speed/thrash metal. Acid Substanță narcotică LSD 25. În informatică Sony ACID Pro editor audio ACID set... ... Wikipedia

acid- amar, acru la gust acerb, acidulat, muscator, picant, intepator, ascutit, acid, otet, otet; concept 613 Ant. acid blând, dulce cu proprietăți acide, corozive acerbic, acidulat, acriș, antialcalin, mușcător,… … Tezaur nou

Acid- Ac id, a. 1. Acru, ascuțit sau mușcător după gust; tartă; avand gust de otet: ca, fructe acide sau lichioruri. De asemenea fig.: Acru temperat. Era sever și......

Acid- Ac id, n. 1. O substanță acră. 2. (Chim.) Unul dintr-o clasă de compuși, în general, dar nu întotdeauna, se disting prin gustul lor acru, solubilitatea în apă și înroșirea culorilor de albastru sau violet vegetal. Ele sunt de asemenea caracterizate…… Dicționarul internațional colaborativ de engleză