Tenemos una instancia de SQL Server que se utiliza para el archivo de correo electrónico (cortesía de un paquete de archivo de terceros). De vez en cuando, el software se transfiere a una nueva base de datos vacía. Hemos hecho esto trimestralmente en el pasado, pero estamos buscando hacerlo mensualmente ahora. La cantidad de datos que se archiva es de aproximadamente 15-20 GB por mes, y la mayor parte de los datos reside en solo un puñado de tablas (generalmente de 2 a 4).
Una vez que pasamos a una nueva base de datos, la antigua se usa solo para lectura. Lo que me gustaría hacer es optimizarlo en un archivo de datos agradable y ajustado, con todas las tablas / índices contiguos y con un factor de relleno muy alto, y sin mucho espacio vacío al final del archivo de datos. Además, estamos usando Standard Edition en este servidor, con todas las limitaciones que eso implica (de lo contrario, ya estaría usando la compresión de datos).
Algunas posibilidades que se me ocurren:
- RECONSTRUIR / REORGANIZAR índices, DBCC SHRINKFILE (De acuerdo, esta no es una opción sensata, ya que DBCC SHRINKFILE fragmentará la orina de todo lo que toque, pero lo estoy incluyendo por completo).
- Cree una nueva base de datos con estadísticas automáticas desactivadas. Script y recrear todas las tablas de la base de datos de origen. Use bcp para exportar / importar los datos a la nueva base de datos, en orden de clave de clúster. Script y recrear todos los índices. Vuelva a calcular todas las estadísticas con escaneo completo.
- Cree una nueva base de datos con estadísticas automáticas desactivadas. Script y recrear todas las tablas de la base de datos de origen. Use SSIS o T-SQL para transferir datos a la nueva base de datos. Script y recrear todos los índices. Vuelva a calcular todas las estadísticas con escaneo completo.
El paso final en todos los casos sería configurar la base de datos en modo de solo lectura.
¿Qué otras buenas / mejores opciones hay para hacer esto? Mi preocupación es trasladar los datos de tal manera que conserve un factor de relleno alto y de una manera lógicamente contigua.
Editar:
Debo mencionar que alrededor del 75% de los datos parecen estar almacenados en columnas de imagen (LOB).
PRIMARY?Respuestas:
Para eliminar la fragmentación física en los archivos, puede mover el índice agrupado con la eliminación existente a un nuevo grupo de archivos. Como van a ser RO, haga que todos llenen el factor 100% ya que no se necesita espacio para inserciones, divisiones de página causadas por actualizaciones.
Esto también le permitiría realizar una restauración gradual y poner la base de datos en línea muy rápidamente si alguna vez decide ir a Enterprise. Enterprise también permite índices de almacén de columnas además de reducir masivamente el tiempo de consulta para estos datos de solo lectura, que es un filete masivo.
Puede usar la opción shrinkfile una vez antes de cambiar a lectura solo sin problemas serios con la fragmentación para eliminar el espacio al final del archivo como lo desee.
En una nota al margen, simplemente verificando que está utilizando los últimos tipos de datos para sus LOBS. es decir, nvarchar (max) o varchar (max) en lugar de ntext o text, varbinary (max) en lugar de image?
fuente
Enfrenté un problema similar con una herramienta de terceros que también estaba usando un tipo de datos de imagen para almacenar datos no estructurados, y lo resolví convirtiendo la columna para usar filestream . Deberá realizar algunas pruebas para asegurarse de que la aplicación siga funcionando como espera, pero esto le dará la capacidad de escribir su propio proceso de archivo que mueva sus datos a un archivo db de manera eficiente.
fuente