Oracle Net Service Overview
Oracle Net Services provides connectivity solutions for businesses in distributed and heterogeneous computing environments. It enables a network session between the client application and the Oracle database server.
A dedicated server process is the type of service handler that the listener executes when it receives a request from the client. The slide shows the process of establishing a client connection to an Oracle database (non-shared server architecture) using the following steps:
- The listener receives a connection request from the client.
- The controller starts the dedicated server process.
- The listener specifies the location of the dedicated server process in the redirection message.
- The client connects directly to the dedicated server.
Message: Depending on the operating system and transport protocol, the third step can be omitted. In this case, the dedicated server process inherits the connection request from the listener. This establishes the same network session between the client and the dedicated server. If the client and database are on the same computer, the application initiating the session can create its own server process without going through the listener. It is known as the Will protocol and is often used when running a database instance.
Understanding the resolution of title
The name method is the conversion method used by the client application to convert the connection ID into a connection descriptor when attempting to connect to a database service. The following methods are available:
- Local name (uses static text configuration files)
- Directory naming (uses a dynamic LDAP-compatible server)
- Simple Connect-Name (uses simple hard-coded strings)
- External naming service (a foreign naming service is used)
Resolved:
SQL> connect hr@(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)
(HOST=host03.example.com)(PORT=1521))(CONNECT_DATA=
(SERVICE_NAME=london.example.com))))
The client application needs a connection descriptor to establish a network session. The connection descriptor contains two components:
- Location of the listener via the protocol address, also known as the listening point.
- A specific database service name or Oracle system identifier that is recognized by the auditor.
The connection descriptor can be explicitly specified, as in the second example on the slide, which does not require name resolution. This method is used by the Data Guard broker when changing the LOG_ARCHIVE_DEST_n parameters for retransmission. It is also possible to specify a direct TCP/IP address instead of a hostname to avoid additional searches, such as using Domain Name Services (DNS).
In most cases, however, the user initiates a connection request by providing a connection string, which may include a username, password, and a simplified login ID. To do this, the simplified login ID must be converted to the correct data using one of the many name conversion methods available. Each naming method has its advantages and disadvantages. The sqlnet.ora file specifies the naming methods available to the client or server. This course uses a local naming method, where network service names and their descriptive g tower connections are stored in a localized configuration file called tnsnames.ora.
Local naming of configuration files
The local naming method uses text configuration files stored on both the client and database server to convert network service names (connection IDs) into detailed connection descriptors. The operating system’s environment variables determine the location of these files. First, the variable TNS_ADMIN is checked. This allows configuration files to be stored centrally (for example, in a cluster file system shared by many computers).
If the variable TNS_ADMIN is not set, the variable ORACLE_HOME is used to find the configuration files. There can be different ORACLE_HOME locations on the same host machine for different reasons. If desired, each of these may contain network configuration files. For example, the files tnsnames.ora and sqlnet.ora are located in the ORACLE_HOME location for each network infrastructure location for the database middleware, database software, middleware, and Enterprise Manager software products. The value of the ORACLE_HOME environment variable refers to a single ORACLE_HOME location. The listener.ora configuration file is used only to give the database software ORACLE_HOME.
Message: In a real application cluster environment, the Oracle database listener is usually executed from the ORACLE_HOME of the grid infrastructure software rather than the ORACLE_HOME of the database software. ORACLE_HOME of the network infrastructure software requires a working configuration if ASM is used. If there is a separation of duties between the cluster software administrator and the database administrator, the database listener can run from the ORACLE_HOME of the database software.
Local name: tnsnames.ora
Database parameter file (spfileNAME.ora/initNAME.ora)
LOG_ARCHIVE_DEST_2=’SERVICE=london …’.
Oracle Net configuration (on the database host machine) : $ORACLE_HOME/network/admin/tnsnames.ora
LONDON =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS=(PROTOCOL=TCP)(HOST=host03.example).com)
(PORT=1521)(SEND_BUF_SIZE=10485760)
(RECV_BUF_SIZE=10485760))
)
(SDU=65535)
(CONNECT_DATA=(SERVICE_NAME=london.example.com)
)
An example of using the local naming method for the Data Guard environment is shown above. The LOG_ARCHIVE_DEST_n parameter, found in the database parameter file with the SERVICE attribute, defines the external Oracle database instance to which the repeated data is sent. The network service name (shown on the slide with the value LONDON) is resolved in the connection descriptor using the method for local names. The connection descriptor contains the protocol and address information needed to communicate with the listener at its listening point. After contact is made with the listener, a network session is requested for the specified SERVICE_NAME. The network service name (LONDON) need not have the same or similar value as SERVICE_NAME(london.example.com).
Time connection failure Planning for role transfer
Switching at the time of connection is enabled by default for multiple address lists (ADDRESS_LIST is used) and does not need to be specified.
PRMY =(DESCRIPTION =(ADDRESS_LIST =(FAILOVER=enabled)(ADDRESS=(PROTOCOL=TCP)(HOST=host01.example).com)(PORT=1521)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760))(ADDRESS=(PROTOCOL=TCP)(HOST=host03.example.com)(PORT=1521)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760))(SDU=65535)(CONNECT_DATA=(SERVICE_NAME=prmy.example.com))
Role update operations, such as. B. Failover and failover, may change the host on which the primary or backup database is currently running. The client configuration must include a connection descriptor that contains all potential hosts on which a particular service can run. This can be configured by specifying an ADDRESS_LIST that contains multiple addresses or listening endpoints. Connection-time failover tells Oracle Net to switch to another listener if the first listener fails. By default, the use of the ADDRESS_LIST element allows switching during the connection.
It is not necessary to use FAILOVER=on, as shown in bold in the above example. If, while connecting, applications accidentally try to connect to an older primary host that is not available, they should not try to connect to that host for more than 3 seconds. This allows a quick attempt to connect to ADDRESS_LIST until a new primary host is found. This can be configured via the following entry in the sqlnet.ora file:
SQLNET.OUTBOUND_CONNECT_TIMEOUT=3
Message: The ADDRESS_LIST clause is optional. Multiple addresses can be defined without explicitly using the ADDRESS_LIST syntax. In this case, the default failover mode is disabled and the syntax FAILOVER=on is explicitly required to enable failover during connection.
Listener configuration: listener.ora
Oracle Net configuration (on the database host machine) : $ORACLE_HOME/network/admin/listener.ora
The following item defines two listening points:
LIST =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL=TCP)(HOST=host03.example.com)
(PORT=1521)(SEND_SDU=10485760)
(RECV_SDU=10485760))))
(DESCRIPTION =
(ADDRESS=(PROTOCOL=IPC)(KEY=ExTPROC1521))
)
ADR_BASE_LISTENER = /u01/app/oracle
LISTENER2 = …
ADR_BASE_LISTENER2 = /u01/app/oracle
The listener is configured with one or more listening protocol addresses, information about supported services, and parameters that determine its execution behavior. The listener configuration is stored in a configuration file named listener.ora. Since the configuration settings have default values, you can start and use the listener without configuration. In an Oracle Data Guard environment, best practices generally point to the need to modify the Session Data Unit (SDU) buffer to improve network performance. This is especially important in a WAN with long latency times. If you change this value, you must create a listener.ora file with non-default values.
The bold text in the above example indicates the name of the listener. This name is used in commands that refer to the listener, such as. B. lsnrctl start LISTENER2. If the default name is used, it is not necessary to specify it in most commands. For example, the lsnrctl start command starts the listener with the default name LISTENER.
A listener can listen to multiple databases, or there can be one listener for each database. It is possible to create multiple listener configurations in a single listener.ora file by duplicating the contents of the file and giving the listener name a different value for each occurrence. The slide shows the second handset named LISTENER2 in blue. Each individual listener needs a different listening point. This technique allows the listener to start and stop separately for each database on the same host machine.
Registration of dynamic rights
Dynamic service registration is configured in the database initialization file. No configuration is required in the listener.ora file. If not specified, the SERVICE_NAMES parameter defaults to the name of the global database, a name composed of the DB_UNIQUE_NAME and DB_DOMAIN parameters in the initialization parameter file. If DB_UNIQUE_NAME is not explicitly defined, this is the default DB_NAME. The default value of the INSTANCE_NAME parameter is equal to the Oracle System ID (SID). All of these names can be explicitly set to non-default values.
SERVICE_NAMES specifies one or more names under which clients can connect to the instance. The authority registers the names of its services with the listener. You can specify multiple service names for, for example. B. distinguish between different uses of the same database :
SERVICE_NAMES=PROD,DG_PRMY,DG_RW,MAIN_REPORTING
By default, the LREG process logs service information with its local listener on the default local TCP/IP address, port 1521. To have the LREG process register with a local listener that does not use TCP/IP port 1521, configure the LOCAL_LISTENER parameter in the initialization settings file to find the local listener.
A remote listener is a listener that resides on one computer and forwards connections to a computer that forwards connections to a database instance on another computer. You can set the recording for remote listeners using the REMOTE_LISTENER parameter.
Static listener records: listener.ora
Static Listener records are required for Recovery Manager and Data Guard Broker operations.
SID_LIST_LISTENER =(SID_LIST =(SID_DESC =(GLOBAL_DBNAME = london.example.com)(ORACLE_HOME = /u01/app/oracle/product/12.1).0/dbhome_1)(SID_NAME = London)(SID_DESC =(GLOBAL_DBNAME = london_DGMGRL.example.com)(ORACLE_HOME = /u01/app/oracle/product/12.1.0/dbhome_1)(SID_NAME = London))))
Dynamic service registration allows the listener registration process (LREG) of a database instance to identify its available services to the listener without input to the listener.ora configuration file. The listener then acts as a port mapper for these services. However, when a database instance is stopped, the auditor deletes all information about the dynamic services associated with that database. Any attempt to establish a network session with an unknown service will normally result in an ORA-12514 error message: The listener does not currently know the service requested in the connection descriptor. The static record allows the listener to be aware of the service even if the database instance is not active. This is often important when using tools and utilities that attempt to start and stop a remote database instance. The configuration of static service information is required in the following cases:
- Using external procedure calls
- Use of heterogeneous services
- Using Oracle Data Guard
- Run external databases using a utility other than Oracle Enterprise Manager Cloud Control.
To enable DGMGRL to restart instances during static brokerage operations To enable DGMGRL to restart instances during brokerage operations, a static service must be registered with the local listener and accept the static service name db_unique_name_DGMGRL.db_domain.
Oracle Net Optimization for Data Guard
To achieve high throughput, especially on a high-bandwidth network, the recommended minimum setting for the TCP buffer sizes for transmit and receive is the BDP (delayed bandwidth) product of the network connection between the primary system and the backup system. BDP is a product of network bandwidth and latency. Tests have shown that throughput increases with socket buffer settings up to three times the BDP. Socket buffer sizes are defined using the Oracle Net parameters RECV_BUF_SIZE and SEND_BUF_SIZE. If the bandwidth is z. B. 622 Mbit/s and the latency is 30 ms, the minimum size for the RECV_BUF_SIZE and SEND_BUF_SIZE parameters is calculated as follows: 622,000,000 / 8 x 0.030 = 2,332,500 bytes. Then multiply BDP 2,332,500 by 3 and you get 6,997,500. Set the transmit and receive buffer size to your calculated value or 10 MB (10485760), whichever is larger.
Oracle Net buffers data in what is called a Session Data Unit (SDU), which by default is 8192 bytes. These data units are then sent to the network layer when they are filled, emptied or read by the client. Normally, Data Guard sends chunks that are much larger than 8192 bytes, so this default value is insufficient because you could end up sending more chunks (fragmenting data) to Oracle Net Services. Increase this value to 64 KB.
To avoid buffer dump delays in the TCP protocol stack, disable the TCP Nagle algorithm by setting the value TCP.NODELAY in sqlnet.ora to YES on the primary and backup system.
The actual value of SEND_BUF_SIZE and RECV_BUF_SIZE may be less than the specified value due to host operating system limitations or memory constraints. The default values for these parameters are specific to the operating system. The following are the default values for the Linux operating system:
SEND_BUF_SIZE : 131 072 bytes (128 KB)
RECV_BUF_SIZE : 174 700 bytes
These values are typically changed to a higher value during the installation of the oracle-rdbms-server-12cR1- pre-installation package, but the changed values are still below the recommended best practices for Data Guard.
Use this setting to define the default and maximum storage capacity of the target device:
# cat /proc/sys/net/core/rmem_default
# cat /proc/sys/net/core/rmem_max
Use this setting to determine the default and maximum memory size of the transmission bus:
# cat /proc/sys/net/core/wmem_default
# cat /proc/sys/net/core/wmem_max
Define the values with the following commands:
# echo ‘net.core.wmem_max=10485760’ >> /etc/sysctl.conf
# echo ‘net.core.rmem max=10485760’ >> /etc/sysctl conf
You must also set the minimum size, the starting size, and the maximum size in bytes:
# echo ‘net.ipv4.tcp_rmem= 10240 131072 10485760’ >> /etc/sysctl.conf
# echo ‘net.ipv4.tcp_wmem= 10240 131072 10485760’ >> /etc/sysctl.conf
Restart the changes you made with the following command:
Message: From Oracle Database 12 From Oracle Database 12c Release 1 (12 1), Oracle Net supports large session data unit (SDU) block sizes with a new upper limit of 2 MB. The larger SDU size can be used to achieve better utilization of the available bandwidth in high-latency host resources and product networks, depending on the application characteristics. At the time of writing, current best practices recommend a value of 64 KB. This may change in the future with additional testing.
Related Tags:
how to configure dgmgrl in oracle 12cdgmgrl racdata guard parameters in oracle 12coracle data guard dgb serviceimportant parameters for data guarddataguard parameters,People also search for,Privacy settings,How Search works,how to configure dgmgrl in oracle 12c,dgmgrl rac,data guard parameters in oracle 12c,oracle data guard dgb service,important parameters for data guard,dataguard parameters,remote_login_passwordfile data guard,alter system set dg_broker_start=false scope=both sid
