Ricostruzione degli indici, DB ora 10 volte più grande

Ho un database SQL Server (2008 R2 SP1) che era di circa 15 concerti. Si scopre che la manutenzione non era in esecuzione da un po 'di tempo, quindi ho creato un piano di manutenzione per ricostruire tutti gli indici, erano molto frammentati.

Il lavoro è terminato e la frammentazione è sparita, ma ora il database ha oltre 120 concerti! Capisco che avrebbe usato spazio extra per fare tutte le ricostruzioni, ma ora che il lavoro è fatto, penso che tutto quello spazio sarebbe spazio libero, ma lo spazio libero viene mostrato solo come 3 concerti, quindi vengono utilizzati 117 concerti anche se il processo di ricostruzione dell'indice è terminato.

Sono molto confuso e potrei usare un po 'di guida, ho il ripristino del db a dimensioni ragionevoli, non abbiamo spazio su disco per questo.

Grazie in anticipo!

Ecco i risultati di entrambe le query pubblicate:

log_reuse_wait_desc NIENTE

name    TotalSpaceInMB  UsedSpaceInMB   FreeSpaceInMB
LIVE_Data   152             123             28
LIVE_Log    18939           89              18849
LIVE_1_Data 114977          111289          3688

Il terzo file è un file .ndf, quello che mostra solo 3688 nello spazio inutilizzato, ma 111289 è usato per circa 15 concerti di dati.

Nel frattempo l'ho appena capito, rompicapo totale. Avevo indicato quello che pensavo fosse un fattore di riempimento di 90 nel lavoro di ricostruzione, ma è scritto come "cambia percentuale di spazio libero in", quindi usando un valore di 90 lì dentro, in realtà stavo usando un fattore di riempimento di 10 !! DOH. Non c'è da stupirsi che sia cresciuto di 10 volte tanto. Ho intenzione di ricostruire con il fattore di riempimento corretto, quindi ridurre. Grazie a tutti per l'input, però.

La ricostruzione degli indici provoca ulteriore spazio di gioco nel DB. Questo è un sottoprodotto naturale del processo di reindicizzazione: il server sta costruendo una nuova versione dell'indice, si spera contigua, accanto alla versione corrente, quindi rilascia la versione corrente al termine.

Ridurre dopo la reindicizzazione non ha senso!

Frammenterai semplicemente l'indice! La riduzione rimuove lo spazio lento riallocando i dati all'interno del DB.

Ecco un bell'articolo di Paul Randal, che quando lavorava in Microsoft si occupava del DBCCcodice, inclusi i restringimenti, sul perché non dovresti ridurlo.

Avresti dovuto usare l'opzione di ricostruzione SORT_IN_TEMPDB=ON.

Nel tuo caso, i file di dati effettivi, in cui si trovano le tabelle in questione, sono stati utilizzati per ordinare gli indici. Gran parte di quello spazio da 120 GB è ancora inutilizzato e verrà riempito con i dati della pagina quando necessario.

È possibile visualizzare lo stato dello spazio utilizzato / libero con questa query (presa da qui ):

use [YourDatabaseNameHere]
go

select
    name,
    cast((size/128.0) as int) as TotalSpaceInMB,
    cast((cast(fileproperty(name, 'SpaceUsed') as int)/128.0) as int) as UsedSpaceInMB,
    cast((size/128.0 - cast(fileproperty(name, 'SpaceUsed') AS int)/128.0) as int) as FreeSpaceInMB
from
    sys.database_files

Per ridurre un file di database specifico (dati o registro), puoi vedere alcune informazioni qui . Un avvertimento prima, liberare spazio inutilizzato sta impiegando un po 'di tempo per database da 100+ Gb (dipende anche dalla velocità di archiviazione), quindi lascialo funzionare.

Senza altri dettagli sospetto che sia necessario eseguire un backup del registro delle transazioni prima di poter recuperare il suo spazio.

Vedi cosa select name, log_reuse_wait_desc from sys.databasesti dice. Se la colonna log_reuse_wait_desc indica LOG_BACKUPche non è possibile recuperare spazio fino a quando non si è eseguito un backup del registro di trasferimento.