Transaction logs and audit trails - quick overview required
Posted in 1998
Hi All, I've just joined a company who are running an in-house developed application written in Informix RDS and looking though the code I am amazed to find that there is no transaction logging going in. That means no BEGIN WORK, COMMIT WORK or ROLLBACK WORK. Without these, in a multiuser enviroment I can only forsee problems but by a freak of nature they seem to be getting along fine! To clarify the effect of transaction logging, can someone please comment on the following: I understand that when starting a database with a transaction log implemented, any database modiictions are logged to the database if such statements are enclosed within BEGIN WORK...COMMIT WORK and that ROLLBACK WORK ensures that the database is not updated. If there are a number of users on the system and that the computer could crash at any moment, would a simple ROLLFORWARD statement be all that is needed to rectify the situation? Would a bcheck be adviseable before a ROLLFORWARD? Given that users could be at varying stages of update, would I be right in syaing the ROLLFORWARD takes account of all the BEGIN WORK's started by the users and that it would adjust the database as necessary? Can someone please give a brief overview of audit trails and how effective they are in monitoring the database. What information is recorded in the trail for a table and can you identify what user/program/process was responsible for a particular update? Sometimes users report that data is missing and a SELECT that returns nothing confirms their suspisions but how are you to know what or who was responsible? Any views/comments would be very much appreciated. Cheers, Ian.