Deframmentazione delle unità disco del database di SQL Server
Questo articolo fornisce alcune indicazioni sulla deframmentazione delle unità di database di SQL Server.
Versione originale del prodotto: SQL Server
Numero KB originale: 3195161
I dischi di SQL Server devono essere deframmentati a livello del sistema operativo?
Ciò dipende dallo stato di frammentazione delle unità correnti. In genere, non fa male e può essere utile, supponendo di seguire le precauzioni descritte nella sezione Precauzioni durante la deframmentazione delle unità di database di SQL Server. L'unico negativo è che è necessario arrestare SQL Server a meno che lo strumento di deframmentazione supporti le funzionalità dei dati transazionali. La buona notizia è che, dopo aver eseguito la deframmentazione, non è necessario farlo di nuovo, a meno che non si disponga di molti file autogrowth e altri file che si spostano e si disattivano i dischi. Assicurarsi di comprendere le strategie di memorizzazione nella cache di scrittura usate dall'utilità. La memorizzazione nella cache da parte di un'utilità di questo tipo potrebbe comportare una cache non supportata dalla batteria e questo potrebbe violare i requisiti del protocollo WAL.
Ulteriori informazioni
Un deframmentatore del disco sposta tutti i file, incluso il file di database, in cluster contigui su un disco rigido. Ciò consente di ottimizzare e velocizzare l'accesso ai file. Ad eccezione del sistema operativo Windows NT, se non si deframmenta il disco rigido, il sistema operativo potrebbe dover passare a diverse posizioni fisiche sul disco per recuperare il file di database, rendendo più lento l'accesso ai file.
Poiché l'accesso ai dati fisici è la parte più costosa di una richiesta di I/O, la deframmentazione può offrire miglioramenti delle prestazioni per SQL Server e altre applicazioni. Il posizionamento di blocchi di dati correlati tra loro riduce i requisiti dell'operazione di I/O.
Attualmente nel mercato sono disponibili varie utilità di deframmentazione. Alcune utilità abilitano la deframmentazione nei file aperti, mentre altre richiedono la deframmentazione di file chiusi o offrono prestazioni migliori se usate in condizioni di file chiusi. Inoltre, alcune utilità hanno funzionalità transazionali, mentre altre no.
Precauzioni quando si deframmenta le unità di database di SQL Server
Quando si valuta un'utilità di deframmentazione da usare con SQL Server, assicurarsi che l'utilità fornisca funzionalità di dati transazionali. In particolare, scegliere un'utilità di deframmentazione che fornisce le funzionalità di dati transazionali seguenti:
Il settore originale non viene considerato spostato fino a quando il nuovo settore non è stato stabilito correttamente e i dati sono stati copiati correttamente.
L'utilità protegge da un errore di sistema, ad esempio un'interruzione dell'alimentazione, in modo sicuro che mantiene i file logicamente e fisicamente intatti. Per garantire l'integrità dei dati, è consigliabile eseguire un test pull-the-plug quando un'utilità di deframmentazione è in esecuzione in un file basato su SQL Server.
Il protocollo Write-Ahead Logging (WAL) richiede la prevenzione delle riscritture del settore per evitare la perdita di dati. L'utilità deve mantenere l'integrità fisica del file purché eseseguono qualsiasi spostamento dei dati. L'utilità deve lavorare sui limiti del settore in modo transazionale per mantenere intatti i file di SQL Server.
L'utilità deve fornire meccanismi di blocco appropriati per garantire che il file mantenga un'immagine coerente per eventuali modifiche. Ad esempio, l'utilità deve garantire che il settore originale non possa essere modificato quando viene copiato in una nuova posizione. Se sono state consentite modifiche, l'utilità di deframmentazione potrebbe perdere la scrittura.
I deframmentatori dei dischi critici che non forniscono queste funzionalità di dati transazionali non devono essere usati a meno che l'istanza di SQL Server che usa i dischi da deframmentare sia stata arrestata in modo da non deframmentare i file di database aperti.
La deframmentazione dei file open-file genera diversi possibili problemi che in genere la deframmentazione dei file chiusi non è:
La deframmentazione dei file open-file influisce sulle prestazioni. Le utilità di deframmentazione possono bloccare le sezioni del file, impedendo a SQL Server di completare un'operazione di lettura o scrittura. Ciò può influire sulla concorrenza del server che esegue SQL Server. Contattare il produttore dello strumento di deframmentazione per informazioni sul blocco dei file e su come questo potrebbe influire sulla concorrenza di SQL Server.
La deframmentazione dei file open-file può influire sulla memorizzazione nella cache e sull'ordinamento della scrittura. Le utilità basate su file open richiedono componenti del percorso di I/O; questi componenti non devono modificare l'ordinamento o la natura desiderata dell'operazione di scrittura. Se i tenant del protocollo write-through o WAL vengono interrotti, è probabile che si verifichino danni al database. Il database e tutti i file associati sono considerati una singola entità. Questo argomento è descritto in molti articoli della Microsoft Knowledge Base, nella documentazione online di SQL Server e in vari white paper. Tutte le scritture devono mantenere le sequenze di ordinamento di scrittura originali e le funzionalità write-through.
Elementi consigliati
- Deframmentare il volume NTFS, a meno che non sia stato formattato, prima di creare un nuovo database o spostare i database esistenti nel volume.
- Assicurarsi di pianificare e ridimensionare i file di dati e di log SQL in modo appropriato quando il database viene creato per la prima volta.
- Creare i log delle transazioni di pre-SQL Server 2014 tenendo presente l'aumento automatico se verrà usato.
- Deframmentare il disco o i dischi in cui risiedono i log delle transazioni. In questo modo si impedisce la frammentazione del file esterno del log delle transazioni. Questo problema può verificarsi se i file hanno avuto molto aumento automatico o quando non è un disco dedicato che contiene molti database, log o altri file modificati. In questo caso, i file (incluso il file di log delle transazioni) possono essere interleaved e frammentati.
- Se si deframmentano le unità di database che sono dischi del cluster, i dischi del cluster devono essere configurati per sospendere il monitoraggio dell'integrità (detto anche modalità di manutenzione).
- Per ridurre al minimo la frammentazione, non ridurre i file di database. Inoltre, aumentarle manualmente in dimensioni che riducono al minimo l'attività di crescita.
- Mantenere i file di database su dischi dedicati.
- Eseguire un backup completo prima di deframmentare i percorsi che contengono file di backup e database di SQL Server.