onaudit: precision of datetime of audited events?

IDS 12.10.FC14 SOLARIS 10 1/13 The onaudit utility creates audit trail files, as documented here: Audit-record format The second field is the date and time of the audited event. I have enabled auditing with onaudit, and observe the audit trail files, and see that all the timestamps recorded in the audit trail files have precision only to the level of second . For example, the following string was copy-and-pasted from an audit trail file: "2024-08-22 12:30:54.000". The documentation ( Creating a table for audit data ) , quoted below, shows how to create a table to store output from the audit trail files. Note that IBM shows the creation of a table which uses a precision of 1 millisecond for the datetime element: The sample CREATE TABLE statement in the following example creates an audit table with the name frag_logs... CREATE TABLE frag_logs ( adttag CHAR(4) NOT NULL, date_time DATETIME YEAR TO FRACTION(3) NOT NULL, hostname VARCHAR(128) NOT NULL, pid INTEGER NOT NULL, server VARCHAR(128) NOT NULL, username VARCHAR(32) NOT NULL, errno INTEGER NOT NULL, code CHAR(4) NOT NULL, dbname VARCHAR(128), tabid INTEGER, objname VARCHAR(128), extra_1 INTEGER, partno INTEGER, row_num INTEGER, login VARCHAR(32), flags INTEGER, extra_2 VARCHAR(160) );QUESTION: How can I get onaudit to produce audit trail files with the event timestamps having 1 ms precision? I am unable to find anything in the documentation that would indicate a way to do this. In short, I would like to have the audit trail files from onaudit provide the times of the events at the 1 ms level of precision. Thank you for any comments. I am reluctant to burden Tech Support with something that seems like I should be able to determine from the documentation. But, alas, I am unable to do so. DG ------------------------------ David Grove ------------------------------

David: I'm not sure if this affects the timestamps in the audit modules, but there is an ONCONFIG parameter, USEOSTIME, that improves the resolution of CURRENT from seconds to the maximum resolution of the processor. It defaults to zero (off) mainly because early on Informix mostly ran on XENIX and the gettimeofday() call that enabling this parameter uses was dirt slow in XENIX. In all modern OS's that system call is fast, so there is no longer any reason to not enable it in your ONCONFIG file. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

Good call Art! I just tested this and setting USEOSTIME to 1 now includes the time fraction in the audit log. The time fraction went from .000 ONLN|2024-08-23 21:18:21. 000 |localhost|1217|informixtest_shm|informix|0:INRW:sysmaster:232:1026:2566:: ONLN|2024-08-23 21:18:21. 000 |localhost|1217|informixtest_shm|informix|0:CLDB:sysmaster to showing the fraction: ONLN|2024-08-23 21:19:54. 243 |localhost|1290|informixtest_shm|informix|0:INRW:sysmaster:232:1026:7436:: ONLN|2024-08-23 21:19:54. 245 |localhost|1290|informixtest_shm|informix|0:CLDB:sysmaster ------------------------------ Mike Walker xDB Systems, Inc www.xdbsystems.com ------------------------------

Thank you, Art and Mike, for that information. That exactly fills the bill! DG ------------------------------ David Grove ------------------------------

Perhaps this line from the documentation on the ONCONFIG parm USEOSTIME: " Systems that run with USEOSTIME set to nonzero notice a performance degradation of up to 4 to 5 percent compared to running with USEOSTIME turned off ." is no longer accurate, then. That would be a high price to pay. But, I'll give it a shot andl change that parm in our next maintenance window for our production server. DG ------------------------------ David Grove ------------------------------

Yea. With USEOSTIME unset the engine uses an internal full second "clock" value that is only updated every 15 seconds or so. Art

David: My understanding that making the change now has little effect came from one of the developers years ago. I honestly have not benchmarked it, but a) I also have not noticed any significant degradation when enabling it, and b) if you need the resolution you don't have any good alternatives. Art ------------------------------ Art S. Kagel, President and Principal Consultant ASK Database Management Corp. www.askdbmgt.com ------------------------------

For the last few years I have always set USEOSTIME The last time I tested it was slower but not enough to care about until the load levels where high. At 'normal' load levels I don't see a statistical relevant performance drop. https://www.oninit.com/bench/index.php?id=useostime.html Cheers Paul

Hello, The performance degradation for what we experienced in the past years using « onaudit » came primarily from the type of verbs that we wanted to audit rather than from the usage of USEOSTIME. Auditing the verb RDRW ( read row) definitely degraded the performance ( even without activating USEOSTIME) since most of the actions we do are SELECTs in any application. We usually advice to audit unusual actions ( the onaudit verbs equivalent to ALTERs for example, DROP, etc). Khaled Bentebal de mon portable