Home > Workload Solutions > Oracle > Best Practices > AMD-Based Oracle Best Practices on Dell PowerEdge R740 and PowerMax 2000 > Introduction to Best Practices for Oracle > Baseline Configuration
In this section, we cover details of the baseline configuration. A baseline configuration was used for determining the initial workload and to enable a comparison with the first set of best practices.
To achieve the goal of 80 percent overall processor utilization in the R7525 server, eight virtualized databases were run in parallel. After several tests using HammerDB and an OLTP workload, a baseline configuration was developed. The following table shows the vCPU and memory allocation for each virtualized database:
Table 5: vCPU and memory allocation
Resource reservation | Baseline configuration per virtual machine | Total across eight virtualized databases |
vCPU | 8 cores | 64 cores |
Memory | 384 GB | 2,304 GB |
A VMware reservation is a guaranteed allocation of CPU or memory for the virtual machine. In the case of the vCPU, each virtual machine received an 8-core reservation. With eight total virtualized databases the total vCPU reservation was 64 cores (8 virtual machines each with 8 cores) on the server. The PowerEdge R7525s servers are two-socket servers and in the configuration for our tests two AMD EPYC 7543 CPUs were used. Each AMD CPU has 32 cores so there was a total of 64 physical cores. This matches with the total number of vCPUs used across the 8 virtual machines.
While the virtual machines used all the physical cores by default, the PowerEdge R7525 servers enable logical processors. When logical processors are enabled, the hypervisor presents twice as many processor cores. In our configuration, the 64 physical processor cores will be presented as 128 cores (64 x 2). Logical processors can boost performance by enabling more executions in parallel. In the case of our eight virtual databases, we used half of the available processor resources: 64 processor cores were reserved, and 128 cores were available.
There is no best practice for how processor cores were allocated to the virtual machine in the baseline configuration, rather the target of 80 percent CPU utilization was the determining factor in guiding the number of vCPUs per virtual database. Testing showed the server reached approximately 30% percent utilization with 8 virtualized databases with 8 processors when running the HammerDB OLTP workloads.
The memory configuration per virtual machine included a reservation of 384 GB. With eight virtual machines a total of 2,304 GB of memory was reserved. The total memory available in the server was 4 TB so the virtual machines used just over half of the available physical memory in the server. In allocating memory to each virtual machine, the goal was to ensure each VM fit into a physical memory bank for each physical CPU. Non-uniform Memory Access (NUMA) refers to a multiprocessor configuration in which each physical CPU has a dedicated memory bank. Information can be retrieved faster from the local memory bank than having to pull the data from another memory bank. When a virtual machine’s memory spans two memory banks, wait times are incurred, causing sub-optimal performance.
To prevent this sub-optimal NUMA design, each virtual machine was allocated 384 GB of memory, thus enabling the use of only the local memory bank. The VMware ESXi hypervisor is responsible for the placement of memory on a processor and has been designed to optimize performance. By reserving memory that enables the virtual machine to use a local memory bank we optimized performance for all the virtual machines on the server.
The PowerMax features the ability to have parent and child storage groups, which enables the administrator to create a configuration that facilitates ease of management, efficient snapshots, and replication. For the baseline storage configuration, all eight virtualized databases used the same design. The following table shows the baseline storage configuration. Please note that the name of the database used was REDPEPPER.
Table 6 Baseline storage configuration
Parent storage group | Child storage group | VMware Volumes | Number of volumes | Volume size (GB) | Notes |
REDPEPPER_DB1 | DB1_DATA | Data1 | 1 | 1,000 | Data files |
REDPEPPER_REDO_DB1 | DB1_REDO | Redo1 | 1 | 50 | Redo files |
REDPEPPER_ARCH_DB1 | DB1_ARCH | Arch1 | 1 | 50 | Archive files |
REDPEPPER_GRID_DB1 | DB1_GRID | Grid1 | 1 | 50 | Grid infrastructure |
Grid2 | 1 | 50 |
| ||
Grid3 | 1 | 50 |
| ||
REDPEPPER _FRA_DB1 | DB1_FRA | FRA1 | 1 | 100 | Flash Recovery Area |
REDPEPPER _TEMP_DB1 | DB1_TEMP | Temp1 | 1 | 100 | Temporary files |
A naming convention using DBn allowed the database administrators to increment the value to create storage groups for all the databases. For example, the second copy of the database had a parent storage group name of REDPEPPER_DB2 with child groups of DB2_DATA, DB2_REDO, and DB2_ARCH. Using this naming convention allowed the administration team to repurpose copies of the database quickly.
The baseline storage configuration used a total of 6 parent storage groups. This approach to the storage configuration simplifies management but it is not the optimal design for database performance. The first storage best practice will improve upon the storage configuration to maximize performance.
The Oracle database configuration includes many default settings that reflect a new installation of the database. In the following table, a subset of the database configuration parameters is listed to show the baseline settings:
Table 7: Database configuration parameters
Parameters | Values |
SGA_TARGET | 64 GB |
PGA_TARGET | 10 GB |
ORACHK UTILITY | N/A |
DB_BLOCK_SIZE | 8 K |
PROCESSES, SESSIONS, TRANACTIONS | 3000 4524 4976 |
UNDO_MANAGEMENT, UNDO_TABLESPACE | AUTO, UNDOTBS1 |
FILESYSTEM_IO_OPTIONS | NONE |
DISK_ASYNC_IO | TRUE |
DB_FILE_MULTIBLOCK_READ_COUNT | 128 |
DB_WRITER_PROCESS | 1 |
REDOLOG_FILE_SIZE | 200 MB (each) |
REDOLOG_FILE_BLOCK_SIZE | 512 |
LOG_CHECKPOINT_INTERVAL | 0 |
LOG_CHECKPOINT_TIMEOUT | 1800 |
LOG_BUFFER | 115,200 K |
ASM STRIPPING / AU SIZE | 4 MB |
REDO / TEMP FILES | COARSE |
In reviewing the configuration parameters, the overall profile can be labeled as an entry-level database. An entry-level database configuration provides a foundation to build upon best practices. Over the course of validating best practices the database configuration will change to optimize performance. This approach of starting with a minimal configuration and adding best practices has the benefit of enabling customers to address database growth challenges using these validated recommendations.