Re: Transaction logs and audit trails - quick overview required

Ian Clark <ian@tubeway-army.demon.co.uk> wrote in article <34c85f8c.72776308@news.demon.co.uk>... > 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! Look at what type of database you have : -no logging -buffered logging -unbuffered logging (or ANSI) Speculation is that you have a no logging database otherwise every elementary would be committed at once . When in a crash situation such a database has the data of the last Checkpoint. Logging database can reconstruct data after a crash (difference between buffered and unbuffered depends how much data can be reconstructed) Thru an automatic Roll-forward. > > 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? when restarting the engine it will roll forward from the last checkpoint,applying all the not applied situation till all not written Logical Logs are applied to disk and then rollback the still open transactions. Only update Data is found in the Logical Log .So after a crash simply restart the engine. if it crashes again (error is in update ,delete statement you are in deep trouble and must attempt a restore with point in time recovery) on the restart call tech support. > 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? I can not help you on audit trail since I only use them to monitor connection of a few users. > 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. > Gaetan Maerten, Informix DBA, EDS Belgium (Bacob account)