Tabla truncada de 200 GB pero no se libera espacio en disco

Solo me quedan 2 GB, así que necesito eliminar esta tabla de historial. Esta tabla ahora está vacía pero no se libera el espacio en disco de la base de datos. Y el archivo de la base de datos es de 320 GB.

Si hace referencia al consumo real del archivo de base de datos en el volumen, entonces SQL Server no lo maneja automáticamente . El hecho de que haya eliminado datos de la base de datos no significa que los archivos de la base de datos se reducirán para adaptarse solo a los datos existentes.

Lo que estaría buscando, si tiene que reclamar espacio en el volumen, estaría reduciendo el archivo en particular DBCC SHRINKFILE. Vale la pena señalar algunas buenas prácticas, según esa documentación:

Mejores prácticas

Tenga en cuenta la siguiente información cuando planee reducir un archivo:

• Una operación de reducción es más efectiva después de una operación que crea mucho espacio no utilizado, como una tabla truncada o una operación de caída de tabla.

• La mayoría de las bases de datos requieren algo de espacio libre para estar disponibles para las operaciones diarias normales. Si reduce una base de datos repetidamente y observa que el tamaño de la base de datos vuelve a crecer, esto indica que el espacio que se redujo es necesario para las operaciones regulares. En estos casos, reducir la base de datos repetidamente es una operación desperdiciada.

• Una operación de reducción no conserva el estado de fragmentación de los índices en la base de datos y, en general, aumenta la fragmentación hasta cierto punto. Esta es otra razón para no reducir repetidamente la base de datos.

• Reduzca varios archivos en la misma base de datos secuencialmente en lugar de concurrentemente. La contención en las tablas del sistema puede causar demoras debido al bloqueo.

También de nota:

DBCC SHRINKFILE las operaciones se pueden detener en cualquier punto del proceso y cualquier trabajo completado se retiene.

Seguramente hay algunas cosas a considerar al hacer esto, y le recomiendo que eche un vistazo a la publicación del blog de Paul Randal sobre lo que sucede cuando realiza esta operación.

El primer paso definitivamente sería verificar cuánto espacio y espacio libre realmente puede reemplazar, así como el espacio utilizado en los archivos:

use AdventureWorks2012;
go

;with db_file_cte as
(
    select
        name,
        type_desc,
        physical_name,
        size_mb = 
            convert(decimal(11, 2), size * 8.0 / 1024),
        space_used_mb = 
            convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024)
    from sys.database_files
)
select
    name,
    type_desc,
    physical_name,
    size_mb,
    space_used_mb,
    space_used_percent = 
        case size_mb
            when 0 then 0
            else convert(decimal(5, 2), space_used_mb / size_mb * 100)
        end
from db_file_cte;

Este es un comportamiento normal cuando trunca la tabla y que implica la eliminación de más de 128 extensiones según los libros en línea

Cuando elimina o reconstruye índices grandes, o elimina o trunca tablas grandes, el Motor de base de datos difiere las asignaciones de página reales y sus bloqueos asociados, hasta después de que se confirma una transacción. Esta implementación admite transacciones automáticas y explícitas en un entorno multiusuario, y se aplica a tablas e índices grandes que usan más de 128 extensiones.

El motor de base de datos evita los bloqueos de asignación necesarios para soltar objetos grandes al dividir el proceso en dos fases separadas: lógica y física.

En la fase lógica, las unidades de asignación existentes utilizadas por la tabla o el índice se marcan para la desasignación y se bloquean hasta que se confirma la transacción. Con un índice agrupado que se descarta, las filas de datos se copian y luego se mueven a nuevas unidades de asignación creadas para el almacén, ya sea un índice agrupado reconstruido o un montón. (En el caso de una reconstrucción de índice, las filas de datos también se ordenan). Cuando hay una reversión, solo esta fase lógica debe revertirse.

La fase física ocurre después de que la transacción se confirma. Las unidades de asignación marcadas para desasignación se eliminan físicamente en lotes. Estas caídas se manejan dentro de transacciones cortas que ocurren en segundo plano y no requieren muchos bloqueos.

Debido a que la fase física ocurre después de que se confirma una transacción, el espacio de almacenamiento de la tabla o índice aún puede aparecer como no disponible. Si se requiere este espacio para que la base de datos crezca antes de que se complete la fase física, el Motor de base de datos intenta recuperar el espacio de las unidades de asignación marcadas para la desasignación. Para encontrar el espacio utilizado actualmente por estas unidades de asignación, use la vista de catálogo sys.allocation_units.

Las operaciones de caída diferida no liberan espacio asignado inmediatamente e introducen costos generales adicionales en el Motor de base de datos. Por lo tanto, las tablas e índices que usan 128 o menos extensiones se descartan, truncan y reconstruyen al igual que en SQL Server 2000. Esto significa que tanto la fase lógica como la física ocurren antes de que se confirme la transacción.

Tendría que esperar y, por supuesto, tendría que reducir manualmente el archivo para recuperar espacio. También vale la pena mencionar que la reducción causa fragmentación lógica y debe evitarse a menos que su necesidad sea grave. Tendría un poco de equilibrio entre la reducción y la fragmentación. Es mejor preguntarse si la reducción realmente resolvería el problema teniendo en cuenta el escenario en el que los datos volverán a crecer de todos modos.

Use la consulta a continuación para verificar cuánto espacio libre hay en la base de datos

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;

Además de las respuestas de Tom y Shanky, si su base de datos contiene datos LOB / BLOB, el DBCC SHRINKFILE puede no funcionar. Si ese es el caso, entonces tiene dos opciones, dependiendo de si puede desconectar la base de datos o no. Si puede desconectar la base de datos, deberá copiar los datos y volver a copiarlos para eliminar el espacio vacío. Puede lograr esto mediante uno de los siguientes:

1. Usar una instrucción SELECT INTO para transferir toda la tabla a una nueva tabla. Suelte la tabla original, ejecute DBCC SHRINKFILE . Cambie el nombre de la nueva tabla al nombre de la tabla original.
2. Usando bcp para copiar la tabla en modo nativo, suelte la tabla, ejecute DBCC SHRINKFILE , cree la tabla y luego bcp los datos en la tabla.
3. Usando Exportar / Importar para mover todos los datos a una nueva base de datos, descartar la base de datos existente, cambiar el nombre de la nueva base de datos al nombre de la base de datos original.

Si no puede desconectar la base de datos, puede usar el comando DBCC SHRINKFILE con la opción EMPTYFILE .

Detalles para la copia sin conexión: http://support.microsoft.com/kb/324432/en-us

Información actual para la opción EMPTYFILE http://msdn.microsoft.com/en-us/library/ms189493(v=sql.105).aspx