DBCC SHRINKDATABASE (Transact-SQL)

• 07/17/2017
• 8 minutos para leer
• • p
  • M
  • j
  • i
  • K
  • +12

Se aplica a: SQL Server (todas las versiones compatibles) Azure SQL Database Azure Synapse Analytics

Reduce el tamaño de los archivos de datos y de registro en la base de datos especificada.

Convenciones de sintaxis de Transact-SQL

Sintaxis

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Argumentos

nombre_de_la_base_de_datos | 0
Es el nombre o el ID de la base de datos que se va a reducir. 0 especifica que se utiliza la base de datos actual.

porcentaje_objetivo
Es el porcentaje de espacio libre que se quiere dejar en el archivo de la base de datos después de que se haya encogido la base de datos.

NOTRUNCATE
Mueve las páginas asignadas del final del archivo a páginas no asignadas en la parte delantera del archivo. Esta acción compacta los datos dentro del archivo. target_percent es opcional. Azure Synapse Analytics no admite esta opción.

El espacio libre al final del archivo no se devuelve al sistema operativo y el tamaño físico del archivo no cambia. Por lo tanto, la base de datos parece no reducirse cuando se especifica NOTRUNCATE.

NOTRUNCATE se aplica sólo a los archivos de datos. NOTRUNCATE no afecta al archivo de registro.

TRUNCATEONLY
Libera todo el espacio libre al final del archivo al sistema operativo. No mueve ninguna página dentro del archivo. El archivo de datos se reduce sólo hasta la última extensión asignada. Ignora target_percent si se especifica con TRUNCATEONLY. Azure Synapse Analytics no admite esta opción.

TRUNCATEONLY afecta al archivo de registro. Para truncar sólo el archivo de datos, utilice DBCC SHRINKFILE.

WITH NO_INFOMSGS
Suprime todos los mensajes informativos que tienen niveles de gravedad de 0 a 10.

Conjuntos de resultados

La siguiente tabla describe las columnas del conjunto de resultados.

Nombre de columna	Descripción
DbId	Número de identificación de la base de datos del archivo que el motor de base de datos intentó reducir.
FileId	Número de identificación del archivo que el motor de la base de datos intentó reducir.
CurrentSize	Número de páginas de 8-KB que ocupa actualmente el archivo.
MinimumSize	Número de páginas de 8-KB que podría ocupar el archivo, como mínimo. Este valor corresponde al tamaño mínimo o al tamaño originalmente creado de un archivo.
PáginasUsadas	Número de páginas de 8-KB utilizadas actualmente por el archivo.
PáginasEstimadas	Número de páginas de 8-KB a las que el Motor de Base de Datos estima que podría reducirse el archivo.

Observaciones

Para reducir todos los datos y archivos de registro de una base de datos específica, ejecute el comando DBCC SHRINKDATABASE. Para reducir un archivo de datos o de registro a la vez para una base de datos específica, ejecute el comando DBCC SHRINKFILE.

Para ver la cantidad actual de espacio libre (no asignado) en la base de datos, ejecute sp_spaceused.

Las operaciones de DBCC SHRINKDATABASE pueden detenerse en cualquier punto del proceso, y cualquier trabajo completado se conserva.

La base de datos no puede ser más pequeña que el tamaño mínimo configurado de la base de datos. Se especifica el tamaño mínimo cuando se crea originalmente la base de datos. O bien, el tamaño mínimo puede ser el último tamaño configurado explícitamente mediante una operación de cambio de tamaño de archivo. Operaciones como DBCC SHRINKFILE o ALTER DATABASE son ejemplos de operaciones de cambio de tamaño de archivo.

Digamos que una base de datos se crea originalmente con un tamaño de 10 MB. Luego, crece a 100 MB. Lo mínimo a lo que se puede reducir la base de datos es a 10 MB, aunque se hayan eliminado todos los datos de la base.

Especifique la opción NOTRUNCATE o la opción TRUNCATEONLY cuando ejecute DBCC SHRINKDATABASE. Si no lo hace, el resultado es el mismo que si ejecuta una operación DBCC SHRINKDATABASE con NOTRUNCATE seguida de la ejecución de una operación DBCC SHRINKDATABASE con TRUNCATEONLY.

La base de datos reducida no tiene que estar en modo de usuario único. Otros usuarios pueden estar trabajando en la base de datos cuando se encoge, incluyendo las bases de datos del sistema.

No se puede encoger una base de datos mientras se hace una copia de seguridad de la misma. A la inversa, no se puede hacer una copia de seguridad de una base de datos mientras se está realizando una operación de reducción de la base de datos.

Cómo funciona DBCC SHRINKDATABASE

DBCC SHRINKDATABASE reduce los archivos de datos por archivo, pero reduce los archivos de registro como si todos los archivos de registro existieran en un grupo de registro contiguo. Los archivos siempre se encogen desde el final.

Suponga que tiene un par de archivos de registro, un archivo de datos y una base de datos llamada mydb. Los archivos de datos y de registro tienen 10 MB cada uno y el archivo de datos contiene 6 MB de datos. El motor de la base de datos calcula un tamaño objetivo para cada archivo. Este valor es el tamaño al que debe reducirse el archivo. Cuando se especifica DBCC SHRINKDATABASE con target_percent, el Motor de Base de Datos calcula que el tamaño objetivo es la cantidad de target_percent de espacio libre en el archivo después de la contracción.

Por ejemplo, si se especifica un target_percent de 25 para la contracción de mydb, el Motor de Base de Datos calcula que el tamaño objetivo para el archivo de datos es de 8 MB (6 MB de datos más 2 MB de espacio libre). Como tal, el Motor de Base de Datos mueve cualquier dato de los últimos 2 MB del archivo de datos a cualquier espacio libre en los primeros 8 MB del archivo de datos y luego encoge el archivo.

