Reconstrucción de índices, DB ahora 10 veces el tamaño

Tengo una base de datos SQL Server (2008 R2 SP1) que fue de aproximadamente 15 conciertos. Resulta que el mantenimiento no se había estado ejecutando en mucho tiempo, así que creé un plan de mantenimiento para reconstruir todos los índices, estaban muy fragmentados.

El trabajo terminó y la fragmentación desapareció, ¡pero ahora la base de datos tiene más de 120 conciertos! Entiendo que habría utilizado espacio adicional para hacer todas las reconstrucciones, pero ahora que el trabajo está hecho, creo que todo ese espacio sería espacio libre, pero el espacio libre solo se muestra como 3 conciertos, por lo que se están utilizando 117 conciertos. aunque el trabajo de reconstrucción de índice haya finalizado.

Estoy muy confundido y podría necesitar alguna orientación, tengo que recuperar la base de datos a un tamaño razonable, no tenemos espacio en disco para esto.

¡Gracias por adelantado!

Aquí están los resultados de ambas consultas publicadas:

log_reuse_wait_desc NADA

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

El tercer archivo es un archivo .ndf, que muestra solo 3688 en el espacio no utilizado, pero 111289 se usa para aproximadamente 15 gigas de datos.

Mientras tanto, acabo de descubrir esto, eructo cerebral total. Había indicado lo que pensé que era un factor de relleno de 90 en el trabajo de reconstrucción, pero está redactado como "cambiar el porcentaje de espacio libre a", por lo que al usar un valor de 90, ¡en realidad estaba usando un factor de relleno de 10! DOH No es de extrañar que creció 10 veces más grande. Voy a reconstruir con el factor de llenado correcto y luego reducir. Sin embargo, gracias a todos por el aporte.

La reconstrucción de los índices provoca espacio adicional en la base de datos. Este es un subproducto natural del proceso de reindexación: el servidor está construyendo una nueva versión del índice, junto con la versión actual, y luego descarta la versión actual cuando se completa.

¡Reducirse después de reindexar no tiene sentido!

¡Simplemente volverás a fragmentar el índice! La reducción elimina el espacio flojo al reasignar datos dentro de la base de datos.

Aquí hay un buen artículo de Paul Randal, quien cuando trabajaba en Microsoft estaba a cargo del DBCCcódigo, incluidos los encogimientos, sobre por qué no debería encogerse.

Deberías haber usado la opción de reconstrucción SORT_IN_TEMPDB=ON.

En su caso, los archivos de datos reales, donde se encuentran las tablas en cuestión, se han utilizado para ordenar los índices. Gran parte de ese espacio de 120 GB todavía no se usa y se llenará con datos de página cuando sea necesario.

Puede ver el estado del espacio utilizado / libre con esta consulta (tomada de aquí ):

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

Para reducir un archivo de base de datos específico (datos o registro), puede ver información aquí . Una advertencia antes de eso, liberar espacio no utilizado está tomando bastante tiempo para bases de datos de más de 100 Gb (depende también de la velocidad de almacenamiento), así que déjelo funcionar.

Sin ningún otro detalle, sospecho que necesita hacer una copia de seguridad del registro de transacciones antes de poder reclamar su espacio.

Mira lo que select name, log_reuse_wait_desc from sys.databaseste dice. Si la columna log_reuse_wait_desc dice LOG_BACKUPque no puede reclamar espacio hasta que haya hecho una copia de seguridad del registro de tran.