Tuning the Audit Vault Server

With use the Audit Vault Server database might run into performance issues. Adjusting database parameters to tune the Audit Vault Server to your needs will help resolve performance issues.

Preventing Shutdown of the Listener Due to Too Many Audit Trails

If there are more than 1024 audit trails on a single Audit Vault Server, the database listener might shutdown with errors TNS-01159: Internal connection limit has been reached; listener has shut down and TNS-12540: TNS:internal limit restriction exceeded. Adjust the MAX_ALL_CONNECTIONS_LISTENER parameter to resolve the issue.

Steps to adjust the MAX_ALL_CONNECTIONS_LISTENER parameter:

1. Stop all the audit trails running on the Audit Vault Server and the Audit Vault Agent.

2. Log in to the appliance through SSH and switch to the root user.

   See Logging In to Oracle DBSecCentral Appliances Through SSH.

3. Stop the following services by running the following commands:

   systemctl stop monitor
   systemctl stop javafwk
   systemctl stop controller
   systemctl stop dbfwlistener

4. Make a backup copy of the listener.ora file:

   cp /var/lib/oracle/dbfw/network/admin/listener.ora /var/lib/oracle/dbfw/network/admin/listener.ora.backup

5. Open the listener.ora file for editting:

   vi listener.ora

6. Add the following line in the listener.ora file:

   MAX_ALL_CONNECTIONS_LISTENER=<Number of trails | Number of trails > 1024>

   For example, if you have 1500 audit trails running:

   MAX_ALL_CONNECTIONS_LISTENER=1500

   It will be necessary to adjust this number if you intend to start more audit trails in the future.

7. Start the previously stopped services by running the following commands:

   systemctl start monitor
   systemctl start javafwk
   systemctl start controller
   systemctl start dbfwlistener

8. Start the audit trails that were previously stopped on the Audit Vault Server and the Audit Vault Agent.

Related Topics

• Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server

• Stopping and Starting Audit Vault Agent

Adjusting Memory Allocation for Oracle DBSecCentral

Oracle Database Security Central (Oracle DBSecCentral) uses a memory allocation helper to dynamically calculate optimal memory settings for the operating system, RDBMS, and Oracle DBSecCentral components based on the system’s total RAM, CPU count, and configuration.

The memory allocation helper reads configuration from the memory-layout.yaml file, which defines proportions, minimums, and margins for memory distribution. The file ensures that Oracle DBSecCentral operates efficiently while reserving resources for the host OS and database processes.

By default, Oracle DBSecCentral allocates memory conservatively to avoid overcommitment, leaving headroom for overhead, for example 10% of total RAM. Customizing this file allows administrators to fine-tune allocations for specific environments, such as high-memory systems, Real Application Clusters (RAC), or workloads with heavy PGA usage. However, improper changes can lead to insufficient memory for critical processes, causing instability or performance degradation.

The memory-layout.yaml file is located at: /opt/avdf/etc/memory-layout.yaml

This file is owned by the root user (or the Oracle DBSecCentral service account) and has restrictive permissions. Edit it using a text editor with appropriate privileges, such as switching to root with su - root and then using vi.

Follow these steps to edit the memory-layout.yaml file:

1. Log in to the source Audit Vault Server through SSH and switch to the root user.

   See Logging In to Oracle DBSecCentral Appliances Through SSH.

2. Backup the original file by running the following command:

   -c 'cp /opt/avdf/etc/memory-layout.yaml /opt/avdf/etc/memory-layout.yaml.bak'

3. Open the original file by running the following command:

   vi /opt/avdf/etc/memory-layout.yaml

4. Modify the values in the memory-layout.yaml file. Update the values as needed based on your system’s requirements. See Table 17-1 below for more information. Keep the following in mind:

   • The file uses YAML format. Ensure indentation is preserved by using spaces, not tabs and note that two spaces per level is standard.

   • Do not add extra keys or remove required ones, as validation will fail.

   • Keys are symbols (for example, :usable), and values are floats or integers.

   • Proportions (for example, :usable: 0.9) must be between 0.0 and 1.0.

   • Absolute values (for example, :core_per_cpu: 1.5) are in GiB and converted to bytes internally.

   Exit the root shell after editing with exit.

