No dejes de divulgar nuestra web y códigos con otro, danos de tu ayuda para ampliar esta comunidad.
Solución:
TRUNCATEONLY afecta tanto a los archivos de REGISTRO como a los de DATOS en 2008. En BOL para SQL Server 2012, el mensaje simplemente indica que si solo desea REDUCIR el archivo de la base de datos, debe usar DBCC SHRINKFILE, que le permitirá reducir los datos o el registro. archivos
Para 2008, se indica claramente que TRUNCATEONLY solo afecta a los archivos de DATOS.
Vamos a probar. Para visualizar lo que sucede usando TRUNCATEONLY
con SHRINKDATABASE
aquí hay un resumen de lo que le sucedió a una base de datos llamada performance
que he instalado localmente.
SELECT @@VERSION;
Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64)
Jun 28 2012 08:36:30
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
USE performance;
corrí DBCC LOGINFO
solo para echar un vistazo dentro del registro de transacciones y descubrí que todos los archivos de registro virtuales después de aproximadamente 200 estaban inactivos, estado = 0. En mi base de datos de rendimiento, todos esos VLF inactivos se pueden truncar y el espacio se puede devolver al sistema operativo .
Aquí hay algunos resultados de muestra de LOGINFO.
FileId FileSize StartOffset FSeqNo Status Parity CreateLSN
------ -------- ----------- ------ ------ ------ -----------------
2 253952 8192 23 2 64 0
2 253952 262144 24 2 64 0
2 270336 516096 25 2 64 24000000013400005
luego corrí DBCC SQLPERF(LOGSPACE)
y obtuve el siguiente resultado
DBCC SQLPERF(LOGSPACE)
/*
Database Name Log Size (MB) Log Space Used (%) Status
Performance 9870,867 3,395626 0
*/
luego corrí
DBCC SHRINKDATABASE(PERFORMANCE, truncateonly)
y obtuve el siguiente resultado
/*
DbId FileId CurrentSize MinimumSize UsedPages EstimatedPages
8 1 66464 288 44944 44944
8 2 116584 72 116584 72
*/
A continuación, volví a ejecutar
DBCC SQLPERF(LOGSPACE)
y consiguió
/*
Database Name Log Size (MB) Log Space Used (%) Status
Performance 910,8047 37,08699 0
*/
SHRINKDATABASE
con TRUNCATEONLY
devolvió 9GB del espacio disponible del archivo de registro de transacciones al sistema operativo.
Intenté el mismo experimento con otra base de datos llamada performance2
sp_spaceused
/*
Performance2 52.19 MB 22.81 MB
*/
DBCC SHRINKDATABASE(Performance2, truncateonly)
sp_spaceused
/*
database_name database_size unallocated space
Performance2 31.13 MB 21.13 MB
*/
que devolvió 20 MB al sistema operativo. Utilizando SQL Server 2008, SHRINKDATABASE TRUNCATEONLY
reduce los datos y los archivos de registro de transacciones.
Acabo de probar con una base de datos temporal y, al usar la opción TRUNCATEONLY, se redujeron tanto el archivo de datos como el archivo de registro.
Creo que lo que están tratando de aclarar es que la opción TRUNCATEONLY cambia el comportamiento al reducir el archivo de datos (es decir, no reorganizar las páginas de datos, simplemente cortar el espacio no utilizado al final), pero el archivo de registro seguirá siendo encogido normalmente.
Si mi comprensión de la opción es correcta, probablemente esta sea una mejor manera de describirla:
El archivo de registro aún se reducirá normalmente al usar la opción TRUNCATEONLY. Esta opción solo afecta el comportamiento al reducir los archivos de datos. Para truncar solo el archivo de datos, use DBCC SHRINKFILE.
Comentarios y calificaciones
Nos encantaría que puedieras dar recomendación a esta crónica si te valió la pena.