Oracle® Database Net Services Administrator's Guide 11g Release 1 (11.1) Part Number B28316-01 |
|
|
View PDF |
This chapter describes how to optimize connection performance.
This chapter contains these topics:
Configuring SDP Protocol Support for Infiniband Network Communication to the Database Server
Configuring the Listener and the Oracle Database To Limit Resource Consumption By Unauthorized Users
Under typical database configuration, Oracle Net encapsulates data into buffers the size of the session data unit (SDU) before sending the data across the network. Oracle Net sends each buffer when it is filled, flushed, or when an application tries to read data. Adjusting the size of the SDU buffers relative to the amount of data provided to Oracle Net to send at any one time can improve performance, network utilization and memory consumption.
The amount of data provided to Oracle Net to send at any one time can be referred to as the message size. Oracle Net assumes by default that the message size will normally vary between 0 and 8192 bytes, and infrequently, will be larger than 8192. If this assumption is true, then most of the time, the data will be sent using one SDU buffer. This assumption is why the default value for the SDU size is 8192.
Consider changing the SDU size when the predominant message size is smaller or larger than 8192. The SDU size you choose should be 70 bytes larger than the predominant message size, as long as the maximum SDU size is not exceeded. If the predominant message size plus 70 bytes exceeds the maximum SDU, then the SDU should be set such that the message size is divided into the smallest number of equal parts where each part is 70 bytes less than the SDU size.
The SDU size can range from 512 bytes to 32767 bytes. If the DEFAULT_SDU_SIZE
parameter is not configured in the sqlnet.ora
file, then the default SDU for the client and a dedicated server is 8192 bytes, while for a shared server the default SDU is 32767 bytes.
The actual SDU size used is negotiated between the client and the server at connect time and will be the smaller of the client and server values. As such, configuring an SDU size different from the default requires configuring the SDU on both the client and server computers, unless you are using shared servers, in which case only the client needs to be changed because the shared server defaults to the maximum value.
For example, if the majority of the messages sent and received by the application are smaller than 8K in size, taking into account about 70 bytes for overhead, setting the SDU to 8K will likely produce good results. If sufficient memory is available, using the maximum value for the SDU will minimize the number of system calls and overhead for Oracle Net Services.
To configure the client, set the SDU size in the following places:
sqlnet.ora
File
For global configuration on the client side, configure the DEFAULT_SDU_SIZE
parameter in the sqlnet.ora
file:
DEFAULT_SDU_SIZE=32767
Connect Descriptors
For a particular connect descriptor, you can override the current settings in the client side tnsnames.ora
file. In a connect descriptor, you specify the SDU
parameter for a description.
sales.us.acme.com= (DESCRIPTION= (SDU=11280) (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)) )
SDU size applies to all Oracle Net protocols.
To configure the database server, set the SDU size in the following places:
sqlnet.ora
File
Configure the DEFAULT_SDU_SIZE
parameter in the sqlnet.ora
file:
DEFAULT_SDU_SIZE=32767
If using shared server processes, set the SDU size in the DISPATCHERS
parameter in the initialization parameter file as follows:
DISPATCHERS="(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp))(SDU=8192))"
If you have configured the listener with a list of targets in the listener.ora
file, the value for SDU in the SID_LIST
element overrides the current setting in the sqlnet.ora
file when using dedicated server processes.
SID_LIST_listener_name= (SID_LIST= (SID_DESC= (SDU=8192) (SID_NAME=sales)))
Note that the smaller value of the SDU size and the value configured for the client will win.
Reliable network protocols like TCP/IP buffer data into send and receive buffers while sending and receiving to or from lower and upper layer protocols. The sizes of these buffers affect network performance, as these buffer sizes influence flow control decisions.
The RECV_BUF_SIZE
and SEND_BUF_SIZE
parameters specify sizes of socket receive and send buffers, respectively, associated with an Oracle Net connection.
To ensure the continuous flow of data and better utilization of network bandwidth, specify the I/O buffer space limit for receive and send operations of sessions with the RECV_BUF_SIZE
and SEND_BUF_SIZE
parameters.
For best performance, the size of the send and receive buffers should be set large enough to hold all of the data that may be sent concurrently on the network connection. For a simple database connection, this typically maps to the OCI_PREFETCH_MEMORY
size.
Setting the SEND_BUF_SIZE
and RECV_BUF_SIZE
to at least the bandwidth-delay product, will insure that when large amounts of data are being sent that the network bandwidth will be optimally utilized.
For example, suppose that the network link between a primary database and a standby database has a round trip time of 34 ms and a bandwidth of 15 Mbps. The bandwidth-delay product of this network link is approximately 64KB. The largest message used to transfer redo data between a primary database and a standby database is 1MB so the optimum value for the SEND_BUF_SIZE
and RECV_BUF_SIZE
parameters in this scenario is therefore 1MB however a setting of at least 64KB should be sufficient to optimize use of the available bandwidth.
Note:
The actual value of theSEND_BUF_SIZE
and RECV_BUF_SIZE
parameters may be less than the value specified either because of limitations in the host operating system or due to memory constraints.Note Also:
It is important to consider the total number of concurrent connections that your system must support and the memory resources that are available because the total amount of memory that will be consumed by these connections will depend on both the number of concurrent connections and the size of their respective buffers.For most network protocols, ensure that the RECV_BUF_SIZE
parameter at one end of the network connection, typically at the client, is equal to the value of the SEND_BUF_SIZE
parameter at the other end, typically at the server.
Specify these parameters in the sqlnet.ora
file or in the connect descriptor on the client side, and the listener.ora
and sqlnet.ora
files on the server side.
Note:
Use these parameters with caution as they affect network and system performance. The default values for these parameters are operating-system specific. Following are the defaults for the Solaris 2.8 Operating System:SEND_BUF_SIZE
: 16,384 bytes
RECV_BUF_SIZE
: 24,576 bytes
The default size for both SEND_BUF_SIZE
and RECV_BUF_SIZE
for Solaris 2.9 is 49,152 bytes.
These parameters are supported for TCP, TCP/IP with SSL, and SDP protocols. Additional protocols may support these parameters on certain operating systems. Refer to operating-system specific documentation of Oracle Net for additional information.
Determining Bandwidth Delay Product
Bandwidth-delay product is the product of network bandwidth and the round trip time of data going over the network. The easiest way to determine the round trip time is to use a command such as ping from one host to another and use the response times returned by ping.
For example, if a network has a bandwidth of 100 Mbps and a round trip time of 5ms, the send and receive buffers should be at least (100X106) * (5X10-3) bits or approximately 62.5 Kilobytes.
For a better understanding of the relationships among the units and factors involved, refer to the following equation:
100,000,000 bits 1 byte 5 seconds ---------------- x ------ x --------- = 62,500 bytes 1 second 8 bits 1000
Clientside Configuration
To configure the client, set the buffer space size in the following places:
sqlnet.ora
File
For global configuration on the clientside, configure the sqlnet.ora
file. Setting just the RECV_BUF_SIZE parameter is typically adequate. If the client is sending large requests, then also set the SEND_BUF_SIZE.
RECV_BUF_SIZE=11784
Connect Descriptors
For a particular connect descriptor, you can override the current settings in the clientside sqlnet.ora
file. In a connect descriptor, you either specify the buffer space parameters for a particular protocol address or description.
sales.us.acme.com= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521) (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521) (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) hr.us.acme.com= (DESCRIPTION= (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784) (ADDRESS=(PROTOCOL=tcp)(HOST=hr1-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=hr.us.acme.com)))
Serverside Configuration
Because the database server writes data to clients, setting just the SEND_BUF_SIZE parameter at the serverside is typically adequate. If the database server is receiving large requests, then also set the RECV_BUF_SIZE parameter.To configure the database server, set the buffer space size in the listener.ora
and in sqlnet.ora
files.
listener.ora
In the listener.ora
file, you can either specify the buffer space parameters for a particular protocol address or for a description.
LISTENER= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521) (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784)) (ADDRESS=(PROTOCOL=ipc)(KEY=extproc) (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784))) LISTENER2= (DESCRIPTION= (SEND_BUF_SIZE=11784) (RECV_BUF_SIZE=11784) (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)))
sqlnet.ora
RECV_BUF_SIZE=65536 SEND_BUF_SIZE=65536
DISPATCHERS Initialization Parameter
If using shared server processes, you can override the current settings obtained from the server's sqlnet.ora
file by setting the buffer space parameters in the DISPATCHERS
initialization parameter as follows:
DISPATCHERS="(ADDRESS=(PROTOCOL=tcp)(SEND_BUF_SIZE=65536))"
Oracle Net Services provides support for the SDP protocol for Infiniband high-speed networks.
The SDP protocol is a standard communication protocol for clustered server environments. SDP is an interface between a network interface card and the application. By using SDP, applications place most of the messaging burden upon the network interface card, freeing the CPU for other tasks. As a result, SDP decreases network latency and CPU utilization.
SDP is designed specifically for System Area Networks (SANs). A SAN is characterized by short-distance, high-performance communications between multiple server systems, such as Oracle Application Server (OracleAS) or any other third-party middle-tier client and database servers clustered into one switch.
This section describes how to set up Oracle Net support of SDP for middle tier and database server communication. It includes the following topics:
See Also:
"Performance Between the Middle Tier and Oracle Database" for an overview of supported deploymentsNote:
Please check with your individual vendor for their version compatibility with Oracle Database 11g.Visit the Oracle Technology Network for further information about SDP protocol support at
Prerequisites to Using SDP Protocol Support
Prior to configuring support for the SDP protocol, install the required hardware, and set up Infiniband hardware and software compatible with OpenFabrics Enterprise Distribution (OFED) 1.2 from a designated vendor on both the application Web server and database server.
In the process of installing the Infiniband software, identify the constant that defines the SDP protocol or address family for your system. This can be obtained from your operating system or OFED documentation.
Perform the following:
Rerun the Oracle Universal Installer.
In the Available Products page, select Oracle Database 11g Server or Oracle Database 11g Client.
In the Installation Types page, select Custom.
In the Available Product Components page, select only Oracle Net Services.
To configure the database server, configure an SDP protocol address in the listener.ora
file on the database server.
Note:
If the SDP protocol or address protocol family constant is not 27, the default value for Oracle Net Services, define the constant in theSDP.PF_INET_SDP
parameter in the sqlnet.ora
file.The following example shows an SDP endpoint that uses port number 1521 on the computer sales-server
.
LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=sdp)(HOST=sales-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (ADDRESS=(PROTOCOL=ipc)(KEY=extproc))))
Note:
If the SDP protocol or address protocol family constant is not 27, the default value for Oracle Net Services, define the constant in theSDP.PF_INET_SDP
parameter in the sqlnet.ora
file.To configure the OracleAS servers or third-party middle-tier client:
If configuring third-party middle-tier client, upgrade the clients to use Oracle Database 11g Client software. From the Oracle Universal Installer, In the Available Products page, select Oracle Database 11g Client.
For both OracleAS servers and third-party middle-tier client, create a net service name to connect to the database server:
For OracleAS servers, specify a net service name that uses the same TCP/IP protocol address configured in the tnsnames.ora
file. For example:
sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
For third-party middle-tier clients, specify a net service name that uses the same SDP protocol address configured in the tnsnames.ora
file.
For example:
sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=sdp)(HOST=sales-server))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com)))
See Also:
Chapter 8, "Configuring Naming Methods" for more information about creating connect descriptorsUnauthorized access to the listener or database server can result in denial-of-service attacks, whereby an unauthorized client attempts to block authorized users' ability to access and use the system when needed. Malicious clients may attempt to flood the listener or database server with connect requests that have the sole purpose of consuming resources, such as connections, processes, or threads. To mitigate these types of attacks, configure limits that constrain the time in which resources can be held prior to authentication. Client attempts to exceed the configured limits will result in connection terminations and an audit trail containing the IP address of the client being logged.
To limit the resource consumption by unauthorized users and enable the audit trail, set time-limit values for the parameters described in Table 14-1. These parameters do not have default values.
Table 14-1 Connect-Timeout Parameters
Parameter | Description |
---|---|
Specify the time, in seconds, for the client to complete its connect request to the listener after the network connection had been established. If the listener does not receive the client request in the time specified, then it terminates the connection. In addition, the listener logs the IP address of the client and an ORA-12525: TNS:listener has not received client's request in time allowed error message to the See Also:
|
|
|
Specify the time, in seconds, for a client to connect with the database server and provide the necessary authentication information. If the client fails to establish a connection and complete authentication in the time specified, then the database server terminates the connection. In addition, the database server logs the IP address of the client and an ORA-12170: TNS:Connect timeout occurred error message to the See Also:
|
When specifying values for these parameters, consider the following recommendations:
Set both parameters to an initial low value.
Set the value of the INBOUND_CONNECT_TIMEOUT_
listener_name
parameter to a lower value than the SQLNET.INBOUND_CONNECT_TIMEOUT
parameter.
For example, you can set INBOUND_CONNECT_TIMEOUT_
listener_name
to 2 seconds and INBOUND_CONNECT_TIMEOUT
parameter to 3 seconds. If clients are unable to complete connections within the specified time due to system or network delays that are normal for the particular environment, then increment the time as needed.