Perché alcuni di DBMS non permetterà di rollback per alcune istruzioni DDL?

Question

Di recente ho scoperto che MySQL non lo fa rollback sostegno DDL come "alter table" ... Viene utilizzato per PostgreSQL, che mi ha colpito come strano, ma un mio amico mi ha detto che anche Oracle non lo consente .. ci sono ragioni tecniche per cui non lo sostengono? E 'semplicemente un "priva di interesse" caratteristica per loro?

Edit: appena trovato questo confronto . Sembra che ci sono molti DBMS che do supporto transazionale DDL.

Answer 1

Il motivo per cui questo funziona in PostgreSQL è che i cataloghi di sistema sono tavoli regolari. Creando così una nuova funzione, ad esempio, solo richiede l'inserimento di una riga nella tabella pg_proc, cambiando il valore predefinito di una colonna richiede solo facendo un aggiornamento di qualche riga in pg_attrdef, e così via. Dal momento che le tabelle sono comunque transazionale, si sarebbe quasi bisogno di andare dal tuo modo di non farlo funzionare in questo modo. (Un sacco di dettagli di implementazione dolorose omessi qui. ;-))

suppongo, non conoscendo il codice sorgente, che altri motori di database utilizzano alcune strutture interne su misura per rappresentare le loro informazioni del catalogo di sistema. E così avrebbero dovuto mettere in ulteriore sforzo, un sacco di sforzo in più probabile, per rendere il lavoro DDL transazionale, e non è evidentemente una priorità per loro.

Il rovescio della medaglia di questo è che questa è la ragione per la quale i principali aggiornamenti di versione di PostgreSQL sono così doloroso. Altri prodotti possono presumibilmente progettare le loro strutture di metadati interne con i cambiamenti e gli aggiornamenti in mente, e quindi non ci sono problemi con l'aggiornamento a una nuova versione principale. In PostgreSQL, non v'è alcun modo per modificare una tabella di catalogo di sistema a guardare improvvisamente come una versione più recente di una tabella di catalogo di sistema, almeno non mantenendo il sistema on-line, perché ciò richiederebbe l'accesso ai cataloghi di sistema. Urgh.

Answer 2

La maggior parte non lo fanno? Peccato.

I principalmente utilizzare SQL Server e lo fa. So che Oracle non lo fa, ma ho pensato che Oracle potrebbe essere un'aberrazione.

In SQL Server, sono abbastanza certo è possibile eseguire più istruzioni DDL in una singola transazione, anche se penso anche che ci sono un paio di restrizioni (che ho dimenticato tutto). Si può fare un creare o un alter o una goccia di maggior parte delle cose e rotolare indietro, se vi piace. Red-Gate SQL Confronta (uno strumento che amo) si avvale di questo.

Il problema di questa operazione è che il vostro ambito della transazione diventa piuttosto interessante ... Quando si coinvolgono i cataloghi di sistema in una transazione di aggiornamento (DDL), si corre il rischio di prendere alcune serrature veramente importanti e si può bloccare l'accesso al cataloghi di sistema. Gli utenti non possono fare molto se le loro richieste non riescono a trovare le loro tabelle nei cataloghi!

A conti fatti, però, è a portata di mano per essere in grado di includere DDL in una transazione con più istruzioni.

Più utilmente, il comando TRUNCATE SQL Server DDL può anche essere un elemento di un multi -affermazione transazione. È possibile troncare una tabella di destinazione (molto veloce), costruirla, e poi fare un commit se vi piace il risultato. Se qualcosa va storto, rollback e voilà !, è come se mai disturbato il tavolo. spazio di log è anche ridotto al minimo. Approfitto di questo abbastanza spesso.

Answer 3

In SQL Server si può eseguire il rollback istruzioni DDL, non sta usando auto di impegnarsi al fine dell'istruzione. In altri DBMS non lo so, ma mi ricordo che in Oracle non si può fare lo stesso. Credo che sia specifico per ogni DBMS, non so cosa mi dicono standard SQL su questo, ma sono sicuro che non implementa produttori al 100% della norma.

C'è una domanda simile su SO: E 'possibile eseguire più istruzioni DDL all'interno di una transazione (in SQL Server)?

Answer 4

Oracle ha condiviso analisi sintattica delle ricerche, in modo da un * SELECT FROM table_a fatto da una sessione è (normalmente) la stessa di quella di un'altra sessione. Sarebbe rompersi se una sessione pensato che ci fosse dieci colonne della tabella e un altro pensiero ci sono stati undici.