Rollback non significa promessa di recupero assoluto
Uno script compensativo può riportare alcune colonne ai valori precedenti, ma non sostituisce transaction log, backup, vincoli applicativi o procedure di disaster recovery. Chiamarlo rollback non deve creare una falsa garanzia.
SQL SafeOps usa quindi il concetto di Guarded Restore: un piano leggibile e mirato, costruito sui valori catturati prima dell’operazione e progettato per fermarsi quando il record non corrisponde più allo stato atteso.
Come viene costruito il piano di restore
Per ogni riga coinvolta vengono conservati in memoria locale la chiave primaria e i valori originali delle colonne modificate. Il generatore produce istruzioni SQL Server compatibili con valori NULL, testo, date, numeri, bit, GUID e dati binari.
- Target identificato tramite chiave primaria.
- Valori originali inseriti nel SET del comando di ripristino.
- Valori successivi all’UPDATE verificati nella WHERE di guardia.
- Nessun invio dei record al cloud SQL SafeOps.
- Script disponibile per revisione prima e dopo l’esecuzione riuscita.
Perché la condizione di guardia è importante
Un ripristino basato soltanto sulla chiave primaria potrebbe cancellare una modifica legittima eseguita dopo il tuo UPDATE. La condizione di guardia controlla anche i valori che l’operazione aveva scritto.
Se quei valori sono cambiati di nuovo, la riga non viene trattata come un semplice candidato al ripristino. Il conflitto deve essere esaminato invece di essere sovrascritto automaticamente.
Cinque passaggi per mantenere il controllo
- 01
Individua le righe
Esegui l’anteprima e verifica che ogni record disponga di una chiave primaria.
- 02
Cattura gli originali
Conserva localmente soltanto i valori necessari a compensare le colonne modificate.
- 03
Genera lo script
Produci istruzioni mirate e compatibili con i tipi SQL Server rilevati.
- 04
Leggi le guardie
Controlla che la WHERE includa sia l’identità sia lo stato scritto dall’UPDATE.
- 05
Conserva il piano
Mantieni lo script disponibile e abbinalo alle normali procedure di backup e recovery.
Dubbi comuni
Il Guarded Restore sostituisce il transaction log?
No. È uno script compensativo applicativo. Transaction log, backup e strategie di recovery hanno finalità più ampie e restano necessari.
Perché verificare i valori modificati nella WHERE?
Per evitare che il ripristino sovrascriva un cambiamento successivo eseguito da un altro utente o processo.
I valori del database vengono caricati online?
No. Il piano viene generato nella sessione locale dell’applicazione collegata direttamente al tuo SQL Server.