Network data compression reduces the size of the session data unit (SDU) transmitted over a data connection. Reducing the size of data reduces the time required to transmit a SQL query and result across the network. In addition, compressed data uses less bandwidth which allows transmission of larger data in less time. The data compression process is transparent to the application layer.

The following are some of the benefits of using data compression:

• Increased network throughput means constrained bandwidth environments can utilize compression to reduce query response time.

• Reduced bandwidth utilization allows other applications to use the bandwidth.

• Reduction in the amount of data transferred between sites.

Under typical database configuration, Oracle Net encapsulates data into buffers the size of the 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. When large amounts of data are being transmitted, increasing the SDU size can improve performance and network throughput. SDU size can be adjusted lower or higher to achieve higher throughput for a specific deployment.

The amount of data provided to Oracle Net to send at any one time is referred to as the message size.

The SDU size can range from 512 bytes to 2 MB. The wide range of sizes allows the network administrator to tune the SDU size for optimal network performance for a given deployment. A high SDU size value requires more memory. The default SDU size for the client and a dedicated server is 8192 bytes. The default SDU size for a shared server is 65535 bytes.

The actual SDU size used is negotiated between the client and the server at connect time and is the smaller of the client and server values. 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.

You should consider changing the SDU size when the predominant message size is smaller or larger than 8192. The SDU size should be 70 bytes more than the predominant message size. 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. To change the default, change the DEFAULT_SDU_SIZE parameter in the sqlnet.ora file.

For example, if the majority of the messages sent and received by the application are smaller than 8 KB, taking into account the 70 bytes for overhead, then setting the SDU to 8 KB will likely produce good results. If sufficient memory is available, then using the maximum value for the SDU minimizes the number of system calls and overhead for Oracle Net Services.

• Setting the SDU Size for the Database
  
• Setting the SDU Size for the Client
  

Bandwidth-delay product is the product of network bandwidth and the round trip time of data going over the network. A simple 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, then the send and receive buffers should be at least (100*10ˆ6) * (5/10ˆ3) bits or approximately 62.5 Kilobytes.

The following equation shows the relationships between the units and factors involved:

100,000,000 bits   1 byte   5 seconds
---------------- x ------ x --------- = 62,500 bytes
 1 second          8 bits     1000

Setting the SEND_BUF_SIZE and RECV_BUF_SIZE parameters to at least the bandwidth-delay product insures that when large amounts of data are being sent that the network bandwidth will be optimally utilized.

Based on the preceding equation, the bandwidth-delay product of this network link is approximately 64 KB. If the largest message used to transfer redo data between a primary database and a standby database is 1 MB, then the value for the SEND_BUF_SIZE and RECV_BUF_SIZE parameters could be 1 MB. However, if the average message is less, then a setting of 64 KB should be sufficient to optimize use of the available bandwidth.

For most network protocols, ensure that the RECV_BUF_SIZE parameter at one end of the network connection, typically at the client, equals the value of the SEND_BUF_SIZE parameter at the other end, typically at the server.

Reliable network protocols, such as 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 by influencing flow control decisions.

The RECV_BUF_SIZE and SEND_BUF_SIZE parameters specify sizes of socket buffers 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. The RECV_BUF_SIZE and SEND_BUF_SIZE parameter values do not have to match, but should be set according to your environment.

For best performance, the size of the send and receive buffers should be set large enough to hold all the data that may be sent concurrently on the network connection. For optimal network performance, these buffers should be set to at least the bandwidth-delay product.

Use these parameters with caution as they affect network and system performance. The default values for these parameters are operating system specific. The following are the defaults for the Linux operating system:

• SEND_BUF_SIZE: 131,072 bytes (128k)

• RECV_BUF_SIZE: 174,700 bytes

These parameters are supported for TCP, TCP/IP with SSL, and SDPs. Additional protocols may support these parameters on certain operating systems. The recommended values for these parameters are specified in the installation guide. Refer to operating system specific documentation for additional information.

• Configuring I/O Buffer Size on the Server
  
• Configuring I/O Buffer Space on the Client
  

Oracle Net Services provides support for the Sockets Direct Protocol (SDP) for InfiniBand high-speed networks.

SDP 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 WebLogic Server or any other third-party middle-tier client and database servers clustered on one switch.

The following sections describe how to set up Oracle Net support of SDP for middle tier and database server communication. It contains the following topics:

• Prerequisites for Using SDP
  
• Configuring SDP on the Server
  
• Configuring SDP on the Client
  

Oracle Net Services provides support for the Exadirect for InfiniBand high-speed networks.. Use the new transport to improve latency and throughput by leveraging Remote Direct Memory Access (RDMA) in an InfiniBand environment

• Prerequisites for Using Exadirect
  
• Configuring Exadirect on the Server
  To configure the database server, configure an Exadirect address in the listener.ora file on the database server.
• Configuring Exadirect on the Client
  Specify a network service name that uses the same Exadirect address that is configured in the tnsnames.ora file.

Unauthorized 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 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.

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.

Sharding provides the ability to horizontally partition the data across multiple independent Oracle databases, also called shards, and based on a key specified in the connect string, route the database requests to a particular shard.

The routing is done at the session level and is based on the value of the sharding key specified in the connection string. The data-dependent routing assumes that all the database requests issued within a session are related to the data associated with the specified key value. If a client needs to access data with a different value of the key, it either establishes a new database session or re-uses a pre-established connection that maps to that sharding key. All the components that are responsible for routing database requests, such as shard directors (Global Service Managers) and connection pools, contain a routing table which maps the key value range to shards that store appropriate data. Oracle Sharding automatically maintains consistency of routing tables across all these components.

• Configuring Data-Dependent Routing for Client-Server Connections
  It involves a single redirection of the connection request process.