Backup delle tabelle del database prima dell'importazione notturna

Sì, c'è un approccio migliore: hai preso in considerazione l'utilizzo delle transazioni? Inizia una nuova transazione, elimina tutto dalla tabella, aggiungi i dati. Se l'aggiunta dei dati fallisce in qualsiasi momento, è sufficiente eseguire il rollback della transazione.

Lo svantaggio è che se non hai rilevato l'importazione dei dati non riuscita durante il tempo di importazione ma solo dopo aver eseguito il commit, potrebbe essere troppo tardi per eseguire il rollback della transazione. Pertanto, potresti utilizzare un numero (ad esempio 10) di tabelle di backup, ad es. backup0 ... backup9, quindi si calcola la data modulo 10 e la si utilizza come indice della tabella di backup. Quindi, in questo caso, si cancella la tabella di backup corretta, si aggiungono i dati alla tabella di backup corretta ed eliminati dalla tabella principale. In questo modo, il conteggio delle tabelle di backup rimane costante.

Alcuni database supportano anche il recupero point-in-time, quindi assicurati di controllare se il tuo database funziona. Se lo fa, puoi recuperare una situazione N giorni fa senza dover avere tabelle di backup.

Suona come se le transazioni risultassero vantaggiose. Se la tua preoccupazione è che l'importazione dei dati sia cattiva o cattiva, puoi avviare una transazione prima di cancellare la tabella, importare la tabella, quindi eseguire il commit della transazione solo dopo che l'importazione è stata completata e il rollback in caso contrario. Basta fare attenzione che il registro delle transazioni nel motore del database sia di dimensioni adeguate.

Prendi in considerazione anche la creazione di una tabella che contiene storico. Questo aiuta a mantenere buoni dati e inoltre c'è in genere la necessità di creare report che mostrino metriche storiche, trend, ecc. Mi piace creare una tabella "istantanea" corrispondente che abbia la stessa struttura ma aggiunga un campo datetime, e faccia uscire la tabella ogni notte (s) nella (e) tabella (e) istantanea e impostare il campo datetime in modo che tutti i record per quella data abbiano lo stesso timestamp. Questo ti permette di interrogare facilmente i dati per giorno, ecc. E fornisce anche un buon modo per recuperare da una cattiva importazione di dati o da altri problemi. Ovviamente, metti un indice su quel campo data / ora.

Poi ho lavori notturni che potano queste istantanee per mantenere ogni giorno per un mese, uno alla settimana dopo un mese e uno al mese dopo un anno, ecc.

Ho trovato questo schema per funzionare bene ed essere gestibile e scalabile. Sembra pulito perché non si finisce con una tonnellata di tavoli, e i dati vengono archiviati in modo tale da poter ottenere facilmente una qualsiasi delle istantanee.

Hai solo bisogno di due copie di ogni tabella, una per i dati di "ieri" e una per "di oggi". il "trucco" è di aggiungere una vista in cima [di una] di queste tabelle e cambiare la / e tua / e domanda / e per usare quella:

create table table_from_elsewhere_a ( ... ) ; 
create table table_from_elsewhere_b ( ... ) ; 

create view table_from_elsewhere as select * from copied_table_a ; 

Il processo di caricamento per ogni tabella ora diventa:

• Scopri quale tabella di base viene utilizzata attualmente dalla vista.
• Svuota e carica la tabella altra .

Ad un certo punto quando sei soddisfatto delle cose,

• Ricreare la vista per utilizzare la tabella appena caricata.

Perché stai usando "tabelle di backup"? SQL Server 2012 è completamente competente nel backup di un database, presupponendo che le tabelle di staging si trovino in un database, in un file .bak, comprimendole e salvandole nello spazio di archiviazione.

Stai usando IIS per alcune delle importazioni di dati? In tal caso, si tratta semplicemente di aggiungere una fase di manutenzione al pacchetto SSIS.