Pregunta sobre tamano de la Db

26/12/2007 - 17:07 por Alr | Informe spam
Mi pregunta es la siguiente:
Que sucede en cuanto al tamano de la tabla y de la Db, con una tabla que
constantemente se agregan y se borran registros (usandose como una tabla
puente: los registros que se agregan los registros que se borran); en el
supuesto de que en una Db solo existiera esta tabla, supongo que al cabo del
tiempo la Db creceria de tamano aunque realmente tuviera muy pocos
registros, es esto cierto ?
Tengo un Procedimiento Almacenado para compactar los archivos Log(Ldf), sin
embargo no se como compactar los archivos Mdf.

Alguna web para ler informacion al respecto ?

Preguntas similare

Leer las respuestas

#1 Anonimo
26/12/2007 - 22:49 | Informe spam
Buenas noches,

¿Para qué quieres compactar los archivos? Si todos los días (por poner una
periodicidad de ejemplo) reduces los ficheros, y todos los días ejecutas
procesos que hacen que dichos ficheros crezcan, ¿por que no dejar la base de
datos con el tamaño que necesita? Estos procesos de reducir ficheros, o de
hacer los ficheros más grandes, son costosos en entrada/salida. Por ponerte
un ejemplo, no tarda lo mismo un carga masiva de varios millones de filas
sobre una base de datos sin espacio libre, que la misma carga masiva sobre
una base de datos con espacio suficiente (que no necesita crecer). La
diferencia, de hecho, puede llegar a ser bastante notable. También, lo
podemos aplicar a TEMPDB, que a fin de cuentas, no deja de ser una base de
datos con sus necesidades de entrada/salida, etc...

Sobre el archivo MDF, ¿has probado a truncar la tabla con TRUNCATE TABLE
miTbl? La actividad diaria, puede producir que tengas muchas páginas
asignadas a la tabla, aunque estén vacías o prácticamente vacías. El comando
TRUNCATE TABLE le indica a la tabla que no tiene páginas de datos asignadas,
luego dichas páginas quedan desasignadas, y las reducciones de ficheros
(DBCC SHRINK) son más eficaces. El problema, el de siempre: TRUNCATE TABLE
no admite una cláusula WHERE, y se lleva fatal con las Foreign Keys (no
funciona, de hecho) !!! También reinicializa los campos autonuméricos...

Espero que te sirvan estos comentarios.

Saludos,

GuilleSQL
http://www.guillesql.es


"Alr'" wrote in message
news:
Mi pregunta es la siguiente:
Que sucede en cuanto al tamano de la tabla y de la Db, con una tabla que
constantemente se agregan y se borran registros (usandose como una tabla
puente: los registros que se agregan los registros que se borran); en el
supuesto de que en una Db solo existiera esta tabla, supongo que al cabo
del tiempo la Db creceria de tamano aunque realmente tuviera muy pocos
registros, es esto cierto ?
Tengo un Procedimiento Almacenado para compactar los archivos Log(Ldf),
sin embargo no se como compactar los archivos Mdf.

Alguna web para ler informacion al respecto ?



Respuesta Responder a este mensaje
#2 alr
31/12/2007 - 17:38 | Informe spam
Por supuesto que si me sirven tus comentarios, y discupla la tardanza de que
conteste, pero es que tuve problemas con mi pc.
Gracias.

<GuilleSQL> wrote in message news:uJ0e$
Buenas noches,

¿Para qué quieres compactar los archivos? Si todos los días (por poner una
periodicidad de ejemplo) reduces los ficheros, y todos los días ejecutas
procesos que hacen que dichos ficheros crezcan, ¿por que no dejar la base


de
datos con el tamaño que necesita? Estos procesos de reducir ficheros, o de
hacer los ficheros más grandes, son costosos en entrada/salida. Por


ponerte
un ejemplo, no tarda lo mismo un carga masiva de varios millones de filas
sobre una base de datos sin espacio libre, que la misma carga masiva sobre
una base de datos con espacio suficiente (que no necesita crecer). La
diferencia, de hecho, puede llegar a ser bastante notable. También, lo
podemos aplicar a TEMPDB, que a fin de cuentas, no deja de ser una base de
datos con sus necesidades de entrada/salida, etc...

Sobre el archivo MDF, ¿has probado a truncar la tabla con TRUNCATE TABLE
miTbl? La actividad diaria, puede producir que tengas muchas páginas
asignadas a la tabla, aunque estén vacías o prácticamente vacías. El


comando
TRUNCATE TABLE le indica a la tabla que no tiene páginas de datos


asignadas,
luego dichas páginas quedan desasignadas, y las reducciones de ficheros
(DBCC SHRINK) son más eficaces. El problema, el de siempre: TRUNCATE TABLE
no admite una cláusula WHERE, y se lleva fatal con las Foreign Keys (no
funciona, de hecho) !!! También reinicializa los campos autonuméricos...

Espero que te sirvan estos comentarios.

Saludos,

GuilleSQL
http://www.guillesql.es


"Alr'" wrote in message
news:
> Mi pregunta es la siguiente:
> Que sucede en cuanto al tamano de la tabla y de la Db, con una tabla que
> constantemente se agregan y se borran registros (usandose como una tabla
> puente: los registros que se agregan los registros que se borran); en el
> supuesto de que en una Db solo existiera esta tabla, supongo que al cabo
> del tiempo la Db creceria de tamano aunque realmente tuviera muy pocos
> registros, es esto cierto ?
> Tengo un Procedimiento Almacenado para compactar los archivos Log(Ldf),
> sin embargo no se como compactar los archivos Mdf.
>
> Alguna web para ler informacion al respecto ?
>
>
>


email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaRespuesta Tengo una respuesta
Search Busqueda sugerida