Limpieza Base de Datos

Hola,

Queríamos consultar sobre la posibilidad de limpiar datos de la BD mapuche ya que ha crecido de manera considerable.

Se viene trabajando y probando el sistema desde hace tiempo, y se ha pasado por varios procesos de migración tanto de datos como de versiones. La idea es poner el sistema en producción a corto plazo pero el tamaño de la BD probablemente sea un problema.

Llevamos a cabo algunas consultas sobre estadísticas en de la BD y sus esquemas:

Tamaño de las BD (prueba contiene datos de la demo):

https://lh3.googleusercontent.com/ckzQCCPswlaLzitIaIZ3njS0pdkWHZTkPaywWOl4rzxAD5OS2TnetjKEJar08CmS3UhXomROOcA1t7BocoDV62eqPlEyhR7dO8N7KIa--qTGxVjc2Ad-2kee0Ze9ymZTGE98rI3rRke_HPbMnEbBCStC1Bl7NN-7kOedSwikr0QwpEDJIUvHO54meFwionCiFuGySA2siRS9-eTz0Qh8A3dWU8tkf0Duwmf6pRTzXQ9T9QuAPprTw05DNQ0BydlerkzOODtUkdBlUIrRyQuRba9RrFN88aJEhlX5Jk6pGKW0nStTKifRxR6LFZ_4LxQk2VHlOsjsw8lFgGBvyYDvu-VONkTXExn9ceofQ4ruQWDPwDs5-9McPqgl3PbgyUXWA1eOS7Q9Zq1kdpQIKIoPw988o5xKl7iOuFG2sIi738hSe6Nf0AbFwO-hqZDU8CNbyxXcpdT-xFN57g30YwImfxd5Z1O8-MBOwtPnxQGEbrlHgkmKduAljW4ZnrfqwvYoZWb3_E70ARwBC4jrqVnzkaIWXmJf-B3_ujJ6oPLj0Z05lzHC174Bro8mVBnn7tmP9t-7Kstvwani4O9spCgycG9yIzgVn_AihlE_dLVD10F-h0rwSmmpxaNLWm3OG6FXVG8uekTttMqZfG6PfkJknlbdMXeggJpo66m6vCtaeFr3P_E7W2Th5hwMOvfuDlOHVjvLX4W732JSefshepw=w608-h381-no

Tamaño tablas en BD mapuche:

https://lh3.googleusercontent.com/cAEp4BeWwukysQud4e-wiPIrv9S5AA1Q5xHcVebyorsCEx-pg79GU2gqWMH7wSsGdMhO3OD0rH2C6eAnf4-zMAi1MddaT3tnN1LfjuIbbuI1JqNW-ut4viYi1gOEoEd0zZ66PFtcf7-Y1kFdnuwmH9lPwZfk46oVUctORj3L5ZkSfV3cbKJKDuGm0YPcgL7yL9VXhn3SlV3UrctX2FngCESZcqjGyh7y6wER0ERzttETo21AsXDYMdvIuyLVvpnzs6sozmUty4Q4qsCe4K0Y9MIechcmyzkKEBkBgzFCZdS1HdtT1OMVxFW5QJX8nAaL-lxuPo3Kdz9vJkx7lNjTVgEfAvyxYz2Nmet1Wl3Pl0WWMzj-iOd05YF2me9_P1Ql8yoad5-YxKc80xxFHQeA_b5JPIdoimybvVMs9PEMb_WGTV6FbvVYRwLYdS0nmdOxU_B-_Jb4WSw6kYksMIj7DuY-N11w6OkZigzvpkHCAWfwE0v2GZT2zGOBjkTdWCn7MgAkyR9ijl8RCmNkwEFYfkDoYjj084LjOxS2JQuxniT9A2okRX-FascH1S9ugfm59cgCM7uIcd-IrYaHKd2UFLcnxHyRwPtxkSERmhNh0-jvtR3uWvqGFTQWtMcCvyJa5U7V4wmOvCAV-lBDGDExjT6PbdAWRkCPDIlfb4TRb7hhzcbcUFah13_sEelOn7LsWrMpHgweEGeiotVjoZI=w762-h651-no

