If you wish to secure or prevent users with viewing certain data, why cant you go ahead creating a view.
As far as I know, users with DBA role and the object owner can export them to dmp files, and the only options that I can think of securing these objects from the Object owner or the DBA role users is by creating an Oracle Wallet.
dear Justin , i have about 2 weeks testing ODV .. this is not secure with console session on the DB server and this not applicable with My BCase ..
simply i want to prevent ( ANY ) access role with DBA (RDBMS , DBF ,CONF ,DLL)
so if there is any other solution . i'll be glade again
Sorry, I understand that you're having problems with Oracle Data Vault. I can't quite figure out what problems you are having. I don't understand what "bcase" stands for. I don't understand why Data Vault is "not applicable". I don't understand what the set of acronyms you posted has to do with anything. DBF is a common extension for Oracle data files but I don't understand what that has to do with Data Vault. I don't understand what a DLL has to do with anything. Oracle is an RDBMS but, again, I don't see how that is relevant.
i am very sorry for misunderstanding ..
i mean that : any user has OS privileges can edit ODV configuration file and disable or enable database and controlling oracle database physical component and this is the main problem in my business case .. how to prevent (ANYONE) controlling database and stopping DBA control power in the Database ..
thanks for reply and again i am sorry for misunderstanding
Taking a step back my POV would is . . .
Trusting your OS users that can control the database (SysAdmins and DBAs) would be a vetting process outside of any software.
Use business policies such as Separation of Duties (SOD) so that only proper individual can modify ODV is a requirement.
SOD should supply you with one form of checks and balances.
ODV can and does supply methods to restrict and separate duties.
My previous implementation of ODV was able to restrict DBA access to what is necessary to do their job and only their job.
No access to schema data or code.
You can always define your own roles to accomplish SOD within the database.
FYI: Oracle Database 12c has a better SOD with additional granular roles of that breaks up SYSDBA privileges.