Reducir una base de datos por debajo de su tamaño inicial

Tengo una base de datos de desarrollo de SQL Server 2005 que es una copia de 30GB en vivo. Hemos eliminado algunos datos que no son necesarios en dev, lo que reduce el espacio de archivos de datos utilizado a 20 GB. Entonces tenemos alrededor del 33% sin usar.

Necesito recuperar el espacio, lo que nos permitirá tener un segundo dev DB en el servidor (basado en la versión reducida); Sin embargo, no puedo reclamar el espacio, he hecho lo siguiente:

• El tamaño inicial del archivo SMS2_Dataes de 30 GB.

  DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY)

  seguido por

  DBCC SHRINKFILE (N'SMS2_Data' , 19500)

Sin alegría. He intentado hacer una copia de seguridad, creando una nueva base de datos con un tamaño inicial bajo y luego restaurando, no me alegro, ya que el tamaño inicial se sobrescribe. También he intentado:

ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 

Esto erró, diciendo:

MODIFICAR ARCHIVO falló. El tamaño especificado es menor que el tamaño actual.

Intenté 20800 y luego seguí subiendo hasta 29000 (29GB) y todavía no me deja cambiarlo.

Han hecho la contracción y luego cambió el modo de recuperación a partir FULLde SIMPLEy viceversa. Sin alegría.

Pensé que tenía que ver con algunos TEXTcampos. Tenemos alrededor de 6 en todo el sistema. Entonces, como prueba, los descarté todos y luego reduje el archivo y aún no cambié.

La única opción que queda es reimportar los datos a otra base de datos. Esto no es práctico, ya que tendría que hacerse en la base de datos en vivo, lo que conlleva demasiado riesgo. Tomamos regularmente una copia de la base de datos en vivo y sobrescribimos dev / test. Tenemos algo así como 500 mesas. Me gustaría una forma de hacerlo que no tuviera el riesgo de exportar datos a una nueva base de datos.

Intenté mover los datos a otro archivo, y copió todos menos el 5% de los datos. Esto es lo que me llevó a intentar soltar todas las columnas de texto.

El servidor está en modo de compatibilidad 90, pero es SP2. Ahora he hecho lo siguiente 3 veces: reindexar todas las tablas, base de datos de copia de seguridad, reducir el archivo, reducir la base de datos. Aún no hay alegría.

EXECUTE sp_spaceused devoluciones:

database_name   database_size   unallocated space
SMS2Tests       31453.94 MB     13903.16 MB

reserved     data         index_size   unused
16545568 KB  10602264 KB  4254360 KB   1688944 KB

Como algunas personas ya mencionaron, podría crear una nueva base de datos y "copiar" cosas de la base de datos anterior. Esta sería la mejor opción para ti. Sin embargo, he notado que quieres hacerlo con bastante frecuencia. Entonces, su mejor opción es Redgate Data Compare y Redgate Compare . Ambos son parte del paquete Redgate SqlToolbelt .

Entonces, que haces:

1. Cree una base de datos vacía con un tamaño inicial pequeño.
2. Use Redgate Compare para copiar la estructura de db, funciones, etc. de la antigua db
3. Use Redgate Data Compare para copiar datos de la base de datos anterior a la nueva
4. Trabaja en la base de datos de desarrollo y luego, en cualquier momento, solo compara datos y actualiza la base de datos de desarrollo regularmente, o si realiza algún cambio en db, puede implementar esos cambios utilizando Redgate Compare y luego haciendo Redgate Data Compare.

Lo que es bueno con Data Compare es que después de copiar esos 30 gb de datos (puede hacerlo comenzando solo con algunas tablas) después de un tiempo solo necesita 'recomparar' solo algunos cambios y no 30 gb completos de datos. Lo que significa que tendrá un impacto mucho menor en ambas bases de datos que si lo copiara normalmente.

Algunas posibilidades aquí.

