Negocio_Auditoria

Cada tabla del esquema de auditoria se llama igual que la tabla real con el prefijo logs_
En este caso debes buscar en la tabla logs_sga_insc_cursada_log filtrando por el campo “operacion = ‘B’” (baja de la inscripción) . Va a tener el dato auditoria_opercion = I (Insert)"

Si lo buscas en logs_sga_insc_cursada debería estar tanto el alta como la baja de esa inscripción (auditoria_operacion = I (Insert) , auditoria_operacion = D (Delete))

Alejandro, gracias por la información, de todas maneras no podemos encontrar el registro en dichas tablas, paso a comentarte.

En sga_insc_cursada_log tenemos un registro con Operación=“B” fecha= “2020-10-25 11:12:32”, el valor del campo nro_transaccion_log = 148731.

Cuando ingresamos a la tabla logs_sga_insc_cursada_log y buscamos ese ID de transacción el mismo no existe.

Cómo buscamos esa transacción en la auditoría?

Lo que nos lleva a la duda si el esquema de auditoría se encuentra funcionando de manera correcta.

Saludos

Javier,

Fijate que en la tabla ‘sga_insc_cursada_log’ tienen dos transacciones: ‘nro_transaccion’ y ‘nro_transaccion_log’. Están usando el número de transacción correcto? .Y si lo buscan por la columna ‘inscripcion’?

Saludos, Florencia.

Florencia, lo busqué por los tres campos mencionados y no existe registro en negocio_auditoria. Pudo dejar de funcionar este esquema? Cómo puedo verificar si está funcionando correctamente y cómo puedo activarlo nuevamente?

Saludos

En sga_insc_cursada_log tenemos un registro con Operación="B" fecha= "2020-10-25 11:12:32", el valor del campo nro_transaccion_log = 148731.

El dato del campo nro_transaccion_log corresponde al nro de transacción de la baja de la inscripción.

El dato del campo nro_transaccion corresponde al nro de transacción del alta de la inscripción. Este dato debieras encontrarlo en las tablas:

SELECT * FROM sga_insc_cursada WHERE nro_transaccion = ...;
SELECT * FROM sga_insc_cursada_log WHERE nro_transaccion = ...;
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada WHERE nro_transaccion = ...;
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada_log WHERE nro_transaccion = ...;

Javier,

El trigger de auditoría sobre la tabla ‘sga_insc_cursada_log’ está habilitado?

SELECT * FROM pg_trigger where tgname = 'tauditoria_sga_insc_cursada_log';

Saludos, Florencia.

Alejandro, no se si me estoy dando a entender, cuando busco el registro de la baja en sga_insc_cursada_log, si lo encuentro, pero no puedo encontrar esa acción en el esquema de auditoría. Es más cuando realizo las consultas que me mandaste, obtengo esto:

SELECT * FROM sga_insc_cursada WHERE nro_transaccion = 134122; → NO DEVUELVE REGISTRO
SELECT * FROM sga_insc_cursada_log WHERE nro_transaccion = 134122; → ES EL REGISTRO ORIGINAL desde donde partimos la consulta
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada WHERE nro_transaccion = 134122; → NO DEVUELVE REGISTRO
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada_log WHERE nro_transaccion = 134122; → NO DEVUELVE REGISTRO

Por lo que no termino de entender cómo se relacionan.
Saludos

Florencia, la consulta

SELECT * FROM pg_trigger where tgname = 'tauditoria_sga_insc_cursada_log';

No me devuelve registros.

Javier,

Entonces no tienen activada la auditoria en esa tabla. Qué pasa si ejecutan la siguiente sentencia?

CREATE TRIGGER tauditoria_sga_insc_cursada_log AFTER INSERT OR UPDATE OR DELETE ON negocio.sga_insc_cursada_log FOR EACH ROW EXECUTE PROCEDURE negocio_auditoria.sp_sga_insc_cursada_log();

Saludos, Florencia.
4

SELECT * FROM sga_insc_cursada WHERE nro_transaccion = 134122; --> NO DEVUELVE REGISTRO
Aqui se registra el alta de la inscripcion. Al darlo de baja deja de existir el registro. Asi que es correcto que no exista registro.
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada WHERE nro_transaccion = 134122; --> NO DEVUELVE REGISTRO
Aqui se registra la auditoria de la tabla sga_insc_cursada. Debiera haber un registro para ese alta con el flag "negocio_auditoria = I " (Insert). Al no existir registro, significa que no tienen habilitada la auditoria de la tabla "sga_insc_cursada".
SELECT * FROM sga_insc_cursada_log WHERE nro_transaccion = 134122; --> ES EL REGISTRO ORIGINAL desde donde partimos la consulta
En esta tabla se registran las bajas y rechazos de inscripciones a cursadas. Con lo cual esta bien que exista esa inscripcion que fue dada de baja.
SELECT * FROM negocio_auditoria.logs_sga_insc_cursada_log WHERE nro_transaccion = 134122; --> NO DEVUELVE REGISTRO
Aqui se registra el log de auditoria de la tabla "sga_insc_cursada_log" (bajas y rechazos de inscripciones). Al no haber registros (debiera haber uno con el flag "negocio_auditoria = I"), significa que no esta activada la auditoria de esta tabla.

Por lo que se ve no tienen activada la auditoria de datos, o al menos en estas dos tablas (sga_insc_cursada, sga_insc_cursada_log).

Florencia, me tira esto la consulta

CREATE TRIGGER

Query returned successfully in 152 msec.

