ARCHIVO DE REDUCCIÓN DE DBCC (Transact-SQL)

Se aplica a:SQL ServerAzure SQL DatabaseInstancia administrada de Azure SQLBase de datos SQL en Microsoft Fabric

Reduce el tamaño especificado de los datos o del archivo de registro de la base de datos actual. Puede usarlo para mover datos de un archivo a otros del mismo grupo, lo que vacía el archivo y permite la eliminación de su base de datos. Puede reducir un archivo a menos de su tamaño de creación y restablecer el tamaño mínimo de archivo al nuevo valor.

Úsalo DBCC SHRINKFILE solo cuando sea necesario porque la reducción es una operación de larga duración y que consume muchos recursos.

Convenciones de sintaxis de Transact-SQL

Sintaxis

DBCC SHRINKFILE
(
    { file_name | file_id }
    { [ , EMPTYFILE ]
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH
  {
      [ WAIT_AT_LOW_PRIORITY
        [ (
            <wait_at_low_priority_option_list>
        ) ]
      ]
      [ , NO_INFOMSGS ]
  }
]

<wait_at_low_priority_option_list> ::=
    <wait_at_low_priority_option>
    | <wait_at_low_priority_option_list> , <wait_at_low_priority_option>

<wait_at_low_priority_option> ::=
    ABORT_AFTER_WAIT = { SELF | BLOCKERS }

Argumentos

file_name

El nombre lógico del archivo es reducir.

file_id

El número de identificación (ID) del archivo debe reducirse. Para obtener un identificador de archivo, use la función del sistema FILE_IDEX o consulte la vista de catálogo sys.database_files en la base de datos actual.

target_size

Entero que representa el nuevo tamaño del archivo en megabytes. Si configuras target_size o 0 no lo especificas, DBCC SHRINKFILE reduces el archivo a su tamaño de creación.

Puede reducir el tamaño predeterminado de un archivo vacío mediante DBCC SHRINKFILE <target_size>. Por ejemplo, si crea un archivo de 5 MB y, a continuación, reduce el archivo a 3 MB mientras el archivo todavía está vacío, el tamaño de archivo predeterminado se establece en 3 MB. Esto solo se aplica para vaciar archivos que nunca han contenido datos.

Esta opción no se admite para los contenedores del grupo de archivos FILESTREAM.

Si se especifica, DBCC SHRINKFILE intenta reducir el archivo a target_size. Las páginas usadas en el área del archivo que se va a liberar se mueven al espacio disponible en las áreas conservadas del archivo. Por ejemplo, con un archivo de datos de 10 MB, una operación de DBCC SHRINKFILE con un 8target_size mueve todas las páginas usadas de los últimos 2 MB del archivo a las páginas sin asignar del primer archivo de 8 MB. DBCC SHRINKFILE no reduce un archivo más allá del tamaño necesario de los datos almacenados. Por ejemplo, si se usan 7 MB de un archivo de datos de 10 MB, una instrucción DBCC SHRINKFILE con un parámetro target_size de 6 reduce el archivo a 7 MB, no 6 MB.

Si especificas target_size con TRUNCATEONLY, DBCC SHRINKFILE puede que no libere espacio libre al final del archivo.

ARCHIVO VACÍO

Migra todos los datos del archivo especificado a otros archivos del mismo grupo de archivos. Es decir, EMPTYFILE migra los datos de un archivo especificado a otros archivos del mismo grupo de archivos. EMPTYFILE garantiza que no se agregan nuevos datos al archivo, a pesar de que este archivo no sea de solo lectura. Puedes usar la ALTER DATABASE sentencia para eliminar un archivo. Si usas la ALTER DATABASE instrucción para cambiar el tamaño del archivo, la bandera de solo lectura se reinicia y se pueden añadir datos.

Para los contenedores de grupo de archivos de FILESTREAM, no puede usar ALTER DATABASE para quitar un archivo hasta que el recolector de elementos no utilizados de FILESTREAM haya ejecutado y eliminado todos los grupos de archivos innecesarios que EMPTYFILE ha copiado a otro contenedor. Para más información, consulte sp_filestream_force_garbage_collection. Para información sobre cómo eliminar un contenedor FILESTREAM, consulte la sección correspondiente en ALTER DATABASE Opciones de Archivo y Grupo de Archivos

EMPTYFILEno está soportado en Azure SQL Database, Azure SQL Database Hyperscale ni SQL Database en Microsoft Fabric.

NOTRUNCATE

Mueve las páginas asignadas desde el final de un archivo de datos hasta las páginas sin asignar de la parte delantera del archivo con o sin la especificación de target_percent. El espacio disponible al final del archivo no se devuelve al sistema operativo y el tamaño físico del archivo no cambia. Por tanto, si se especifica NOTRUNCATE, parecerá que el archivo no se reduce.

NOTRUNCATE solo es aplicable a archivos de datos. No afecta a los archivos de registro.

Esta opción no se admite para los contenedores del grupo de archivos FILESTREAM.

TRUNCATESOLO

Libera al sistema operativo todo el espacio disponible al final del archivo, pero no realiza ningún movimiento de página dentro del archivo. El archivo de datos solo se reduce hasta el último tamaño asignado.

Si se especifica target_size con TRUNCATEONLY, es posible que no se libere espacio libre al final del archivo.

La TRUNCATEONLY opción no mueve la información del registro, pero sí elimina los archivos de registro virtual inactivos (VLFs) del final del archivo de registro. Esta opción no se admite para los contenedores del grupo de archivos FILESTREAM.

CON NO_INFOMSGS

Suprime todos los mensajes de información.

WAIT_AT_LOW_PRIORITY con operaciones de reducción

Aplica a: SQL Server 2022 (16.x) y versiones posteriores, Azure SQL Database, Azure SQL Managed Instance, base de datos SQL en Microsoft Fabric

La función de espera a baja prioridad reduce la contención de bloqueo durante la operación de reducción. Para más información, consulte Entendiendo los problemas de concurrencia con DBCC SHRINKFILE.

Esta característica es similar a WAIT_AT_LOW_PRIORITY con operaciones de índice en línea, con algunas diferencias.

• No puedes especificar la ABORT_AFTER_WAIT opción NONE.
• No puedes configurar la MAX_DURATION opción. El tiempo de espera de bloqueo de baja prioridad para una operación de reducción es siempre de un minuto.

WAIT_AT_LOW_PRIORITY

Cuando se ejecuta un comando de reducción en WAIT_AT_LOW_PRIORITY modo, las consultas que requieren bloqueos de estabilidad de esquema (Sch-S) en las páginas del Mapa de Asignación de Índices (IAM) no se bloquean con la operación de reducción. Sin embargo, la operación de reducción puede ser bloqueada por un Sch-S bloqueo en una página IAM. Shrink sigue ejecutándose solo cuando es capaz de obtener un bloqueo de modificación de esquema (Sch-M) en una página IAM que requiera.

Si una operación de reducción en WAIT_AT_LOW_PRIORITY modo no puede obtener este bloqueo debido a una consulta de larga duración que contiene un Sch-S bloqueo, la operación de reducción expira con el error 49516, por ejemplo: Msg 49516, Level 16, State 1, Line 134 Shrink timeout waiting to acquire schema modify lock in WLP mode to process IAM pageID 1:2865 on database ID 5.

{ ABORT_AFTER_WAIT = [ YO | BLOQUEADORES ] }

Se aplica a: SQL Server (SQL Server 2022 (16.x) y versiones posteriores), Azure SQL Database, base de datos SQL en Microsoft Fabric.

• SELF

  SELF es la opción predeterminada. Sal de la operación de reducción de archivos que se está ejecutando sin tomar ninguna acción adicional.

• BLOCKERS

  Elimina todas las transacciones de usuario que bloquean la operación de reducción de archivo, de forma que dicha operación pueda continuar. La BLOCKERS opción requiere que el inicio de sesión tenga el ALTER ANY CONNECTION permiso de o.KILL DATABASE CONNECTION

Conjunto de resultados

En la siguiente tabla se describen las columnas de conjunto de resultados.

Comentarios

DBCC SHRINKFILE se aplica a los archivos de la base de datos actual. Para más información sobre cómo modificar la base de datos actual, véase USE.

Puede detener las operaciones DBCC SHRINKFILE en cualquier momento sin que por ello se pierda el trabajo ya completado. Si usa el parámetro EMPTYFILE y cancela la operación, el archivo no se marca para evitar que se agreguen datos adicionales.

Otros usuarios pueden trabajar en la base de datos durante la reducción de archivos; la base de datos no tiene que estar en modo de usuario único. No es necesario ejecutar la instancia de SQL Server en modo de usuario único para reducir las bases de datos del sistema.

Problemas conocidos

Aplica a: SQL Server, Azure SQL Database, SQL Database en Microsoft Fabric, Azure SQL Managed Instance, Azure Synapse Analytics dedicado SQL pool

• En versiones SQL Server anteriores a SQL Server 2025 (17.x), las páginas utilizadas por los tipos de columna de objetos grandes (LOB) (varbinary(max), varchar(max) y nvarchar(max)) en segmentos comprimidos de columnstore no pueden moverse por DBCC SHRINKDATABASE y DBCC SHRINKFILE. Para obtener más información, consulte Novedades de los índices de almacén de columnas.

Descripción de los problemas de simultaneidad con DBCC SHRINKFILE

Los comandos de reducción de bases de datos y de reducción de archivos pueden provocar problemas de concurrencia, especialmente en el mantenimiento activo como la reconstrucción de índices, o en entornos de procesamiento de transacciones en línea (OLTP) muy concurridos.

Por ejemplo, una consulta de usuario puede adquirir un bloqueo de estabilidad de esquema (Sch-S) en una página de Mapa de Asignación de Índice (IAM) y mantenerlo hasta completarse. Al intentar recuperar espacio durante el uso habitual, las operaciones de reducción de base de datos y reducción de archivos requieren un bloqueo de modificación de esquema (Sch-M) al mover o eliminar páginas IAM, bloqueando los Sch-S bloqueos necesarios para las consultas del usuario. Como resultado, las consultas de larga duración pueden bloquear una operación de reducción. Esto también significa que cualquier nueva consulta que requiera un Sch-S bloqueo en una página IAM puede entrar en cola detrás de la operación de reducción, agravando aún más este problema de concurrencia.

Introducida en SQL Server 2022 (16.x), la función de espera a baja prioridad para operaciones de reducción aborda este problema al tomar el bloqueo de modificación de esquema en las páginas IAM en este WAIT_AT_LOW_PRIORITY modo. Para obtener más información, consulte WAIT_AT_LOW_PRIORITY con operaciones de reducción.

Para más información sobre Sch-S y Sch-M bloqueos, consulte la guía de bloqueo de transacciones y versionado de filas.

Reducción de un archivo de registro

En los archivos de registro, Motor de base de datos usa target_size para calcular el tamaño de destino completo del registro. Por lo tanto, target_size es el espacio disponible del registro después de la operación de reducción. El tamaño de destino completo del registro se convierte en el tamaño de destino de cada archivo de registro. DBCC SHRINKFILE intenta reducir cualquier archivo de registro físico a su tamaño final de forma inmediata. Sin embargo, si parte del registro lógico está en los registros virtuales más allá del tamaño final, el Motor de base de datos libera tanto espacio como sea posible y a continuación emite un mensaje informativo. El mensaje indica las acciones que se deben llevar a cabo para mover el registro lógico de los registros virtuales al final del archivo. Una vez realizadas estas acciones, se puede usar DBCC SHRINKFILE para liberar el espacio restante.

Como un archivo de registro solo puede reducirse hasta el límite de un archivo de registro virtual, puede que no sea posible reducirlo a un tamaño menor que el de un archivo de registro virtual, aunque no esté siendo utilizado. Motor de base de datos elige dinámicamente el tamaño del registro de archivo virtual cuando se crean o extienden los archivos de registro.

Procedimientos recomendados

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

• Una reducción es más efectiva después de una operación con la que se crea mucho espacio no utilizado, como por ejemplo, una operación para truncar o eliminar tablas.

• La mayoría de las bases de datos requieren que haya espacio disponible para realizar las operaciones diarias normales. Si reduce un archivo de base de datos de forma reiterada y advierte que su tamaño vuelve a aumentar, esto es señal de que el espacio disponible es necesario para las operaciones normales. En estos casos, reducir repetidamente el archivo de la base de datos es contraproducente. El crecimiento de archivos necesario para asignar nuevo espacio tras la reducción puede dificultar el rendimiento.

• Una operación de reducción no preserva el estado de fragmentación de los índices en la base de datos y puede aumentar la fragmentación del índice, lo que podría reducir el rendimiento de E/S de lectura para consultas que usan escaneos grandes.

• Si necesitas reducir los archivos de datos de una base de datos grande, considera usar el script ShrinkDriver PowerShell. El script automatiza y simplifica el proceso de reducción, convirtiéndolo en una única operación observable y reanudábel. El script reduce varios archivos en paralelo, lo intenta de nuevo cuando se interrumpe y genera informes de estado detallados mientras se ejecuta.

Solución de problemas

En esta sección se describe el modo de diagnosticar y corregir los problemas que pueden ocurrir al ejecutar el comando DBCC SHRINKFILE.

El archivo no se reduce.

Si el tamaño del archivo no cambia tras una operación de reducción sin errores, prueba los siguientes pasos para verificar que el archivo tiene suficiente espacio libre:

• Ejecute la siguiente consulta.

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

• Si quieres reducir el archivo del registro de transacciones, usa la vista de gestión dinámica de sys.dm_db_log_space_usage (DMV) para ver el espacio utilizado en el registro de transacciones.

La operación de reducción no puede reducir más el tamaño del archivo si no hay espacio libre suficiente.

Una razón común para que un archivo de registro de transacciones no se reduzca es la ausencia de copias de seguridad regulares de los registros de transacciones. Para truncar el registro, realice una copia de seguridad del registro de transacciones y vuelva a ejecutar la operación de DBCC SHRINKFILE. Si no es necesario recuperar en un momento en el tiempo, considera los modelos de recuperación (SQL Server) para evitar el crecimiento de archivos de registro.

La operación de reducción está bloqueada

Una transacción que se ejecuta con un nivel de aislamiento basado en las versiones de fila puede bloquear las operaciones de reducción. Por ejemplo, si se está ejecutando una operación de eliminación grande con un nivel de aislamiento basado en versiones de fila cuando se ejecuta una operación DBCC SHRINKDATABASE, la operación de reducción espera a que la operación de eliminación finalice antes de continuar. Cuando ocurre este bloqueo, las operaciones DBCC SHRINKFILE y DBCC SHRINKDATABASE imprimen un mensaje informativo (5202 para SHRINKDATABASE y 5203 para SHRINKFILE) en el registro de errores de SQL Server. Este mensaje se registra cada cinco minutos durante la primera hora y luego cada hora. Por ejemplo:

DBCC SHRINKFILE for file ID 1 is waiting for the snapshot
transaction with timestamp 15 and other snapshot transactions linked to
timestamp 15 or with timestamps older than 109 to finish.

Este mensaje significa que las transacciones de instantáneas con marcas de tiempo anteriores a 109 (la última transacción que realizó la operación de reducción) están bloqueando la operación de reducción. También indica que las columnas transaction_sequence_num o first_snapshot_sequence_num de la vista de administración dinámica sys.dm_tran_active_snapshot_database_transactions contienen el valor 15. Si las columnas de vista transaction_sequence_num o first_snapshot_sequence_num contienen un número inferior al de la última transacción realizada mediante una operación de reducción (109), la operación de reducción espera a que esas transacciones finalicen.

Para resolver el problema, realiza uno de los siguientes pasos:

• Finalizar la transacción que bloquea la operación de reducción
• Finalizar la operación de reducción Si finaliza la operación de reducción, se mantiene todo el trabajo completado.
• No hacer nada y permitir que la operación de reducción espere a que finalice la transacción que la está bloqueando.

Permisos

Debe pertenecer al rol fijo de servidor sysadmin o al rol fijo de base de datos db_owner .

Ejemplos

Los ejemplos de código de este artículo usan la base de datos de ejemplo de AdventureWorks2025 o AdventureWorksDW2025, que puede descargar de la página principal de Ejemplos de Microsoft SQL Server y proyectos de comunidad.

Un. Reducir un archivo de datos a un tamaño final especificado

En el siguiente ejemplo se reduce el tamaño de un archivo de datos denominado DataFile1 de la base de datos de usuario UserDB a 7 MB.

USE UserDB;
GO

DBCC SHRINKFILE (DataFile1, 7);
GO

B. Reducir un archivo de registro a un tamaño final especificado

En el ejemplo siguiente se reduce el archivo de registro de la base de datos AdventureWorks2025 a 1 MB. Para permitir que el DBCC SHRINKFILE comando reduzca el archivo, primero se trunca el archivo estableciendo el modelo de recuperación de la base de datos a SIMPLE.

USE AdventureWorks2025;
GO

-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY SIMPLE;
GO

-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2025_Log, 1);
GO

