Many seasoned database administrators howl in protest at the mere suggestion of running native auditing functions due to the poor performance and log management headaches that often come with auditing.What's with the stigma? And what kind of performance degradation given that database auditing is supposed to provide an accurate and complete source of information for a broad range of security and compliance requirements? In several series of performance tests I have conducted during the past four years, just turning on the audit decreased transactional throughput by 44 percent for an Oracle audit, 31 percent for IBM DB2, and 37 percent for SQL Server trace. This is not acceptable. And this decrease came just from creating the audit trail and doesn't include moving the data to an external analysis or reporting tool.
But once I tuned the process, the performance decrease was 6 percent for Oracle, 9 percent for DB2, and 4 percent for SQL Server.
How did I do this? By carefully selecting the right options at my disposal. Specifically, consider the following:
In general, the relational database vendors know their customers rely on auditing to support compliance and security requirements, and they have greatly improved performance during the past four years. If you are smart with your setup, then auditing is no longer the performance nightmare it once was. Don't let a previous bad experience keep you from exploring database auditing as an option.
Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading. Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and ... View Full Bio