No soy bueno en SQL, pero tengo una base de datos para mantener.
Casi no queda lugar para ello, así que decidí eliminar todos los datos para, digamos, el año 2008. Después de ejecutar la consulta de eliminación (había limpiado alrededor de 10 000 000 filas) y limpiar el registro de transacciones, descubrí que mi las acciones no tuvieron efecto en el tamaño de la base de datos. ¿Hay algo más que deba hacer?
Respuestas:
Si bien la reducción es peligrosa por las razones mencionadas aquí. Hay un medio feliz 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. Yo llamo a esto "Dimensionamiento correcto" su base de datos. Permitiría que este espacio libre esté allí y no se esfuerce por devolverlo y mantener su tamaño total justo en el tamaño utilizado. ¿Por qué? Debido a que su base de datos eventualmente crecerá nuevamente ... Luego se encogerá nuevamente ... Y se verá atrapado en este horrible patrón de encogimientos inútiles seguidos de crecimientos, y todo el tiempo, como algunos han señalado, estará aumentando su fragmentación de índice.
He publicado un blog sobre esto en el que advertí a la gente: " ¡No toquen ese botón de contracción! ", Pero a veces ... A veces es necesario. Si tiene una base de datos grande, solo liberó un espacio significativo y no espera volver a crecer nunca más; bueno, entonces está bien considerar la reducción como una operación única, siempre que pueda ocuparse de su fragmentación del índice después de la reconstrucción 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 reducción. El enfoque de crear una base de datos vacía y copiar datos en ella funciona, pero eso puede ser muy difícil con bases de datos más grandes y muchos datos.
Si planea agregar ese espacio a la base de datos a través del uso normal y los patrones de crecimiento en el futuro, entonces es posible que desee dejar el espacio allí.
también
Dijiste que "borraste" tu registro de transacciones. Me gustaría saber cómo hiciste esto, pero a medida que leas la publicación que compartí y las demás de la serie, verás algunos consejos sobre la administración del registro de transacciones. Pero en resumen: si está en modo de Recuperación completa, debe realizar copias de seguridad de registros regulares para mantener el registro reutilizándose. De lo contrario, sin copias de seguridad de registros 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 en un punto específico en el tiempo con fines de recuperación ... Si está en una situación simple y ve que el registro crece excesivamente,BEGIN TRAN ... do work.... COMMIT TRANo si acaba de emitir una gran DELETEdeclaración y eliminó todo un desorden de datos en una transacción implícita).
También supongo 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 está buscando inmediatamente después de su operación. Paul Randal bloguea sobre Ghost Cleanup .
Eliminar 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 la fila.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Después de ejecutar esto, querrá reconstruir índices. La reducción generalmente causa fragmentación del índice, y eso podría ser un costo de rendimiento significativo.
También recomendaría que después de reducir, vuelva a crecer los archivos para tener espacio libre. De esa forma, cuando entran 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 (a través del tamaño 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 de GAM (consulte Inside The Storage Engine: GAM, SGAM, PFS y otros mapas de asignación) para encontrar la página más alta asignada en el A continuación, lo mueve lo más hacia el frente del archivo que pueda, y así sucesivamente. En el caso anterior, invirtió completamente el orden del índice agrupado, pasando de perfectamente desfragmentado a perfectamente fragmentado. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Mire la ironía de la reducción de la base de datos. 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 lleva al tamaño de la base de datos para aumentar mucho más que el tamaño original de la base de datos (antes de reducir). Bueno, al reducir, uno no obtiene lo que buscaba habitualmente ".
Cuando elimina datos, SQL Server reserva su espacio para su uso posterior para insertar nuevos datos. Necesita reducir la base de datos. Puedes encontrar más información aquí .
Encontré esto porque acabo de eliminar un montón de tablas de respaldo porque mi base de datos se había "agotado". Seguí mirando la propiedad "Tamaño", pensando por qué esto no se está volviendo más pequeño. . Después de leer esto, no, no quiero reducir la base de datos. Lo que quiero hacer es "reclamar" el espacio para la basura que acabo de eliminar. Lo que necesitaba mirar era "Espacio disponible". Estoy pensando que quizás eso es lo que alguien más podría necesitar para mirar eso también.
Vale la pena señalar también que si la tabla tiene índices, puede existir fragmentación después de eliminar grandes extensiones de datos. Hoy tenía una mesa que tenía ~ 70 millones de registros, con aproximadamente 13 GB. Lo limpié a 1639 registros (el resto fue generado por un solo error) pero la tabla todavía ocupaba alrededor de 4.5 GB. Después de reconstruir todos los índices en la tabla, solo tomaba 85 páginas (680kb). Después de eso, utilicé un archivo retráctil incremental para recuperar el espacio (y arreglé el error en el sistema para evitar que se repita).