Oracle Database Auditing Performance Guidelines

Transcription

1 Oracle Database Auditing Performance Guidelines Anjo Miguel Consultant July 2011

2 Enabling Oracle Database Audit could potentially have an impact on database performance, but how much? Is it measurable? What is the best configuration for optimal auditing and minimal performance impact? Oracle addressed this topic in there white paper Oracle Database Auditing: Performance Guidelines. We did our own test on our test infrastructure. This paper provides information about the tests and the lessons learned. 1. Introduction Homonymous Oracle s white paper (Oracle, August 2010) presents results of throughput and additional CPU usage after enabling auditing. Their results show an increase between 1.4% and 14.1% on throughput time and between 1.7% and 15.8% on additional CPU usage. Unfortunately there is not much information on the tests: where the transaction time was spent, which tool they use to measure, how many tests were run, etc. With the tests below we tried to get the same (or at least similar) results by running as close as possible as described on Oracle s white paper. We did not manage. There were both better and worst results. There was not so big difference between each type of auditing and the worst result showed only 5.8% throughput difference. On the other hand the best results were never as good as Oracle paper shows. It was also measured the overhead of using just the new default Oracle 11g audit settings and also the difference on Redo size per transaction, block changes, logical reads and spaced used for audit information depending on the way we perform the audit task. 2. Test Environment The tests were done on a Trivadis virtual machine running Linux and Oracle bit vanilla (no extra patches). The VM has 2GB of memory allocated and /proc/cpuinfo shows 2 cores of AMD Opteron 2.4GHz. Oracle database had the following parameters modified: MEMORY_TARGET=900M FILESYSTEMIO_OPTIONS=SETALL Due to slow IO system, there were a lot (22%) of log file sync and log file parallel write wait events. It was decided to make redo log writes asynchronous. This solution is only valid if you accept data loss in the event of a crash of the database. The following parameters were changed: COMMIT_LOGGING=BATCH COMMIT_WAIT=NOWAIT [email protected]. Info-Tel Date Page 2 / 7

3 After this change the wait events related to redo log decreased to just 1.5% and the two biggest wait events (CPU time and db file sequential read) counted for 95% of the wait time. There were 5x 100MB redologs and the DB was in NOARCHIVELOG mode. For creating load it was used SwingBench 2.3 (SwingBench) with a TPC-C like work and configured to use around 70% CPU without any audit enabled (20 parallel users, random 20ms to 40ms wait between transactions). 3. Audit Best Practices The best practices from Oracle documentation were followed: - Move audit tables aud$ and fga_log$ outside SYSTEM tablespace - Set large file-size OS audit files with DBMS_AUDIT_MGMT - Perform cleanup operation on all audit trail types 4. Measurements Each run of test took 180 seconds, getting both Swingbench and AWR statistics on the work done between the second 60 and 120 of the test. Figure 1 - Swingbech workspace during the tests There were three sets of runs, changing the audit parameter between each run. For each configuration there were at least three runs (one on each set set) and only the best result was kept. Between each run the audit tables were truncated, schema statistics gathered and instance bounced. After each set of runs the schema was dropped and re-imported. The order of the tests changed in each of the sets. [email protected]. Info-Tel Date Page 3 / 7

4 Overhead AWR results Wait times 5. Results g Default Audit Settings Starting with Oracle Database 11g there is a script $ORACLE_HOME/rdbms/admin/secconf.sql (called by default when creating a database with DBCA) which enables auditing for the following security-relevant SQL statements and privileges: ALTER ANY PROCEDURE CREATE ANY JOB DROP ANY TABLE ALTER ANY TABLE CREATE ANY LIBRARY DROP PROFILE ALTER DATABASE CREATE ANY PROCEDURE DROP USER ALTER PROFILE CREATE ANY TABLE EXEMPT ACCESS POLICY AUDIT ROLE BY ACCESS CREATE EXTERNAL JOB GRANT ANY OBJECT PRIVILEGE ALTER SYSTEM CREATE PUBLIC DATABASE LINK GRANT ANY PRIVILEGE ALTER USER CREATE SESSION GRANT ANY ROLE AUDIT SYSTEM AUDIT SYSTEM BY ACCESS CREATE USER DROP ANY PROCEDURE The impact of this auditing activity is relatively small whichever audit method is used. In our tests these default settings generated entries only at beginning and at the end of each session. 11g standard auditing AUDIT TRAIL none OS DB XML CPU Time 78% 76% 75% 73% db file sequential read 17% 19% 20% 21% SwingBench Transactions/s 57,1 56,83 56,65 56,82 Transactions/s 68,00 67,20 68,80 68,40 Redo size/transaction (bytes) BlockChanges/transaction 10 10,3 10,2 10,3 LogicalReads/transaction ,3 345,6 337,1 CPU Usage 67,10% 70,10% 68,20% 65,20% time/transaction (SwingBench) 0,00% +0,47% +0,79% +0,49% time/transaction (AWR) 0,00% 1,18% -1,18% -0,59% redo generated/transaction 0% 6% 5% 5% block changes/transaction 0% 3% 2% 3% Table 1 - Results with 11g default auditing enabled The overhead is negligible (AWR even showed better results!) and there is only 5% more of redo generated. [email protected]. Info-Tel Date Page 4 / 7