-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2025
    SET RECOVERY FULL;
GO

C. Truncar un archivo de datos

En el ejemplo siguiente se trunca el archivo de datos principal en la base de datos AdventureWorks2025. Se consulta la vista de catálogo sys.database_files para obtener el valor de file_id del archivo de datos.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (1, TRUNCATEONLY);

D. Vaciado de un archivo

En el ejemplo siguiente se ilustra cómo vaciar un archivo de forma que se pueda quitar de la base de datos. Para los fines de este ejemplo, primero se crea un archivo de datos que contiene datos.

USE AdventureWorks2025;
GO

-- Create a data file and assume it contains data.
ALTER DATABASE AdventureWorks2025
    ADD FILE (NAME = Test1data, FILENAME = 'C:\t1data.ndf', SIZE = 5 MB);
GO

-- Empty the data file.
DBCC SHRINKFILE (Test1data, EMPTYFILE);
GO

-- Remove the data file from the database.
ALTER DATABASE AdventureWorks2025
     REMOVE FILE Test1data;
GO

E. Reducir un archivo de base de datos con WAIT_AT_LOW_PRIORITY

En el siguiente ejemplo se intenta reducir el tamaño de un archivo de datos en la base de datos de usuario actual a 1 MB. Se consulta la vista de catálogo sys.database_files para obtener el valor de file_id del archivo de datos, que en este ejemplo es file_id 5. Si no se puede obtener un bloqueo en un minuto, se anula la operación de reducción.

USE AdventureWorks2025;
GO

SELECT file_id,
       name
FROM sys.database_files;
GO

DBCC SHRINKFILE (5, 1) WITH WAIT_AT_LOW_PRIORITY (ABORT_AFTER_WAIT = SELF);

Contenido relacionado

• Reducción de una base de datos
• Reducción de un archivo
• DBCC SHRINKDATABASE (Transact-SQL) // Comando para reducir el tamaño de la base de datos
• Consideraciones sobre la configuración del crecimiento automático y de la reducción automática en SQL Server
• Archivos de base de datos y grupos de archivos
• sys.database_files (Transact-SQL)
• sys.databases (Transact-SQL)
• FILE_ID (Transact-SQL)
• ALTER DATABASE (Transact-SQL)
• Administración del espacio de archivo para bases de datos en Azure SQL Database