Monitor table usage in oracle 10g without monitoring the indeces

I want create a report on what tables are used in my database to eliminate the tables which are never accessed used.

i found this article which does this task but it mnitors the index(es) on each table

But in my problem I have to monitor the table access/usage by monitoring the columns...

i am using Oracle 10g with ~1100 tables
Who is Participating?

Improve company productivity with a Business Account.Sign Up

mrjoltcolaConnect With a Mentor Commented:
Don't use triggers for this, use FGA.

Using triggers is less desirable as it can affect the actual transactions if you have errors. Use FGA feature, thats what is for. You don't even need the normal auditing configured, but you do need to set "audit_trail" to db_extended:

See below my example using the SCOTT EMP sample schema.

-- Sample 10g Fine Grain Auditing policy setup
-- mrjoltcola
-- Use the EMP schema (SCOTT/TIGER) to demonstrate fine-grained auditing (@{ORACLE_HOME}/rdbms/admin/utlsampl.sql)
-- 1st check database to see if either AUDITING and/or FGA support is setup
show parameter audit
Should see:
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest                      string      C:\ORACLE\ADMIN\DEV\ADUMP
audit_sys_operations                 boolean     FALSE
audit_trail                          string      NONE
-- We don't have to have standard auditing on, but to use standard auditing, set AUDIT_TRAIL above
-- Change to db_extended so we get fine grained audit plus SQL_BIND (bind vars) and SQL_TEXT auditing. Then restart database
sqlplus / as sysdba
SQL> ALTER SYSTEM SET audit_trail=db_extended SCOPE=SPFILE;
SQL> shutdown immediate
SQL> startup open
-- To use FGA, we use FGA policies
-- FGA
-- Add a SALARY policy to the EMP table
-- Run as SYS or another user with execute on package dbms_fga
-- Default action is to audit SELECT but with 10g we can add DML actions by adding to statement_types parameter
-- Setup a policy to audit access of Employee Salaries
   dbms_fga.drop_policy (
   dbms_fga.add_policy (
      audit_condition => NULL,  -- TRUE
      audit_column    => 'SAL',
      statement_types => 'SELECT,INSERT,UPDATE,DELETE'
connect scott/tiger
-- Scott selects salaries and then gives self a raise
select * from emp;
update emp set sal = 30000 where ename = 'SCOTT'; 
-- DBA connects and checks audit trail
connect / as sysdba
-- Find who ran what against EMP table
select timestamp, db_user, sql_text from dba_fga_audit_trail where object_name = 'EMP';
01-APR-09          SCOTT	select * from emp
01-APR-09          SCOTT	update emp set sal = 30000 where ename = 'SCOTT'

Open in new window

I'll say right away that I am not aware of a table that has LAST ACCESS time of a table, but I welcome another expert to enlighten me. DBA_TAB_MODIFICATIONS does log DML, but a SELECT is not DML.

What you CAN do is to use 10g Fine Grained Auditing and set a policy on all those tables to log SELECT. Then run a report at the end of 30 days, or however long, and you'll see who is accessing what.
Oracle doesn't keep explicit data about the usage of the tables.
If you need this you can create triggers to monitor DML (DELETE, INSERT, UPDATE)
activities, but there is no possibility to monitor SELECT access.

There is Fine Grained Audit fature:

9i  FGA provides support for SELECT statements only.
10g FGA extends in the following ways:

    --> Support for DML statements :
        A. INSERT
        B. UPDATE
        C. DELETE
Auditing is turned off by default in Oracle, so unless you (or some DBA at your organization in the past) has turned on auditing, your audit_trail will be empty!

The audit records can either be written to an ASCII log file on the server, or they can be written to the database where they are visible in the view: DBA_AUDIT_TRAIL.  This is controlled by the init parameter: "AUDIT_TRAIL" that can be set or changed in your init*.ora file or spfile.
When you say you "have to monitor the table access/usage by monitoring the columns..." do you mean you need to identify when data changes in each column of every table?

If so then you could turn on auditing or build your own triggers to gather the required information about which columns have changed.  Turning on auditing will be an overhead to the running of your database and will potentially generate lots more data that will need to be managed.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.