5 Overhead AWR results Wait times 5.2 Normal Audit Overhead For this test the audit on INSERT and UPDATE by the TPC-C schema was enabled. It generated about 110 audit records per second. SQL> audit insert any table by soe; Audit succeeded. SQL> audit update any table by soe; Audit succeeded. The results were the following: AUDIT TRAIL none OS XML AUDIT INSERT+UPDATE BY SOE XML, DB DB, CPU Time 78% 73% 70% 70% 71% 71% db file sequential read 17% 21% 23% 25% 21% 24% SwingBench Transactions/s 57,1 54,33 53,78 54,67 54,93 53,92 Transactions/s 68,00 66,90 66,60 66,80 66,80 66,30 Redo size/transaction (bytes) BlockChanges/transaction 10 10,5 10,4 10,4 16,3 36,9 LogicalReads/transaction ,2 338, ,4 419,5 CPU Usage 67,10% 68,40% 65,00% 72,90% 72,70% 69,50% Audit trail size (18k entries) 0 6,5MB 11MB 14MB 3MB 7MB time/transaction (SwingBench) 0,00% +4,85% +5,81% +4,26% +3,80% +5,57% time/transaction (AWR) 0,00% +1,62% +2,06% +1,76% +1,76% +2,50% redo generated/transaction 0% +4% +6% +5% +84% +109% block changes/transaction 0% +5% +4% +4% +63% +269% Table 2- Results with audit of certain statements The extra time spent per transaction does not have a significant difference between the methods used. While SwingBench showed an overhead above 3,8%, AWR revealed an extra work that ranged between 1.6% for OS setting and a maximum of 2,5% for DB, setting. The big differences seen here are in terms of redo generated and block changes. Any setting to write audit on the DB generates two times more redo and can triple the number of block changes. This can have impact on the performance and also on space needed for archived logs. In terms of spaced used by the audit trail, XML settings used 2 to 3 times more space than a DB setting. Audit trail set to OS stays on the average of performance and space consumed. [email protected]. Info-Tel Date Page 5 / 7

6 Overhead AWR results Wait times 5.3 Fine Grained Audit Overhead The tests for FGA were made by creating the following policy that generated about 100 audit records per second: dbms_fga.add_policy ( object_schema => 'SOE', object_name => 'PRODUCT_INFORMATION', policy_name => 'TestAudit', audit_condition => 'SYS_CONTEXT(''USERENV'',''MODULE'') = ''Browse Products''', audit_trail => DBMS_FGA.XML+DBMS_FGA.); The results were the following: AUDIT TRAIL none XML XML, DB DB, CPU Time 78% 76% 78% 56% 52% db file sequential read 17% 18% 17% 20% 21% log file parallel write 17% 15% SwingBench Transactions/s 57,1 55,58 54,57 54,55 53,98 Transactions/s 68,00 68,50 66,30 67,10 65,70 Redo size/transaction (bytes) BlockChanges/transaction 10 10,6 10,2 16,3 29,3 LogicalReads/transaction ,5 344,2 360,1 387,5 CPU Usage 67,10% 69,20% 67,00% 72,70% 71,30% Audit trail size (18k entries) 0 3MB 10MB 9,3MB 16MB time/transaction (SwingBench) 0,00% +2,66% +4,43% +4,47% +5,46% time/transaction (AWR) 0,00% -0,74% +2,50% +1,32% +3,38% redo generated/transaction 0% +5% +4% +76% +112% block changes/transaction 0% +6% +2% +63% +193% Table 3 - Results with usage of fine grained auditing It is interesting to see that the results between the usage of normal audit or fine grained are not very different. However we can see that the overhead is higher when using DB based audit trail compared to XML based. There is a relatively important wait time on log file parallel write when running with FGA targeted to the DB, which did not appear in any of the other tests (and this wait time was consistent between each set of runs). The redo generated was again at least 75% more when making the audit trail on the database. 6. Conclusions The new Oracle 11g default audit settings are appropriate for any database and do not represent an important overhead. However one should not forget to use Oracle Audit best practices, control the space used by the audit and perform regular clean-up with the 11.2 DBMS_AUDIT_MGMT package. [email protected]. Info-Tel Date Page 6 / 7

7 When deeper audit in needed (either standard or fine grained), it is better to use OS/XML based auditing to avoid doubling the redo size generated when using DB based audit. 7. Future Work Several difficulties were found due to the dynamic resource allocation from the virtual machines server. This feature was making performance to change at random points of the result collection. Trivadis VMs are designed for functionality tests thus their performance is not optimized and bottlenecks were detected on the I/O subsystem. For better results this test should be performed on a physical machine or on a VM without dynamic resource allocation and which has a good I/O subsystem attached. Figure 2 - Dynamic resource allocation were changing the performance of the machine during the test Different test can be planned by simplifying the load to a simple loop that selects nothing, and this way avoiding most of the I/O. A test like this would probably permit to get more accurate results on the overhead of audit, even though it would not be a realistic workload. Other suggestions are welcome. Every success in the use of Trivadis expertise wishes Miguel Anjo Trivadis SA Rue Marterey 5 Tel: CH-1005 Lausanne Fax: Internet: Mail: [email protected] Literature and Links Oracle. August An Oracle White Paper - Oracle Database Auditing: Performance Guidelines: August SwingBench. [email protected]. Info-Tel Date Page 7 / 7