Cómo hacemos para activar la auditoría nuevamente? sudo ./guarani crear_auditoria -f guarani

Documentacion de auditoría del sistema

Alejandro, gracias por la información, ya verificaremos qué tabla auditar.

Gente, consulta, traté de activar auditoría en alguna tablas mediante “Configurar Tablas” y me genera el siguiente error, independientemente de la tabla que quiera activar.

SQLSTATE: db_42704

CODIGO: 7

MENSAJE: ERROR: trigger “tauditoria_final” for table “final” does not exist

SQL: ALTER TABLE negocio.final DISABLE TRIGGER tauditoria_final; – toba_log: 637426234

Esa tabla no la había visto nunca…

No es una tabla creada por el SIU. Será una que crearon ustedes? ¿Podes verificar ?

No, no tenemos ninguna tabla llamada final. Lo raro es que queremos crear para sga_actas y salta el error. Por eso no entendemos que pasa.

Hola Javier,

tenes a mano el log de Toba de esto?.. ya sea que lo hiciste via toba_usuarios (instalacion/i__blahblah/p__toba_usuarios/logs) o via comando (instalacion/logs_comandos/) para ver que esta intentando levantar via SQL?.
De paso, que version de Postgresql estan usando?

Por otro lado, cuando ingresas en “Configurar Tablas”, te aparece ‘final’ en el listado? (si se que son 3504)… quiero ver si es algo con la config de bases.ini o alguna secuencia especifica de la operacion, por defecto se levanta el resultado de esta SQL:


SELECT tablename 
FROM pg_tables 
WHERE 
		        		tablename NOT LIKE 'pg_%'
		        	AND tablename NOT LIKE 'sql_%'
   			       AND schemaname = 'negocio'
			       ORDER BY UPPER(tablename);

Y luego si hay tablas marcadas en la interface, se suman aquellas que se hayan seleccionado … si la tabla no existe no deberia ser levantada desde la metadata de Postgres para ser procesada, por otro lado si aparece en el listado es porque en algun momento se agrega… lo que hay que averiguar es donde y por que motivo.

Saludos

PD: Consulta… la fuente de datos tiene mas de un esquema configurado?

Richard, te voy paso a paso…
0- Quiero corregirme… si tenemos una tabla final (tengo que averiguar cómo llegó ahí, es un desarrollo interno pero debería tener otra nomenclatura).
1-Te adjunto log .
2-Versión Postgres: “PostgreSQL 9.6.16 on x86_64-pc-linux-gnu (Ubuntu 9.6.16-1.pgdg18.04+1), compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit”
3-Sí me aparece final, pero no la tengo seleccionada para que me genere auditoría en la misma.
4- Te paso la estructura de nuestro archivo bases.ini

Saludos


bases.rar (268 Bytes)

Hola Javier,

Ok…esa tabla esta en el mismo schema que el negocio de guarani?, si es parte de una personalizacion quizas el schema de dichas tablas este registrado en la fuente de datos y pueda venir por ahi el tema.
Por eso te preguntaba si la fuente tenia mas de un schema asignado.

1-Te adjunto log .
Te falto adjuntarlo.
2-Versión Postgres: "PostgreSQL 9.6.16 on x86_64-pc-linux-gnu (Ubuntu 9.6.16-1.pgdg18.04+1), compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0, 64-bit"
Bien, es un viejo conocido... no alguna version nueva que pudo cambiar algun mecanismo (tal como las secuencias en la 12).. debe ser un tema de programacion a lo sumo.
3-Sí me aparece final, pero no la tengo seleccionada para que me genere auditoría en la misma.
El tema es que cuando se reprocesa la configuracion de las tablas de auditoria, se hace sobre todas las tablas del schema original.. por eso te esta apareciendo [b]final[/b], lo que queria descartar es que fuera una tabla de otro schema donde el usuario de esa conexion no tenia permisos.

En algun momento lo tuvimos mas granular y solo se tocaban aquellas que se marcaban, sin embargo se generaron problemas cuando quedaban algunos triggers dando vueltas y otros no, por lo que lo pasamos a un esquema “todo o nada” y al quitar la tabla desactivamos el trigger que dispara la funcion.

4- Te paso la estructura de nuestro archivo bases.ini
Gracias igual esto iba de la mano de saber si la fuente tenia mas de un schema cargado.

Opciones para salvaguardarlo:

  • La correcta, seria actualizar el esquema de auditoria mediante el comando exportando los datos de auditoria (si son muchos realmente quizas no convenga por el tiempo), hay que tener cuidado especial cuando hay varios esquemas en una sola fuente. luego de la actualizacion tendrian que restaurar los datos de auditoria manualmente.

  • La “alambrada”, crear el trigger con el nombre que lo espera el mecanismo y via toba_usuarios configurar las tablas que van a quedar con la auditoria activa.
    Dicha tabla no te va a quedar con auditoria (a menos que tenga la funcion la tabla de logs) por lo que no te conviene dejarla activa.

Si eso no funciona, ahi si ya necesito con mas detalle info de lo que tenes ahi y como llegaron porque es un caso que no he encontrado antes.

Saludos

Richard, perdón ahora te paso el log. Si mal no recuerdo tenemos dos schemas en la fuente, negocio y negocio_unt. Podemos corroborar esa información en otro lugar que no sea el Toba_editor?

Creo que vamos por la opción “alambrada”. Ya voy a tratar de hacerlo y te comento.

Muchas gracias!


sistema.rar (2.38 KB)