Newsgroup: it.comp.software.database
Titolo: Scusate l'eresia...

A cosa servono le transazioni?
Perchè il loro utilizzo sembra imprescindibile con un motore Server?
Perchè un qualunque dannato manuale da per scontata l'esistenza delle
transazioni come fossero nate per generazione spontanea ... e di conseguenza
devo chiedere molto alla vostra pazienza?  ;-))
Che succede se s'implementano Batch senza usare transazioni (a parte il non
poter "tornare indietro" col RollBack).
Ciao a tutti.

 transazioni come fossero nate per generazione spontanea, senza
preoccuparsi di far capire bene a un neofita l'importanta PRATICA delle
medesime ... e di conseguenza


 A cosa servono le transazioni?
Vedi 
http://www.soft-land.org/articoli/transazioni.html
Davide

 Vedi 
http://www.soft-land.org/articoli/transazioni.html
Anzitutto grazie per il link.
I contenuti dell'articolo sono esposti con stile chiaro e sobrio, tuttavia
chissà che i miei dubbi e le domande che sto per porti non ti diano spunti
per migliorarlo ulteriormente ;-)
Considera che i miei dubbi riguardano espressamente MS SQL Server a cui
accedo via ODBC.
Allora:
1) Continua a non essermi chiaro che tipo d'errori (non hardware) si
dovrebbero verificare durante la scrittura in un db.
Una volta debuggato il codice, cosa potrebbe ostacolare la fase di
memorizzazione dati?
L'unica cosa che mi viene in mente è uno stallo da parte del motore, se
contemporaneamente molte postazioni stessero scrivendo sulla stessa tabella,
o addirittura gli stessi records.
In questi casi tuttavia un motore SQL intelligente dovrebbe gestirsi
internamente una *coda* di richieste e assolverle tutte in maniera
trasparente al programmatore.
Sono sulla strada giusta o sono di altro tipo gli errori da bypassare con le
transazioni?
2) Se più utenti aggiornano la stessa tabella, e il programma in questione
si avvale di transazione, il temporaneo gestito sul Server è uno solo o ne
viene creato uno per ogni utente?
3) La fase di Commit, ovvero di scrittura vera e propria sul DB, è comunque
critica: chi mi assicura (soprattutto in multiutenza) che vada a buon fine?
Ti ringrazio per l'attenzione, ciao.

 chi mi assicura (soprattutto in multiutenza) che vada a buon fine?
Nessuno. Ma se il meccanismo funziona come dovrebbe tale fase risulta nella
scrittra di una singola informazione in un singolo file.
Davide

 scrittra di una singola informazione in un singolo file.
Scusa, l'affermazione non mi č chiara.
Facciamo un esempio pratico: 100 utenti aggiornano la stessa tabella
contemporaneamente su MS Sql Server, non consideriamo anomalie o bugs
ambientali (come quelli da te citati a inizio post) che possano affliggere
l'aggiornamento dati:
Caso A) <no transazione>:  i dati vengono scritti direttamente nella tabella
interessata.
Potrebbero verificarsi errori ODBC dovuti a "blocchi" di multiutenza?
Caso B)  <transazione implementata>: anzitutto non mi č chiaro se il
temporaneo creato dalla transazione sia unico o ne vengano creati 100, uno
per ogni utente.
A naso propendo per la seconda ipotesi, comunque sia a un certo punto _se la
generazione dei temp č andata a buon fine_ cento processi d'aggiornamento
dati dovranno essere "Committati" sulla tabella ... a questo punto mi pare
si ritorni al Caso A)  (anche se le scritture avverranno tutte sul disco del
PC Server).
Ciao, Cristiano.

 contemporaneamente su MS Sql Server,
SQL Server non consente l'aggiornamento a piu' di una persona,
effettivamente, se un'utente entra in modifica, nessun'altro puo'
nemmeno LEGGERE i records.
Davide

 nemmeno LEGGERE i records.
