Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Uno snapshot del database è una visualizzazione statica di sola lettura di un database di SQL Server (database di origine). Lo snapshot del database è coerente in modo transazionale con il database di origine al momento della creazione dello snapshot. Uno snapshot del database si trova sempre nella stessa istanza del server del database di origine. Quando il database di origine viene aggiornato, lo snapshot del database viene aggiornato. Pertanto, esiste più a lungo uno snapshot del database, più è probabile che si usi lo spazio su disco disponibile.
È possibile generare più snapshot di uno stesso database di origine. Ogni snapshot del database viene mantenuto fino a quando non viene eliminato in modo esplicito dal proprietario del database.
Annotazioni
Gli snapshot del database non sono correlati ai backup di snapshot, all'isolamento delle transazioni tramite snapshot o alla replica tramite snapshot.
Contenuto dell'argomento
Panoramica delle funzionalità
Gli snapshot del database operano a livello di pagina 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. Nello snapshot viene archiviata la pagina originale, mantenendo i record di dati nello stato corrispondente al momento in cui è stato creato lo snapshot. Lo stesso processo viene ripetuto per ogni pagina che viene modificata per la prima volta. All'utente, uno snapshot del database non viene mai modificato, perché le operazioni di lettura in uno snapshot del database accedono sempre alle pagine di dati originali, indipendentemente dalla posizione in cui risiedono.
Per archiviare le pagine originali copiate, lo snapshot utilizza uno o più sparse file. Inizialmente, un file sparse è un file essenzialmente vuoto che non contiene dati utente e non è ancora stato allocato spazio su disco per i dati utente. Man mano che nel database di origine vengono aggiornate sempre più pagine, le dimensioni del file aumentano. 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.
Vantaggio degli snapshot di database
È possibile utilizzare gli snapshot per la generazione di report.
I client possono eseguire query su uno snapshot del database, che rende utile la scrittura di report in base ai dati al momento della creazione dello snapshot.
Mantenimento dei dati cronologici per la generazione di report.
Uno snapshot consente di estendere l'accesso utente ai dati relativi a un momento determinato. Ad esempio, è possibile creare uno snapshot del database alla fine di un determinato periodo di tempo, ad esempio un trimestre finanziario, per la creazione di report successivi. ed eseguire report di fine periodo sullo snapshot. Se lo spazio su disco è consentito, è anche possibile gestire snapshot di fine periodo per un periodo illimitato, consentendo query sui risultati di questi periodi; ad esempio, per analizzare le prestazioni dell'organizzazione.
Uso di un database mirror gestito a scopo di disponibilità per l'offload dei report.
L'utilizzo degli snapshot del database con il mirroring del database consente di rendere disponibili per la creazione di report i dati archiviati nel server mirror. Inoltre, l'esecuzione di query sul database mirror può liberare risorse sul principale. Per altre informazioni , vedere Mirroring e snapshot del database (SQL Server).
Salvaguardia dei dati da errori amministrativi.
In caso di errore dell'utente in un database di origine, è possibile ripristinare lo stato in cui si trovava il database di origine quando è stato creato uno snapshot del database specificato. La perdita di dati è limitata agli aggiornamenti del database eseguiti dopo la creazione dello snapshot.
Ad esempio, prima di eseguire aggiornamenti importanti, ad esempio un aggiornamento in blocco o una modifica dello schema, creare uno snapshot del database nel database protegge i dati. In caso di errore è possibile utilizzare lo snapshot per il recupero, riportando il database allo stato memorizzato nello snapshot. Il ripristino è potenzialmente molto più veloce a questo scopo rispetto al ripristino da un backup; tuttavia, non è possibile eseguire il rollforward in un secondo momento.
Importante
Non è possibile eseguire il ripristino di un database offline o danneggiato. Pertanto, l'esecuzione di backup regolari e il test del piano di ripristino sono necessari per proteggere un database.
Annotazioni
Gli snapshot del database dipendono dal database di origine. Pertanto, l'uso degli snapshot del database per ripristinare un database non è un sostituto della strategia di backup e ripristino. L'esecuzione di tutti i backup pianificati rimane comunque essenziale. Se è necessario ripristinare il database di origine nel momento in cui è stato creato uno snapshot del database, implementare un criterio di backup che consenta di eseguire questa operazione.
Salvaguardia dei dati da errori degli utenti.
Creando regolarmente snapshot del database, è possibile ridurre l'impatto di un errore utente principale, ad esempio una tabella eliminata. Per assicurare un livello elevato di protezione, è possibile creare una serie di snapshot del database, relativi a un intervallo di tempo sufficiente per riconoscere e rispondere alla maggior parte degli errori da parte degli utenti. Ad esempio, è possibile mantenere da 6 a 12 snapshot in sequenza che si estendono su un intervallo di 24 ore, a seconda delle risorse del disco. Ogni volta che viene creato un nuovo snapshot è possibile eliminare lo snapshot meno recente.
Per il recupero dopo un errore da parte degli utenti, è possibile riportare il database allo stato registrato nello snapshot immediatamente precedente l'errore. Il ripristino è potenzialmente molto più veloce a questo scopo rispetto al ripristino da un backup; tuttavia, non è possibile eseguire il rollforward in un secondo momento.
In alternativa, è possibile ricostruire manualmente una tabella eliminata o altri dati persi dalle informazioni in uno snapshot. Ad esempio, è possibile copiare in blocco i dati dallo snapshot nel database e reintegrare manualmente i dati nel database.
Annotazioni
Il numero di snapshot simultanei necessari in un database, la frequenza per la creazione di un nuovo snapshot e il tempo di memorizzazione degli snapshot dipendono dalle ragioni per cui si decide di utilizzare gli snapshot del database.
Gestione di un database di test
In un ambiente di test può essere utile quando si esegue ripetutamente un protocollo di test per il database per contenere dati identici all'inizio di ogni ciclo di test. Prima di eseguire il primo round, uno sviluppatore di applicazioni o un tester può creare uno snapshot del database nel database di test. Dopo ogni test, sarà possibile ripristinare rapidamente lo stato precedente del database ripristinando il relativo snapshot.
Termini e definizioni
istantanea del database
Vista statica, di sola lettura e consistente dal punto di vista transazionale di un database (di origine).
database di origine
Per uno snapshot del database, il database del quale è stato creato lo snapshot. 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 il database non è più disponibile per qualsiasi motivo, anche tutti gli snapshot del database diventano non disponibili.
file sparse
File fornito dal file system NTFS che richiede molto meno spazio su disco rispetto a quanto altrimenti necessario. Un file di tipo sparse viene utilizzato per archiviare pagine copiate in uno snapshot del database. Un file di tipo sparse appena creato richiede poco spazio su disco. Man mano che i dati vengono scritti in uno snapshot del database, lo spazio su disco viene allocato gradualmente dal file system NTFS nel file di tipo sparse corrispondente.
Prerequisiti per e limitazioni per gli snapshot del database
Contenuto della sezione
Prerequisiti
Il database di origine, in cui può essere utilizzato qualsiasi modello di recupero, deve soddisfare i prerequisiti seguenti:
L'istanza del server deve essere in esecuzione in un'edizione di SQL Server che supporta gli snapshot del database. Per ulteriori informazioni, vedere Features Supported by the Editions of SQL Server 2014.
Il database di origine deve essere online, a meno che non si tratti di un database mirror nell'ambito di una sessione di mirroring del database.
È possibile creare uno snapshot del database in qualsiasi database primario o secondario in un gruppo di disponibilità. Il ruolo di replica deve essere PRIMARY o SECONDARY, non nello stato di RESOLVING.
È consigliabile uno stato di sincronizzazione del database corrispondente a SYNCHRONIZING o SYNCHRONIZED quando si crea uno snapshot del database. Tuttavia, gli snapshot del database possono essere creati quando lo stato di sincronizzazione del database non è in sincronizzazione.
Per altre informazioni, vedere Snapshot del database con gruppi di disponibilità AlwaysOn (SQL Server).
Per creare uno snapshot del database in un database mirror, è necessario che il database si trovi nello stato di mirroring SYNCHRONIZED.
Non è possibile configurare il database di origine come un database condiviso scalabile.
Annotazioni
Tutti i modelli di recupero supportano gli snapshot del database.
Limitazioni per il database di origine
In presenza di snapshot del database, al database di origine dello snapshot si applicano le limitazioni seguenti:
Il database non può essere eliminato, scollegato o ripristinato.
Annotazioni
Il backup del database di origine funziona normalmente; non è interessato dagli snapshot del database.
Le prestazioni sono ridotte a causa di un aumento delle operazioni di I/O nel database di origine risultante da un'operazione di copia in scrittura allo snapshot ogni volta che viene aggiornata una pagina.
I file non possono essere eliminati dal database di origine o da eventuali snapshot.
Limitazioni per gli snapshot del database
Agli snapshot del database si applicano le limitazioni seguenti:
È necessario creare e mantenere uno snapshot del database sulla stessa istanza del server in cui si trova il database di origine.
Gli snapshot del database includono sempre un intero database.
Gli snapshot del database dipendono dal database di origine e non sono risorse di archiviazione ridondanti. Non proteggono da errori del disco o da altri tipi di danneggiamento. Pertanto, l'uso degli snapshot del database per ripristinare un database non è un sostituto della strategia di backup e ripristino. L'esecuzione di tutti i backup pianificati rimane comunque essenziale. Se è necessario ripristinare il database di origine nel momento in cui è stato creato uno snapshot del database, implementare un criterio di backup che consenta di eseguire questa operazione.
Quando una pagina viene aggiornata nel database di origine e spostata in uno snapshot, se lo snapshot esaurisce lo spazio su disco o si verifica un altro errore, lo snapshot diventa sospetto e deve essere eliminato.
Gli snapshot sono di sola lettura. Poiché sono di sola lettura, non possono essere aggiornati. Gli snapshot del database non devono pertanto essere validi dopo un aggiornamento.
Gli snapshot dei database model, master e tempdb non sono consentiti.
Non è possibile modificare alcuna specifica dei file di snapshot del database.
Non è possibile eliminare i file da uno snapshot del database.
Non è possibile eseguire il backup o il ripristino degli snapshot del database.
Non è possibile collegare o scollegare snapshot del database.
Non è possibile creare snapshot di database in file system FAT32 o partizioni RAW. I file sparse usati dagli snapshot del database vengono forniti dal file system NTFS.
L'indicizzazione full-text non è supportata per gli snapshot del database. I cataloghi full-text non vengono propagati dal database di origine.
Uno snapshot del database eredita i vincoli di sicurezza del proprio database di origine esistenti al momento della creazione dello snapshot. Poiché gli snapshot sono di sola lettura, le autorizzazioni ereditate non possono essere modificate e le modifiche alle autorizzazioni apportate all'origine non verranno riflesse negli snapshot esistenti.
Uno snapshot riflette sempre lo stato dei filegroup al momento della sua creazione. I filegroup online e quelli offline non modificano il proprio stato. Per altre informazioni, vedere "Snapshot del database con filegroup offline" più avanti in questo argomento.
Se un database di origine diventa RECOVERY_PENDING, gli snapshot del database potrebbero diventare inaccessibili. Dopo aver risolto il problema nel database di origine, gli snapshot dovrebbero essere nuovamente disponibili.
Il ripristino non è supportato per i filegroup di sola lettura e per i filegroup compressi. I tentativi di ripristinare un database contenente uno di questi tipi di filegroup hanno esito negativo.
In una configurazione di log shipping, gli snapshot del database possono essere creati solo nel database primario, non in un database secondario. Se si passano ruoli tra l'istanza del server primario e un'istanza del server secondario, è necessario eliminare tutti gli snapshot del database prima di poter impostare il database primario come database secondario.
Un database snapshot non può essere configurato come un database condiviso scalabile.
I filegroup FILESTREAM non sono supportati dagli snapshot del database. Se i filegroup FILESTREAM esistono in un database di origine, vengono contrassegnati come offline negli snapshot del database e gli snapshot del database non possono essere usati per ripristinare il database.
Annotazioni
Un'istruzione SELECT eseguita in uno snapshot del database non deve specificare una colonna FILESTREAM. In caso contrario, verrà restituito il seguente messaggio di errore:
Could not continue scan with NOLOCK due to data movement.Quando le statistiche su uno snapshot di sola lettura sono mancanti o non aggiornate, il motore di database crea e gestisce statistiche temporanee in tempdb. Per altre informazioni, vedere Statistiche.
Requisiti di spazio su disco
Gli snapshot del database richiedono spazio su disco. Se uno snapshot del database esaurisce lo spazio su disco, viene contrassegnato come sospetto e deve essere eliminato. Il database di origine, tuttavia, non è interessato; le azioni su di esso continuano normalmente. Rispetto a una copia completa di un database, tuttavia, gli snapshot sono estremamente efficaci in termini di spazio. Uno snapshot richiede esclusivamente lo spazio necessario per le pagine che vengono modificate durante la sua durata. In genere, gli snapshot vengono mantenuti per un periodo di tempo limitato, pertanto le dimensioni non rappresentano un problema importante.
Più a lungo mantieni uno snapshot, tuttavia, più è probabile che si utilizzi lo spazio disponibile. La dimensione massima in base alla quale un file sparse può aumentare è la dimensione del file di database di origine corrispondente al momento della creazione dello snapshot.
Se uno snapshot del database esaurisce lo spazio su disco, deve essere eliminato (eliminato).
Annotazioni
Tranne che per lo spazio del file, uno snapshot del database utilizza approssimativamente le stesse risorse di un database.
Snapshot del database con gruppi di file offline
I filegroup offline nel database di origine influenzano gli snapshot del database quando si tenta di eseguire una delle operazioni seguenti:
Creare un'istantanea
Quando nel database di origine sono presenti uno o più filegroup offline, la creazione degli snapshot ha esito positivo con i filegroup offline. I file di tipo sparse non vengono creati per i filegroup offline.
Portare un filegroup offline
È possibile portare un file offline nel database di origine. Tuttavia, il filegroup rimane online negli snapshot del database se era tale alla creazione dello snapshot. Se i dati sottoposti a query sono stati modificati dopo la creazione dello snapshot, la pagina dei dati originale sarà accessibile nello snapshot. Tuttavia, è possibile che, per le query che utilizzano lo snapshot per l'accesso ai dati non modificati nel filegroup, si verifichino errori di input/output (I/O).
Portare un filegroup online
Non è possibile portare online un filegroup in un database che contiene snapshot del database. Se un filegroup è offline al momento della creazione dello snapshot o viene portato offline mentre esiste uno snapshot del database, il filegroup rimane offline. Questo perché riportare un file online comporta il suo ripristino, che non è possibile se esiste uno snapshot nel database.
Ripristinare lo snapshot come database di origine
Il ripristino di un database di origine a uno snapshot del database richiede che tutti i filegroup siano online, ad eccezione dei filegroup offline al momento della creazione dello snapshot.