tiene buenas razones para preocuparse ya que la base de datos se reduce en SQL Server a menudo "apesta". Paul Randal, el jefe del motor de almacenamiento en SQL 2005 declaró: ShrinkDB está escrito muy mal. Encontrará espacio vacío tomando los datos al final y colocándolos al principio y siga haciendo esto hasta que tenga espacio libre al 'final' de los archivos DB. En este punto, puede liberar el espacio de SQL Server y devolverlo al sistema operativo. Está invirtiendo efectivamente los archivos de su base de datos, por lo que generalmente verá una fragmentación masiva. Puede leer sobre sus puntos de vista en esta publicación de blog o en este video de MCM Internals
Como con todo, primero debes probarlos en tu entorno. Una mejor manera de hacerlo es mover datos a un grupo de archivos diferente. Puede hacer una reconstrucción del índice en línea con el índice agrupado y luego reindexar en el nuevo grupo de archivos. Luego puede soltar el viejo y liberar el espacio y casi no tener fragmentación. Tenga en cuenta que esto tomará aproximadamente un 120% de espacio adicional mientras se trabaja a través de él. El problema con esto es que necesita incluso espacio libre adicional que parece que podría no tener. Esta es una característica empresarial.
Si el espacio libre es tan importante, entonces es posible que tenga que morder la bala y reducir lentamente la DB un trozo pequeño a la vez para evitar procesos de larga ejecución. Tenga en cuenta que sus datos estarán muy fragmentados y querrá reindexar todo nuevamente. Tenga en cuenta que después de reindexar todo, aumentará un poco su espacio utilizado y volverá a tener espacio libre adicional. Vea el consejo de Brent aquí .
En cuanto a cuánto espacio libre es bueno para usted, es una cuestión de cuánto puede permitirse las actividades de fragmentación y crecimiento de archivos. Con IFI habilitado, el crecimiento del archivo es casi instantáneo pero aún se obtiene fragmentación. Una buena regla general es preasignar tanto espacio como creas que necesitarás, o monitorear el crecimiento y ajustar los fragmentos periódicamente si es necesario. Esto mantiene baja la fragmentación física.
También el crecimiento del archivo de registro es mucho más importante. Los archivos de registro adicionales pueden causar fragmentación de VLF. Esto hace que sus restauraciones sean mucho más lentas y puede afectar el punto de control / truncarse. Aquí hay algunos riesgos de rendimiento que toma con un registro fragmentado. Haz un DBCC LOGINFO();en cada base de datos. Intente mantener el número alrededor de 50 por Kim Tripp, pero si ve cientos, tiene problemas de fragmentación, lo que significa que sus archivos de registro tuvieron que crecer para admitir las operaciones. Una buena manera de ver cuál debería ser su archivo de registro según Paul Randal es dejarlo crecer durante una semana y reindexarlo. Ese podría ser un buen punto, tal vez pueda tirar un poco más de espacio libre allí por si acaso. Asegúrese de que sus registros no estén fragmentados con DBCC LOGINFO (); de nuevo y si lo son, significa que crecieron mucho. Reducir y volver a expandir el archivo de registro utilizandoeste método .