Strano, perfino con Jet si riesce a leggere un record in modifica da un
altro utente...
Ciao, Cristiano

 tabella (magari dei Commit Trans che dovrebbero confermare le modifiche)?
Il primo che inizia la modifica acquisisce un lock, il secondo che ci
prova viene messo in attesa finche' il primo non ha terminato le sue
modifiche o annulla la transazione o finche' non ottieni un bel timeout.
Se/quando acquisisci il lock, ti ritrovi i dati gia' modificati dal
precedente utente.
Davide

 critica: chi mi assicura (soprattutto in multiutenza) che vada a
buon fine?
Tecniche interne al rdbms Oracle per esempio neanche scrive sui
datafile una volta committato... ma ci pensa dopo a tempo perso.
/G

 altro utente...
Infatti hai ragione, è possibile leggere dati in fase di modifica da un
altro utente, impostando l'isolation level a READ UNCOMMITTED.
Ciao!
--
Lorenzo Benaglia
UGIdotNET - 
http://www.ugidotnet.org
UGISS - 
http://www.ugiss.org

 altro utente...
Infatti hai ragione, č possibile leggere dati in fase di modifica da un
altro utente, impostando il livello di isolamento a READ UNCOMMITTED.
Il livello di isolamento (chiamato piů comunemente isolation level)
definisce il comportamento transazionale di default che SQL Server utilizza
per tutti gli statement di SELECT eseguiti per una determinata connessione.
Per definire l'isolation level si ricorre al seguente comando T-SQL:
SET TRANSACTION ISOLATION LEVEL
    { READ COMMITTED
        | READ UNCOMMITTED
        | REPEATABLE READ
        | SERIALIZABLE
    }
READ COMMITTED
E' l'impostazione di default, e fa in modo che venagano mantenuti dei lock
condivisi (shared locks) durante la lettura dei dati, in modo da evitare i
dirty reads, ma durante la transazione i dati "non in fase di lettura"
possono essere modificati, generando nonrepeatable reads o phantom;
READ UNCOMMITTED
Questa impostazione non crea alcun tipo di lock, dando origine a dirty
reads. Io l'ho usato per generare degli snapshot di dati finanziari da
visualizzare sul nostro portale, interrogando una tabella in continuo
aggiornamento;
REPEATABLE READ
I locks sono mantenuti per tutta la durata della transazione, in modo da
prevedine l'aggiornamento dei dati da parte degli altri utenti; in questo
modo non si possono verificare i nonrepeatable reads ma nuove righe possono
essere inserite nel data set dando origine ai phantom;
SERIALIZABLE
Viene mantenuto un range lock sull'intero data set, impedendo
l'aggiornamento e l'inserimento da parte di altri utenti. Questo isolation
level garantisce la piů alta consistenza dei dati, a scapito della
concorrenza, quindi va utilizzato "con parsimonia".


 eliminate dal log.
