Tamaño exagerado base de datos

jannethps · #1 (**permalink**) 10/05/2016, 08:14

Hola,
Buenos días a todos. Muchas gracias por leerme.

Mi problema el día de hoy, espero puedan ayudarme.

Recién empecé a trabajar en una nueva empresa y recibí una base de datos en SQL Server 2008 R2 que pesa casi 80GB, incluyendo el log... Después de reducir el log la base de datos quedó pesando casi 30GB, lo que es simplemente increíble.

La base de datos tiene como 8 tablas de las cuales una es de detalle y está enorme en peso... Y tiene como 10 millones de registros, y unos 20 campos.
Ya revisé los tipos de campos y otras pocas opciones pero al crecer tanto la base el disco duro está llegando al máximo y cualquier cosa es una eternidad.
No se guardan imágenes, solo texto!

Finalmente voy a crear una segunda base de datos pero antes de hacerlo quisiera preguntarles a ustedes su opinión al respecto para ver si a alguien le ha pasado algo parecido y tiene alguna idea de qué pueda estar sucediendo.

Gracias y saludos!!

gnzsoloyo · #2 (**permalink**) 10/05/2016, 08:34

"Tamaño exagerado" en BBDD es un concepto relativo. Depende de lo que estés habituado a manejar, y por sobre todas las cosas depende de lo que requiera el sistema.
Uno de los sistema subalternos de la empresa e que trabajo, que sólo se usa para registrar los eventos de una de las aplicaciones web, geenera 60 Gb diarios de datos... y eso NO es la base productiva de la aplicación. Sólo la de mensajes de su funcionamiento (la usamos para trazabilidad de errores y performance).
Lo que que quiero decirte es que hay que ver qué requerimientos y para que uso esta esa base, sin lo cual no se puede decir que sea mucho, poco o insufciente.
Lo que sí podemos decir es que si el sistema se ralentiza por la magnitud de datos, pero los datos son necesarios, es probable que tengan un cuello de botella en el hardware del servidor de la base de datos.
Y ESO SÍ es un PROBLEMA que hay que resolver.

Libras · #3 (**permalink**) 10/05/2016, 08:38

Me encanto el "tamaño exagerado" yo esperaba minimo un Tera de la base de datos en la descripcion, no una friolera de 80GB y como bien te dijeron el tamaño exagerado de la base de datos es relativo, en mi experiencia personal te puedo comentar que he lidiado con una base de datos de 45TB(hasta ahorita la mas grande con la que me he topado), ahora para que crear una segunda base de datos? para eliminar la lentitud en el disco? para empezar analisemos algunas cosas de tu base de datos:

1.-Los archivos de log, bases de datos de sistema y archivos de datos(mdf) estan en discos separados o todos sobre el mismo?
2.-Cual es el tamaño de tu disco duro?
3.-Cuales son las caracteristicas fisicas de tu servidor?(memoria, cpu, disco)
4.-Como esta asignada la memoria a la instancia de sql server?
5.-Dices que tienes un problema de lentitud, pero ya sabes cual es la causa de la lentitud?
6.-Que informacion guardas en esa base de datos?, se puede purgar informacion vieja?
7.-Como estan los niveles de fragmentacion de indices de las tablas implicadas?
8.-Ya revisaste las estadisticas? cuando fue la ultima vez que se hizo un updatestats?
9.-Te recomiendo correr un sqlprofiler con los counters de ioread, iowrite, cpu y memory, esto para asegurarnos que el cuello de botella se encuentra en disco

con esta informacion ya podriamos partir para poder "domar" a tu pequeño monstruito ;)

jannethps · #4 (**permalink**) 10/05/2016, 08:59

Gracias por responder.

Es una base de datos nueva para una aplicación que aún están desarrollando, es la base de datos que va a estar en producción, los registros son muy pocos para el peso tan grande que tiene y siendo solo texto.
Donde trabajaba anteriormente manejábamos bases de datos globales porque era una multinacional y jamás llegamos a las 20GB y con millones de registros.

Por eso digo que el tamaño es exagerado, sé que hay bases mucho más grandes pero con cada registro que entra suben algunas megas y eso no tiene sentido.

1.-Los archivos de log, bases de datos de sistema y archivos de datos(mdf) estan en discos separados o todos sobre el mismo?
Sí... lo crearon todo en un mismo lugar.

2.-Cual es el tamaño de tu disco duro?
209 GB aprox. en la partición donde está la base

3.-Cuales son las caracteristicas fisicas de tu servidor?(memoria, cpu, disco)
Es un servidor virtual.
12 de Ram, Intel Xeon de 2.53

