hai buone ragioni per preoccuparti perché il DB si restringe spesso in SQL Server "succhia". Paul Randal, il responsabile del motore di archiviazione in SQL 2005, ha dichiarato, ShrinkDB è scritto molto male. Troverà spazio vuoto prendendo i dati alla fine e li metterà all'inizio e continuerà a farlo fino a quando non avrà spazio libero alla "fine" dei file DB. A questo punto può quindi liberare lo spazio da SQL Server e restituirlo al sistema operativo. Stai invertendo efficacemente i tuoi file di database, quindi di solito vedrai un'enorme frammentazione. Puoi leggere le sue opinioni su questo post sul blog o su questo video di MCM Internals
Come per tutto, è necessario prima testarli nel proprio ambiente. Un modo migliore per farlo è spostare i dati in un filegroup diverso. È possibile eseguire una ricostruzione dell'indice online con l'indice cluster e quindi reindicizzare nel nuovo filegroup. Quindi puoi rilasciare quello vecchio e rilasciare lo spazio e non avere quasi alcuna frammentazione. Nota che questo richiederà circa il 120% di spazio in più mentre ci sta lavorando. Il problema con questo è che hai bisogno anche di ulteriore spazio libero che sembra che potresti non avere. Questa è una funzionalità aziendale.
Se lo spazio libero è di gran lunga un premio, allora potresti dover mordere il proiettile e ridurre lentamente il DB un piccolo pezzo alla volta per evitare processi di lunga durata. Nota che i tuoi dati saranno fortemente frammentati e vorrai reindicizzare di nuovo tutto. Nota che dopo aver reindicizzato tutto, aumenterai un po 'lo spazio utilizzato e tornerai ad avere spazio libero aggiuntivo. Vedi i consigli di Brent qui .
Per quanto riguarda lo spazio libero per te, dipende da quanto puoi permetterti attività di frammentazione e crescita dei file. Con IFI abilitato, la crescita dei file è quasi istantanea ma si ottiene ancora la frammentazione. Una buona regola empirica è preallocare tutto lo spazio di cui pensi di aver bisogno, oppure monitorare la crescita e regolare periodicamente in blocchi se necessario. Questo mantiene bassa la frammentazione fisica.
Anche la crescita dei file di registro è molto più importante. File di registro aggiuntivi possono causare la frammentazione VLF. Questo rende i tuoi ripristini molto più lenti e può influenzare checkpoint / tronchi. Ecco alcuni rischi per le prestazioni che si assumono con un registro frammentato. Fare un DBCC LOGINFO();su ogni database. Cerca di mantenere il numero intorno a 50ish per Kim Tripp, ma se ne vedi centinaia, hai problemi di frammentazione, il che significa che i tuoi file di registro devono crescere per supportare le operazioni. Un buon modo per vedere quale dovrebbe essere il tuo file di registro per Paul Randal è lasciarlo crescere per una settimana e reindicizzare. Questo potrebbe essere un buon punto, forse puoi gettare un po 'più spazio libero lì per ogni evenienza. Assicurarsi che i log non siano frammentati con DBCC LOGINFO (); di nuovo e se lo sono, significa che sono cresciuti molto. Ridurre ed espandere nuovamente il file di registro utilizzandoquesto metodo .