È sicuro attivare la riduzione automatica di SQL Server?


Risposte:


70

(Inizialmente avevo fatto una domanda normale ma poi ho scoperto il metodo corretto - grazie BrentO)

No, mai.

L'ho incontrato diverse volte ora su ServerFault e voglio raggiungere un vasto pubblico con alcuni buoni consigli. Se la gente aggrotta le sopracciglia in questo modo di fare le cose, vota e lo rimuoverò volentieri.

La riduzione automatica è un'impostazione del database molto comune da abilitare. Sembra una buona idea: rimuovere lo spazio aggiuntivo dal database. Esistono molti "DBA involontari" (si pensi a TFS, SharePoint, BizTalk o semplicemente al vecchio SQL Server) che potrebbero non sapere che il restringimento automatico è decisamente malvagio.

In Microsoft ero proprietario del motore di archiviazione di SQL Server e ho provato a rimuovere la funzione di restringimento automatico, ma è rimasto per la compatibilità con le versioni precedenti.

Perché l'auto-restringimento è così male?

È probabile che il database cresca di nuovo, quindi perché ridurlo?

  1. Shrink-grow-shrink-grow provoca la frammentazione a livello di file system e richiede molte risorse.
  2. Non puoi controllare quando prende il via (anche se è normale)
  3. Utilizza molte risorse. Lo spostamento di pagine nel database richiede CPU, molta I / O e genera un sacco di registro delle transazioni.
  4. Ecco il vero kicker: la riduzione dei file di dati (sia automatica che no) provoca una massiccia frammentazione dell'indice, che porta a scarse prestazioni.

Ho pubblicato un post sul blog qualche tempo fa con uno script SQL di esempio che mostra i problemi che causa e spiega in modo un po 'più dettagliato. Vedi Riduzione automatica: disattivalo! (nessuna pubblicità o spazzatura come quella sul mio blog). Non confonderlo con la riduzione del file di registro, che a volte è utile e necessario.

Quindi fatevi un favore: date un'occhiata alle impostazioni del database e disattivate la riduzione automatica. Inoltre, non dovresti ridurre i tuoi piani di manutenzione, esattamente per lo stesso motivo. Spargi la voce ai tuoi colleghi.

Modifica: dovrei aggiungere questo, ricordato dalla seconda risposta: c'è un malinteso comune sul fatto che l'interruzione di un'operazione di riduzione può causare corruzione. No non lo farà. Possedevo il codice di restringimento in SQL Server: ripristina lo spostamento della pagina corrente che sta facendo se interrotto.

Spero che sia di aiuto!


C'è un modo per poter reindicizzare subito dopo una riduzione?
Lance Roberts,

4
Non reindicizzare perché ciò aumenterà di nuovo il file (crea un nuovo indice prima di eliminare quello vecchio), ma eseguendo una riorganizzazione (tramite il mio vecchio DBCC INDEXDEFRAG o il nuovo ALTER INDEX ... REORGANIZE) si risolverà la frammentazione, a spese di altro IO, CPU, registrazione ...
Paul Randal,

Ho notato che dopo aver rimosso la funzione di ridimensionamento automatico, l'utilizzo della memoria dello srrver è maggiore.
user193655

4

Certo, Paul ha ragione.

Vedi tutti i DB e le loro impostazioni di autoshrink. Se hai molti database, ne entrerai di nascosto uno.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

È questo nel dmv da qualche parte ... Mi chiedo.


2
sys.d Database ha un campo is_auto_shrink (e is_auto-close, is_auto_update_stats, ecc.)
Paul Randal,

meraviglioso im googling: come ho avuto un rapporto che ci aiuta a sapere quale dbs configurato come autoshrink e il tuo codice funziona bene e generare un buon rapporto da tutti i db per noi
sabre tabatabaee yazdi

2

Non è "pericoloso", non danneggia nulla.

Ma non è raccomandato per ambienti di produzione in cui il database può decidere di chiudere e avviare un costoso esercizio di riarrangiamento appena prima che arrivi una pila di richieste che richiedono più tempo per essere soddisfatte. Stai molto meglio utilizzando le operazioni di riduzione della pianificazione insieme ad altre operazioni di manutenzione come i backup (in realtà, dopo i backup - in questo modo otterrai di più dal registro delle transazioni). O semplicemente non ridurre affatto a meno che non ci sia un problema di crescita - puoi sempre impostare un monitor per farti sapere quando lo spazio allocato inutilizzato cresce oltre un certo rapporto o dimensione fissa.

IIRC l'opzione è disattivata per impostazione predefinita per tutti i database in tutte le edizioni MSSQL tranne Express.


2
Gli strizzacervelli non dovrebbero essere programmati: dovrebbero essere operazioni davvero rare a causa dei problemi che causano. Non capisco il tuo commento sull'esecuzione della riduzione dopo il backup: i record di registro generati dall'operazione di riduzione verranno acquisiti dal successivo backup del registro delle transazioni indipendentemente da quando lo si esegue o da quali altri backup vengono eseguiti. Grazie
Paul Randal,

1

C'è un white paper disponibile su TechNet che spiega la manutenzione SQL in modo più dettagliato.

http://technet.microsoft.com/en-us/library/cc262731.aspx


Sfortunatamente quel white paper è indirizzato solo alle installazioni di SharePoint e presenta effettivamente degli errori. Ho appena trascorso del tempo a insegnare l'attuale classe MCM di SharePoint con l'autore del white paper, Bill Baer.
Paul Randal,

3
Una buona introduzione generale alla manutenzione del database è nel mio articolo di TechNet Magazine sull'argomento Manutenzione efficace del database - technet.microsoft.com/en-us/magazine/cc671165.aspx .
Paul Randal,

1

Ho visto un server SQL con Autogrow e Autoshrink abilitati. Questo server (relativamente potente) era tremendamente lento, perché tutto ciò che faceva tutto il giorno era ridurre e far crescere i file del database. Il ridimensionamento automatico può essere utile, ma consiglierei due cose:

  1. Disattiva Autoshrink per impostazione predefinita.
  2. Documenta le configurazioni del tuo server, in modo da sapere dove sono abilitati Autogrow e Autoshrink e dove non lo sono.

1

L'unica volta in cui sono stato costretto a ridurre un database è stato quello di aggiornare una copia su un server di prova con meno spazio su disco (insufficiente per contenere il database di produzione).

I file del database di produzione avevano uno spazio libero generoso, sfortunatamente è necessario ripristinare un database con le stesse dimensioni di file di cui è stato eseguito il backup. Quindi non aveva altra scelta che ridurre la produzione prima di eseguirne il backup. (La riduzione ha richiesto secoli, molte risorse sono state consumate e la successiva crescita del registro delle transazioni è stata problematica.)


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.