4.-Como esta asignada la memoria a la instancia de sql server?
Debo revisar

5.-Dices que tienes un problema de lentitud, pero ya sabes cual es la causa de la lentitud?
Aún estoy revisando.

6.-Que informacion guardas en esa base de datos?, se puede purgar informacion vieja?
La base de datos es nueva, ni siquiera ha salido a los usuarios... no se puede purgar

7.-Como estan los niveles de fragmentacion de indices de las tablas implicadas?
Debo revisar

8.-Ya revisaste las estadisticas? cuando fue la ultima vez que se hizo un updatestats?
No las he revisado

9.-Te recomiendo correr un sqlprofiler con los counters de ioread, iowrite, cpu y memory, esto para asegurarnos que el cuello de botella se encuentra en disco
Lo puse a correr desde temprano pero aún no termina

Saludos!!

gnzsoloyo · #5 (**permalink**) 10/05/2016, 09:05

Cita:

con cada registro que entra suben algunas megas

Ok... ¿Y qué contienen esos registros, que pueda justificar semejante incremento? ¿Qué y cuantas tablas intervienen en un alta de registros como dices?

jannethps · #6 (**permalink**) 10/05/2016, 09:13

Hola,

Son alrededor de 20 campos, y uno es una foránea a otra tabla de 25-30 registros fijos para sacar el código de las sucursales y la PK es un auto numérico.

