Re: auditing dml

On Tue, Oct 28, 2008 at 3:19 PM, Floyd Wellershaus <floyd@fwellers.com> wrote: > We are going to be running some intensive testing between two > applications, on different databases. > The plan was to run the apps, then compare the database tables afterward. > But that is going to be too much, due to the size of our tables and the > number of tables. > It was suggested to either use auditing, or possibly onlog. In that way, > instead of examining all rows in all tables, we can just compare the ddl and > dml that are run on both servers after the apps do their thing. > > 2 questions: > 1) Is there a tool that can extract the contents of the logical logs and > present all dml that was run, in a readable fashion ? No; the logical logs do not capture SQL statements - DML or DDL - in any meaningful format. The logical logs contain row-level/page-level information - frequently just the changed bytes - and not statements. > 2) In case #1 doesn't work or isn't plausible, I may need to set up > auditing. By what I am reading in the overview of auditing, I can set up > masks on certain dml and ddl events, like insert, update, delete, drop, > create etc... > The timeframe I have to do this, and the time I have to do it within the > timeframe is very limited, so before I go too far down this road, I'd like > to ask if there are any shortcuts or tips or templates to make it easier. > Is auditing very hard to do for a limited number of users and events ? ( > this is just for testing purposes ) > > Is it something that I will definitely need to get informix support to help > me with, or can someone point me in the right direction aside from just > reading every word about auditing in the manual ? There should be auditing presentations from conferences past available online. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.