I'd like to attempt to make a list of the things DBA2 can or can not do - and I would invite anyone to add/comment on this - consider this just a starting point...

Basically, I will assume there are two users with DBA authority named DBA1 and DBA2, and would assume that DBA2 might turn into malicious intentions:

I. What DBA2 can do:

• DBA2 can alter or drop any database object any other user (including DBA1) has created.
• DBA2 can alter (grant/revoke) any permissions on any database object.
• DBA2 can revoke DBA1's DBA authority - and vice versa.
• DBA2 can drop DBA1's user account or change its password (or set it to an empty string to disallow any connection from DBA1) - and vice versa.
• DBA2 can modify/drop any login procedure that would try to enforce particular login logic.
• Encrypted tables/columns are just stored in encrypted form, but are decrypted when accessed - therefore any user with access to such data can read the "plaintext", including DBA2.

II. What DBA2 cannot do:

• As anybody else, DBA2 cannot read the source of any object SET HIDDEN by DBA1 (and cannot set it UNHIDDEN, as there no such statement - but DBA2 can still ALTER the object).
• Strong database encryption is beyond database authorities: In case DBA1 knows the DBKEY whereas DBA2 does not know it, DBA2 won't be able to start the database if this requires the entering of the DBKEY. The same is true for translating encrypted logs.
• In case the database server runs with secured features, and a key is specified to allow secured features in particular cases, and only DBA1 knows this particular key for this (dbsrv12 -sk key), DBA2 cannot re-enable these features. (However, DBA2 might be able to start the database - or a copy - on his own without securing these features or with a different key).
• In case the database contains data that is encrypted on an application level (i.e. outside the database), and DBA2 does not know about that encryption, then he cannot read the decrypted data (but could change it to anything else).