Preventive controls on Db Admin activity

If I understand your question correctly, the answer is no.  The privileges to view permission-related behavior is limited to the sysdba or sysoper type accounts, so external controls cannot be used that manner.  Before you get side-tracked with vaults or wallets, can we clarify whether your concern is truly "audit", the reporting of events such as attempts to alter the payroll table -- or database security?  

At a high level, database security is controlled by granting SELECT, INSERT, UPDATE, DELETE, ALTER, or EXECUTE permissions on a schema object to one or more other accounts.  Generally we use ROLES to define the set of permissions needed by a class of user, as appropriate for development, test, or production.  In addition, PROFILES provide control of a user's resource consumption limits, and password enforcement.  For example, you'll find in the rdbms/admin folder a package that the profile can use to enforce your organization's password policy.

Am I on track with your intent?  I'll be glad to help further.

The concerns largely emanate from external auditors comments in their Audit report where they (as most of the auditors routinely do), state that there is no effective mechanism to audit DB Admin activities.
Oracles inbuilt audit mechanism is too crude to be effectively taken as an efficient 'preventive' mechanism in case the DB Admin is upto some malicious activity. Auditing DB Admin activity is, according to Auditors, only a detective rather than preventive control. One way is to create a profile that enables drop/delete and other such high level activities of DB Admin and then share that password with some support manager or internal security function but to me, that's not practical and doable in our scenario.

The auditors concern here is and you guessed it the DB Admin attempts to alter the payroll tables, drop and change table values and do away with the logs generated while he/she did all that.

My condolences, if your shop cannot trust its adinistrators to have integrity.  I have worked (a short while) as an IT special auditor for Alcoa, but this is draconian indeed.  What O/S?  On UNIX/LINUX it's fairly common to require a DBA to login as oneself, then su to the OPS$DBA account where the OPS account is indentified externally -- so that the OPS account may SQLPLUS "/" from the database node but not from his/her PC.  In my current shop, the schema owner accounts are locked in production.  A scheduled release plan is required to do any DDL.

Do you have specific deliverables required to satisfy your external pests, I mean guests?

Your last line says it all..it's not about my shop truting it's DBAs it's about external auditors report and their observation that we should have preventive rather than detective controls on our DBA activities. All said and done, it's easy to make our comment on their report that 'we accept the inherent risk' but I was only wondering if there is a doable solution in light of our Oracle 9i running on windows 200/3 OS?
It appears that you are following a well laid out release plan, can you please relate that in a nutshell, I mean, how do you cater to code change between development to production. (I've increased the points :)

Forced accept.

Computer101
EE Admin