Introduction
Oracle Database is the world’s leading converged, multi-model database management system. Its performance, scalability, and reliability are significantly enhanced in Exadata, an engineered system preassembled and pre-integrated to reduce complexity and speed up application deployment. Due to this performance and reliability, Exadata is the platform on which many organizations run their most critical workloads. With that comes sensitive data, which must be protected to organizational standards.
Exadata’s shared responsibility model on-premises and in the cloud grants customers privileged access (e.g., root, SYS) to the VMs and databases. The customer can use those credentials to secure the VM and database and address local policy and regulatory requirements. This includes and is not limited to installing agents, forwarding operating system and database audit logs to customer security information event management (SIEM) systems, and controlling access to and identity management for VMs and databases via tools that are compatible with the Exadata Compute VM operating system and Oracle database.
Third-party security agents, referred to going forward as security agents, can have the most significant impact on Exadata operations. Most of these security agents run at the root level on the Linux operating system, which is the highest privilege level, allowing these agents to see all processes running on the operating system, including those used by Exadata and the database. In addition to viewing the processes, more advanced security agents use pattern analysis to detect malicious activities like ransomware and stop the activity from occurring or spreading. This detection and prevention work well for end-user devices and general-purpose servers but can sometimes impact engineered systems like Exadata. These impacts include performance degradation, kernel panics, file locks, breaking Exadata upgrades, and blocking ksplice from applying kernel patches.
Oracle’s support note: How To Configure Anti-Virus On the Oracle Database Server (Doc ID 782354.1) provides guidance. The guidance identifies which Oracle database files must be excluded from the Anti-virus scanner. The reason for this is that when the antivirus scans these files, a lock may be placed on the file, impacting the performance of the database. Customers should also contact their agent vendor to know more about the details of the scanning mechanism of the particular software and for any additional Oracle files that have to be excluded from the scanner. Sometimes, excluding only these files is insufficient, so exclude the entire folder/directory of Oracle database files.
Targeted testing should be used when implementing any security agent that installs proprietary and/or externally built kernel modules or runs as root. Also, runbooks should be created to understand how to disable any third-party agents on the Exadata during maintenance activities.
Approaches for Testing
Real-World Workload Replication
Custom scripts that replicate actual workloads encountered by the database can be used to accurately represent how the database would perform in a real-world scenario. This can involve reproducing the query patterns, data access patterns, and concurrency levels seen in production environments.
Oracle provides a way to do this with Oracle Real Application Testing (RAT). Oracle RAT helps you thoroughly assess the effect of a security agent on a real-world application in a test environment before deploying the change in production. To test your workload, first, you use RAT to capture the workload. During this process, all external client requests are directed to the Oracle server and are stored into compact “capture” files on the database host file system while incurring negligible overhead. Then, those “capture” files can be replayed on a test system running the security agent.
Benchmarking
Benchmarks can also be used to measure the performance of specific database operations or features. These benchmarks consist of predefined queries or workloads that mimic typical database activities. Examples include OLTP (Online Transaction Processing) benchmarks like TPC-C and, which simulate transaction processing workloads, and OLAP (Online Analytical Processing) benchmarks for decision support, like TPC-DS.
Various benchmarking tools are available to help measure database performance. These tools generate load and measure response time, CPU utilization, throughput, and I/O performance. Some benchmarking tools are HammerDB (not my database), Swingbench, and Benchmark Factory® for Databases.
You can select the benchmarks that most closely match your workloads running on Exadata, run those benchmarks without the agent and again with the agent installed, and evaluate the difference. This will allow you to assess what impact the agent may have.
Conclusion
This blog was designed to be a high-level guide for your organization to assess the impact a third-party agent may have on your Exadata. Third-party agent vendors can also follow this approach to determine if their agent will function on Exadata, and with Oracle Cloud Infrastructure offering Exadata, that bar is lower than ever.
Finally, while installing third-party agents is allowed, Oracle will not provide technical support for non-Oracle software. This includes installation, testing, certification and error resolution. The supplier of the custom/third party software is responsible for any technical support for it. Oracle recommended that all non-Oracle software be tested, validated, and certified by the vendor for use in an Oracle Linux and/or Exadata environment, and thorough testing is performed in the target environment by the customer (Doc ID 1593827.1).