muy - Cómo reducir el tamaño de la tabla de SQL Server que creció a partir de un cambio de tipo de datos
tamaño de base de datos sql server (5)
Tengo una tabla en SQL Server 2005 que tenía un tamaño de aproximadamente 4 gb.
(cerca de 17 millones de discos)
Cambié uno de los campos del tipo de datos char(30) al char(60) (hay un total de 25 campos, la mayoría de los cuales son char(10) por lo que la cantidad de espacio char se suma a unos 300)
Esto hizo que la tabla se duplicara en tamaño (más de 9 gb)
Luego cambié char(60) a varchar(60) y luego ejecuté una función para eliminar los espacios en blanco de los datos (para reducir la longitud promedio de los datos en el campo a aproximadamente 15)
Esto no redujo el tamaño de la mesa. Reducir la base de datos tampoco ayudó.
Además de recrear realmente la estructura de la tabla y copiar los datos (¡eso es 17 millones de registros!) ¿Hay una forma menos drástica de volver a bajar el tamaño?
Alternativamente, puede hacer una reconstrucción completa de la tabla para asegurarse de que no haya datos adicionales en cualquier lugar:
CREATE TABLE tmp_table(<column definitions>);
GO
INSERT INTO tmp_table(<columns>) SELECT <columns> FROM <table>;
GO
DROP TABLE <table>;
GO
EXEC sp_rename N''tmp_table'', N''<table>'';
GO
Por supuesto, las cosas se complican más con la identidad, los índices, etc, etc ...
Bueno, está claro que no estás recuperando espacio. :-)
Cuando cambiaste los campos de texto a CHAR (60), todos se llenan a capacidad con espacios. Así que TODOS tus campos tienen ahora realmente 60 caracteres de longitud.
Cambiar eso de nuevo a VARCHAR (60) no ayudará, los campos aún tienen 60 caracteres de longitud ...
Lo que realmente necesita hacer es ejecutar una función TRIM en todos sus campos para reducirlos a su longitud recortada, y luego hacer una reducción de la base de datos.
Una vez que haya hecho eso, debe RECONSTRUIR su índice agrupado para recuperar parte de ese espacio desperdiciado. El índice agrupado es realmente donde viven sus datos; puede reconstruirlos así:
ALTER INDEX IndexName ON YourTable REBUILD
De forma predeterminada, su clave principal es su índice agrupado (a menos que haya especificado lo contrario).
Bagazo
No ha limpiado ni compactado ningún dato, ni siquiera con una "base de datos reducida".
Recupera el espacio de las columnas de longitud variable eliminadas en tablas o vistas indizadas.
Sin embargo, una simple reconstrucción del índice si hay un índice agrupado también debería hacerlo
ALTER INDEX ALL ON dbo.Mytable REBUILD
Sé que no estoy respondiendo a su pregunta como lo está haciendo, pero ¿ha considerado archivar algunos de los datos en una tabla de historial y trabaja con menos filas?
La mayoría de las veces, a primera vista, puede pensar que necesita toda esa información todo el tiempo, pero cuando realmente se sienta y lo examina, hay casos en que eso no es cierto. O al menos he experimentado esa situación antes.
Tuve un problema similar aquí SQL Server, Convertir NTEXT a NVARCHAR (MAX) relacionado con el cambio de ntext a nvarchar (max).
Tuve que hacer un UPDATE MyTable SET MyValue = MyValue para conseguir que UPDATE MyTable SET MyValue = MyValue tamaño de todo muy bien.
Esto obviamente lleva bastante tiempo con muchos discos. Hubo una serie de sugerencias sobre cómo hacerlo mejor. La clave uno era una marca temporal que se indicaba si se había hecho o no, y luego se actualizaba unos pocos miles a la vez hasta que todo estuviera terminado. Esto significaba que tenía "algo" de control sobre lo que estaba haciendo.
Sin embargo, en otra nota, si realmente desea reducir la base de datos tanto como sea posible, puede ser útil si reduce el modelo de recuperación a lo simple, reduce los registros de transacciones, reorganiza todos los datos de las páginas y luego vuelve a configurarlos. modelo de recuperación. Sin embargo, tenga cuidado, la reducción de las bases de datos generalmente no es recomendable, y si reduce el modelo de recuperación de una base de datos activa, está pidiendo que algo salga mal.