Você está na página 1de 6

What is an AuditTrail?

An AuditTrail is one of functionality for retaining a history of changes to data. What ,who
and when can be identified on a particular table or column if the functionality is enabled.

When you enter or update data in your forms, you change the database tables underlying
those forms. An audit trail tracks which row in the database was updated at what time,
and which user was logged in using the associated form(s).

If you are seeking auditing ability to track changes on a particular table of Oracle this
post might helpful to you.

Enabling the Functionality of AuditTrail

You can turn AuditTrail on or off (Yes or No). Normally the default setting is No (Off).
When you enter or update data in your forms, you change the database tables underlying
the forms you see and use. AuditTrail tracks which rows in a database table(s) were
updated at what time and which user was logged in using the form(s). Also..

Several updates can be tracked, establishing a trail of audit data that documents
the database table changes.
AuditTrail is a feature enabled on a form-by-form basis by a developer using
Oracle's Application Object Library.
All the forms that support AuditTrail are referred to as an audit set. You should
also note not all forms may be enabled to support AuditTrail.
To enable or disable AuditTrail for a particular form, you need access to Oracle
Application Object Library's Application Developer responsibility.
Users cannot see nor change this profile option.
This profile option is visible and updatable at the site and application levels.

The internal name for this profile option is AUDITTRAIL:ACTIVATE.

Setting Up AuditTrail(>11i )

You can choose to store and retrieve a history of all changes users make on a given table.
Auditing is accomplished using audit groups, which functionally group tables to be
audited. For a table to be audited, it must be included in an enabled audit group.
The steps for setting up AuditTrail include:

Yuu need to verify Select Privileges on SYS.DBA_TABLES

Have your database administrator grant SELECT privileges on SYS.DBA_TABLES to


the APPLSYS account. Normally, this step would Normally taken care during the
installation of Oracle.

Define Audit Groups

This is very very important.These are groups of tables and columns, where you do not
necessarily need to include all the columns in a given table. You enable auditing for audit
groups rather than for individual tables. You would typically group together those tables
that belong to the same business process (for example, purchase order tables see at the
end).

A given table can belong to more than one audit group. If so, the table is audited
according to the highest "state" of enabling for any of its groups, where Enabled is the
highest, followed by Disable Dump Data, Disable No Growth, and Disable Purge Table,
in that order.

Navigation: Security -> AuditTrail -> Groups

Define Audit Installations

You choose the registered Oracle IDs at your site that you want to audit. This allows you
to audit across multiple application installations. When a table is added to an audit group,
auditing will automatically be enabled for all installations of the table for which audit is
enabled.

Navigation: Security -> AuditTrail -> Install

Run the Audit Trail Update Tables Report to Enable Auditing

Your AuditTrail definitions (and auditing) do not take effect until you run the Audit Trail
Update Tables Report. If you change any of your definitions later, you must rerun this
program. You run the Audit Trail Update Tables Report from the standard submission
(Submit Reports) form.

Audit Trail Update Tables Report

This program creates database triggers on the tables in your audit groups for your
installations. It also creates shadow tables, one for each audited table, to contain the audit
information. If you have changed your audit definitions or disabled auditing for an audit
group, the program drops or modifies the auditing triggers and shadow tables
appropriately.
The program also builds special views you can use to retrieve your audit data for
reporting.

You can check SQL*Plus to see if the Shadow Tables have been created or not. Shadow
Table name is the same 26 Characters of the Table being audited followed by a suffix of
"_A" ,suffix of "_AI" for Insert Triggers, "_AU" for Update triggers , "_AD" for Delete
Triggers,suffix of "_AIP" for Insert Procedures "_AUP" for Update Procedures and
"_ADP" for Delete Procedures.

AuditTrail Limitations

These are limitation of AuditTrail:

Your table should consist of maximum 240 columns


You cann't use the column for audit trail whose data type is LONG, RAW, or
LONG RAW
Your audit group must include all columns that make up the primary key for a
table; these columns are added to your audit group automatically.
Once you have added a column to an audit group, you cannot remove it.
AuditTrail requires two database connections. If your operating platform does not
automatically support two database connections
(e.g., VMS or MPE/XL), then add the environment variable 'FDATDB=<database
connect string>' to your environment file.
Because the structure of the audited table may change between product versions,
AuditTrail does NOT support upgrading existing shadow tables or audited data.
Before an upgrade, you should archive the shadow tables and perform all
necessary reporting on the audited data.
Oracle recommended Disabling AuditTrail feature Prior to Upgrade to higher
version.
If your plan is to use some auditTrail on table which name is bit longer(> 26
characters), you can't achieve this. As there is Bug(#3872242
) reported by Oracle that restrict you from this, as AuditTrail Update Tables Errors
out on audited tables that are > 26 characters.

