Funzionamento degli snapshot del database
Uno snapshot del database offre una vista statica in sola lettura dello stato di un database di origine al momento della creazione dello shapshot, escluse le transazioni di cui non è stato eseguito il commit. Il rollback delle transazioni di cui non è stato eseguito il commit viene eseguito in nuovo snapshot del database poiché Motore di database esegue il recupero dopo la creazione dello snapshot, senza alcun effetto sulle transazioni nel database.
Gli snapshot del database dipendono dal database di origine. Gli snapshot di un database devono essere inclusi nella stessa istanza del server del database. Inoltre, se un database diventa non disponibile per qualsiasi motivo, tutti i relativi snapshot diventano non disponibili.
Gli snapshot possono essere utilizzati per la generazione di report. Nel caso di un errore utente nel database di origine, è inoltre possibile ripristinare lo stato del database di origine al momento in cui è stato creato lo snapshot. La perdita dei dati sarà limitata agli aggiornamenti applicati al database successivamente alla creazione dello snapshot. La creazione di uno snapshot del database, inoltre, può risultare immediatamente utile prima di apportare modifiche rilevanti a un database, ad esempio allo schema o alla struttura di una tabella. Per ulteriori informazioni sull'utilizzo degli snapshot, vedere Utilizzi tipici degli snapshot del database.
Benché ai fini dell'utilizzo degli snapshot la comprensione del loro funzionamento non sia essenziale, può risultare utile. Gli snapshot del database operano a livello di pagine di dati. Prima che una pagina del database di origine venga modificata per la prima volta, la pagina originale viene copiata dal database di origine allo snapshot. Questo processo è denominato operazione copy-on-write. Nello snapshot viene archiviata la pagina originale, mantenendo i record di dati nello stato corrispondente al momento in cui è stato creato lo snapshot. Gli aggiornamenti apportati successivamente a una pagina modificata non influiscono sul contenuto dello snapshot. Lo stesso processo viene ripetuto per ogni pagina modificata per la prima volta. In questo modo, lo snapshot consente di mantenere le pagine originali per tutti i record di dati modificati dal momento della creazione dello snapshot stesso.
Per archiviare le pagine originali copiate, lo snapshot utilizza uno o più file sparse. All'inizio un file sparse è un file essenzialmente vuoto che non contiene alcun dato utente e in cui non è stato allocato spazio su disco per i dati utente. Man mano che una sempre maggiore quantità di pagine viene aggiornata nel database di origine, la dimensione del file aumenta. Quando viene creato uno snapshot, il file sparse occupa una quantità ridotta di spazio su disco. Man mano che il database viene aggiornato nel tempo, tuttavia, un file sparse può assumere dimensioni estremamente elevate. Per ulteriori informazioni sui file sparse, vedere Informazioni sulle dimensioni dei file sparse negli snapshot del database.
Nella figura seguente viene illustrata un'operazione copy-on-write. I rettangoli grigio chiaro nel diagramma dello snapshot rappresentano lo spazio potenziale in un file sparse non ancora allocato. Quando viene ricevuto il primo aggiornamento a una pagina del database di origine, Motore di database scrive le informazioni nel file e il sistema operativo alloca una parte di spazio dei file sparse dello snapshot e vi copia la pagina originale. La pagina del database di origine viene quindi aggiornata da Motore di database. Nella figura seguente viene illustrata un'operazione copy-on-write di questo tipo.
.gif "Operatore di lettura sullo snapshot dopo l'aggiornamento della pagina")
.gif "Nota importante") Importante |
|---|
Gli snapshot del database non fungono da archivi ridondanti, pertanto non offrono protezione contro errori del disco o altri tipi di danneggiamento. L'esecuzione di backup regolari e il test del piano di ripristino sono operazioni fondamentali per la protezione del database. Se è necessario ripristinare il database di origine al punto nel tempo in cui è stato creato uno snapshot del database, implementare criteri di backup che consentano di eseguire tale operazione. |
Operazioni di lettura in uno snapshot del database
All'utente uno snapshot del database appare sempre come non modificato, in quanto le operazioni di lettura nello snapshot del database accedono sempre alle pagine di dati originali, indipendentemente dalla posizione.
Se la pagina non è stata ancora aggiornata nel database di origine, tramite un'operazione di lettura nello snapshot viene letta la pagina originale dal database di origine. Nella figura seguente viene illustrata un'operazione di lettura in un nuovo snapshot creato, il cui file sparse, pertanto, non contiene alcuna pagina. La lettura viene eseguita solo dal database di origine.
.gif "Operazione di lettura prima della copia della prima pagina nello snapshot")
Dopo che una pagina è stata aggiornata, un'operazione di lettura nello snapshot accede comunque alla pagina originale, archiviata, da quel momento in poi, in un file sparse. Nella figura seguente viene illustrata un'operazione di lettura nello snapshot che accede a una pagina dopo che questa è stata aggiornata nel database di origine. La pagina originale viene letta dal file sparse dello snapshot.
.gif "Operazione copy-on-write")
Effetti del modello di aggiornamento sull'aumento delle dimensioni dello snapshot del database
Se le dimensioni del database di origine sono significativamente elevate e l'utilizzo dello spazio su disco rappresenta un problema, è consigliabile sostituire uno snapshot meno recente con uno nuovo. La durata ideale di uno snapshot dipende dalla velocità con cui aumenta di dimensione e dallo spazio su disco disponibile per i relativi file sparse. Lo spazio su disco richiesto da uno snapshot dipende dalla quantità di pagine diverse del database di origine aggiornate durante la vita dello snapshot. Se pertanto gli aggiornamenti riguardano per lo più un subset ridotto di pagine aggiornate ripetutamente, il tasso di aumento diminuirà con il tempo e i requisiti di spazio per lo snapshot resteranno relativamente modesti. Se invece tutte le pagine originali vengono aggiornate almeno una volta, le dimensioni dello snapshot aumentano raggiungendo quelle del database di origine. Se lo spazio su disco è in via di esaurimento, gli snapshot entrano in conflitto per ottenere lo spazio su disco necessario. Se lo spazio dell'unità disco si esaurisce, non sarà possibile eseguire alcuna operazione di scrittura negli snapshot.
Nota
Per informazioni su come individuare le dimensioni effettive e potenziali di uno snapshot, vedere Informazioni sulle dimensioni dei file sparse negli snapshot del database.
Per questo motivo, è utile conoscere il modello classico di aggiornamento per un database durante la pianificazione della quantità di spazio necessario per la durata prevista di uno snapshot. Per alcuni database, la frequenza degli aggiornamenti potrebbe essere piuttosto costante. Molte delle pagine di un database di inventario, ad esempio, potrebbero essere aggiornate ogni giorno, rendendo consigliabile la sostituzione degli snapshot meno recenti una volta al giorno o una volta alla settimana. Per altri database la proporzione di pagine aggiornate potrebbe variare durante il ciclo aziendale. Il database di un catalogo, da esempio, potrebbe essere aggiornato principalmente ogni trimestre, con aggiornamenti occasionali in altri momenti. In questo caso, la creazione di snapshot appena prima e dopo ogni aggiornamento trimestrale rappresenterebbe una strategia locale adeguata. Lo snapshot precedente l'aggiornamento consentirebbe il ripristino in caso di errori di aggiornamento significativi, mentre lo snapshot successivo all'aggiornamento potrebbe essere utilizzato per la creazione di report durante il trimestre seguente.
Nella figura seguente vengono illustrati gli effetti di due modelli di aggiornamento diversi sulle dimensioni di uno snapshot. Il modello di aggiornamento A rappresenta un ambiente in cui solo il 30% delle pagine originali è stato aggiornato durante la vita dello snapshot. Il modello di aggiornamento B rappresenta un ambiente in cui durante la vita dello snapshot è stato aggiornato l'80% delle pagine originali.
.gif "Modelli di aggiornamento alternativi e dimensioni dello snapshot")
Metadati sugli snapshot del database
Per gli snapshot del database, nei metadati del database è inclusa la proprietà source_database_id, archiviata in una colonna della vista del catalogo sys.databases. Per ulteriori informazioni sull'utilizzo di questa proprietà, vedere sys.databases (Transact-SQL).
In genere, uno snapshot del database non espone metadati propri, ma metadati del database di origine. Tra questi metadati sono inclusi, ad esempio, i dati restituiti dall'istruzione seguente:
USE <database_snapshot> SELECT * FROM sys.database_files
dove <database_snapshot>è il nome di uno snapshot del database.
Le uniche eccezioni si verificano quando il database di origine utilizza la ricerca full-tex o il mirroring del database, che in uno snapshot si disattivano alterando alcuni valori nei metadati dello snapshot.
Vedere anche