IL CONCETTO DI LOGGING
Il database manager di Progress realizza le proprietà di atomicità e
durabilità di una transazione, utilizzando una tecnica di logging undo-redo, in
combinazione con una write-ahead logging.
Dal momento che le modifiche del database avvengono per mezzo di una o più
transazioni, notazioni o descrizioni di tali variazioni sono registrate su
disco in un tipo di file di log delle transazioni, conosciuto come undo-redo
log file. Quando si verifica un errore durante una transazione, questi record
di log sono usati per effettuare il rollback della transazione, eliminando
tutti i suoi effetti sul database (ripristino di tutti i dati ai loro valori
precedenti). Gli stessi record di log sono usati al verificarsi di un
crash recovery, per ripristinare il database in uno stato consistente.
Vi è un secondo log opzionale, chiamato redo log (discusso in seguito), che
può essere utilizzato per migliorare l'affidabilità del sistema registrando il
log delle transazioni in due fasi.
Il log undo-redo
Il log undo-redo è chiamato il "file di pre-immagine (before-image)"
o "file BI". Il BI file contiene un registro di tutte le
modifiche al database più recenti. Il database manager scrive uno o più
record di log, riguardanti le modifiche, nel BI file prima di effettuare la
modifica. Sebbene sia chiamato il before-image file, il log undo-redo file
non contiene in realtà una pre-immagine del database.
Esso contiene dati che
vengono utilizzati per:
- Annullare o invertire gli effetti di una transazione che non è stata
ancora commitata.
- Ripristinare il database in uno stato consistente dopo un crash,
ripetendo (redo) le modifiche fatte in precedenza. Lo stesso insieme di
modifiche potrebbe essere ripetuto più di una volta perché un guasto potrebbe
verificarsi durante una fase di rcovery.
- Conservare gli effetti delle transazioni committate, anche in caso di
fallimento
subito dopo il completamento della transazione.
- Consentire il riutilizzo incrementale di spazio nel file di undo-redo log
quando i record non sono più necessari, riducendo al minimo la dimensione del file.
- Limitare la quantità di dati che devono essere elaborati, e il tempo
richiesto per
farlo, durante il ripristino da un failure.
A seconda del tipo di operazione in corso sul database , ciò che è
necessario per soddisfare tali requisiti potrebbe essere una copia dei dati
prima di essere modificati, una copia dei nuovi dati, una combinazione dei due,
o forse altre informazioni. Ci sono oltre 50 diversi tipi di record di log
e ogni tipo contiene dati diversi.
Il BI file log può essere rappresentato da un singolo file o da più file (BI
extents) che fanno parte di una struttura di database multi-file.
Redoing a change
L’informazione registrata nel file di log è tale che si può combinare i
dati registrati nel log con i dati nella versione “vecchia” di un database block,
per produrre una nuova versione aggiornata. Ad esempio, quando un record
viene aggiornato, il record di log
conterrebbe vecchi e nuovi valori di solo quelle parti che hanno subito una
modifica. I nuovi valori sarebbero fusi nel vecchio record per rifare
(redo) una modifica.
Undoing a change
Lo stesso file log di registrazione, che è stato utilizzato per effettuare
la modifica iniziale, può essere utilizzato per annullare un'operazione in
combinazione con la nuova versione di un database block, per produrre la
vecchia versione del record. Continuando l'esempio precedente, i vecchi
valori sarebbero consolidati con il nuovo record per annullare una modifica.
Si noti che quando una modifica è annullata, si genera un nuovo record di
log che descrive l'annullamento. Questo è necessario perché può
verificarsi un errore prima che la copia, residente su disco, del database sia
aggiornata a valle dello scatenarsi dell’evento di undo.
Il redo log
Il redo log è chiamato il "log dopo-immagine (after-image)" o
"file AI". Il file AI contiene l’immagine di tutte le modifiche che si sono verificate dopo un
backup completo dell'intero database.
Lo scopo del AI log file è di fornire un meccanismo per il recupero dei
dati da un eventuale incidente che distrugge tutto o in parte il database e/o
il file di BI. Per recuperare i dati è necessario effettuare un ripristino
del database e poi applicare tutte le modifiche che sono state fatte dai tempi
del backup.
Il processo di riapplicare le modifiche si chiama roll-forward. Durante
questo processo, il database manager legge i record nel file di AI e ripete
ogni modifica di database, nello stesso ordine in cui sono state eseguite originariamente. Alla
fine del processo di roll-forward, il database sarà nello stesso stato in cui
si trovava appena prima l’errore si verificasse.
L’AI file log può essere rappresentato da un singolo file o da più file (AI
extents) che fanno parte di una struttura di database multi-file.
Deferred Writes
L'esistenza del log undo-redo consente al database manager di mantenere in
memoria le modifiche al database a tempo indeterminato, con una politica di
gestione del buffer "steal/no force". I blocchi del database
possono essere scritti su disco ogni volta che è conveniente. Le modifiche
vengono mantenute in un'area di memoria chiamata database buffer pool e non
devono essere scritte su disco, quando vengono apportate, né quando la transazione che le ha effettuate
è commited. È sufficiente che il transaction log record esista sul disco. Questo
concetto è noto, in gergo, come "scritture differite (deferred writes)". Il
meccanismo consente alte prestazioni ed ottimizzazione delle operazioni di
scrittura su disco; i database blocks nel buffer pool possono essere aggiornati
più volte prima di essere scritti su disco. Il database manager può
scegliere il tempo e l'ordine in cui scrivere i dati, infatti, i blocchi
aggiornati possono essere scritti prima che la transazione sia committata, o
dopo, a seconda di quale momento è il più adatto. In effetti, il transaction
log record consente di trasformare il processo di update sul database da random
(più lento) a scrittura sequenziale (più veloce).
Write-ahead logging
Quando si utilizza la tecnica write-ahead, le registrazioni di tutte le modifiche
del database sono scritte nel log, prima che siano applicate in memoria e su
disco. In questo modo i dati nel undo-redo log (before-image log), possono essere
usati per ripetere o rifare tutte le modifiche che possono essere perse prima
di essere scritte nel database. Senza il log record, le modifiche non possono
essere annullate se l'operazione di roll-back si rende necessaria. Il database
non può essere ripristinato in uno stato coerente e sarà inutilizzabile.
Affinché la tecnica di registrazione write-ahead funzioni correttamente, tutte le
scritture nel log file devono essere effettuate in modo sincrono; ciò significa
che quando il database manager scrive un buffer log su disco (utilizzando un chiamata
di sistema write(), o qualcosa di simile), i dati devono essere effettivamente
scritti su disco e non solo salvati in memoria. Per questo motivo i file di database, BI, AI non devono essere
memorizzati su file system remoti montati attraverso le reti.
0 commenti:
Posta un commento