Prima di addentrarmi nella risposta volevo ripassare brevemente le funzioni
svolte dal Transaction Log.
Ma cos'è il Transaction Log?
Il Transaction Log registra tutte le modifiche effettuate in un database ed
una serie di informazioni aggiuntive che gli permettono di annullare (roll
back) o ripristinare (roll forward) tali modifiche in caso di un errore di
sistema (Hardware o Software) oppure a causa di un comando esplicito di
ROLLBACK della transazione garantendo in questo modo la consistenza dei
dati.
Dal punto di vista fisico il Transaction Log è costituito da 1 o più files
associati ad un database durante la sua creazione/modifica.
Vediamo cosa succede quando effettuiamo una modifica ad una tabella.
SQL Server memorizza le modifiche nel Transaction Log *su disco* nel momento
in cui tali modifiche sono eseguite, *prima* che vengano memorizzate nel
database.
Il processo può essere brevemente riassunto nei seguenti punti:
1) Una modifica viene inviata a SQL Server da una applicazione;
2) Non appena la modifica viene eseguita, le data pages coinvolte vengono
lette da disco ed inserite nel buffer cache (nel caso non siano già presenti
a causa di un precedente comando);
3) Ogni istruzione di modifica viene registrata nel log non appena viene
eseguita. Le modifiche sono *sempre* registrate nel log e scritte su disco
*prima* che vengano inserite nel database. Questo tipo di log viene chiamato
write-ahead;
4) Ciclicamente si verifica il processo di checkpoint che scrive fisicamente
nel database tutte le *transazioni completate*.
Se si verifica un problema (schianta un disco, va via la corrente e come al
solito l'elettricista si è dimenticato di mettere sotto UPS i server, prende
fuoco la sala fredda... adesso sto esagerando ;-)) all'accensione successiva
parte automaticamente un processo di recovery che utilizza il transaction
log per effettuare il roll forward di tutte le transazioni concluse
correttamente (committed) e l'annullamento (roll back) di quelle non ancora
concluse.
I transaction markers nel log sono utilizzati durante il processo automatico
di recovery per determinare i punti di partenza e di fine di una
transazione. Una transazione è considerata completata quanto il marker BEGIN
TRANSACTION ha il corrispondente marker COMMIT TRANSACTION. Le data pages
sono scritte su disco quando si verifica il processo di checkpoint.
Quindi tornando alla tua domanda non è vero che le transazioni sono
eliminate dal Transaction Log ad ogni checkpoint, ma tale comportamento
dipende dall'impostazione del Recovery Model.
In SQL Server 2000 puoi selezionare per ogni database 3 recovery model in
modo da determinare la modalità di backup dei dati e di stabilire
l'esposizione al rischo di perdita di dati:
1) Simple Recovery
Con il Simple Recovery model, il database può essere recuperato in base ai
dati presenti nell'ultimo backup effettuato.
Comunque con questa impostazione non è possibile ripristinare il database al
momento del crash o ad un determinato periodo temporale, in quanto le
transazioni vengono eliminate dal Transaction Log ad ogni checkpoint.
Per fare questo occorre selezionare il Full Recovery o Bulk-Logged Recovery
model.
2) Full Recovery
Il Full Recovery model utilizza i database backup ed i transaction log
backup per fornire una protezione completa sulla perdita di dati. Se uno o
più data file viene danneggiato, è possibile recuperare tutte le transazioni
concluse con successo. Le transazioni in corso durante il crash ma non
ancora concluse, saranno annullate.
Il Full Recovery permette di ripristinare il database al momento del crash o
ad uno specifico periodo temporale. Per garatire questo grado di recovery,
tutte le operazioni, incluse quelle bulk come la SELECT INTO, CREATE INDEX e
operazioni di bulk loading sono loggate completamente.
3) Bulk-Logged Recovery
Il Bulk-Logged Recovery model fornisce protezione dei dati garantendo
un'ottima performance ed una bassa occupazione del transaction log durante
le operazioni di bulk copy.
Le seguenti operazioni sono minimamente loggate:
- SELECT INTO.
- Operazioni di Bulk load (bcp e BULK INSERT).
- CREATE INDEX (anche sulle indexed views).
- Operazioni sui campi text e image (WRITETEXT e UPDATETEXT).
Con il Bulk-Logged Recovery model l'esposizione alla perdita di dati durante
queste operazioni di bulk copy è maggiore rispetto al Full Recovery model.
Mentre le operazioni bulk copy sono loggate completamente nel caso di Full
Recovery model, lo sono minimamente e non possono essere controllare a
livello di singola operazione impostando il Bulk-Logged Recovery model.
In caso di guasto, un data file danneggiato può comportare un intervento
manuale per ripristinare l'integrità dei dati.
Per maggiori informazioni ti consiglio di consultare i Books Online di SQL
Server.


 citarne un paio.
Errori umani ... di programmazione?
Penso di no.
Errori software: esempio pratico?
Ciao, Cristiano

 Errori software: esempio pratico?
A bizzeffe...
uno su tutti: caduta di connessione col rdbms...
/G

"Cristiano Avaldi" <>
Grazie a tutti per la collaborazione ;-)
Cristiano