5. Save the file.

6. Validate the file by testing the memory helper manually by extracting a calculated value such as usable memory. This command will similar to the following command:

   -c 'ruby /opt/avdf/lib/ruby/avdf/avs_memory_helper.rb mem_usable -u 1048576'

   The above command outputs the usable memory value.

   If this check runs without errors, such as errors about bad configuration or missing keys, the file is valid. If validation fails, check the logs at /var/log/avdf/avdf.log for errors like Errors in memory-layout.yaml.

7. Apply the changes to the memory file by

   1. Restart the Audit Vault Server by running the following command as the root user:

      systemctl reload avdf

   2. Verify the new settings by querying the memory helper:

   -c 'ruby /opt/avdf/lib/ruby/avdf/avs_memory_helper.rb mem_usable'

    This outputs the calculated usable memory in bytes (use `-u` option for human-readable output if customized, e.g., `-u 1048576` for MiB).
   

Table 1 Memory File Parameters

Name	Type	Description	Range	Default	Example	Usage Notes
:usable	Float	Proportion of total system RAM safely allocated to Oracle DBSecCentral and related processes (e.g., OS + RDBMS). Reserves ~10% for overhead.	0.0 to 1.0	0.9	0.85 (Set on low-memory systems to reserve more for OS)	Lower values increase stability but reduce Oracle DBSecCentral performance.
:core_as_share	Float	Proportion of usable RAM allocated to core OS and RDBMS processes. Excess goes to Oracle DBSecCentral.	0.0 to 1.0	0.8	0.7 (Reduce if Oracle DBSecCentral needs more memory)
:core_per_cpu	Float (GiB)	Minimum RAM per CPU core for core processes (capped by core_as_share).	≥ 1.5 GiB	1.5	2.0 (Increase for multi-core systems)	Ensures baseline allocation; logs warnings if total RAM insufficient.
:rac_requirement	Float (GiB)	Additional RAM reserved for RAC (Real Application Clusters). Applied only if RAC is detected.	≥ 10.0 GiB	10.0	15.0 (Increase for large RAC clusters)	Only affects calculations in RAC mode; adjust based on cluster size/workload.
:core_split_os	Float	Proportion of core allocation dedicated to pure OS processes (remainder to RDBMS).	0.0 to 1.0	0.2	0.3 (Increase OS share)	Must sum with core_split_rdbms to 1.0 implicitly.
:core_split_rdbms	Float	Proportion of core allocation for RDBMS (complements core_split_os).	0.0 to 1.0	0.8
:rdbms_split_pga_target	Float	Proportion of RDBMS allocation for PGA (Process Global Area) target. Remainder to SGA.	0.0 to 1.0	0.2	0.3 (For PGA-heavy workloads, e.g., sorting)
:pga_limit	Float	Multiplier for PGA target to set the hard limit (e.g., target × 2.0).	≥ 0.0	2.0	1.5 (Tighten limit)
:dev_shm_margin	Float	Multiplier for SGA size to set /dev/shm size (shared memory).	≥ 1.0	1.2	1.5 (Increase for large SGA)
:kernel_shmall_margin	Float	Multiplier for /dev/shm to set kernel.shmall (shared memory pages).	≥ 1.0	1.1	1.2
:usable_min	Float (GiB)	Minimum usable RAM threshold. If below, warnings are logged and minimums assumed.	≥ 7.0 GiB	7.0	4.0 (For small VMs)	Do not set below hardware minimums.
:swap_max	Float (GiB)	Maximum desired swap space (capped to prevent over-allocation).	≥ 0 GiB	32.0	64.0 (Increase for swap-heavy systems)	Shortfalls are warned if current swap < desired.