Oracle Audit Trail获取在上次交易中更新的列的列表

Question

Consider a table(Student) under a schema say Candidates(NOT DBA):

Student
{RollNumber : VARCHAR2(10),
Name : VARCHAR2(100),
CLass : VARCHAR2(5),
...
...
...
}

Let us assume that the table already contains some valid data.

I executed an update query to modify the name and class of the Student table

UPDATE STUDENT SET Name = 'ASHWIN' , CLASS = 'XYZ' 
WHERE ROLLNUMBER = 'AQ1212'

Followed by another update query in which I am updating some other fields

UPDATE STUDENT SET Math_marks = 100 ,PHY_marks , CLASS = 'XYZ' 
WHERE ROLLNUMBER = 'AQ1212'

Since I modified different columns in two different queries. I need to fetch the particular list of columns which got updated in last transaction. I am pretty sure that oracle must be maintaining this in some table logs which could be accessed by DBA. But I don't have the DBA access.

All I need is a the list of columns that got updated in last transaction under schema Candidates I DO NOT have the DBA rights

Please suggest me some ways.

NOTE : Here above I mentioned a simple table. But In actual I have got 8-10 tables for which I need to do this auditing where a key factor lets say ROLLNUMBER acts a foreign key for all other tables. Writing triggers would be a complex for all tables. So please help me out if there exists some other way to fetch the same.

Answer 1

"I am pretty sure that oracle must be maintaining this in some table logs which could be accessed by DBA."

Actually, no, not be default. An audit trail is a pretty expensive thing to maintain, so Oracle does nothing out of the box. It leaves us to decide what we what to audit (actions, objects, granularity) and then to switch on auditing for those things.

The Oracle requires DBA access to enable the built-in functionality, so that may rule it out for you anyway.

Auditing is a very broad topic, with lots of things to consider and configure. The Oracle documentation devotes a big chunk of the Security manual to Auditing. Find the Introduction To Auditing here . For monitoring updates to specific columns, what you're talking about is Fine-Grained Audit. Find out more .

---

"I have got 8-10 tables ... Writing triggers would be a complex for all tables."

Not necessarily. The triggers will all resemble each other, so you could build a code generator using the data dictionary view USER_TAB_COLUMNS to customise some generic boilerplate text.