Las preguntas son las siguientes:

Qué datos se podrían limpiar sin repercusiones en el funcionamiento del sistema?

Cómo se podría evitar a futuro el crecimiento considerable del tamaño? Cabe destacar que en la Administración de logs tenemos marcadas todas las casillas, entonces cuáles recomiendan desmarcar?

Gracias y Saludos

Hola German, como estas?
El sistema basicamente esta separado en dos esquemas:

  • Esquema mapuche → Contiene las tablas y datos necesarios para un correcto funcionamiento del sistema. Borrar información representa una perdida de datos o mal funcionamiento
  • Esquema mapuche_auditoria → Contiene el log de todos los movimientos que se realizan sobre el sistema.

Claramente las tablas que mayor crecimiento tienen son las de logs del sistema (esquema mapuche_auditoria). Por defecto el sistema tiene el logueo sobre la mayoría de las tablas. Cual habilitar o deshabilitar es una politica que debe definir la institución y evaluar el costo de del almacenamiento de los datos vs. necesidad de auditoria sobre los mismos.

Hay una funcionalidad del sistema (reporte de novedades) que utiliza el log de auditoria como soporte para detectar los datos actualizados. Este reporte necesita que un conjunto de tablas tenga el check de que se loguea (logs_dh01, logs_dh02, logs_dh03, logs_dh04, logs_dh05, logs_dh06, logs_dh08, logs_dh09, logs_dh20, logs_dh24, logs_dh25, logs_dha1, logs_dhb7, logs_dhb8)

En caso de que consideren que los datos de auditoria no les sirven, pueden armar un script (o store procedure) que recorra cada una de las tablas de logs_ y las vacía por completo o teniendo como parámetro que elimine los datos menores a una fecha dada (tener en cuenta que para que el reporte de novedades funcione, las tablas deben contener al menos un registro inicial).

Si van a eliminar datos del esquema de auditoria, una buena practica seria realizar un backup del mismo antes del borrado y mantenerlo como respaldo ante la necesidad de consultar datos de dicho esquema.

Espero que les sea de ayuda, cualquier duda nos consultan que lo seguimos viendo.

Saludos, Nico

Hola Germán, muy buen hilo para compartir métodos de optimización en la base de datos.

En Uncoma el sistema está en producción desde 2010 creo y con 4000 agentes liquidandose por mes aprox. El tamaño de la base ha escalado bastante por lo que un backup comprimido pesa alrededor de 2GB. Adjunto imagen con el tamaño de las tablas mas grandes (casi todas del esquema mapuche_auditoria).

Como optimización solamente creamos algun que otro índice en la tabla logs_dh03 para que la consulta del reporte de novedades sea mas eficiente. También tenemos scripts que realizan vaccum analyze los fines de semana.

Nuestra política para las tablas de log es mantener los últimos 2 años (por eso el tamaño de la base es grande, podríamos guardar el último año únicamente) y en Enero se hace y se guarda un backup del esquema mapuche_auditoria antes de realizar el borrado de los datos viejos.

@Nicolas: Hace un tiempo tuve un problema con el reporte de novedades donde no podía encontrar un registro en la tabla logs_dh01. Hasta donde rastreé, había legajos sin registro en logs_dh01. Ahora que leo en tu comentario que las tablas deben contener al menos un registro inicial para el reporte de novedades, puede haber sucedido que sea por esto el error que salía? Digo, te referís a que cada legajo debe tener al menos un registro en logs_dh01 por ejemplo?

Saludos!


tablas.jpg

tablas.png

Hola Marco, exactamente a eso me refiero. En este caso, cada legajo debe tener un registro inicial para comparar.
Saludos, Nico.