Messaggio la tua transazione è stata completata con successo. Cos'è una transazione con carta di credito. Divieto dell'operazione. Il cosiddetto "autocommitmento"

Il sistema di controllo delle transazioni in sospeso opera su sb-opknt.online. Visitando questo sito, imparerai a conoscere una transazione incompiuta per un importo di 131.269 rubli. È necessario agire e prelevare denaro entro poche ore, altrimenti il pagamento verrà annullato. Abbiamo verificato se il progetto sta effettuando un pagamento.

Il sistema di controllo delle transazioni in sospeso ti invierà davvero denaro?

Il sito forniva solo un indirizzo e-mail per la comunicazione con un certo PJSC "OPK NT". Non abbiamo trovato informazioni su questo PJSC e i dettagli sul sito non sono stati indicati. La società era chiaramente fittizia. Il disclaimer era di difficile lettura ed era collocato in fondo al sito. Ma ogni visitatore dovrebbe leggerlo, poiché le dichiarazioni sul reddito promesso erano annunciate come ipotesi senza garanzie di pagamento.

Non aveva senso sperare di ricevere denaro dal sistema di controllo delle transazioni in sospeso. Il messaggio sul sito, il numero della transazione e l'account personale, nonché l'importo: tutto sarà lo stesso per tutti i visitatori. Il fatto di un possibile annullamento di denaro indicava la natura discutibile del sito.

Siamo stati reindirizzati alla pagina successiva, che presumibilmente è un account personale. Abbiamo inserito diversi numeri nel modulo e ordinato un prelievo di denaro. I dati sono stati verificati e i fondi sono stati inviati. È improbabile che sia stato possibile inviare un pagamento ai nostri dati errati, ma non ci sono stati reclami contro di noi. Ci è stato offerto di pagare solo 496 o 396 rubli per il metodo di trasferimento scelto. Il pagamento è stato previsto sul servizio E-Pay, che serve a promuovere le truffe, che in un certo modo hanno caratterizzato il sito testato.

Dopo il pagamento di 396 rubli, l'operazione di trasferimento è proseguita. Come previsto, è sorto un nuovo ostacolo: la banca della parte ricevente ha rifiutato la transazione. Il truffatore che ha creato il sito testato non si è fermato a un pagamento e ha richiesto il successivo, 720 rubli per i servizi di preparazione della documentazione. Nessuno era interessato ai documenti qui, era solo un pretesto per chiedere soldi. Siamo stati nuovamente inviati a E-Pay.

Abbiamo capito che i 131.269 rubli promessi non ci sarebbero stati pagati. Inizialmente siamo stati ingannati. L'affermazione che tutte le azioni sul sito sono protette si è rivelata falsa: sul sito non esisteva il protocollo https che proteggesse i dati e gli antivirus noti erano rappresentati da immagini prive di significato.

Risultati sul Sistema di Controllo delle Operazioni Incomplete:

le informazioni sul sito specificato sono false;
non dovresti visitare questa risorsa.

Per una panoramica dettagliata, guarda il video:

pubblichiamo modi comprovati per fare soldi.

I truffatori diventano creativi quando escogitano motivi per i pagamenti. Ma farli, sperando di essere pagati, è inutile. Dalla nostra mailing list, puoi scoprire le truffe che sono sorte su Internet, se ti iscrivi. I nostri contatti del team -. Inviaci i tuoi suggerimenti per testare i siti.

Esistono vari modelli di transazioni che possono essere classificati in base a varie proprietà, tra cui la struttura della transazione, la concorrenza all'interno della transazione, la durata, ecc.

Attualmente si distinguono i seguenti tipi di transazioni: transazioni piatte o classiche, transazioni concatenate e transazioni nidificate.

Le transazioni piatte, o tradizionali, sono caratterizzate da quattro proprietà classiche: atomicità, consistenza, isolamento, durabilità (forza) - ACID (Atomicità, Consistenza, Isolamento, Durabilità). Le transazioni tradizionali sono talvolta chiamate transazioni ACID. Le proprietà sopra menzionate significano quanto segue:

La proprietà dell'atomicità (Atomicità) si esprime nel fatto che una transazione dovrebbe essere eseguita nel suo insieme o per niente.

La proprietà Consistency garantisce che man mano che le transazioni progrediscono, i dati passano da uno stato coerente a un altro: la transazione non interrompe la coerenza reciproca dei dati.

La proprietà Isolation indica che le transazioni concorrenti per l'accesso al database vengono elaborate fisicamente in sequenza, in isolamento l'una dall'altra, ma agli utenti sembra che vengano eseguite in parallelo.

La proprietà Durability è interpretata come segue: se una transazione viene completata con successo, le modifiche ai dati da essa apportate non possono in nessun caso essere perse (anche in caso di errori successivi).

Ci sono due opzioni per completare una transazione. Se tutte le istruzioni hanno esito positivo e non si sono verificati errori hardware o software durante la transazione, la transazione viene confermata.

Il commit di una transazione è l'atto di scrivere su disco le modifiche nel database che sono state apportate durante l'esecuzione di una transazione.

Fino a quando non viene eseguito il commit della transazione, è consentito eseguire il rollback di queste modifiche, ripristinare il database allo stato in cui si trovava al momento dell'inizio della transazione. Commettere una transazione significa che tutti i risultati della transazione sono resi costanti. Diventeranno visibili ad altre transazioni solo dopo che la transazione corrente è stata confermata. Fino a questo punto, tutti i dati interessati dalla transazione saranno "visibili" all'utente nello stato all'inizio della transazione in corso.

Se durante l'esecuzione di una transazione accade qualcosa che rende impossibile completarla normalmente, il database deve essere riportato allo stato originale. Un rollback della transazione è l'azione che esegue il rollback di tutte le modifiche ai dati apportate dalle istruzioni SQL al corpo della transazione in sospeso corrente.

Ogni istruzione in una transazione fa la sua parte del lavoro, ma tutte le sue istruzioni devono essere completate incondizionatamente affinché l'intero lavoro venga completato con successo. Il raggruppamento di istruzioni in una transazione indica al DBMS che l'intero gruppo dovrebbe essere eseguito nel suo insieme e questa esecuzione dovrebbe essere supportata automaticamente.

Lo standard ANSI/ISO SQL definisce il modello di transazione e le funzioni delle istruzioni COMMIT e ROLLBACK. Lo standard specifica che una transazione inizia con la prima istruzione SQL, avviata dall'utente o contenuta in un programma, che modifica lo stato corrente del database. Tutte le istruzioni SQL successive costituiscono il corpo della transazione. La transazione si conclude in uno dei quattro modi possibili (Figura 11.1):

la dichiarazione COMMIT indica il buon esito dell'operazione; il suo utilizzo apporta modifiche permanenti al database all'interno della transazione in corso;

l'istruzione ROLLBACK interrompe la transazione, annullando le modifiche apportate al database nell'ambito di tale transazione; una nuova transazione inizia immediatamente dopo aver utilizzato ROLLBACK;

il completamento con successo del programma in cui è stata avviata la transazione corrente significa il completamento con successo della transazione (come se fosse utilizzata l'istruzione COMMIT);

un'errata chiusura del programma interrompe la transazione (come se fosse stata utilizzata un'istruzione ROLLBACK).

In questo modello, ogni istruzione che modifica lo stato del database è considerata una transazione, quindi, dopo aver completato con successo questa istruzione, il database entra in un nuovo stato stabile.

Le prime versioni di DBMS commerciali implementavano il modello di transazione ANSI/ISO. Successivamente, è stato implementato un modello di transazione esteso nel DBMS SYBASE, che include una serie di operazioni aggiuntive. Il modello SYBASE utilizza i seguenti quattro operatori:

L'istruzione BEGIN TRANSACTION segnala l'inizio di una transazione. A differenza del modello ANSI/ISO, in cui l'inizio di una transazione è implicitamente specificato dalla prima istruzione di modifica dei dati, nel modello SYBASE, l'inizio di una transazione è specificato esplicitamente utilizzando l'istruzione di inizio transazione.

L'istruzione COMMIT TRANSACTION segnala il completamento con successo della transazione. È equivalente all'istruzione COMMIT nel modello standard ANSI/ISO. Questo operatore, come l'operatore COMMIT, esegue il commit di tutte le modifiche apportate al database durante l'esecuzione di una transazione.

L'istruzione SAVE TRANSACTION crea un punto di salvataggio all'interno della transazione che corrisponde allo stato intermedio del database salvato al momento dell'esecuzione di questa istruzione. L'istruzione SAVE TRANSACTION può contenere il nome di un punto di salvataggio. Pertanto, durante l'esecuzione di una transazione, possono essere memorizzati più punti di salvataggio, corrispondenti a più stati intermedi.

L'istruzione ROLLBACK ha due modifiche. Se questa istruzione viene utilizzata senza un parametro aggiuntivo, viene interpretata come un'istruzione di rollback per l'intera transazione, ovvero in questo caso è equivalente all'istruzione ROLLBACK nel modello ANSI/ISO. Se l'istruzione di rollback ha un parametro ed è scritta come ROLLBACK B, allora viene interpretata come un'istruzione di rollback della transazione parziale al punto di salvataggio B.

I principi di esecuzione delle transazioni nel modello di transazione esteso sono mostrati in Fig. 11.2. Nella figura gli operatori sono contrassegnati da numeri in modo che sia più conveniente per noi tracciare l'andamento della transazione in tutti i casi possibili.

