Aumento desmesurado Archivo Log base de datos


#1

Buenas tardes a todos…

Bien, en realidad nunca le había prestado mucha atención a la parte del tamaño de los archivos Log del SQL server, sin embargo tengo un cliente que presenta poco espacio en sus discos duros, y tenemos que estarle realizando mantenimientos a cada momento.

En la última me puse a revisar un poco más y me encontré que le están haciendo la reducción del Log de la base de datos a cada momento porque presentan un crecimiento promedio de 6 GB por día. y estoy hablando que el día que me dí cuenta de esta situación, fue porque el día anterior yo mismo realicé la reducción de Log y se redujeron unos 10 GB, pero al día siguiente ya había crecido el Log 6.70GB de nuevo. y al parecer no es un comportamiento raro en este cliente.

Ya se que la mejor solución es la reducción de Log y ya estoy hablando de realizarle una tarea que haga reducción de log todas las noches como indican las notas de SAP:

  • h_tps://service.sap.com/sap/support/notes/1002099 SAP Note 1002099 (for MSSQL 2000)

  • h_tps://service.sap.com/sap/support/notes/1224089 SAP Note 1224089 (for MSSQL 2005)

Pero mi pregunta es: ¿es normal que el Log de la BD productiva crezca unos 2, 4 o 6 GB aún cuando ahorita los usuarios están de vacaciones y NADIE entro en el sistema el día anterior? esto lo digo con base, nosotros controlamos los accesos al sistema, quienes tienen permisos y que usuarios se conectan a que hora y demás, es parte de nuestro trabajo de monitoreo.


#2

Hola compañero, la verdad es que estos temas no son mi fuerte y lo único que se me viene a la mente es un número grande en el historial/log:

Esperemos que alguien con más conocimiento en el tema nos pueda orientar (@BusinessOne)

Saludos.


#3

Hola,

Lo que yo realizo son backup diarios de la base productiva y la SBO_COMMON, si tienes poco espacio en disco puedes realizar los backup luego copiarlos a otro equipo dentro de la red(Tarea Automatica) luego destruir los archivos originales(Backup en server).
Ademas puedes realizar un shrink a la base de datos y al log, tambien reducir el tamaño del Historial/log.

Puedes ver el siguiente enlace: h_tps://archive.sap.com/discussions/thread/1571335

Saludos.


#4

Ya había revisado eso… normalmente lo dejo en 99. Según yo, significa que guarda solo el Log de 99 transacciones ¿no? ¿o es el Log de los últimos 99 días? si es de los últimos 99 días si podría reducirlo.

@bfierro Correcto, ya hago esos BackUps, y están en un disco más grande, la cuestión es que el disco se le está llenando, y eso que apenas tiene un respaldo de los últimos 3 días porque así lo quiere el cliente.

El servidor está en la nube, se puede aumentar el tamaño, pero el cliente está reacio a aumentarlo porque le costará unos 10 dolares mas mensuales, de verdad me parece ilógico pero bueno…

la pregunta de verdad era ¿si es normal un incremento tan alto, a diario?. Ya estamos por programar la reducción del log en las madrugadas automático. pero de verdad que no le veo mas de 3 o con mucha suerte 4 semanas antes de que se vea obligado a aumentar los discos o detener la operación por completo.


#5

Historial/log

Determina el número de registros que deben grabarse en el archivo log.

En el archivo log se graba el historial de las modificaciones efectuadas en los registros maestros (artículos, cuentas de mayor y socio de negocios), documentos y otras ventanas de SAP Business One. Esta parametrización es actualizada por empresa, para todos los usuarios.

Para visualizar el log de historial de una ventana específica, seleccione en la barra de menús Inicio de la ruta de navegación Herramientas Paso de navegación Modificar log Fin de la ruta de navegación.

De esta manera estás permitiendo un log de 99 líneas por cada documento de SAP, creo que eso está desencadenando tu problemática.

Porque no dejas una Log de 15 o 20 en una base de datos de TEST y verificas que no se replique el comportamiento.

Revisa por favor lo siguiente:

ht_ps://andresnaranjo.wordpress.com/2012/02/16/reducir-tamano-bd-sap-business-one/

De hecho el primer paso para el mantenimiento de la base de datos comienza con la reducción del log.

IMPORTANTE: No existe una recomendación única para tal valor. Todo depende cuanto
histórico desea almacenarse. Por ejemplo, una orden de venta con 150 líneas y un log
**configurado a 50, significara un almacenamiento de 150 * 50 = 7500 registros en las **
tablas del históricotablas del histórico
(Esto copiado del manual de mantenimiento de base de datos proporcionado por mi partner)

Saludos.


#6

Hola,

@Ares17000 por si sirve de aporte (aunque tampoco tengo muy claro el motivo) las ejecuciones automáticas para crear SolPed o previsiones de compra para el MRP pueden hacer crecer el LOG considerablemente a diario aunque no haya usuarios, al fin y al cabo se ejecutan igual.

Creo que mas o menos todos nos hemos llevado algun susto con el LOG y sabemos como solucionarlo, -los que no saben sufrieron infarto mientras desaparecian los ultimos KB del disco jejeje- pero no tenemos claro porque ocurre, si alguien conoce algun motivo más, estaria muy interesado en conocerlo.

Gracias,

Saludos.


#7

Probaré bajándolo a 20 líneas en la BD de pruebas. Despues dependiendo del comportamiento lo cambio en productivo.

Saludos Cordiales…


#8

Bueno les comento que por el momento lo que se realizó fue lo siguiente con el cliente:

  1. Se creo un Job que hace la reducción de Log Mensual
  2. Se redujo la cantidad de BackUps vivos en el servidor.
  3. Se redujo de 99 a 15 el resguardo de Log en la base de datos.

y bueno… espero que este tema le sirva a otras personas que lleguen al foro.

Buenas tardes y que tengan un buen día.


#9

Podrías atestiguar por favor si notaste alguna mejoría considerable con la reducción del “historial/log”.

Digo, veo que lo mencionas como parte de la solución pero me gustaría saber si notaste alguna mejoría tan solo con el cambio de dicho parámetro, serviría para aclarar todo lo que se platicó en este tema.

Gracias.


#10

De hecho apenas si dejó de crecer de 6 GB diarios a 5.2 GB Diarios… esperaba que bajara más pero no fue lo suficiente como para no tomar medidas más drásticas de aumento del disco, reducir cantidad de backups y el job de reducción automático.


#11

Este tema se cerró automáticamente 7 días después del último post. No se permiten nuevas respuestas.