Sometime back we found while enabling this on these tables.

PO_REQUISITION_HEADERS_ALL
PO_REQUISITION_LINES_ALL
PO_REQ_DISTRIBUTIONS_ALL

What are the primary Auditing Tables?

FND_AUDIT_COLUMNS
FND_AUDIT_GROUPS
FND_AUDIT_SCHEMAS
FND_AUDIT_TABLES
Client Dilema : HOW TO ENABLE AUDITING AT "FORMS" AND "USER"
LEVEL TOGETHER

Customer has set the profile "Sign-on: Audit Level" to FORMS to collect information
about the forms sessions at a particular time .
By default the value for this profile was USER. Since he has set the value to Forms can
he collect the User related information

Yes you can ...


If the profile "Sign-on: Audit Level" is set to FORMS then it will collect Form sessions
information in addition to user session information.
So you will get information related to User session as well as forms session. There is no
harm in setting this profile value to FORMS.

Steps by step: Enabling audit trial

As per the below example the 'Define An application user' is a user table name for
FND_USER,the same steps you can follow for your own tables.

1. Go to Audit Trail -> Tables -> Query for Define an Application User.let say you
are suppose to do the audit on these tables.
o PO_DISTRIBUTIONS_ALL
o PO_LINES_ALL
o PO_LINE_LOCATIONS_ALL
o PO_HEADERS_ALL
2. Add the columns whatever you want to audit.
3. Go to Audit Trail -> Groups -> Query for Audit Setup Group
4. Enable the 'Audit Setup Group'.
5. Run audittrail update table.
6. add the Define an application user table under Audit Setup Group.
7. Run the audit train update table again.
8. Go to Audit Query Navigator ->Functional Groups-> Now you can see the Define
an Application user table added under the audit setup
group.
9. If the table is available as per the step 8,Now run the Audit trail report,you will be
able to get the audit information.

Steps by step: How to Disable AuditTrails

There are three ways to disable auditing feature:

1. Disable Prepare for Archive


2. Disable Interrupt Audit
3. Disable Purge Table
Steps by step: How To Remove a Column From Audit Trial Tables?

1. You need to navigate with System Administrator responsiblity Security ->


AuditTrail ->Groups
2. Query the group that contains the table that you want to modify columns
assignment
3. Disable this group using the option : Disable - Purge Table
4. Run the concurrent request "AuditTrail Update Tables"
5. Truncate fnd_audit_columns drop all triggers,procedure, view , synoyms
6. Make a copy of table "FND_AUDIT_COLUMNS"
7. Go to the following navigation path : System Administrator -> Security ->
AuditTrail -> Tables
8. Query your table that you need to remove a column from it.
9. Go to Help -> Diagnostics -> Examine <Enter apps password>
10. Choose the field = COLUMN_ID and take remark of that value
11. Choose the field = TABLE_ID and take remark of that value too.
12. Login to sqlplus using apps/<apps password>
13. Execute the following:
delete from FND_AUDIT_COLUMNS where TABLE_ID = <value in step 10>
and column_id = <value in
step 9>;
14. Save you work
15. Go back to step 1 and query the group that contains the table that you made the
columns change and Enable this group using the option : Enabled
16. Finally complete this by executing the concurrent request "AuditTrail Update
Tables"

Steps by step: Enabling Audit Trail for Custom Objects

The process remain same, as mention above. You should make sure that your
have used ad_dd package to create custom objects in Applications. and you have used
ad_dd.register_table to register table and ad_dd.register_column to register columns

Your step for enabling custom Object should be as

Grant select on table to APPS


Create a synonym as APPS to the table
Run the AD_DD package to register the table
Run the AD_DD package to register the columns
Run the AD_DD package to register the primary keys
o execute ad_dd.register_primary_key('application short name', 'primary key
column name', 'table name','description of key column', 'S', 'Y','Y');
o execute ad_dd.register_primary_key_column('application short name',
'primary key column name', 'table name', 'column name', 1);

or you can also do it In the screen:


-> Security > Oracle > Register

Report helpful while enabling this feature

As discussed in last post these two report is important.

AuditTrail Report for Audit Group Validation


AuditTrail Update Tables

Você também pode gostar