Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicità Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
Greenpeace
Alcuni motivi per evitare lo shrink di un database
Scritto da Rocco Galati il 03-03-2011 ore 11:05
Nell'articolo precedente, si sono elencate alcune procedure da evitare per diminuire i rischi di errore durante l'amministrazione di un database. Una di queste riguarda lo shrink della base di dati, che può provocare un notevole calo nelle prestazioni dell'applicazione.

L'operazione di shrink può essere effettuata in SQL con il comando DBCC SHRINKDATABASE, che consente di compattare i dati e i file di log di un database specifico, oppure con il comando DBCC SHRINKFILE, che permette di ridurre la dimensione di un file di dati o di log riferiti al database correntemente preso in considerazione, oppure di svuotare un file trasferendo i dati verso un altro gruppo di file. In entrambi i casi, il server SQL sposta le pagine verso l'inizio del file liberando lo spazio in fondo a quest'ultimo per prepararlo al compattamento.

Molti amministratori di database hanno l'abitudine di eseguire periodicamente questa operazione pensando di riuscire, così, a ridurre la dimensione della propria base di dati e a aumentare la velocità dell'applicazione; purtroppo, come è anche possibile vedere andando ad analizzare l'output di uno script SQL che esegue lo shrink, il risultato che si ottiene è un file con un indice di frammentazione altissimo. Non solo: la compattazione genera una serie di operazioni di I/O, che occupano buona parte della CPU installata sulla macchina e danno luogo a file di log di dimensioni elevate. Quest'ultimo aspetto è dovuto al fatto che durante lo shrink, il processo aggiunge al file di log numerose righe di informazioni per ogni singola operazione o record spostato.

La scelta di eseguire ripetutamente lo shrinking del database porta ad accrescere sempre più lo spazio su disco occupato dai log virtuali, che hanno una forte ripercussione sul tempo di start-up dell'applicazione come anche un allungamento dei tempi per il restore e l'esecuzione delle normali istruzioni sulla base di dati.

Per un approfondimento maggiore sul tema della frammentazione dei dati è possibile leggere l'articolo di Tibor Karaszi, in cui si affrontano nel dettaglio tutte le conseguenze derivanti da un utilizzo troppo assiduo dell'operazione di shrink.
Precedente: Efficienza dei consumi, un fattore chiave per i sensori wireless
Successiva: Tutta la crittografia in un'ora (2/2)
Intervento di Marco Zordan a.k.a. customsoft del 03-03-2011 ore 14:24, Arzignano (VI)
Cavaliere
Cavaliere

(108 interventi)
Iscritto il 14-02-2002
Alternativa:
1) Metto in manutenzione il sito magari lasciando solo una copia statica.
2) Esporto i dati dal DB/tabella.
3) Li importo in un/a nuovo/a DB/tabella.
4) Riabilito il sito sul/la nuovo/a DB/tabella.

Saluti
Marco (SE&O)
Intervento di Domenico Sgarbossa a.k.a. sbraaa del 03-03-2011 ore 17:21, Padova (PD)
Nobile
Nobile
(93 interventi)
Iscritto il 29-03-2002
Forse sarebbe il caso di esplicitare il fatto che questo si riferisce a SQL Server.
Mi sembra di ricordare che con Informix, Oracle, PostgreSQL, MySQL le cose siano diverse.
Probabilmente i ragionamenti proposti trovano utilità anche con altri prodotti ma francamente mi sembra una problematica tipica di SQL Server (forse anche Sybase avendo i due database natali comuni).
Dico bene?
Intervento di Rocco Galati a.k.a. roccogalati del 03-03-2011 ore 17:34, Torino (TO)
Nobile
Nobile

(96 interventi)
Iscritto il 07-12-2002
sbraaa ha scritto:
Forse sarebbe il caso di esplicitare il fatto che questo si riferisce a SQL Server.
Mi sembra di ricordare che con Informix, Oracle, PostgreSQL, MySQL le cose siano diverse.
Probabilmente i ragionamenti proposti trovano utilità anche con altri prodotti ma francamente mi sembra una problematica tipica di SQL Server (forse anche Sybase avendo i due database natali comuni).
Dico bene?

Si, i riferimenti sono per SQL Server di Microsoft.
Intervento di Filippo Fadda a.k.a. dedalo del 13-03-2011 ore 23:08, Capriata d'orba (AL)
Duca
Duca

(1961 interventi)
Iscritto il 03-04-2001
roccogalati ha scritto:
Si, i riferimenti sono per SQL Server di Microsoft.
Magari specificalo nel titolo la prossima volta Rocco.
Intervento di Rocco Galati a.k.a. roccogalati del 14-03-2011 ore 00:57, Torino (TO)
Nobile
Nobile

(96 interventi)
Iscritto il 07-12-2002
dedalo ha scritto:
roccogalati ha scritto:
Si, i riferimenti sono per SQL Server di Microsoft.
Magari specificalo nel titolo la prossima volta Rocco.

Va bene, anche se comunque la cosa era abbastanza chiara dai link; è stato per questo motivo che non l'ho indicato nel titolo.
Copyright Programmazione.it™ 1999-2013. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.279 secondi.