This content has been marked as final. Show 8 replies
Why do you "need" to rewrite the Perl script?
It seems to me, given the capabilities of the product to which this forum is dedicated, your Perl script is a reinvention of the wheel. I'd suggest putting it away and gain capabilities far beyond those you can code yourself.
PS: Re-engineering Oracle is a violation of your license agreement. That, likely, includes the audit records you are asking about.
Thank you for your answer.
I will try to explain the question more detailed.
One of our custormers want to store the messages in the audit log file into a table (something as below
create table audit_log (
Maybe someone will think that setting audit_trail=DB is a better solution. But our customer prefered this one.
So we wrote the perl script to extact the information from audit log file and write them into this table.
We can roughly guess the format of the audit log file(of Oracle Database 10g Release 10.2.0.4.0) . But we hope to have something to confirm our guess.
By the way , we have no will to re-engineering the oracle . It is far beyond our ability.
Due to the Oracle license issue I stated previously I doubt anyone will help you beyond advising you to stop your reverse engineering work unless you confirm with Oracle it is not a license violation.
Your customer wanting to store records in a table is hardly a reason to put yourselves at risk or to write a single line of Perl.
Oracle is more than capable of putting audit records into a table. You can then simply use a SQL statement, or a Materialized View, to extract what you wish.
Trying to understand the construction of an Oracle audit trail file is certainly NOT attempting to "reverse-engineer Oracle". That is quite obviously an extreme exaggeration. If it were the case, then one could also say that reading the published documentation on (for example) DBA_AUDIT_TRAIL is also "reverse-engineering Oracle".
To answer the original question: "There is no published documentation from Oracle Corporation on the format of an Oracle audit trail file." You have to figure it out yourself - and it changes without notice (as it did between 10.2.0.3 and 10.2.0.4).
Figuring it out could well be interpreted a reverse engineering. I would suggest getting advice from an attorney before making such statements. I am not speaking for Oracle in any manner. But I have observed situations where "figuring it out" resulted in being served with court papers.
Oracle publishes views of the audit trail data. You can find a list of the views for the 11.1 database here:
The audit trail does not really change between patchsets as that would constitute underlying structure changes and right now, the developers are not allowed to change the underlying structure of tables in patchsets. But, we can change what may be displayed in a column from patchset to patchset. For example, we are getting ready to update the comment$text field to display more information like dblinks and program names.
I personally don't like overloading the comment$text field like that, but sometimes when you need the information, that is the only choice except to wait for the next major release :)
As for the output of the audit log files, those can change between patchsets because of bugs that were found and some changes to support Audit Vault. My apologies out there for anyone that is reading the audit files written to the OS directly, I would recommend using the views.
Hope that helps. Tammy
The Number in  tell the byte-length of parameter values.
For example "ACTION : 'CONNECT'" means values for ACTION tag is of 7 char long.
The change was done to make this audit data more compatible with Audit Vault (An Awesome product to manage audit data of multiple Databases)
To answer your question specifically, the format of the audit files an Oracle database writes is not documented in public documentation. As user tbednar said earlier, Oracle does reserve the right to change this format without notice, and has done so a few times recently. Ignoring for a moment the legality of doing so, "figuring out" the format is something that's a bad idea simply because you can never fully figure it out. There will always be corner cases and changes over time. Therefore, it is best to stick to documented interfaces, such as the DBA_AUDIT_TRAIL view.