En primer lugar, ¿estás en SQL 2005 SP3 o posterior? Algunos informaron problemas de SHRINKFILE en versiones anteriores (consulte http://www.sqlservercentral.com/Forums/Topic981292-146-6.aspx#bm985164 )

En segundo lugar, ¿puede verificar que la base de datos esté configurada en modo 90 y no en modo 80? Aparentemente, esto fue un problema con SQL 2000, pero la restricción se levantó en SQL 2005. Si su base de datos todavía está configurada en compatibilidad con el modo 80, esto podría ser un problema.

En tercer lugar, esto podría ser un problema con los datos LOB (text, ntext, varchar (max)). Vea el excelente artículo de Paul Randall aquí

Supongo que entiendes lo que SHRINKing realmente hace y que puede afectar negativamente tu rendimiento:

• SHRINK funciona moviendo páginas a ciegas desde el final del archivo hasta el principio
• Como tal, puede fragmentar horriblemente los índices, lo que puede causar problemas de rendimiento significativos
• Debido a que es una operación tan intensiva en datos, la reducción podría tomar un tiempo considerable

Normalmente recomendaría seguir el encogimiento con una reindexación completa (que recuperará parte del espacio que se acaba de liberar), pero no parece que puedas llegar a ese punto.

Si observa su SPID retráctil en el monitor de actividad, ¿parece estar haciendo algo? (Los contadores de E / S y CPU cambian) ¿O está bloqueado? Lo único que puedo pensar es si hay otra actividad en la base de datos, bloqueando la reducción. Asegúrese de que ningún otro spids activo esté haciendo uso de la base de datos en ese momento.

Cambiar al modo de recuperación simple durante este proceso también es una buena idea, para evitar que el registro crezca demasiado.

SHRINKDATABASE solo reducirá la base de datos (en el mejor de los casos) a su tamaño mínimo, por lo que eso no lo ayudará.

Cuando intenta reducir el ARCHIVO a través de la interfaz de usuario de SSMS utilizando los valores predeterminados, usa 'DBCC SHRINKFILE (N'MyDB', 0, TRUNCATEONLY) '. Ese comando solo reducirá el archivo (en el mejor de los casos) a la última extensión asignada.

Si desea reducir el archivo debajo de MinSize, simplemente cambie el parámetro DBCC SHRINKFILEde 0 al tamaño en el que desea intentar reducir el archivo en MB. Un número distinto de cero le indicará a SHRINKFILE que reduzca el archivo a ese tamaño si es posible. Por DBCC SHRINKFILE('MyDB', 300, TRUNCATEONLY)lo tanto , reducirá el archivo a 300 MB si la base de datos tiene espacio.

Puede ver MinSize ejecutando esto:

DBCC TRACEON(3604)
go
DBCC PAGE('MyDB', 1, 0, 3) with tableresults
go

MinSize en MB se calcula de esta manera: (MinSize * 8) / 1024

Si realmente quieres hacer esto:

• configurado para recuperar el modo simple
• ser consciente de: DBCC SHRINKDATABASE (MyDatabase, TRUNCATEONLY);

Si tiene, digamos, 20003 (mb) de datos reales en la base de datos, entonces "TAMAÑO = 20000" sería demasiado pequeño. Pruebe con 21000 o 25000, vea si eso funciona. (Y recuerde, 1 GB = 1024 MB).

Tratar

DBCC SHRINKDATABASE (N'SMS2_Data' , 0)

Utilicé esto en una base de datos SQL 2005 que tengo aquí y el espacio asignado para el archivo de datos pasó de 10.2 GB a 3 GB.

Fyi, este es un proceso largo, y me tomó un poco más de 19 minutos para mi base de datos.

Supongo que tiene un único archivo de base de datos con el nombre lógico SMS2_Data. También tiene uno o más archivos de registro de transacciones en la base de datos.

Tiene un desafío que no se puede solucionar en la copia actual de la base de datos. La información importante que declara es que el "tamaño original del archivo de base de datos es de 30 GB". Desafortunadamente, este archivo no se puede reducir más pequeño que su tamaño original.

Como ya has experimentado, SHRINKDB y SHRINKFILE no te están dando lo que quieres. Estos comandos siguen la regla no puede reducirse más pequeña que el tamaño original. Por lo tanto, solo puede reducir una base de datos al tamaño original y no más pequeña.

La copia de seguridad y restauración de la base de datos a una base de datos más pequeña existente tampoco funciona. Cuando realiza una restauración de la base de datos, los archivos de la base de datos se restauran a los tamaños de archivo tal como estaban durante la copia de seguridad. Y, el modelo de recuperación (simple, completo, etc.) no tiene relevancia para este problema.

Y, un último punto de malas noticias. Puede considerar agregar otros archivos de base de datos más pequeños a la base de datos, transferir todos los datos del archivo de 30 GB y luego soltarlo. Desafortunadamente, esto tampoco funcionará porque no puede eliminar el archivo inicial de la base de datos.

Entonces, la mejor solución es copiar los datos a otra base de datos. Tienes algunas opciones aquí, y quizás ya las conozcas. El primer paso es crear una nueva base de datos con un tamaño que sea menor que el tamaño de los datos. Luego, puede expandir el tamaño de la base de datos al tamaño requerido.

Puede considerar SSIS como una forma de transferir los datos de una base de datos a la otra. Encontrará una tarea de copia de la base de datos que lo ayudará. Puedes seguir los siguientes pasos:

1. Cree una nueva base de datos con un tamaño menor que la base de datos de origen
2. Configure el paquete SSIS con la tarea de transferencia de la base de datos. Establezca la tarea para usar la transferencia en línea.
3. Ejecute el paquete SSIS.
4. El paquete SSIS puede alterar el tamaño de la base de datos para que coincida con el tamaño de la base de datos de origen. Reduzca esta base de datos porque tiene un tamaño de archivo original más pequeño.

Consulte información adicional sobre la tarea de la base de datos de transferencia de SSIS .

Algún espacio no utilizado en la base de datos es normal.
Si tiene muchos registros grandes (por ejemplo, cadenas largas), podría haber mucho espacio sin usar en las páginas de datos (porque un registro generalmente no se divide entre páginas).
Otra cosa es un factor de relleno: inicialmente, los índices agrupados no se crean 100% completos para evitar divisiones de página (una operación costosa) en inserciones posteriores.
Si se eliminaron muchos datos de la base de datos, el espacio previamente ocupado por estos datos no se recuperará automáticamente, permanecerá asignado a la tabla.

Intente llamar DBCC DBREINDEX (table_name, '', 100)a todas las tablas de su base de datos: reconstruirá todos los índices con un factor de relleno del 100%, de modo que los datos se coloquen de la manera más compacta posible. Luego intente reducir la base de datos nuevamente.

Descubrí que reducir una base de datos de SQL Server puede ser problemático. Parece que tienes que hacer una canción y una rutina de baile.

Este es el proceso por el que generalmente paso:

Base de datos de Backup Shrink El registro de Backup Shrink y los archivos de base de datos por separado. Copia de seguridad Repita hasta que finalmente se encoja.

He tenido que hacer este proceso algunas veces hasta tres veces para que finalmente funcione. Hemos tenido una base de datos de más de 68 GB de tamaño, con algo del 98% de espacio no utilizado. Pasé por esta rutina de canto y baile varias veces, pero finalmente se redujo a menos de 1 GB.

Hubiera intentado reducir el tamaño inicial del archivo mdf a 29 000 MB primero, luego a 28, 000 detectando el golpe cercano.

No es razonable esperar reducir el 30% en el tamaño del archivo de la base de datos al eliminar el 30% de los datos.

Puede estimar cuánto espacio no utilizado en su base de datos por

execute sp_spaceused

en el contexto de su base de datos (use yourdatabaename;)
¿Puede publicar el resultado de su ejecución?

Actualización:
publiqué mi pregunta relacionada:

• compresión, desfragmentación, recuperación de espacio, reducción de la base de datos versus archivo de reducción