Salve,
lo shrink dei db, come gia' @Oregon, non e' un'attivita' da effettuarsi in maniera compulsiva...
tendenzialmente andrebbe eventualmente eseguita dopo la cancellazione massiva di dati oppure drop completo di tabelle, al fine di effettivamente rilasciare lo spazio "libero" non utilizzato...
Trivialmente, l'allocazione di pagine di dati all'interno del file dati avviene in maniera autogestita nei binary trees utilizzando come "parametri" le impostazioni di FILLFACTOR e PAD_INDEX dell'indice clustered (per la leaf page dei dati) o comunque anche per le pagine degli indici...
Quando, ad opera di un'INSERT/UPDATE l'inserimento di una nuova riga all'interno di una pagina, avviene il superamento delle soglie di cui sopra, verra' eseguito uno page split, che sposta meta' delle righe in una nuova pagina, con aggiornamento dei bookmarks di concatenazione per permettere la corretta navigazione. Questo NON indica frammentazione, ma solo che possono esserci pagine non riempite "completamente", atte ad ospitare eventuali nuove righe, e questo fa si che la dimensione del database aumenti... L'impostazione di aumento di dimensione definisce di quanto il file aumentera' per ogni blocco di aumento, fino a soddisfare l'esigenza di spazio richiesta. Questo, sempre se e' impostata per la base dati l'opzione di autogrowth.
In caso contrario, verra' generato un errore di impossibilita' di aggiungere nuove pagine di dati all'interno del db. Questo avviene anche al tentativo di superamento della soglia di 10gb del/dei file di dati nella versione Express di SQL Server.
L'allocazione di nuovo spazio tende a privilegiare la preparazione di pagine "contigue" per l'assegnazione alle tabelle (ma comunque porta un certo grado di frammentazione nelle operazioni di I/O) questo per alleviare le attivita' che il subcomponente SQL-IO di SQL Server deve effettuare per il caricamento dei dati, che vengono effettuati in blocchi contigui di memoria, considerando che la lettura da effettuarsi sara' sempre a livello di pagina, che essa sia mezza piena o meno....
La dimensione del/dei transaction log files non viene computata nel calcolo della soglia massima per SQLExpress, come neanche gli evantuali file stream associati al database.
Tornando allo shrink, sempre @Oregon indica correttamente che l'attivita' tende a muovere le pagine di dati all'interno del file mdf, causando quindi non una "vera frammentazione", ma comunque l'overhead in termini I/O di caricamento delle pagine da disco.
–
Andrea