[SOLUCIONADO]Registro desaparecido en auditoría

Gente buenos días, consulta, en el schema negocio tenemos un acta cargada y cerrada, pero cuando buscamos el registro en logs_sga_actas no podemos encontrar la misma. Puede ser posible esto? básicamente, si en teoría nadie ingresó por fuera a la DB, puede ser que no tengamos registro de esa acta?

Saludos

Hola,

¿están activos los triggers en la tabla sga_actas?

Son 3: tauditoria_sga_actas, tdb_sga_actas y tub_sga_actas.

saludos.
2

Leo, tengo tres triggers y el estado de los mismos es O.

Es muy raro. Solo falta el log de ese acta o no hay ningun registro en esa tabla de log de actas?
¿Pasa lo mismo con otras tablas?

Alejandro, es muy raro porque faltan como 6 meses de auditoría, es como si la auditoría hubiese cortado y al instalar la versión 3.18.1 volvimos a registrar.

Esto puede ser posible? se pudo haber desactivado la auditoría de alguna manera? Quizás no se activo de manera correcta al generar una versión propia de la 3.17.1.X? Es posible esto?

Saludos

Hola Javier,

Te dejo la documentación de Auditoría del sistema.

Fíjate que se puede elegir cuales tablas se auditan y cuales no.

saludos.
2

Leo, buenos días, gracias por la documentación pero no tocamos nada de ahí, mi consulta viene por otro lado. La duda que tengo es, es posible que se haya desactivado la auditoría al haber realizado un cambio de versión?

Saludos

Hola Javier,

Eso no estara relacionado con este hilo ?. Finalmente como resolvieron eso?

Esto puede ser posible? se pudo haber desactivado la auditoría de alguna manera? Quizás no se activo de manera correcta al generar una versión propia de la 3.17.1.X? Es posible esto?

La auditoria la podes desactivar via toba_usuarios (si llevan auditoria de la base de toba podrian rastrear el acceso a dicha operacion)…pero para eso necesitas un rol en la DB que tenga permisos, la que les recomendaria (viendo que hay reincidencia sobre el problema) es que luego de tener instalada la version correspondiente, tanto en Guarani como en toba_usuarios tengan un User de db cuyo rol solo tenga permisos de SIUD (y exec sobre los triggers)… y el resto se use solo en situaciones puntuales, ya sea ante un problema especifico o una actualizacion del sistema.

Salvo para lo que es una actualizacion de versiones y/o actualizar el esquema de auditoria, cosas que pueden hacer via comandos… no necesitarian un usr con permisos para modificar la estructura creo yo.
@Ale corregime si me equivoco.

Saludos

@Richard sinceramente no recuerdo siquiera cómo resolvimos el tema de aquel entonces, lo que sí puedo ver es que la fecha de ese error se encuentra dentro del lapso de tiempo que no tenemos de manera correcta en el schema de auditoría.

Actualmente tenemos todas las tablas visadas para que generen log.

Tendremos que poner un poco más de atención en esto, dado que es la segunda vez que necesitamos datos de la auditoría y no la podemos utilizar como se debe …

Aprovecho y pregunto, al visualizar qué tablas estamos monitoreando del Proyecto Guaraní (configurar tablas) y presionamos Guardar, nos tira el siguiente error:

SQLSTATE: db_42704
CODIGO: 7
MENSAJE: ERROR: trigger “tauditoria__temp_arau_nom_eliminar” for table “_temp_arau_nom_eliminar” does not exist
SQL: ALTER TABLE negocio._temp_arau_nom_eliminar DISABLE TRIGGER tauditoria__temp_arau_nom_eliminar; – toba_log: 637598376

Efectivamente dicha tabla no tiene ningún trigger creado.

Para activar la auditoría en toba_usuarios, presionamos el botón, se refresca la página pero es como si no hace nada, no podemos seleccionar que tablas auditar.
No creo que se haya activado.

Saludos

Javier, esa tabla es una tabla temporal que se usa en el proceso de generar datos para Araucano.
Creo en version 3.18 esa tabla se puso para que se cree como UNLOGGED lo que hacia que no se creara como temporal, es decir tenia una sentencia de creacion como la siguiente

CREATE UNLOGGED TABLE _temp_arau_nom_eliminar (alumno integer NOT NULL, certificado integer NOT NULL);

Luego se sacó esa opción UNLOGGED pero no se agrego la opcion TEMP, con lo cual las tablas se estan creando y quedan en la base luego de que se corra este proceso.
Debería ser:

CREATE TEMP TABLE _temp_arau_nom_eliminar (alumno integer NOT NULL, certificado integer NOT NULL);

Lo mismo debiera ser con la otra tabla temporal:

CREATE TEMP TABLE _temp_arau_nom_informar (alumno integer NOT NULL, certificado integer NOT NULL);

Esto lo podes ver en el archivo: php\nucleo\administracion\araucano\act_araucano.php

@Alejandro, verifique el archivo que mencionaste y tiene la siguiente sentencia:

CREATE TABLE _temp_arau_nom_eliminar (alumno integer NOT NULL, certificado integer NOT NULL);
CREATE INDEX _id__temp_arau_nom_eliminar ON _temp_arau_nom_eliminar (alumno, certificado);

No hay UNLOGGED ni TEMP de ninguna de los dos tablas mencionadas. De todas maneras al ser temporales se pueden borrar para que el proceso de seleccioar las tablas a auditar puede terminar bien?

En cuanto a " Para activar la auditoría en toba_usuarios, presionamos el botón, se refresca la página pero es como si no hace nada, no podemos seleccionar que tablas auditar.
No creo que se haya activado. "

Como podemos solucionarlo?

Saludos

Esta bien, lo tienen como salió en la version 3.18. En la 3.19 agregaremos la clausula TEMP para que esas dos tablas se creen en forma temporal en ese proceso.
Como están ahora NO son temporales.

Hola Javier,

Es algo sobre lo que van a tener que generar alguna base de conocimiento, porque estan nuevamente en la misma situacion… solo que ahora parece que la tabla la creo G3.
Quizas frente a ese error se opto por desactivar en su momento la auditoria para poder proseguir con alguna operacion y finalmente luego de solucionado no se reactivo.

Actualmente tenemos todas las tablas visadas para que generen log. Tendremos que poner un poco más de atención en esto, dado que es la segunda vez que necesitamos datos de la auditoría y no la podemos utilizar como se debe ...

Aprovecho y pregunto, al visualizar qué tablas estamos monitoreando del Proyecto Guaraní (configurar tablas) y presionamos Guardar, nos tira el siguiente error:
SQLSTATE: db_42704
CODIGO: 7
MENSAJE: ERROR: trigger “tauditoria__temp_arau_nom_eliminar” for table “_temp_arau_nom_eliminar” does not exist
SQL: ALTER TABLE negocio._temp_arau_nom_eliminar DISABLE TRIGGER tauditoria__temp_arau_nom_eliminar; – toba_log: 637598376

Efectivamente dicha tabla no tiene ningún trigger creado.

Para activar la auditoría en toba_usuarios, presionamos el botón, se refresca la página pero es como si no hace nada, no podemos seleccionar que tablas auditar.
No creo que se haya activado.

Te paso una opcion que saque de este hilo donde Florencia propuso seguir este camino y menciona que toba_usuarios no sirve para modificar la auditoria de Guarani porque no sigue las particularidades que manejan.


CREATE TRIGGER tauditoria__temp_arau_nom_eliminar
    AFTER INSERT OR DELETE OR UPDATE
    ON negocio._temp_arau_nom_eliminar
    FOR EACH ROW
    EXECUTE PROCEDURE negocio_auditoria.sp__temp_arau_nom_eliminar();

ALTER TABLE negocio._temp_arau_nom_eliminar
    DISABLE TRIGGER tauditoria__temp_arau_nom_eliminar;

Basicamente seria ejecutar esas sentencias y luego volver a ejecutar el comando para crear la auditoria de Guarani.
Una vez que tengan la auditoria creada, salvo que tengan que meter una modificacion a la estructura de la base de datos… no deberia ser necesario tocarla hasta que sea requerido y por lo que vi en dicho hilo, en cualquier caso no usar toba_usuarios porque evidentemente esta generando algo que se lleva de los pelos con el mecanismo que usa Guarani.

Saludos

Richard / Alejandro, ok ya ejecutaremos los comandos como nos indican aquí.

Aprovecho para hacer otra consulta, investigando un poco el problema Original de la consulta, encontré lo siguiente en la DB (ver adjunto).

Básicamente el trigger tauditoria_sga_actas se encuentra deshabilitado, esto debería estar así o debería estar siempre habilitado?

Saludos


Triggers_sga_actas.PNG

Triggers_sga_actas.PNG_thumb.png

Debería estar habilitado si quieren registrar los cambios en la tabla sga_actas.

Muchas gracias por las respuestas, trataremos de monitorear un poco más el schema a ver si podemos encontrar alguna causa.
Saludos