Este post ha sido analizado por nuestros expertos para que tengas la garantía de la veracidad de nuestra esta división.
Solución:
Si bien la reducción es peligrosa por las razones mencionadas aquí. Hay un término medio entre la respuesta de Jimbo y la respuesta de John… Siempre debe considerar seriamente si desea o no reducir su base de datos.
En un mundo ideal, crearía su base de datos con mucho espacio libre para crecer. A esto lo llamo “dimensionamiento correcto” de su base de datos. Permitiría que este espacio libre estuviera allí y no se esforzara por devolverlo y mantendría su tamaño total justo en su tamaño usado. ¿Por qué? Porque su base de datos eventualmente volverá a crecer… Luego se reducirá de nuevo… Y estará atrapado en este horrible patrón de inútiles disminuciones seguidas de crecimientos – y todo el tiempo, como algunos han señalado, estará aumentando la fragmentación de su índice.
Escribí en un blog sobre esto en el que amonesté a la gente a “¡No toques ese botón de encogimiento!” pero a veces… A veces es necesario. Si tiene una base de datos grande, acaba de liberar un espacio significativo y no espera volver a crecer en ella nunca; bueno, entonces está bien considerar la reducción como una operación de una sola vez, siempre que pueda ocuparse de la fragmentación de su índice después mediante la reconstrucción. a ellos. La operación de reducción puede llevar mucho tiempo, por lo que querrá planificarla para un momento en el que pueda pagar el precio de una ejecución de reducción. El enfoque de crear una base de datos vacía y copiar datos en ella funciona, pero eso puede volverse muy difícil con bases de datos más grandes y una gran cantidad de datos.
Si planea volver a agregar ese espacio a la base de datos a través del uso normal y los patrones de crecimiento en el futuro, es posible que desee dejar el espacio allí.
También
Dijiste que “borraste” tu registro de transacciones. Tendría curiosidad por saber cómo hiciste esto, pero a medida que leas la publicación que compartí y las otras de la serie, verás algunos consejos sobre la administración del registro de transacciones. Pero, en resumen, si se encuentra en el modo de recuperación completa, debe realizar copias de seguridad periódicas del registro para que el registro se reutilice. De lo contrario, sin copias de seguridad de registro mientras está en modo completo, el archivo de registro sigue creciendo y creciendo y siempre guarda lo que ha hecho porque le dijo a SQL que no solo desea mantener ese registro para la recuperación de fallas, sino que desea mantener un copia de seguridad manual para reproducir transacciones/deshacer transacciones para recuperar a un punto específico en el tiempo con fines de recuperación… Si está en simple y ve que el registro crece excesivamente, esto puede ser una señal (típicamente) de que está haciendo MUCHO de trabajo en una transacción (ya sea que haya dicho BEGIN TRAN ... do work.... COMMIT TRAN o si acaba de emitir una gran DELETE declaración y eliminó un montón de datos en una transacción implícita).
También asumo que está buscando este espacio libre en su sistema de archivos. Si lo está buscando dentro de SQL y dentro de ese archivo grande que tiene, podría ser que esté esperando que se complete la limpieza fantasma si busca inmediatamente después de su operación. Paul Randal bloguea sobre Ghost Cleanup.
La eliminación de filas en una base de datos no disminuirá el tamaño real del archivo de la base de datos.
Debe compactar la base de datos después de la eliminación de filas.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Después de ejecutar esto, querrá reconstruir los índices. La reducción generalmente provoca la fragmentación del índice, y eso podría significar un costo de rendimiento significativo.
También recomendaría que después de reducir, vuelva a crecer los archivos para tener algo de espacio libre. De esa forma, cuando ingresan nuevas filas, no activan el crecimiento automático. El crecimiento automático tiene un costo de rendimiento y es algo que le gustaría evitar (mediante el dimensionamiento adecuado de la base de datos) siempre que sea posible.
¡NO REDUZCA SU BASE DE DATOS!
“¿Por qué sucede esto? Una operación de reducción de archivos de datos funciona en un solo archivo a la vez y utiliza los mapas de bits GAM (consulte Dentro del motor de almacenamiento: GAM, SGAM, PFS y otros mapas de asignación) para encontrar la página más alta asignada en el Luego lo mueve hacia el frente del archivo tanto como puede, y así sucesivamente. En el caso anterior, invirtió completamente el orden del índice agrupado, llevándolo de perfectamente desfragmentado a perfectamente fragmentado. “
http://www.sqlskills.com/BLOGS/PAUL/post/Por-que-no-debe-reducir-sus-archivos-de-datos.aspx
“Mire la ironía de la base de datos Shrinking. Una persona reduce la base de datos para ganar espacio (pensando que ayudará al rendimiento), lo que conduce a un aumento en la fragmentación (reducción del rendimiento). Para reducir la fragmentación, uno reconstruye el índice, lo que conduce al tamaño de la base de datos aumentó mucho más que el tamaño original de la base de datos (antes de reducirse). Bueno, al reducir, uno no obtuvo lo que estaba buscando por lo general”.
SQL SERVER – Shrinking Database is Bad – Increases Fragmentation – Reduces Performance