However, as already suggested, if the en/decryption takes place before/after storage/retrieval, then there should be no reason for obtaining the key to troubleshoot. Any database activity the administrator can address would be on the encrypted data anyway, so needing the keys is a red herring, and you've just been compromised by social engineering -- the weakest link in the chain.
Unless, of course, the administrator is also the developer. In that case, you've failed to properly compartmentalize. In which case, you've just been compromised by social engineering -- the weakest link in the chain.
As the other poster noted, when the salary is encrypted before entry, you effectively address this issue. But in this extreme case, you loose all ability to query on the salary data. You can still request it, but you can't request it within a range. That would need to be decrypted before you know it. Instead, you need a hashing/encryption algorithm that includes a limited amount of information, say a bin, embedded into the encryption data or maintained in a separate field or table that would allow you to perform at least some minimal searches on that data.
For example, post-pend a four-digit number at the end of each encrypted value, 0000 through 9999, to indicate a range of salaries. Then, you could query a specific bin or range of bins based on those last four digits. Or include a digital signature as part of the salary, to indicate who entered the data. (A separate table would work better, of course, since it's more normalized.) Again, in both cases, you need to know something about the type of data and the scope of possible queries during the design.
Of course it's expensive. And it doesn't get you out of auditing. Watching the sign that says the gate is closed doesn't tell you diddley about the guy climbing over the fence. So before you start down this road, you need to decide up front whether it will cost more to recover from compromised data, or to deter compromises.
Keep in mind that the first lesson in cypher is that there is no such thing as an unbreakable cypher. You can't prevent someone from getting access to your data no matter how hard you try. The question is rather, can you make hard enough that the subject would find it easier to go elsewhere, or if not, take long enough to decypher that by the time they get the data, it's no longer of value.