Deframmentazione SQL Server unità disco di database

  • Articolo

Questo articolo fornisce alcune indicazioni relative alla deframmentazione delle unità di database SQL Server.

Versione originale del prodotto: SQL Server
Numero KB originale: 3195161

È consigliabile deframmentare SQL Server dischi a livello di sistema operativo?

Dipende dallo stato di frammentazione delle unità correnti. In genere, non fa male e può essere utile, presupponendo di seguire le precauzioni descritte nella sezione Precauzioni durante la deframmentazione SQL Server unità di database. L'unico aspetto negativo è che è necessario arrestare SQL Server a meno che lo strumento di deframmentazione non supporti le funzionalità dei dati transazionali. La buona notizia è che, dopo aver eseguito la defrag, non è davvero necessario farlo di nuovo a meno che non si dispone di molti autogrowth e altri file in movimento su e fuori i dischi. Assicurarsi di comprendere eventuali 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 da batteria e ciò 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 in un disco rigido. Questo 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 del disco per recuperare il file di database, rallentando 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. I blocchi di dati correlati al posizionamento vicini tra loro riducono i requisiti delle operazioni di I/O.

Attualmente sul mercato sono disponibili diverse utilità di deframmentazione. Alcune utilità consentono la deframmentazione nei file aperti, mentre altre richiedono la deframmentazione di file chiusi o prestazioni migliori se usate in condizioni di file chiusi. Inoltre, alcune utilità hanno funzionalità transazionali, mentre altre no.

Precauzioni quando si deframmenta SQL Server unità di database

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 copiati correttamente.

  • L'utilità protegge da un errore di sistema, ad esempio un'interruzione dell'alimentazione, in modo sicuro che mantiene i file intatti logicamente e fisicamente. 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 wal (Write-Ahead Logging) richiede la prevenzione delle riscritture del settore per evitare la perdita di dati. L'utilità deve mantenere l'integrità fisica del file purché esegua lo spostamento dei dati. L'utilità deve funzionare sui limiti del settore in modo transazionale per mantenere intatti i file 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 assicurarsi che il settore originale non possa essere modificato quando viene copiato in una nuova posizione. Se sono consentite modifiche, l'utilità di deframmentazione potrebbe perdere la scrittura.

I deframmentatori di 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 non sia stata arrestata in modo da non deframmentare i file di database aperti.

La deframmentazione di file aperti genera diversi possibili problemi che la deframmentazione dei file chiusi in genere non comporta:

  • La deframmentazione dei file aperti influisce sulle prestazioni. Le utilità di deframmentazione possono bloccare sezioni del file, impedendo 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 su come i file vengono bloccati e su come ciò potrebbe influire sulla concorrenza SQL Server.

  • La deframmentazione di file aperti può influire sulla memorizzazione nella cache di scrittura e sull'ordinamento. Le utilità basate su file aperti richiedono componenti del percorso di I/O; questi componenti non devono modificare l'ordinamento o la natura prevista 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 come una singola entità. Questo argomento è illustrato in molti articoli della Microsoft Knowledge Base, SQL Server libri online e vari white paper. Tutte le scritture devono mantenere le sequenze di ordinamento di scrittura originali e le funzionalità write-through.

Suggerimenti

  • 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 pre-SQL Server 2014 tenendo presente l'aumento automatico se verrà usato.
  • Deframmentare il disco o i dischi in cui si trovano i log delle transazioni. In questo modo si eviterà la frammentazione del file esterno del log delle transazioni. Questo problema può verificarsi se i file hanno avuto una notevole aumento automatico o quando non si tratta di 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, è necessario configurare i dischi del cluster per sospendere il monitoraggio dell'integrità (noto anche come modalità di manutenzione).
  • Per ridurre al minimo la frammentazione, non compattare i file di database. Inoltre, aumentarli 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 SQL Server file di database e di backup.

Riferimenti