La transazione inizia con un operatore esplicito dell'inizio della transazione, che nel nostro schema ha il numero 1. Segue l'operatore 2, che è un operatore di ricerca e non cambia lo stato corrente del database, e i seguenti operatori 3 e 4 trasferire il database in un nuovo stato. L'istruzione 5 salva questo nuovo stato intermedio del database e lo contrassegna come stato intermedio nel punto A. Quindi seguono le istruzioni 6 e 7, che trasferiscono il database in un nuovo stato. E l'operatore 8 salva questo stato come stato intermedio nel punto B. L'operatore 9 esegue un nuovo inserimento dati e l'operatore 10 esegue un controllo della condizione 1; se la condizione 1 è soddisfatta, viene eseguita l'istruzione 11, che riporta la transazione allo stato intermedio B Ciò significa che le conseguenze delle azioni dell'istruzione 9 vengono, per così dire, cancellate e il database ritorna allo stato intermedio B, sebbene dopo l'esecuzione dell'istruzione 9 fosse già in un nuovo stato E dopo il rollback della transazione, invece dell'istruzione 9, che era stata precedentemente eseguita dallo stato Nel database, viene eseguita l'istruzione 13 di immissione di nuovi dati, quindi viene trasferito il controllo all'istruzione 14. L'istruzione 14 controlla nuovamente la condizione, ma già qualche nuova condizione 2, se la condizione è soddisfatta, il controllo viene trasferito all'operatore 15, che riporta la transazione allo stato intermedio A, ovvero tutte le istruzioni che hanno modificato il database, partendo da 6 e terminando con 13, sono considerati non eseguiti, ovvero i risultati della loro esecuzione sono scomparsi e siamo nuovamente nello stato A, poiché dopo l'esecuzione dell'istruzione 4 Il controllo successivo viene trasferito all'operatore 17, che aggiorna il contenuto del database, dopodiché il controllo La decisione viene trasferita all'operatore 18, che è associato alla condizione di controllo 3. Il controllo termina trasferendo il controllo all'operatore 20, che esegue il commit della transazione, e il database entra in un nuovo stato stabile ed è impossibile modificarlo entro la transazione corrente. Oppure, se il controllo viene trasferito all'operatore 19, la transazione viene ripristinata all'inizio e il DB torna al suo stato iniziale e tutti gli stati intermedi sono già stati controllati qui ed è impossibile eseguire un'operazione di rollback a questi stati intermedi dopo l'esecuzione dell'istruzione 19

Ovviamente, il modello di transazione esteso di SYBASE supporta un meccanismo di esecuzione delle transazioni molto più flessibile.I punti di salvataggio consentono di impostare i marker all'interno di una transazione in modo che solo una parte del lavoro svolto in una transazione possa essere annullata.la capacità di annullare le modifiche per determinati operatori Tuttavia, questo impone costi aggiuntivi sulle risorse del sistema - l'operatore esegue il lavoro e le modifiche vengono quindi annullate, di solito i miglioramenti nella logica di elaborazione possono essere una soluzione migliore

1. Transazionie blocco

2. Concetto di transazione

Quando si lavora con i database, gli errori e gli errori non sono esclusi. Possono essere causati da errori degli utenti che interagiscono con il DBMS o dal funzionamento instabile dei computer. Pertanto, il DBMS utilizza metodi speciali per annullare le azioni che hanno causato tali errori. Un comando SQL che interessa il contenuto e la struttura di un database non è irreversibile. L'utente può determinare cosa accadrà dopo la fine delle sue azioni: se le modifiche apportate al database rimarranno o verranno ignorate. Per questo, la sequenza delle operazioni sul database è combinata in gruppi - transazioni.

Per transazioneè una sequenza di operazioni eseguite su un database e il suo trasferimento da uno stato coerente a un altro stato coerente.

Una transazione è considerata come un'azione inscindibile sul database, significativa dal punto di vista dell'utente, cioè è un'unità logica di lavoro del sistema. Una transazione inizia ogni volta che si verifica una sessione di database.

Un esempio di transazione potrebbe essere un trasferimento di denaro ATM. Importo 100 tr. viene trasferito dal conto corrente al conto della carta. Il programma sottrae l'importo dal conto corrente e poi lo aggiunge al conto della carta. Quando il programma è in esecuzione, dopo la prima modifica, si verifica un'interruzione di corrente e il conto della carta non aumenta. Per evitare questa situazione, entrambe le squadre devono essere combinate in una transazione. Nel caso in cui non vengano eseguiti tutti i comandi della transazione, viene eseguito il rollback della transazione.

Definiamo una transazione per l'inserimento dei dati sui libri appena ricevuti in biblioteca. Questa operazione può essere suddivisa in 2 sequenziali: in primo luogo, l'inserimento dei dati sul libro è una nuova riga nella tabella Libri... Quindi è necessario inserire i dati su tutte le copie del libro: questo è l'input di una serie di nuove righe nella tabella Istanze. Se questa sequenza di azioni viene interrotta, il database non corrisponderà all'oggetto reale, quindi è desiderabile eseguirlo come un singolo lavoro sul database.

3. Proprietà di transazione. Metodi di completamento delle transazioni

Esistono vari modelli di transazioni che possono essere classificati in base a varie proprietà, tra cui la struttura della transazione, la concorrenza all'interno di una transazione, la durata, ecc.

Attualmente si distinguono i seguenti tipi di transazioni: transazioni piatte o classiche, transazioni concatenate e transazioni nidificate.

Le transazioni piatte sono caratterizzate dalle proprietà classiche di atomicità, consistenza, isolamento e durata.

· La proprietà dell'atomicità si esprime nel fatto che una transazione deve essere eseguita nel suo insieme o per niente.

· La proprietà di consistenza garantisce che man mano che una transazione procede, i dati passano da uno stato coerente a un altro stato coerente: la transazione non interrompe la coerenza reciproca dei dati.

· La proprietà di isolamento significa che le transazioni in competizione per l'accesso al database vengono elaborate fisicamente in sequenza, in isolamento l'una dall'altra, ma agli utenti sembra che vengano eseguite in parallelo.

· La proprietà longevità significa che se una transazione viene completata con successo, le modifiche ai dati che ha apportato non possono essere perse in nessun caso, anche in caso di errori successivi.

Ci sono 2 opzioni per completare una transazione:

· se tutte le dichiarazioni hanno esito positivo e non si sono verificati errori hardware o software durante la transazione, la transazione viene confermata. (Un commit è una scrittura su disco delle modifiche apportate al database durante l'esecuzione di una transazione). Finché non viene eseguito il commit della transazione, è possibile eseguire il rollback di queste modifiche e riportare il database allo stato in cui si trovava all'inizio della transazione. Commettere una transazione significa che tutti i risultati della transazione sono resi costanti. Diventeranno visibili ad altre transazioni solo dopo che la transazione corrente è stata confermata.

· Se si verifica un errore durante l'esecuzione della transazione, il database deve essere riportato allo stato originale. Un rollback della transazione è l'azione che esegue il rollback di tutte le modifiche ai dati apportate dalle istruzioni SQL al corpo della transazione in sospeso corrente.

4. OperatoriTransazioneSQLlavorare con le transazioni

ANSI / ISO operatori definiti COMMETTERE e RITORNO, nello standard, l'inizio di una transazione è implicitamente specificato dal primo operatore di modifica dei dati; Operatore COMMETTERE indica il buon esito della transazione, i risultati della transazione sono registrati nella memoria esterna; quando l'operatore completa la transazione RITORNO i risultati della transazione vengono annullati. Il completamento con successo del programma in cui è stata avviata la transazione significa il completamento con successo della transazione (come se l'operatoreCOMMETTERE ), completamento non riuscito - interrompe la transazione (come se fosse utilizzato l'operatoreRITORNO ). In questo modello, ogni istruzione che modifica lo stato dei dati è considerata una transazione. Questo modello è stato implementato nelle prime versioni di DBMS commerciali. Successivamente, è stato implementato un modello di transazione esteso nel DBMS SYBASE.

Nel modello di transazione esteso (ad esempio, nel DBMS SQL SERVER), sono previste una serie di operazioni aggiuntive:

· operatore INIZIA TRANSAZIONE informa sull'inizio di una transazione;

· operatore IMPEGNA UNA TRANSAZIONE segnala il buon esito della transazione. Questo operatore, oltre a COMMIT nel modello standard ANSI/ISO, corregge tutte le modifiche che sono state apportate al database durante l'esecuzione di una transazione;

· operatore SALVA TRANSAZIONE crea un punto di salvataggio all'interno della transazione che corrisponde allo stato intermedio del database salvato al momento dell'esecuzione di questa istruzione. Nell'operatore SALVA TRANSAZIONE può essere presente un nome di punto di salvataggio, pertanto, durante l'esecuzione di una transazione, possono essere memorizzati più punti di salvataggio corrispondenti a più stati intermedi;

· operatore RITORNO ha 2 modifiche. Se viene utilizzato senza un parametro aggiuntivo, viene interpretato come un operatore per eseguire il rollback dell'intera transazione, se ha il parametro ROLLBACK n, quindi viene interpretato come un operatore per ripristinare parzialmente la transazione al punto di salvataggio n.

I punti di salvataggio sono utili in transazioni lunghe e complesse per fornire la possibilità di annullare le modifiche apportate da istruzioni specifiche.

Nella maggior parte dei casi, puoi impostare un parametro chiamato AUTOCOMMIT , che ricorderà automaticamente tutti i comandi eseguiti e le azioni che hanno portato all'errore verranno sempre automaticamente annullate. Di solito questa modalità viene impostata con un comando come:

SET AUTOCOMMIT SU ;

e tornando al normale dialogo di elaborazione delle richieste:

SET AUTOCOMMIT SPENTO ;

Inoltre, è possibile installare AUTOCOMMIT , che il DBMS eseguirà automaticamente al momento della registrazione.Se la sessione dell'utente è terminata in modo anomalo, ad esempio si è verificato un errore di sistema, la transazione corrente eseguirà automaticamente il rollback delle modifiche. Non è consigliabile organizzare il lavoro in modo tale che le singole transazioni contengano molti comandi, soprattutto non correlati tra loro. Ciò può portare al fatto che quando le modifiche vengono annullate, verranno eseguite troppe azioni, comprese quelle necessarie e che non hanno causato errori. L'opzione migliore è quando la transazione consiste in un comando o più comandi strettamente correlati.

Il trigger viene eseguito come transazione definita implicitamente, quindi i comandi di controllo della transazione sono consentiti all'interno del trigger. In particolare, se trovi una violazione dei vincoli di integrità, devi usare il comando TRANSAZIONE DI ROLLBACK ... Se il trigger viene completato correttamente, puoi utilizzare il comando COMMETTERE TRANSAZIONE .
Esecuzione di un comando TRANSAZIONE DI ROLLBACK o COMMETTERE TRANSAZIONE non interrompe il trigger, quindi dovresti monitorare attentamente i tentativi di eseguire il rollback di una transazione più volte quando vengono soddisfatte condizioni diverse.

Esempio di transazione:

INIZIA TRAN

AGGIORNA conto

SET equilibrio = equilibrio- 100

Se @@ errore = 0

INIZIO

TRASPORTO ROLLBACK

RESTITUZIONE

FINE

AGGIORNA conto_carta

SET saldo = saldo + 100

DOVE [e-mail protetta] _account

Se @@ errore = 0

INIZIO

TRASPORTO ROLLBACK

RESTITUZIONE

FINE

IMPEGNA IL TRASPORTO

Comando INIZIO TRAN informa il server dell'inizio di una transazione. Ciò significa che prima che il server riceva il comandoCOMMETTERE TRAN tutte le modifiche sono temporanee. Pertanto, se il server si arresta in modo anomalo dopo il primo aggiornamento, verrà eseguito il rollback della transazione. Nessun processo può accedere ai dati fino al completamento della transazione.

5. Registro delle transazioni.

L'implementazione del principio di conservazione degli stati intermedi, conferma o rollback di una transazione è fornita da un meccanismo speciale a supporto del quale è stata creata una struttura di sistema, chiamato log delle transazioni. Il registro delle transazioni contiene una sequenza di record di modifica del database. È progettato per fornire un'archiviazione affidabile dei dati nel database. Ciò implica la possibilità di ripristinare lo stato coerente del database dopo qualsiasi tipo di guasto hardware e software. Principi generali di registrazione e ripristino:

· i risultati delle transazioni impegnate devono essere salvati nello stato ripristinato del database;

· i risultati delle transazioni non impegnate non dovrebbero essere presenti nello stato ripristinato del database.

Ciò significa che viene ripristinato l'ultimo stato coerente del database.

Sono possibili le seguenti situazioni in cui è necessario ripristinare lo stato del database:

· Ripristino da un'improvvisa perdita del contenuto della RAM (soft glitch). Questa situazione può verificarsi nei seguenti casi: durante uno spegnimento di emergenza o quando si verifica un guasto irreversibile del processore. La situazione è caratterizzata dalla perdita di quella parte del database che si trovava nei buffer RAM al momento del guasto.

· Ripristino da un guasto dei principali supporti di database esterni (guasto hardware).

Il sistema dovrebbe essere in grado di riprendersi sia da interruzioni minori (ad esempio, transazioni non riuscite) sia da interruzioni maggiori (ad esempio, interruzioni di corrente, guasti hardware).

In caso di soft failure, è necessario ripristinare il contenuto del database dai contenuti dei log delle transazioni archiviati sui dischi. In caso di guasto hardware, è necessario ripristinare il contenuto del database dalle copie di archivio e dai registri delle transazioni, che sono archiviati su supporti esterni non danneggiati.

Esistono due opzioni principali per la gestione delle informazioni di registro. Nella prima opzione, viene mantenuto un registro delle modifiche del database locale separato per ogni transazione da questa transazione. Questi registri sono chiamati registri locali. Sono utilizzati per i rollback locali delle transazioni. Inoltre, viene mantenuto un registro delle modifiche del database generale, utilizzato per ripristinare il database dopo errori software e hardware.

Questo approccio consente di eseguire rapidamente rollback delle singole transazioni, ma genera informazioni duplicate nei registri locali e condivisi. Pertanto, la seconda opzione viene utilizzata più spesso, mantenendo solo un registro delle modifiche del database generale, che viene utilizzato anche durante l'esecuzione di rollback individuali.

La struttura generale del log può essere rappresentata sotto forma di file sequenziale, nel quale viene registrata ogni modifica al database che avviene durante l'esecuzione di una transazione. Tutte le transazioni hanno numeri interni, quindi tutte le modifiche apportate da tutte le transazioni vengono registrate nel registro delle transazioni.

Ogni voce di log è contrassegnata con il numero della transazione a cui appartiene e i valori degli attributi che essa modifica, inoltre, per ogni transazione, nel log viene registrato il comando per avviare e terminare la transazione.

Per una maggiore affidabilità, il log delle transazioni viene spesso duplicato dagli strumenti di sistema del DBMS, motivo per cui la quantità di memoria esterna è molte volte maggiore della quantità effettiva di dati nel database.

Sono disponibili 2 opzioni per la registrazione delle transazioni: protocollo di aggiornamento differito e protocollo di aggiornamento immediato.

La registrazione degli aggiornamenti pigri presuppone il seguente meccanismo di esecuzione delle transazioni:

1. Quando inizia la transazione T1, viene inserito un record nel protocollo

T1 Inizio Transazione

2. Durante l'esecuzione di una transazione, nel protocollo viene registrato un nuovo valore per ogni record modificato.

T1. ID _ DISCO , attributo, nuovo valore

(ID _ DISCO - numero di registrazione univoco)

3. Se tutte le azioni che compongono la transazione vengono completate con successo, la transazione viene registrata parzialmente e nel protocollo viene inserito quanto segue:

T 1 COMM

4. Dopo il commit della transazione, i record di protocollo relativi a T1 vengono utilizzati per apportare modifiche al database.

5. Se si verifica un errore, il DBMS esamina il registro e scopre quali transazioni devono essere rifatte. La transazione T1 deve essere rifatta se il protocollo contiene entrambi i record T1 Inizio Transazione e T 1 COMM . Il database potrebbe essere in uno stato incoerente, tuttavia, tutti i nuovi valori degli elementi di dati modificati sono contenuti nel registro e ciò richiede la riesecuzione della transazione. Per questo, viene utilizzata la procedura di sistema.RIFARE(), che sostituisce tutti i valori degli elementi con nuovi attraversando il registro in ordine in avanti.

6. Se il registro non contiene il comando per eseguire il commit della transazione INSIEME A OMMIT, non è richiesta alcuna azione e la transazione viene riavviata.

Un meccanismo alternativo con esecuzione immediata prevede di apportare modifiche direttamente al database, e non solo i nuovi, ma anche tutti i vecchi valori degli attributi modificati vengono inseriti nel protocollo, quindi ogni record si presenta così:

T1. ID _ DISCO , attributo, nuovo valore vecchio valore

In questo caso la scrittura nel log precede l'esecuzione diretta dell'operazione sul database. Quando viene eseguito il commit della transazione, ovvero viene rilevato il comando T1 IMPEGNO, e viene eseguito, tutte le modifiche sono già state apportate nel database e non sono necessarie ulteriori azioni rispetto a questa transazione.

Quando viene eseguito il rollback di una transazione, viene eseguita una procedura di sistema DISFARE (), che restituisce tutti i vecchi valori nella transazione annullata, passando in sequenza attraverso il protocollo, a partire dal comando INIZIA LA TRANSAZIONE.

Il seguente meccanismo viene utilizzato per il failover:

· Se una transazione contiene un comando per avviare una transazione, ma non contiene un comando di commit con conferma della sua esecuzione, la sequenza di azioni viene eseguita come quando viene eseguito il rollback della transazione, ovvero vengono ripristinati i vecchi valori.

Il recupero, infatti, avviene secondo algoritmi più complessi, poiché le modifiche, sia nel log che nel database, non vengono registrate immediatamente, ma vengono bufferizzate. La registrazione delle modifiche è strettamente correlata non solo alla gestione delle transazioni, ma anche al buffering delle pagine del database nella RAM. Se infatti un record relativo a una modifica al database, che dovrebbe andare nel log quando si esegue una qualsiasi operazione di modifica del database, venisse scritto immediatamente nella memoria esterna, ciò comporterebbe un notevole rallentamento del sistema. Pertanto, anche i record del log vengono bufferizzati: durante il normale funzionamento, la pagina successiva viene spinta nella memoria esterna del log solo quando è piena di record.

6. Serrature.

Nei sistemi multiutente, più utenti o applicazioni possono essere eseguiti contemporaneamente con lo stesso database. Uno dei compiti principali del DBMS è garantire l'isolamento degli utenti, ovvero la creazione di una tale modalità di funzionamento in modo che ciascuno degli utenti pensi di lavorare solo con il database. Tale attività DBMS viene solitamente chiamata parallelismo delle transazioni.

Ci sono tre problemi principali con l'elaborazione parallela del database:

§ Modifiche mancanti ... Questa situazione si verifica quando 2 transazioni modificano contemporaneamente lo stesso record nel database. Ad esempio, 2 operatori stanno lavorando per prendere ordini, il primo operatore ha preso un ordine per 30 monitor. Quando è andato al magazzino, c'erano 40 monitor e lui, dopo aver ricevuto conferma dal cliente, ha emesso la vendita di 30 monitor su 40. Parallelamente a lui lavora un secondo operatore, che accetta un ordine per 20 dei stesso monitor e, a sua volta, contattando il magazzino, ottiene lo stesso valore di 40 ed effettua un ordine per il suo cliente. Terminato il lavoro con i dati, esegue il comando Aggiornare, che aggiunge 20 come il resto dei monitor nel magazzino. Dopodiché, il primo operatore finisce di lavorare con il suo cliente ed esegue anche il comando ricaricare, che registra il resto di 10 come numero di monitor in stock. Hanno venduto un totale di 50 monitor su 40, con 10 monitor in stock.

§ Problemi di dati intermedi ... Collegato con la possibilità di accedere a dati intermedi. Supponiamo che il primo operatore, negoziando con il suo cliente, abbia inserito i 30 monitor ordinati, ma prima di finalizzare l'ordine, il cliente volesse scoprire alcune caratteristiche in più del prodotto. L'applicazione con cui sta lavorando il primo operatore ha già cambiato i monitor rimanenti nel magazzino e le informazioni sui 10 monitor rimanenti sono ora memorizzate lì. In questo momento, il secondo operatore sta cercando di prendere un ordine dal suo cliente per un ordine di 20 monitor, ma la sua applicazione mostra che sono rimasti solo 10 monitor nel magazzino e l'operatore è costretto a rifiutare il suo cliente. A questo punto, il cliente del primo operatore decide di non acquistare i monitor, l'operatore annulla la transazione e di nuovo ci sono 40 monitor nel magazzino. Questa situazione è diventata possibile perché l'applicazione del secondo operatore ha avuto accesso ai dati intermedi formati dalla prima applicazione.

§ Problemi di dati incoerenti. Associato alla possibilità di modificare i dati x, già letto x da un'altra applicazione. Entrambi gli operatori iniziano a lavorare quasi contemporaneamente, ricevono uno stato di magazzino iniziale di 40 monitor, quindi il primo operatore vende 30 monitor al suo cliente. Esce dalla sua applicazione ed esegue il comando di commit della transazione COMMIT. Lo stato del database è coerente. In questo momento il cliente del secondo operatore decide di effettuare un ordine e il secondo operatore, riaccedendo ai dati, vede che il numero di monitor è cambiato. Il secondo operatore ritiene che l'integrità della transazione sia violata, perché nel corso di un lavoro, ha ricevuto 2 diversi stati di magazzino. Questa situazione si è verificata perché l'applicazione del 1° operatore è stata in grado di modificare la tupla di dati, che era già stata letta dall'applicazione del 2° operatore.

Riassumendo i problemi elencati, si possono distinguere i seguenti tipi di conflitti tra due transazioni parallele:

· W-W - la transazione 2 tenta di modificare un oggetto modificato dalla transazione 1 che non è terminata;

· R-W - la transazione 2 tenta di modificare un oggetto letto dalla transazione 1 che non è terminata;

· La transazione W-R 2 tenta di leggere un oggetto modificato dalla transazione 1 non terminata;

7. Serializzazione delle transazioni

Al fine di evitare tali conflitti, è necessario sviluppare alcune procedure per l'esecuzione coerente delle operazioni concorrenti. Tale procedura deve rispettare le seguenti regole:

1. Durante l'esecuzione della transazione, l'utente vede solo i dati coerenti. L'utente non dovrebbe vedere dati intermedi incoerenti.

2. Quando in DB 2 le transazioni vengono eseguite in parallelo, i risultati dell'esecuzione delle transazioni dovrebbero essere gli stessi della transazione 1 e poi della transazione 2, o viceversa.

La procedura per l'implementazione di questi principi è denominata serializzazione delle transazioni. Garantisce che ogni utente, accedendo al database, lavori con esso come se non ci fossero altri utenti che accedono contemporaneamente agli stessi dati. Il risultato di un'esecuzione congiunta di un'operazione equivale al risultato di una certa esecuzione sequenziale delle stesse operazioni.

La via d'uscita più semplice sarebbe l'esecuzione sequenziale delle transazioni, ma tale uscita non è ottimale in termini di tempo, esistono metodi più flessibili per controllare l'accesso parallelo al database. Il meccanismo più comune per risolvere questi problemi consiste nel bloccare un oggetto (ad esempio una tabella) per l'intera durata di una transazione. Se una transazione accede a un oggetto bloccato, rimane in sospeso finché l'oggetto non viene sbloccato, dopodiché può iniziare a elaborarlo. Tuttavia, il blocco crea nuovi problemi: la latenza delle transazioni dovuta al blocco.

Quindi, i blocchi, chiamati anche acquisizioni di oggetti sincronizzati, possono essere applicati a diversi tipi di oggetti. L'oggetto di blocco più grande può essere l'intero database, ma questo tipo di blocco renderà il database inaccessibile a tutte le altre applicazioni che funzionano con questo database. Il prossimo tipo di oggetto di blocco sono le tabelle. La transazione che opera sulla tabella la blocca per l'intera durata della transazione. Questo tipo di blocco è preferibile al precedente perché consente transazioni simultanee che operano su altre tabelle.

Numerosi DBMS implementano il blocco a livello di pagina. In questo caso, il DBMS blocca solo le singole pagine su disco quando una transazione vi accede. Questo tipo di blocco è ancora più morbido e consente a transazioni diverse di operare sulla stessa tabella se accedono a pagine di dati diverse.

In alcuni DBMS è possibile il blocco a livello di riga, ma tale meccanismo di blocco richiede costi aggiuntivi per il suo supporto. SQL Server si sforza di impostare blocchi a livello di record per massimizzare la concorrenza. All'aumentare del numero di blocchi di riga, il server può passare al blocco della pagina se il numero di record supera la soglia.

8. Ignora i blocchi a livello di richiesta. Tipi di chiusura

Se dopo il nome della tabella nella frase A PARTIRE DAL segue una delle seguenti parole chiave, la richiesta interferisce con il gestore dei blocchi e viene applicato il tipo di blocco specificato:

· NOLOCK - consente la lettura sporca;

· PAGLOCK - blocco a livello di pagina;

· ROWLOCK - blocco a livello di record;

· TABLOCK - blocco della tabella condivisa;

· TABLOCKX - esclusivo lucchetto da tavolo

Attualmente, il problema del blocco è oggetto di un gran numero di studi.

Esistono due tipi fondamentali di serrature (manopole di sincronizzazione):

Blocchi condivisi (non rigidi): questa modalità indica l'acquisizione condivisa di un oggetto e viene utilizzata per eseguire un'operazione di lettura su un oggetto. Gli oggetti bloccati in questo modo non vengono modificati durante l'esecuzione di una transazione e sono disponibili per altre transazioni, ma solo in modalità lettura;

Lucchetti esclusivi (difficili): non consentire a nessuno, oltre al proprietario di questo lucchetto, di accedere ai dati. Questi blocchi vengono utilizzati per i comandi che modificano il contenuto o la struttura di una tabella e sono validi fino alla fine della transazione.

Le acquisizioni di oggetti da più transazioni lette sono compatibili, ovvero più transazioni possono leggere lo stesso oggetto. L'acquisizione di un oggetto tramite una transazione di lettura non è compatibile con un'altra acquisizione tramite un'altra transazione dello stesso oggetto tramite scrittura. Le acquisizioni dello stesso oggetto da transazioni di scrittura diverse non sono compatibili.

Tuttavia, l'uso di diversi tipi di blocchi porta al problema dei deadlock. Il problema del deadlock si poneva quando si considerava l'esecuzione di processi paralleli in ambienti operativi ed era legato anche alla gestione di oggetti condivisi (condivisi). Esempio di deadlock: supponiamo che la transazione A blocchi la tabella 1 e poi la tabella 2. La transazione B, invece, la tabella 2 e quindi la tabella 1.

Se entrambe queste transazioni hanno iniziato a funzionare contemporaneamente, dopo aver eseguito le operazioni di modifica sulla prima tabella, entrambe finiranno in un'attesa infinita: la transazione A attenderà il completamento della transazione B e sbloccherà la tabella 2 e la transazione B attenderà inutilmente il completamento della transazione A e lo sblocco della tabella 1.

Le situazioni possono essere molto più complesse. Il numero di transazioni reciprocamente bloccate può essere molto più alto. Ogni transazione non è in grado di rilevare questa situazione da sola. Deve essere risolto dal DBMS. La maggior parte dei DBMS commerciali dispone di un meccanismo per rilevare tali deadlock.

Il rilevamento del deadlock si basa sulla creazione (o sulla manutenzione) di un grafico in attesa di transazione. Il grafo di attesa può essere un grafo diretto, ai cui vertici si trovano i nomi delle transazioni. Se la transazione T1 è in attesa della fine della transazione T2, allora una freccia va dalla parte superiore di T1 alla parte superiore di T2. Inoltre, le frecce possono essere contrassegnate con i nomi degli oggetti bloccati e il tipo di blocco.

Il meccanismo di blocco utilizza il concetto di livello di isolamento dei blocchi per determinare quante tabelle verranno bloccate. Tradizionalmente vengono utilizzati tre livelli di isolamento:

· Il livello di isolamento, chiamato reread, implementa una strategia in modo che all'interno di una determinata transazione, tutti i record recuperati dalle query non possano essere modificati. Questi record non possono essere modificati fino al completamento della transazione.

· Il livello di isolamento, denominato puntatore di stabilità, impedisce la modifica di ogni record durante la lettura o la lettura durante la modifica.

· Il terzo livello di stabilità è chiamato di sola lettura. La sola lettura blocca l'intera tabella e pertanto non può essere utilizzata con i comandi di aggiornamento. Pertanto, la sola lettura garantisce che l'output della query sia internamente coerente con i dati della tabella.

Quindi, lo strumento di controllo della concorrenza nel DBMS determina fino a che punto i comandi emessi simultaneamente interferiranno l'uno con l'altro. Nei moderni DBMS, è uno strumento adattabile che trova automaticamente la soluzione ottimale, tenendo conto della fornitura delle massime prestazioni del database e della disponibilità dei dati per i team operativi.

9. DOMANDE DI CONTROLLO

1. Definire una transazione. Fornisci esempi di transazioni.

2. Elencare e caratterizzare le proprietà delle transazioni.

3. Quali sono le possibili opzioni per completare le transazioni.

4. Quali sono gli operatori della lingua SQL servono a lavorare con le transazioni nel modello di transazione esteso?

5. Posso utilizzare i comandi di controllo delle transazioni nei trigger?

6. A cosa serve il registro delle transazioni?

7. In quali casi viene eseguito il ripristino del database dal registro delle transazioni?

8. Quali opzioni ci sono per la registrazione delle transazioni?

9. Quali sono le differenze tra le opzioni di registrazione delle transazioni: il protocollo di aggiornamento differito e il protocollo di aggiornamento immediato.

10. Quali problemi sorgono quando gli utenti lavorano in parallelo con il database?

11. Quali oggetti di database possono essere bloccati per implementare il principio dell'isolamento dell'utente?

12. È possibile impostare il tipo di blocco nelle query?

13. Quali tipi di acquisizione di oggetti tramite più transazioni esistono? Quali sono compatibili?

14. Qual è il problema dei vicoli ciechi?

Esistono vari modelli di transazioni che possono essere classificati in base a varie proprietà, tra cui la struttura della transazione, la concorrenza all'interno della transazione, la durata, ecc.

Attualmente si distinguono i seguenti tipi di transazioni: transazioni piatte o classiche, transazioni concatenate e transazioni nidificate.

· Proprietà atomicità(Atomicità) si esprime nel fatto che l'operazione dovrebbe essere completata nel suo insieme o per niente.

· Proprietà di consistenza(Coerenza) garantisce che man mano che le transazioni procedono, i dati passano da uno stato coerente a un altro - la transazione non interrompe la coerenza reciproca dei dati.

· Proprietà di isolamento(Isolamento) significa che le transazioni concorrenti per l'accesso al database vengono elaborate fisicamente in sequenza, in isolamento l'una dall'altra, ma agli utenti sembra che vengano eseguite in parallelo.

· Proprietà di durata(Durabilità) è interpretata come segue: se la transazione è andata a buon fine, le modifiche ai dati da essa apportate non possono in nessun caso essere perse (anche in caso di errori successivi).

Il commit di una transazione è l'atto di scrivere su disco le modifiche nel database che sono state apportate durante l'esecuzione di una transazione.

1. la dichiarazione COMMIT indica il buon esito dell'operazione; il suo utilizzo apporta modifiche permanenti al database all'interno della transazione in corso;

2. l'istruzione ROLLBACK interrompe la transazione, annullando le modifiche apportate al database nell'ambito di tale transazione; una nuova transazione inizia immediatamente dopo aver utilizzato ROLLBACK;

3. l'esito positivo del programma in cui è stata avviata l'operazione in corso significa l'esito positivo dell'operazione (come se si utilizzasse l'istruzione COMMIT);

4. La chiusura errata del programma interrompe la transazione (come se fosse stata utilizzata l'istruzione ROLLBACK).

· L'istruzione BEGIN TRANSACTION indica l'inizio di una transazione. A differenza del modello ANSI/ISO, in cui l'inizio di una transazione è implicitamente specificato dalla prima istruzione di modifica dei dati, nel modello SYBASE, l'inizio di una transazione è specificato esplicitamente utilizzando l'istruzione di inizio transazione.

· L'estratto conto COMMIT TRANSACTION riporta il buon esito della transazione. È equivalente all'istruzione COMMIT nel modello standard ANSI/ISO. Questo operatore, come l'operatore COMMIT, esegue il commit di tutte le modifiche apportate al database durante l'esecuzione di una transazione.

· L'istruzione SAVE TRANSACTION crea un punto di salvataggio all'interno della transazione che corrisponde allo stato intermedio del database salvato al momento dell'esecuzione di questa istruzione. L'istruzione SAVE TRANSACTION può contenere il nome di un punto di salvataggio. Pertanto, durante l'esecuzione di una transazione, possono essere memorizzati più punti di salvataggio, corrispondenti a più stati intermedi.

· L'operatore ROLLBACK ha due modifiche. Se questa istruzione viene utilizzata senza un parametro aggiuntivo, viene interpretata come un'istruzione di rollback per l'intera transazione, ovvero in questo caso è equivalente all'istruzione ROLLBACK nel modello ANSI/ISO. Se l'istruzione di rollback ha un parametro ed è scritta come ROLLBACK B, allora viene interpretata come un'istruzione di rollback della transazione parziale al punto di salvataggio B.

Riso. 11.1.Modello di transazione ANSI/ISO

Riso. 11.2.Esempi di esecuzione di transazioni nel modello esteso

La transazione inizia con un operatore esplicito dell'inizio della transazione, che nel nostro schema ha il numero 1. Segue l'operatore 2, che è un operatore di ricerca e non cambia lo stato corrente del database, e i seguenti operatori 3 e 4 trasferire il database in un nuovo stato. L'istruzione 5 salva questo nuovo stato intermedio del database e lo contrassegna come stato intermedio nel punto A. Quindi seguono le istruzioni 6 e 7, che trasferiscono il database in un nuovo stato. E l'operatore 8 salva questo stato come stato intermedio nel punto B. L'operatore 9 esegue un nuovo inserimento dati e l'operatore 10 esegue un controllo della condizione 1; se la condizione 1 è soddisfatta, viene eseguita l'istruzione 11, che riporta la transazione allo stato intermedio B. Ciò significa che le conseguenze delle azioni dell'istruzione 9 vengono, per così dire, cancellate e il database torna nuovamente allo stato intermedio B, sebbene dopo l'esecuzione dell'istruzione 9 fosse già in una nuova condizione. E dopo il rollback della transazione, invece dell'istruzione 9, che è stata eseguita in precedenza dallo stato Nel database, viene eseguita l'istruzione 13 di immissione di nuovi dati, quindi il controllo viene trasferito all'istruzione 14. L'istruzione 14 controlla nuovamente la condizione, ma già alcuni nuova condizione 2; se la condizione è soddisfatta, il controllo passa all'operatore 15, che riporta la transazione allo stato intermedio A, ovvero tutti gli operatori che hanno modificato il database, partendo da 6 e terminando con 13, sono considerati non soddisfatti, ovvero , i risultati della loro esecuzione sono scomparsi e siamo di nuovo nello stato E, come dopo l'esecuzione dell'operatore 4. Successivamente, il controllo viene trasferito all'operatore 17, che aggiorna il contenuto del database, dopodiché il controllo viene trasferito all'operatore 18, che è associato alla condizione di verifica 3. La verifica termina o trasferendo il controllo all'operatore 20, che impegna la transazione, e il database passa a uno nuovo stato stazionario, ed è impossibile modificarlo all'interno della transazione corrente. Oppure, se il controllo viene trasferito all'operatore 19, viene eseguito il rollback della transazione all'inizio e il database torna al suo stato iniziale e tutti gli stati intermedi sono già stati controllati qui ed è impossibile eseguire un'operazione di rollback a questi intermedi stati dopo l'esecuzione dell'operatore 19.

Naturalmente, il modello di transazione esteso di SYBASE supporta un meccanismo di esecuzione delle transazioni molto più flessibile. I punti di salvataggio consentono di impostare indicatori all'interno di una transazione in modo che solo una parte del lavoro svolto nella transazione possa essere annullata. È consigliabile utilizzare i punti di salvataggio in transazioni lunghe e complesse per fornire funzionalità di annullamento per istruzioni specifiche. Tuttavia, ciò comporta costi aggiuntivi delle risorse di sistema: l'operatore esegue il lavoro e le modifiche vengono quindi annullate; di solito, i miglioramenti nella logica di elaborazione possono essere una soluzione migliore.

Registro delle transazioni

L'implementazione nel DBMS del principio di preservare gli stati intermedi, confermare o ripristinare una transazione è fornita da un meccanismo speciale, per il cui supporto viene creata una determinata struttura di sistema, chiamata Registro delle transazioni.

Tuttavia, lo scopo del registro delle transazioni è molto più ampio. È progettato per fornire un'archiviazione affidabile dei dati nel database.

E questo requisito implica, in particolare, la capacità di ripristinare lo stato coerente del database dopo qualsiasi tipo di guasto hardware e software. Ovviamente sono necessarie alcune informazioni aggiuntive per eseguire i restauri. Nella stragrande maggioranza dei moderni DBMS relazionali, tali informazioni aggiuntive ridondanti vengono mantenute sotto forma di un registro delle modifiche del database, il più delle volte chiamato Registro delle transazioni.

Pertanto, l'obiettivo generale della registrazione delle modifiche al database è garantire che il database possa essere ripristinato a uno stato coerente dopo qualsiasi errore. Poiché la base per mantenere l'integrità di un database è il meccanismo di transazione, la registrazione e il ripristino sono strettamente correlati al concetto di transazione. I principi generali del recupero sono i seguenti:

· I risultati delle transazioni impegnate devono essere salvati nello stato ripristinato del database;

· I risultati delle transazioni non impegnate non devono essere presenti nello stato ripristinato del database.

Questo, infatti, significa che è in corso il ripristino dello stato coerente più recente del database.

Sono possibili le seguenti situazioni in cui è necessario ripristinare lo stato del database.

· Rollback individuale della transazione. Questo rollback dovrebbe essere applicato nei seguenti casi:

o la situazione standard per un rollback di una transazione è il suo completamento esplicito con un'istruzione ROLLBACK;

o chiusura anomala del programma applicativo, che è logicamente equivalente all'esecuzione dell'istruzione ROLLBACK, ma ha fisicamente un meccanismo di esecuzione diverso;

o rollback forzato di una transazione in caso di deadlock nell'esecuzione parallela delle transazioni. In tal caso, per sbloccare lo stallo, questa transazione può essere selezionata come "vittima" e la sua esecuzione da parte del kernel DBMS può essere interrotta forzatamente.

· Recupero dopo un'improvvisa perdita del contenuto della RAM (soft failure). Questa situazione può verificarsi nei seguenti casi:

o in caso di arresto di emergenza dell'alimentazione;

o in caso di guasto irreversibile del processore (ad esempio, operazione di controllo RAM), ecc. La situazione è caratterizzata dalla perdita di quella parte del database che era contenuta nei buffer RAM al momento del guasto.

· Recupero da un guasto dei principali supporti esterni del database (hard failure). Questa situazione, data un'affidabilità sufficientemente elevata dei moderni dispositivi di memoria esterni, può verificarsi relativamente raramente, ma nonostante ciò il DBMS dovrebbe essere in grado di ripristinare il database anche in questo caso. La base del ripristino è la copia di archivio e il registro delle modifiche del database.

Per ripristinare uno stato coerente del database quando si esegue il rollback di una transazione singolarmente, è necessario eliminare gli effetti delle istruzioni di modifica del database eseguite in tale transazione. Per ripristinare uno stato coerente del database in caso di soft failure, è necessario ripristinare il contenuto del database dai contenuti dei log delle transazioni archiviati sui dischi. Per ripristinare uno stato coerente del database in caso di guasto hardware, è necessario ripristinare il contenuto del database dalle copie di archivio e dai registri delle transazioni archiviati su supporti esterni non danneggiati.

In tutti e tre i casi, l'archiviazione ridondante dei dati è la base del ripristino. Questi dati ridondanti vengono archiviati in un registro contenente una sequenza di record di modifica del database.

Esistono due opzioni principali per la gestione delle informazioni di registro. Nella prima opzione, viene mantenuto un registro delle modifiche del database locale separato per ogni transazione da quella transazione. Questi registri sono chiamati registri locali. Sono utilizzati per i rollback individuali delle transazioni e possono essere mantenuti nella memoria RAM (più correttamente, virtuale). Inoltre, viene mantenuto un registro generale delle modifiche del database, utilizzato per ripristinare lo stato del database dopo errori software e hardware.

Questo approccio consente di eseguire rapidamente rollback delle singole transazioni, ma genera informazioni duplicate nei registri locali e condivisi. Pertanto, la seconda opzione viene utilizzata più spesso, mantenendo solo un registro generale delle modifiche al database, che viene utilizzato anche durante l'esecuzione di rollback individuali. Successivamente, consideriamo questa particolare opzione.

La struttura generale del log può essere condizionatamente rappresentata sotto forma di file sequenziale, che registra ogni modifica al database che avviene durante l'esecuzione di una transazione. Tutte le transazioni hanno i propri numeri interni, quindi tutte le modifiche apportate da tutte le transazioni vengono registrate in un unico registro delle transazioni.

Ogni voce nel registro delle transazioni è contrassegnata dal numero della transazione a cui appartiene e dai valori degli attributi che cambia. Inoltre, per ogni transazione, nel log viene registrato il comando per avviare e terminare la transazione (vedi Figura 11.3).

Per una maggiore affidabilità, il log delle transazioni viene spesso duplicato dagli strumenti di sistema dei DBMS commerciali, motivo per cui la quantità di memoria esterna è molte volte maggiore della quantità effettiva di dati archiviati nello storage.

Esistono due alternative per la registrazione delle transazioni: protocollo di aggiornamento differito e protocollo di aggiornamento immediato.

La registrazione delle modifiche in sospeso presuppone il seguente meccanismo per l'esecuzione delle transazioni:

1. Quando inizia la transazione T1, viene inserito un record nel protocollo

<Т1 Begin transaction>

2. Durante l'esecuzione della transazione, nel protocollo viene scritto un nuovo valore per ogni record modificato: ... Qui ID_RECORD è un numero di record univoco.

3. Se tutte le azioni che compongono la transazione T1 sono state completate con successo, la transazione viene parzialmente registrata e inserita nel protocollo.<Т1 СОММIТ>.

4. Dopo il commit della transazione, i record di protocollo relativi a T1 vengono utilizzati per apportare le modifiche appropriate al database.

5. Se si verifica un errore, il DBMS esamina il registro e scopre quali transazioni devono essere rifatte. La transazione T1 deve essere rifatta se il protocollo contiene entrambi i record<Т1 BEGIN TRANSACTION и <Т1 СОММIТ>... Il database potrebbe essere in uno stato incoerente, tuttavia, tutti i nuovi valori degli elementi di dati modificati sono contenuti nel registro e ciò richiede la riesecuzione della transazione. Per questo viene utilizzata una procedura di sistema REDOQ, che sostituisce tutti i valori dei dati con dei nuovi, guardando il protocollo in ordine diretto.

6. Se il protocollo non contiene il comando di commit della transazione COMMIT, non è richiesta alcuna azione e la transazione viene riavviata.

Riso. 11.3.Registro delle transazioni

Un meccanismo alternativo con esecuzione immediata prevede di apportare modifiche immediate al database, e non solo i nuovi, ma anche tutti i vecchi valori degli attributi modificati vengono inseriti nel protocollo, quindi ogni record si presenta come<Т1, ID_RECORD, атрибут новое значение старое значение...>... In questo caso la scrittura nel log precede l'esecuzione diretta dell'operazione sul database. Quando viene eseguito il commit della transazione, ovvero viene rilevato il comando<Т1 СОММIТ>e viene eseguito, tutte le modifiche sono già state apportate nel database e non sono necessarie ulteriori azioni rispetto a questa transazione.

Quando si esegue il rollback di una transazione, viene eseguita la procedura di sistema UNDO(), che restituisce tutti i vecchi valori nella transazione annullata, procedendo in sequenza attraverso il protocollo a partire dal comando BEGIN TRANSACTION.

Il seguente meccanismo viene utilizzato per il failover:

· Se l'errore si è verificato dopo l'esecuzione dell'ultimo comando di modifica del database, ma prima dell'esecuzione del comando di commit, viene eseguito il comando di commit e non vengono apportate modifiche al database. Il lavoro si svolge solo a livello di protocollo.

· Tuttavia, va notato che i problemi di ripristino sembrano molto più complicati degli algoritmi forniti in precedenza, dato che le modifiche sia al registro che al database non vengono registrate immediatamente, ma memorizzate nel buffer. La sezione successiva è dedicata a questo.

Registrazione e buffering

La registrazione delle modifiche è strettamente correlata non solo alla gestione delle transazioni, ma anche al buffering delle pagine del database in memoria.

Se un record di modifica del database, che dovrebbe andare al registro per qualsiasi operazione di modifica del database, fosse effettivamente scritto immediatamente nella memoria esterna, questo rallenterà notevolmente il sistema. Pertanto, anche i record del log vengono bufferizzati: durante il normale funzionamento, la pagina successiva viene spinta nella memoria esterna del log solo quando è piena di record.

La sfida consiste nel progettare una policy push generale per garantire che il database possa essere ripristinato da un arresto anomalo.

Il problema non si pone con i rollback individuali delle transazioni, poiché in questi casi i contenuti della memoria principale non vengono persi e possono essere utilizzati sia i contenuti del buffer di log che i buffer di pagina del database. Tuttavia, se si verifica un errore software e il contenuto dei buffer viene perso, è necessario disporre di uno stato coerente del registro e del database nella memoria esterna per ripristinare il database.

Il principio di base di una politica coerente per l'estrazione del buffer di registro e dei buffer di pagina del database è che una modifica a un oggetto del database deve essere scritta nella memoria del registro esterno prima che l'oggetto modificato si trovi nella memoria del database esterno. Il corrispondente protocollo di logging (e gestione del buffering) si chiama Write Ahead Log (WAL) - "write first to the log" e consiste nel fatto che se si vuole scrivere un oggetto del database modificato su una memoria esterna, bisogna prima assicurarsi che il il registro delle transazioni viene scritto nei record di memoria esterna della sua modifica.

In altre parole, se nella memoria esterna del database c'è qualche oggetto database, in relazione al quale è stata eseguita l'operazione di modifica, allora nella memoria esterna del log c'è necessariamente un record corrispondente a questa operazione. Non è vero il contrario, ovvero se la memoria esterna del registro contiene un record su alcune operazioni di modifica di un oggetto del database, l'oggetto modificato stesso potrebbe non essere presente nella memoria esterna del database.

Un'ulteriore condizione per il push dei buffer è imposta dal requisito che ogni transazione completata con successo deve essere effettivamente impegnata nella memoria esterna. Qualunque sia l'errore, il sistema deve essere in grado di ripristinare lo stato del database contenente i risultati di tutte le transazioni commesse al momento dell'errore.

Una soluzione semplice sarebbe un pop del buffer di log seguito da un pop di massa dei buffer della pagina del database modificati dalla transazione. Questo viene fatto abbastanza spesso, ma introduce un sovraccarico significativo durante l'esecuzione di un'operazione di commit.

Risulta che il requisito minimo per garantire che l'ultimo stato coerente del database possa essere ripristinato è che quando una transazione viene confermata, tutti i record di modifica del database da questa transazione vengono inseriti nella memoria esterna del registro. In questo caso, l'ultimo record nel registro effettuato per conto di questa transazione è un record speciale relativo alla fine della transazione.

Ora diamo un'occhiata a come è possibile eseguire operazioni di ripristino del database in varie situazioni se il sistema mantiene un registro comune memorizzato nel buffer per tutte le transazioni e viene mantenuto in conformità con il protocollo WAL.

Rollback individuale di una transazione

Per poter eseguire un rollback di una singola transazione sul registro generale, tutti i record di registro per questa transazione sono collegati in un elenco inverso. La parte superiore dell'elenco delle transazioni non riuscite è l'ultima modifica al database apportata da questa transazione. Per le transazioni completate (di cui i singoli rollback non sono più possibili), l'inizio della lista è la registrazione della fine della transazione, che viene necessariamente spinta nella memoria esterna del log. La fine della lista è sempre la prima record della modifica del database effettuata da questa transazione. In genere, a ogni record viene assegnato un ID transazione univoco in modo che un elenco diretto di record di modifica del database possa essere ripristinato da una determinata transazione.

Quindi, un rollback di una singola transazione (sottolineiamo ancora una volta che ciò è possibile solo per le transazioni non impegnate) viene eseguito come segue:

· Il record successivo viene selezionato dall'elenco di questa transazione.

· Viene eseguita l'operazione opposta: al posto di un'operazione INSERT, viene eseguita un'operazione DELETE corrispondente, viene eseguita un'operazione INSERT invece di un'operazione DELETE, e invece di un'operazione UPDATE diretta, un'operazione UPDATE inversa ripristina lo stato precedente del database oggetto.

· Viene registrata anche una qualsiasi di queste operazioni inverse. In realtà, ciò non è necessario per un singolo rollback, ma quando si esegue un singolo rollback di una transazione, potrebbe verificarsi un soft failure, al momento del ripristino dal quale sarà necessario eseguire il rollback di una transazione per la quale il singolo rollback non viene eseguito completamente.

· Se il rollback viene completato correttamente, nel registro viene scritto un record della fine della transazione. Dal punto di vista del registro, tale transazione è impegnata.

Recupero da un errore soft

Uno dei problemi principali con il ripristino da un errore software è che una singola operazione di modifica del database logico può modificare più blocchi di database fisici, come una pagina di dati e più pagine di indice. Le pagine del database vengono memorizzate nel buffer nella RAM e visualizzate in modo indipendente. Nonostante l'uso del protocollo WAL, dopo un errore software, l'insieme di pagine nella memoria esterna del database potrebbe risultare incoerente, ovvero alcune pagine di memoria esterna corrispondono all'oggetto prima della modifica e alcune - dopo il cambio. Le operazioni del livello logico non sono applicabili a questo stato dell'oggetto.

Lo stato della memoria esterna di un database è detto fisicamente consistente se gli insiemi di pagine di tutti gli oggetti sono consistenti, cioè corrispondono allo stato dell'oggetto prima o dopo che è stato modificato.

Assumeremo che il registro segni i punti di consistenza fisica del database - i momenti in cui la memoria esterna contiene i risultati coerenti delle operazioni che sono state completate prima del momento corrispondente, e non ci sono risultati delle operazioni che hanno non completato e il buffer di registro viene inserito nella memoria esterna. Vedremo come ottenere la consistenza fisica un po' più tardi. Chiamiamo tali punti tpc (tempo di consistenza fisica) - punti di accordo fisico.

Quindi, al momento di un soft failure, sono possibili i seguenti stati di transazione:

· La transazione è stata completata con successo, ovvero è stata confermata l'operazione della transazione COMMIT e per tutte le operazioni della transazione è stata ricevuta una conferma della sua esecuzione nella memoria esterna;

· La transazione è andata a buon fine, ma per alcune operazioni non è stata ricevuta la conferma della loro esecuzione nella memoria esterna;

· La transazione ha ricevuto ed eseguito il comando ROLLBACK;

· La transazione non è stata completata.

Consistenza fisica del database

Come si può garantire che ci siano punti di consistenza fisica nel database, ovvero come ripristinare lo stato del database al momento del tpc? Esistono due approcci principali utilizzati per eseguire questa operazione: un approccio basato su shadow e un approccio che utilizza la registrazione delle modifiche al database pagina per pagina.

All'apertura di un file, viene letta in RAM la tabella per la mappatura dei numeri dei suoi blocchi logici agli indirizzi dei blocchi fisici della memoria esterna. Quando un blocco di un file viene modificato, viene allocato un nuovo blocco nella memoria esterna. In questo caso, la tabella di mappatura corrente (in RAM) viene modificata e la tabella ombra rimane invariata. Se si verifica un errore mentre si lavora con un file aperto, lo stato del file prima dell'apertura viene automaticamente salvato nella memoria esterna. Per ripristinare esplicitamente il file è sufficiente rileggere in RAM la tabella di shadow mapping.

L'idea generale del meccanismo ombra è mostrata in Fig. 11.4.

Riso. 11.4.Utilizzo delle tabelle di visualizzazione delle ombre

Nel contesto di un database, il meccanismo ombra viene utilizzato come segue. I checkpoint vengono eseguiti periodicamente. Per fare ciò, vengono completate tutte le operazioni logiche, vengono espulsi tutti i buffer della memoria principale, il cui contenuto non corrisponde al contenuto delle pagine corrispondenti della memoria esterna. La tabella ombra per la mappatura dei file del database viene sostituita con quella corrente (più correttamente, la tabella di mappatura corrente viene scritta al posto di quella ombra).

Il ripristino su tpc è istantaneo: l'attuale tabella di mappatura viene sostituita con una shadow (durante il ripristino, viene semplicemente letta la tabella di mappatura shadow). Tutti i problemi di ripristino vengono risolti, ma a scapito di un uso eccessivo della memoria esterna. Al limite, potresti aver bisogno del doppio della memoria esterna di quella effettivamente necessaria per archiviare il database. Il meccanismo dell'ombra è uno strumento affidabile ma troppo rozzo. Viene fornito uno stato coerente di memoria esterna in un momento comune a tutti gli oggetti. Infatti è sufficiente disporre di un insieme di insiemi consistenti di pagine, ognuna delle quali può corrispondere ai propri campioni temporali.

Per soddisfare un requisito così debole, insieme alla registrazione logica delle operazioni di modifica del database, vengono registrate le modifiche pagina per pagina. Il primo passaggio per il ripristino da un errore software consiste nel ripristinare le operazioni logiche non riuscite una pagina alla volta. Come avviene con i record logici rispetto alle transazioni, l'ultimo record di modifica impaginato da una singola operazione logica è la fine dell'operazione.

Ci sono due metodi per risolvere il problema in questo approccio. Il primo metodo mantiene un registro comune delle operazioni logiche e di paginazione. Naturalmente, la presenza di due tipi di record, interpretati in modi completamente diversi, complica la struttura del giornale. Inoltre, le registrazioni dei cambiamenti pagina per pagina, la cui rilevanza è di natura locale, aumentano in modo significativo (e non molto significativo) il giornale.

Pertanto, sta diventando sempre più popolare mantenere un (breve) diario separato delle modifiche alle pagine. Questa tecnica viene utilizzata, ad esempio, nel noto prodotto Informix Online.

Supponiamo che in qualche modo sia stato possibile ripristinare la memoria esterna del database allo stato al momento tpc (come si può fare - un po' più tardi). Quindi:

· Non è richiesta alcuna azione per la transazione T1. È terminato prima di tpc e tutti i suoi risultati si riflettono nella memoria esterna del database.

· Per la transazione T2, è necessario rieseguire il resto delle operazioni (redo). Infatti, nella memoria esterna non ci sono assolutamente tracce di operazioni che sono state eseguite nella transazione T2 dopo il momento tpc. Pertanto, la reinterpretazione diretta delle operazioni T2 è corretta e porterà a uno stato logicamente coerente del database (poiché la transazione T2 è stata completata con successo prima del soft failure, il registro contiene un record di tutte le modifiche apportate da questa transazione).

· Per una transazione TK, la prima parte delle operazioni (undo) deve essere eseguita nella direzione opposta. Infatti, nella memoria esterna del database, i risultati delle operazioni TK che sono state eseguite dopo il momento tpc sono completamente assenti. D'altra parte, è garantito che la memoria esterna contenga i risultati delle operazioni TK eseguite prima di tpc. Di conseguenza, l'interpretazione inversa delle operazioni TK è corretta e porterà a uno stato coerente del database (poiché la transazione TK non è stata completata al momento di un soft failure, durante il ripristino è necessario preservare tutte le conseguenze della sua esecuzione ).

· Per una transazione T4 iniziata dopo tpc e terminata prima di un errore software, dovrebbe essere eseguita una ripetizione completa.

Infine, non è richiesta alcuna azione per una transazione T5 iniziata dopo il momento tpc e che non ha avuto il tempo di completarsi al momento del soft failure. I risultati di questa transazione mancano completamente dalla memoria esterna del database.

Recupero da un incidente violento

È chiaro che il registro delle modifiche del database non è sufficiente per ripristinare il database all'ultimo stato coerente dopo un errore hardware. In questo caso, la base del ripristino è il log e la copia di backup del database.

Il ripristino inizia ricopiando il database dalla copia di archivio. Quindi viene eseguita una ripetizione per tutte le transazioni completate, ovvero le operazioni vengono rieseguite nell'ordine in avanti.

Più precisamente, accade quanto segue:

· Tutte le operazioni vengono eseguite lungo il tronco in direzione avanti;

· Per le transazioni che non sono state completate al momento dell'errore, viene eseguito un rollback.

Infatti, poiché un hard failure non comporta una perdita di buffer RAM, è possibile ripristinare il database a un livello tale che anche le transazioni fallite possano continuare. Ma questo di solito non viene fatto perché il ripristino da un arresto anomalo è un processo piuttosto lungo.

Sebbene ci siano requisiti speciali per la registrazione in termini di affidabilità, in linea di principio può essere perso. Quindi l'unico modo per ripristinare il database è tornare alla copia di archivio. Ovviamente, in questo caso, non sarai in grado di ottenere l'ultimo stato coerente del database, ma questo è meglio di niente.

L'ultimo problema che esamineremo brevemente riguarda l'esecuzione di backup di un database. Il modo più semplice è archiviare il database quando il registro è pieno. Nel log viene introdotta la cosiddetta “zona gialla”, al raggiungimento della quale viene temporaneamente bloccata la formazione di nuove transazioni. Quando tutte le transazioni sono state completate e, quindi, il database è in uno stato coerente, è possibile archiviarlo e quindi ricominciare a riempire il registro.

È possibile eseguire il backup del database meno frequentemente di quanto il registro si riempia. Se il registro è pieno e tutte le transazioni avviate sono terminate, è possibile archiviare il registro stesso. Poiché un tale registro archiviato è essenzialmente necessario solo per ricreare una copia archiviata del database, le informazioni del registro archiviato possono essere notevolmente compresse.

Ogni volta che utilizza una carta bancaria per pagare merci, prelevare fondi o effettuare trasferimenti, il cliente della banca effettua determinate transazioni. E sebbene tutte le transazioni richiedano solo pochi minuti, l'intero ciclo di operazioni è un processo piuttosto ampio, che include l'invio di richieste di prelievo di denaro, l'elaborazione e l'esecuzione.

Una transazione è qualsiasi operazione con una carta bancaria, la cui esecuzione porta a un cambiamento nello stato del conto del cliente. La transazione può essere effettuata in tempo reale (online) e offline.

Le transazioni online richiedono la conferma obbligatoria del pagamento al momento dell'effettuazione di un pagamento o del trasferimento di fondi.

Le transazioni online includono trasferimenti di denaro tra carte, operazioni di prelievo di contanti presso sportelli automatici, operazioni di regolamento in punti vendita e negozi. Considera il processo di esecuzione di una transazione online utilizzando l'esempio del pagamento di un articolo in un centro commerciale.

Le parti coinvolte nell'operazione sono tre:

la banca acquirente che serve il punto vendita selezionato (è il suo terminale POS che è installato nel negozio);
la banca emittente che serve la carta di pagamento;
sistema di pagamento internazionale, che costituisce un anello intermedio nelle operazioni di regolamento (Visa, MasterCard, ecc.).

Ordine di transazione online

Una transazione di regolamento inizia dal momento in cui la carta di pagamento viene consegnata alla cassa e il terminale POS legge i dati necessari per il pagamento (numero carta, periodo di validità, cognome del titolare e altre informazioni criptate su nastro magnetico). Le informazioni lette vengono trasferite alla banca acquirente che serve il terminale POS (di norma, i negozi concludono accordi speciali per il servizio dei terminali, in base ai quali vengono addebitate commissioni per ogni transazione).

I dati ricevuti vengono trasmessi dalla banca acquirente al centro di elaborazione dati (DPC) del sistema di pagamento internazionale che serve la carta.

Il data center verifica la presenza o meno di una carta di pagamento nella lista degli stop (le carte sospettate di frode possono comparire nella lista degli stop), a seguito della quale l'operazione viene approvata o rifiutata.

Successivamente, le informazioni vengono trasferite al centro di elaborazione della banca emittente, dove viene approvato il pagamento. Qui viene verificata la legalità della transazione: controlla se ci sono fondi sufficienti per completare la transazione e controlla se il codice PIN inserito corrisponde al valore reale. Inoltre, viene effettuato un controllo per il superamento del limite stabilito per l'esecuzione delle operazioni.

La risposta della banca emittente viene rinviata, attraverso il data center, alla banca acquirente e al punto vendita. I dettagli del pagamento vengono visualizzati sull'assegno, che viene trasferito all'acquirente.

Caratteristiche delle transazioni online e offline

Le azioni considerate durante l'esecuzione di transazioni online completano l'interazione tra l'acquirente e il negozio. Ma il processo di transazione in sé non finisce qui. Il fatto è che i fondi non vengono addebitati immediatamente sulla carta: vengono temporaneamente bloccati. I fondi vengono trasferiti al negozio dal conto dell'acquirente e vengono addebitati sulla carta solo dopo che la banca acquirente ha trasferito il documento finanziario all'emittente per l'addebito. Questo può accadere in un periodo di diversi giorni o addirittura un mese.

Le transazioni offline sono condotte secondo un principio diverso. Passano senza verifica azioni da parte remota e approvazione o rifiuto. La transazione viene approvata in anticipo, il saldo sulla carta bancaria viene riservato e tutti i dettagli del pagamento vengono salvati nella memoria del terminale di pagamento.

Una transazione offline viene eseguita successivamente, quando le informazioni accumulate nel terminale vengono trasmesse tramite canali di comunicazione alla banca servente. Di solito sono necessari diversi giorni dal momento in cui viene richiesto il pagamento al pagamento effettivo.

Le transazioni offline vengono utilizzate nei casi in cui non è possibile stabilire una connessione con il centro di elaborazione in tempo reale (su aerei, autobus, taxi, ecc.).

Divieto e annullamento delle transazioni

Le transazioni più comuni sono i pagamenti in negozio, i trasferimenti di denaro e i prelievi di contanti. Ci sono diversi motivi per cui le transazioni possono essere vietate.

I più comuni sono:

la carta di credito è stata bloccata;
non ci sono fondi sufficienti sulla carta bancaria necessaria per completare l'operazione;
la carta di pagamento ha stabilito restrizioni all'effettuazione dei pagamenti;
la carta di pagamento è scaduta;
è stato commesso un errore durante l'inserimento del codice PIN;
la carta di credito è stata inserita nella lista degli stop per sospetto riciclaggio di denaro, frode, ecc.;
ci sono problemi tecnici (sul sito web, con un bancomat, ecc.).

Se il divieto di transazione non è correlato a un saldo insufficiente della carta, è necessario contattare la banca di servizio per risolvere i problemi. In alcuni casi, le transazioni possono essere annullate su iniziativa dei clienti stessi (ovviamente, se non si tratta di prelievi di contanti). È necessario conoscere la possibilità di annullare le transazioni per poter restituire i fondi addebitati sulla carta in modo fraudolento.

Il modo più semplice è annullare la transazione il giorno in cui è stata eseguita.

La funzione di annullamento delle operazioni è nei terminali stessi.

Se i dati dai terminali sono già stati trasferiti alla banca, dovresti contattare l'istituto finanziario stesso.