Suponga que el archivo de datos de mydb contiene 7 MB de datos. Especificar un target_percent de 30 permite que este archivo de datos se reduzca al porcentaje libre de 30. Sin embargo, si se especifica un target_percent de 40 no se encoge el archivo de datos porque el Motor de Base de Datos no encogerá un archivo a un tamaño menor que el que ocupan los datos actualmente.

También se puede pensar en esta cuestión de otra manera: El 40 por ciento de espacio libre deseado + el 70 por ciento de archivo de datos lleno (7 MB de 10 MB) es más del 100 por ciento. Cualquier target_size mayor que 30 no reducirá el archivo de datos. No se reducirá porque el porcentaje libre que desea más el porcentaje actual que ocupa el archivo de datos es superior al 100 por ciento.

Para los archivos de registro, el motor de la base de datos utiliza target_percent para calcular el tamaño objetivo para todo el registro. Por eso target_percent es la cantidad de espacio libre en el registro después de la operación de contracción. El tamaño objetivo para todo el registro se traduce entonces en un tamaño objetivo para cada archivo de registro.

DBCC SHRINKDATABASE intenta reducir cada archivo de registro físico a su tamaño objetivo inmediatamente. Digamos que ninguna parte del registro lógico permanece en los registros virtuales más allá del tamaño objetivo del archivo de registro. Entonces el archivo se trunca con éxito y DBCC SHRINKDATABASE termina sin ningún mensaje. Sin embargo, si parte del registro lógico permanece en los registros virtuales más allá del tamaño objetivo, el motor de la base de datos libera todo el espacio posible y, a continuación, emite un mensaje informativo. El mensaje describe las acciones necesarias para mover el registro lógico fuera de los registros virtuales al final del archivo. Una vez ejecutadas las acciones, se puede utilizar DBCC SHRINKDATABASE para liberar el espacio restante.

Un archivo de registro sólo puede reducirse hasta el límite de un archivo de registro virtual. Por eso, reducir un archivo de registro a un tamaño menor que el de un archivo de registro virtual podría no ser posible. Puede que no sea posible incluso si no se está utilizando. El tamaño del archivo de registro virtual es elegido dinámicamente por el motor de la base de datos cuando se crean o amplían los archivos de registro.

Mejores prácticas

Considere la siguiente información cuando planee reducir una base de datos:

• Una operación de reducción es más eficaz después de una operación que crea espacio no utilizado, como una operación de truncamiento de tabla o de eliminación de tabla.
• La mayoría de las bases de datos requieren algo de espacio libre para estar disponibles para las operaciones regulares del día a día. Es posible que reduzca una base de datos repetidamente y observe que el tamaño de la base de datos vuelve a crecer. Este crecimiento indica que el espacio reducido es necesario para las operaciones regulares. En estos casos, encoger la base de datos repetidamente es una operación desperdiciada.
• Una operación de encogimiento no preserva el estado de fragmentación de los índices en la base de datos, y generalmente aumenta la fragmentación en cierto grado. Este resultado es otra razón para no reducir repetidamente la base de datos.
• A menos que tenga un requisito específico, no establezca la opción de base de datos AUTO_SHRINK en ON.

Solución de problemas

Es posible bloquear las operaciones de reducción por una transacción que se está ejecutando bajo un nivel de aislamiento basado en versiones de filas. Por ejemplo, una operación de eliminación grande que se ejecuta bajo un nivel de aislamiento basado en versiones de filas está en progreso cuando se ejecuta una operación DBCC SHRINK DATABASE. Cuando se produce esta situación, la operación de reducción esperará a que se complete la operación de eliminación antes de reducir los archivos. Cuando la operación de reducción espera, las operaciones DBCC SHRINKFILE y DBCC SHRINKDATABASE imprimen un mensaje informativo (5202 para SHRINKDATABASE y 5203 para SHRINKFILE). Este mensaje se imprime en el registro de errores de SQL Server cada cinco minutos en la primera hora y luego cada hora siguiente. Por ejemplo, si el registro de errores contiene el siguiente mensaje de error:

DBCC SHRINKDATABASE for database ID 9 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 error significa que las transacciones de instantáneas que tienen marcas de tiempo anteriores a 109 bloquearán la operación de reducción. Esa transacción es la última transacción que completó la operación de contracción. También indica que las columnas transaction_sequence_num o first_snapshot_sequence_num en la vista de gestión dinámica sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) contienen un valor de 15. La columna transaction_sequence_num o first_snapshot_sequence_num de la vista puede contener un número menor que la última transacción completada por una operación de reducción (109). Si es así, la operación de reducción esperará a que terminen esas transacciones.

Para resolver el problema, puede realizar una de las siguientes tareas:

• Finalice la transacción que está bloqueando la operación de reducción.
• Finalice la operación de reducción. Cualquier trabajo completado se mantiene.
• No hacer nada y permitir que la operación de encogimiento espere hasta que la transacción de bloqueo se complete.

Permisos

Requiere ser miembro del rol fijo de servidor sysadmin o del rol fijo de base de datos db_owner.

Ejemplos

A. Reducir una base de datos y especificar un porcentaje de espacio libre

El siguiente ejemplo reduce el tamaño de los archivos de datos y de registro en la base de datos del usuario UserDB para permitir un 10 por ciento de espacio libre en la base de datos.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Truncar una base de datos

El siguiente ejemplo reduce los archivos de datos y de registro en la base de datos de ejemplo AdventureWorks hasta la última extensión asignada.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Reducir una base de datos de Azure Synapse Analytics

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

Ver también

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Reducir una base de datos