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

13

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.

sql-server sql-server-2008 sql-server-2008-r2 AS2012
fuente

Respuestas:

15

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.

AS2012
fuente
1
Este mago es simplemente horrible.
usr
Lo sé, estoy tan acostumbrado a la línea de comando donde especificas FILL_FACTOR y no% libre, desearía que fuera consistente.
No reindexes y luego reduzcas, ¡es solo una pérdida de tiempo! Vea mi respuesta para más información.
JNK
1
JNK Sé a qué te refieres con no encogerte después de una reconstrucción, ya que eso fragmentará todo de nuevo. Sin embargo, en este escenario particular donde Jeff agregó por accidente el 90% de espacio libre a cada página, no veo otra forma de recuperar el espacio para: reconstruir con el factor de relleno 90, reducir el archivo, sin embargo, tendría que hacer otra reconstrucción con fillfactor 90% de nuevo. ¿O habría otra forma de recuperar el espacio? (Bueno, tal vez un nuevo grupo de archivos y luego reconstruir con soltar en el nuevo grupo de archivos, pero eso no funciona para todos)
Edward Dortland
2

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.

JNK
fuente
0

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.

Marcel N.
fuente
Sí, no tendrá formato, lo agregaré a la pregunta, un momento.
@JeffBane: ¿Puedes agregar esta información a tu pregunta, en una cita? No puedo distinguir lo que hay allí.
Marcel N.
1
Al reconstruir un índice, necesitaría el doble del espacio del índice + 20% para la clasificación. Entonces, en general, para reconstruir cada índice en su base de datos, solo necesita el 120% de su índice más grande en su base de datos. Si usa SORT_IN_TEMPDB, solo gana un 20%, aún necesita un 100% adicional en su archivo de datos. Además, usar sort in tempdb aumenta drásticamente su carga de E / S, ya que en lugar de escribir el índice una vez en el archivo de datos, ahora lo escribe una vez en tempdb y luego lo escribe en el archivo de datos. Entonces eso no siempre es ideal.
Edward Dortland
-1

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.

dpw
fuente
La necesidad de hacer una copia de seguridad del registro de transacciones nunca haría que las páginas no se publicaran.
mrdenny