Y en los 20 campos que quedan guardan unos precios y la mayoría de campos son int y los pocos de texto tienen 50 máximo de longitud.
De ahí que abriera este post, no veo justificación :(

Gracias!!

Libras · #7 (**permalink**) 10/05/2016, 09:17

El sqlprofiler no termina hasta que tu lo termines :P

Mas preguntas:

Cual es el growth de la base de datos?(o sea cuando crece el archivo crece en megas o en %)

Modo de recuperacion de tu base de datos?

tienes habilitada la creacion de estadisticas automaticas?

Cual es fillfactor para cada los indices?

Cual es el tamaño de los indices de las tablas?

Cual es el tamaño inicial de tu archivo de bases de datos, porque ahorita dices que tienes 20GB pero esos 20GB estan siendo usados o solo reservados?

iislas · #8 (**permalink**) 10/05/2016, 09:27

Tengo la extraña sensacion que es otro caso mas de "Prefiero que le sobre y no que le falte"

Libras · #9 (**permalink**) 10/05/2016, 09:33

Despues de haber pensado en todas las posibles causas del crecimiento "exagerado" de la base de datos y de comenzar de lo mas complejo a lo mas basico, quizas llegamos a la conclusion de que el archivo de base de datos tiene 20GB reservados pero solo esta usando 5GB :P jejejeje, sobre las respuestas a las primeras preguntas:

1.-Los archivos de log, bases de datos de sistema y archivos de datos(mdf) estan en discos separados o todos sobre el mismo?
Sí... lo crearon todo en un mismo lugar.
Mala Practica, deberian de estas los archivos de sistema en un disco, los archivos de log en otro y los de bases de datos en otro

2.-Cual es el tamaño de tu disco duro?
209 GB aprox. en la partición donde está la base
209GB, y tienes usados 20 por la base de datos, o sea estas usando un 10% del disco, en donde esta el problema entonces??? todavia tienes mucho espacio en disco como para que tengas contencion

3.-Cuales son las caracteristicas fisicas de tu servidor?(memoria, cpu, disco)
Es un servidor virtual.
12 de Ram, Intel Xeon de 2.53
Caracteristicas basicas para un SQL server, te recomendaria mas memoria digamos unos 50GB de ram digo si fuera posible :P

6.-Que informacion guardas en esa base de datos?, se puede purgar informacion vieja?
La base de datos es nueva, ni siquiera ha salido a los usuarios... no se puede purgar
Si no ha salido a usuarios donde esta el problema o la lentitud? creo que el archivo tiene asignado los 20GB pero no esta usando todo

jannethps · #10 (**permalink**) 10/05/2016, 09:52

Hola...

Cual es el growth de la base de datos?(o sea cuando crece el archivo crece en megas o en %)
Crece en megas

Modo de recuperacion de tu base de datos?
Full

tienes habilitada la creacion de estadisticas automaticas?
Sí está creada... create y update

Cual es fillfactor para cada los indices?
Está en 0

Cual es el tamaño de los indices de las tablas?

Cual es el tamaño inicial de tu archivo de bases de datos, porque ahorita dices que tienes 20GB pero esos 20GB estan siendo usados o solo reservados?
El reservado son 30GB pero sólo quedan libres alrededor de 5M

Y ni idea qué quisieron decir con:
Tengo la extraña sensacion que es otro caso mas de "Prefiero que le sobre y no que le falte"

Saludos.

jannethps · #11 (**permalink**) 10/05/2016, 09:58

Cita:

Iniciado por Libras

Despues de haber pensado en todas las posibles causas del crecimiento "exagerado" de la base de datos y de comenzar de lo mas complejo a lo mas basico, quizas llegamos a la conclusion de que el archivo de base de datos tiene 20GB reservados pero solo esta usando 5GB :P jejejeje, sobre las respuestas a las primeras preguntas:

1.-Los archivos de log, bases de datos de sistema y archivos de datos(mdf) estan en discos separados o todos sobre el mismo?
Sí... lo crearon todo en un mismo lugar.
Mala Practica, deberian de estas los archivos de sistema en un disco, los archivos de log en otro y los de bases de datos en otro

2.-Cual es el tamaño de tu disco duro?
209 GB aprox. en la partición donde está la base
209GB, y tienes usados 20 por la base de datos, o sea estas usando un 10% del disco, en donde esta el problema entonces??? todavia tienes mucho espacio en disco como para que tengas contencion

3.-Cuales son las caracteristicas fisicas de tu servidor?(memoria, cpu, disco)
Es un servidor virtual.
12 de Ram, Intel Xeon de 2.53
Caracteristicas basicas para un SQL server, te recomendaria mas memoria digamos unos 50GB de ram digo si fuera posible :P

6.-Que informacion guardas en esa base de datos?, se puede purgar informacion vieja?
La base de datos es nueva, ni siquiera ha salido a los usuarios... no se puede purgar
Si no ha salido a usuarios donde esta el problema o la lentitud? creo que el archivo tiene asignado los 20GB pero no esta usando todo

No, el tamaño reservado es de 30GB y a este momento hay algo más de 3M disponibles.

2. No fui clara, el disco tiene disponibles alrededor de 40GB, no sabría decir qué son las demás cosas y bases de datos que tienen en ese mismo servidor. El log crece demasiado así que hoy al revisar estaba pesando casi 60GB, ya lo reduje.

1 y 3. No son posibles... Eso es lo que hay de momento

3. No, el tamaño reservado es de 30GB y a este momento hay algo más de 3M disponibles.

La aplicación ya está en producción, cuando entré a trabajar acá ya la iban a compartir con todos en la organización y ahí fue que vi los problemas de tamaño en la base.
La información cargada ya es la final, así que al ingresar a la aplicación o se tarda casi dos minutos o genera timeout

Libras · #12 (**permalink**) 10/05/2016, 10:10

Te recomiendo el empezar a pensar en separar los archivos de log, de bases de datos de sistema y de bases de datos de usuario, 60GB de log es demasiado, cual es el modo de reutiliacion del log, no contestaste cual es el tamaño de los indices, esta base de datos solo tiene un archivo de datos o tiene varios? cual es el crecimiento del log, en % o en megas y cuanto? dices que la base tiene crecimiento en megas, pero cuantos megas?

ahora la pregunta mas fuerte, que esta ocurriendo en esa base de datos? tienes demasiadas transacciones concurrentes? o se hacen cargas masivas? cual es el waitype mas recurrente en tu base?, cuantos VLFS tienes? cuantos indices en tus tablas? los queries usan realmente los indices? numero de operaciones DML que tienes en tu base de datos................

Demasiadas cuestiones sin ver al paciente en vivo :P jejejejejeje, pero bueno hay que tratar de saber cuales son los sintomas antes de dar un diagnostico:

Y ni idea qué quisieron decir con:
Tengo la extraña sensacion que es otro caso mas de "Prefiero que le sobre y no que le falte", queriamos decir que al parecer tenias un archivo de datos con un tamaño grande reservado pero una utilizacion baja, cosa que parece que no es asi.......

jannethps · #13 (**permalink**) 10/05/2016, 10:33

Gracias...
Ya hablé sobre el tema del servidor y al parecer han venido trabajando para migrar a Azure, así que esperando qué dicen... demasiado nueva y demasiado pérdida en cómo manejan acá las cosas...

Voy a revisar los puntos que han escrito a lo largo del post a ver si algo puedo optimizar y cuando tenga las otras respuestas las subo...

Sí se hacen como dos o tres cargas masivas a eso de las 5 de la mañana a diario, pero por cada carga no son ni 4 mil registros.

Les escribo de nuevo cuando tenga las respuestas.

Gracias a todos!!