1.4.4 Maximum Number of Database Processes

This topic describes the maximum number of database processes on each Exadata database server or virtual machine guest.

The tables in this topic contain the maximum number of database processes supported on each Exadata database server.

In all cases, the best practice is to keep the process count below the specified values. Also, if a subset of the database workload uses parallel queries, the effective limit will be between the values in the "Maximum Number of Processes with No Parallel Queries" and "Maximum Number of Processes with All Running Parallel Queries" columns.

The following table shows the maximum number of database processes supported on each physical Exadata database server in a bare-metal system configuration.

Table 1-1 Maximum Number of Database Processes on a Physical Database Server

Machine Type	RDMA Network Fabric Type	Maximum Number of Processes with No Parallel Queries	Maximum Number of Processes with All Running Parallel Queries
2-socket	RoCE Network Fabric	25,000	16,000
8-socket	RoCE Network Fabric	64,000	44,000
2-socket	InfiniBand Network Fabric	16,000	14,000
8-socket	InfiniBand Network Fabric	64,000	44,000

The following table shows the maximum number of database processes supported on each virtual machine (VM) guest (Oracle VM DomU or KVM guest) in a virtualized system configuration.

Table 1-2 Maximum Number of Database Processes on a Virtual Machine Guest

Machine Type	RDMA Network Fabric Type	Maximum Number of Processes with No Parallel Queries	Maximum Number of Processes with All Running Parallel Queries
2-socket	RoCE Network Fabric without Exadata Secure RDMA Fabric Isolation configured	25,000	16,000
2-socket	RoCE Network Fabric with Exadata Secure RDMA Fabric Isolation configured	50,000	32,000
2-socket	InfiniBand Network Fabric	16,000	14,000

Use the following best practices to optimize resource utilization while supporting a high process count:

• Establish database connections using a set of Oracle Net listeners instead of using local bequeath connections.

• On each database server, the number of Oracle Net listeners should be a multiple of the number of server CPU sockets. For example, on an 8-socket database server, you should configure at least eight listeners.

• Evenly spread the Oracle Net listeners across the available CPU sockets.

  For example, assuming the listener.ora file is configured correctly for eight listeners (named LISTENER0 - LISTENER7), you can use the following script to start eight listeners on an 8-socket server with each listener bound to a different CPU socket:

  #!/bin/bash
  export ORACLE_HOME=/u01/app/oracle/product/19.0.0.0/dbhome_1
  for socket in `seq 0 7`
  do
   numactl --cpunodebind=${socket} $ORACLE_HOME/bin/lsnrctl start LISTENER${socket}
  done

• Use Oracle Net connection rate limiting to control connection storms and enhance system stability.

  To avoid excessive client connection timeouts and server-side errors, limit the connection rate on each database server to 400 connections per second. In other words, the sum of the rate_limit control parameter should not exceed 400 across all Oracle Net listeners on each database server.

  See Connection Rate Limiter Parameters in Oracle Database Net Services Reference.

• Use the following recommended Oracle Net listener control parameter settings to avoid Oracle Net connection errors, such as TNS-12514.

  • MAX_ALL_CONNECTIONS_listener_name=4096

  • MAX_REG_CONNECTIONS_listener_name=2048

  See Control Parameters in Oracle Database Net Services Reference.