This content has been marked as final. Show 6 replies
since you are using extended auditing, what is the sqltext recorded for the statements that did make it into the audit trail?
Harm ten Napel
They are being recorded as a regular ps insert.
Here's a sample
insert into CONF_VALOR_PROPRIEDADE (chave, configuracao_id, propriedade_id, valorBruto, version, id) values (:1, :2, :3, :4, :5, :6)
SQL_BIND: #1(36):xxx/protocoloacesso #2(3):300 #3(3):100 #4(5):https #5(1):0 #6(4):2102
Hi ,1 person found this helpful
the feature you are using seems to be ultimately mapped to a database feature called array insert and what you are
observing is not a bug, in this case the binds being shown are only for the LAST array bind value in a single audit record.
An array insert is akin to an "insert as select" operation in that it can create many rows in a single execution.
This information comes from diagnosing a similar problem in Bug 15932553 (not a bug),
Harm ten Napel
Thanks, very helpful piece of information!
But, is there a way to audit the entire array parameter, or it just can't be done?
After analising your answer I re-read the documentation. Your right, that's explicit on footnote1:
Columns with an asterisk (*) in Table 6-2 appear in the audit records only if you have set the AUDIT_TRAIL initialization parameter to DB_EXTENDED or XML, EXTENDED. Also, for an array, the values recorded are only the last set of bind values.
It just makes me wonder why isn't a way to override this... seems to me that oracle audit can work properly on any real world application
One way to collect this type of audit data is to use the REDO Collector of Audit Vault.
Ategrity Solutions Ltd