DB-hub Technology Oracle 教程 Oracle Net Architecture

Oracle 教程 Oracle Net Architecture

1.Oracle Application Architecture

1.1.Client/Server Architecture

In the Oracle Database environment, the database application and the database are separated into a client/server architecture.

The components are as follows:

  • The client runs the database application, for example, SQL*Plus or a Visual Basic data entry program, that accesses database information and interacts with a user.
  • The server runs the Oracle Database software and handles the functions required for concurrent, shared data access to an Oracle database.

Although the client application and database can run on the same computer, greater efficiency is often achieved when the client portions and server portion are run by different computers connected through a network. The following sections discuss variations in the Oracle Database client/server architecture.

Distributed Processing

Using multiple hosts to process an individual task is known as distributed processing.

Front-end and back-end processing occurs on different computers. In Figure 18-1, the client and server are located on different hosts connected through Oracle Net Services.

Figure 18-1 Client/Server Architecture and Distributed Processing

Figure 18-2 is a variation that depicts a distributed database. In this example, a database on one host accesses data on a separate database located on a different host.

Figure 18-2 Client/Server Architecture and Distributed Database

Advantages of a Client/Server Architecture

Oracle Database client/server architecture in a distributed processing environment provides a number of benefits.

Benefits include:

  • Client applications are not responsible for performing data processing. Rather, they request input from users, request data from the server, and then analyze and present this data using the display capabilities of the client workstation or the terminal (for example, using graphics or spreadsheets).
  • Client applications are not dependent on the physical location of the data. Even if the data is moved or distributed to other database servers, the application continues to function with little or no modification.
  • Oracle Database exploits the multitasking and shared-memory facilities of its underlying operating system. Consequently, it delivers the highest possible degree of concurrency, data integrity, and performance to its client applications.
  • Client workstations or terminals can be optimized for the presentation of data (for example, by providing graphics and mouse support), while the server can be optimized for the processing and storage of data (for example, by having large amounts of memory and disk space).
  • In networked environments, you can use inexpensive client workstations to access the remote data of the server effectively.
  • The database can scale as your system grows. You can add multiple servers to distribute the database processing load throughout the network (horizontally scaled), or you can move the database to a minicomputer or mainframe to take advantage of a larger system’s performance (vertically scaled). In either case, data and applications are maintained with little or no modification because Oracle Database is portable between systems.
  • In networked environments, shared data is stored on the servers rather than on all computers, making it easier and more efficient to manage concurrent access.
  • In networked environments, client applications submit database requests to the server using SQL statements. After it is received, each SQL statement is processed by the server, which returns results to the client. Network traffic is minimized because only the requests and the results are shipped over the network.

1.2.Multitier Architecture

In a traditional multitier architecture, an application server provides data for clients and serves as an interface between clients and database servers.

This architecture enables use of an application server to:

  • Validate the credentials of a client, such as a Web browser
  • Connect to a database server
  • Perform the requested operation

Figure 18-3 A Multitier Architecture Environment

Clients

A client initiates a request for an operation to be performed on the database server.

The client can be a Web browser or other end-user program. In a multitier architecture, the client connects to the database server through one or more application servers.

Application Servers

An application server provides access to the data for the client. It serves as an interface between the client and one or more database servers, and hosts the applications.

An application server permits thin clients, which are clients equipped with minimal software configurations, to access applications without requiring ongoing maintenance of the client computers. The application server can also perform data reformatting for the client, reducing the load on the client workstation.

The application server assumes the identity of the client when it is performing operations on the database server for this client. The best practice is to restrict the privileges of the application server to prevent it from performing unneeded and unwanted operations during a client operation.

Database Servers

A database server provides the data requested by an application server on behalf of a client. The database performs the query processing.

The database server can audit operations performed by the application server on behalf of clients and on its own behalf. For example, a client operation can request information to display on the client, while an application server operation can request a connection to the database server.

In unified auditing, the database can append application contexts, which are application-specific name-value pairs, to records in the unified audit trail. You can configure which application contexts the database writes to database audit records.

Service-Oriented Architecture (SOA)

The database can serve as a Web service provider in traditional multitier or service-oriented architecture (SOA) environments.

SOA is a multitier architecture relying on services that support computer-to-computer interaction over a network. In the context of SOA, a service is a self-sufficient functional endpoint that has a well defined functionality and service level agreement, can be monitored and managed, and can help enforce policy compliance.

SOA services are usually implemented as Web services accessible through the HTTP protocol. They are based on XML standards such as WSDL and SOAP.

The Oracle Database Web service capability, which is implemented as part of Oracle XML DB, must be specifically enabled by the DBA. Applications can then accomplish the following through database Web services:

  • Submit SQL or XQuery queries and receive results as XML
  • Invoke standalone PL/SQL functions and receive results
  • Invoke PL/SQL package functions and receive results

Database Web services provide a simple way to add Web services to an application environment without the need for an application server. However, invoking Web services through application servers such as Oracle Fusion Middleware offers security, scalability, UDDI registration, and reliable messaging in an SOA environment. However, because database Web services integrate easily with Oracle Fusion Middleware, they may be appropriate for optimizing SOA solutions.

1.3.Grid Architecture

In an Oracle Database environment, grid computing is a computing architecture that effectively pools large numbers of servers and storage into a flexible, on-demand computing resource.

Modular hardware and software components can be connected and rejoined on demand to meet the changing needs of businesses.

2.Net Layers

The Oracle Net listener is an application positioned on top of the Oracle Net foundation layer. The database receives an initial connection from a client application through the listener.

The listener brokers client requests, handing off the requests to the Oracle database server. Every time a client requests a network session with a database, the listener receives the initial request.

Figure 5-1 illustrates the various layers on the client and database during an initial connection. As shown in the diagram, the listener is at the top layer of the server-side network stack.

Figure 5-1 Layers Used in an Initial Connection

3.Oracle Net Services

3.1.How Oracle Net Services Works

Oracle Database protocols accept SQL statements from the interface of the Oracle applications, and then package them for transmission to Oracle Database.

Transmission occurs through a supported industry-standard higher level protocol or API. Replies from Oracle Database are packaged through the same higher level communications mechanism. This work occurs independently of the network operating system.

Depending on the operating system that runs Oracle Database, the Oracle Net Services software of the database server could include the driver software and start an additional background process.

3.2.Oracle Net Listener

The Oracle Net Listener (the listener) is a server-side process that listens for incoming client connection requests and manages traffic to the database. When a database instance starts, and at various times during its life, the instance contacts a listener and establishes a communication pathway to this instance.

Service registration enables the listener to determine whether a database service and its service handlers are available. A service handler is a dedicated server process or dispatcher that acts as a connection point to a database. During registration, the LREG process provides the listener with the instance name, database service names, and the type and addresses of service handlers. This information enables the listener to start a service handler when a client request arrives.

The following graphic shows two databases, each on a separate host. The database environment is serviced by two listeners, each on a separate host. The LREG process running in each database instance communicates with both listeners to register the database.

Figure 18-4 Two Listeners

Figure 18-5 shows a browser making an HTTP connection and a client making a database connection through a listener. The listener does not need to reside on the database host.

Figure 18-5 Listener Architecture

The basic steps by which a client establishes a connection through a listener are:

  1. A client process or another database requests a connection.
  2. The listener selects an appropriate service handler to service the client request and forwards the request to the handler.
  3. The client process connects directly to the service handler. The listener is no longer involved in the communication.

  4. 用户发出连接请求，与用户进程交互，客户端通过TNSNAME或Easy connect或LDAP等名称解析方式来解析连接字符串

  5. 用户进程通过Oracle Net 与服务器进程交互，服务器端启用Listener进程
  6. 服务器进程与实例交互(由Oracle Net维护)，一旦连接成功，即使Listener服务停止，也不会影响该会话。
  7. 实例通过后台进程来完成数据库的读写操作

本地连接（CONNECT username/password）不需要Listener。

Listener配置文件：
ORACLE_HOME/network/admin/listerer.ora
ORACLE_HOME/network/admin/sqlnet.ora
ORACLE_HOME/network/admin/tnsnames.ora

一个Listener能够为多个数据库实例提供服务

3.3.Service Names

A service name is a logical representation of a service used for client connections.

When a client connects to a listener, it requests a connection to a service. When a database instance starts, it registers itself with a listener as providing one or more services by name. Thus, the listener acts as a mediator between the client and instances and routes the connection request to the right place.

A single service, as known by a listener, can identify one or more database instances. Also, a single database instance can register one or more services with a listener. Clients connecting to a service need not specify which instance they require.

Figure 18-6 shows one single-instance database associated with two services, book.example.com and soft.example.com. The services enable the same database to be identified differently by different clients. A database administrator can limit or reserve system resources, permitting better resource allocation to clients requesting one of these services.

Figure 18-6 Multiple Services Associated with One Database

可以指定一个或多个service_name，service_name通常可以使用SID代替。Oracle建议使用service_name而不是SID。可以通过定义多个不同的service_name来区分不同类型的用户连接，service_name缺省的格式为db_name.domain_name。
实例将所定义的service_name注册到Listener，当客户端请求服务时，Listener根据service_name决定将使用哪一个实例提供服务并与实例建立连接。
例如：
service_names = sales.oracle.com,hr.oracle.com
sales部门通过sales service_name建立连接，hr部门通过hr service_name建立连接。

3.4.Oracle Net 支持的连接类型

  1. 客户端-服务器模式(如SQLPlus)
  2. Java 应用程序(JDBC等)
  3. Web 客户端应用程序
  4. 使用基于Web的应用程序(App Server)作为中间件来实现，可以配置JDBC Oracle Call Interface (OCI) driver 或thin JDBC driver
  5. 通过HTTP直接连接到Oracle 服务器，如OEM

如果WEB应用服务器采用JDBC OCI DRIVER， 那么WEB服务必须的安装Oracle Net组件，才能和oracle数据库进行通讯，走的TCP/IP协议。
如果WEB应用服务是JDBC THIN DRIVER， 也就是瘦客户端， 那么不需要Oracle Net组件，只需要配置JAVA NET就可以和Oracle进行通讯。

3.5.Listener相关术语

SQL> conn scott/tiger@orcl

**connect string*

username/password@net_service_name
用户名scott
– 密码为tiger
– “/” 用于分割用户与密码
– “@” 指示网络连接所需的用户进程
– orcl 连接标识符

connect identifier

  • @后面的即为连接标识符，例如：orcl
  • 连接标识符的名字是一个映射到连接描述符的简化
  • 连接标识符可以为网络服务名/别名、数据库服务名等。(net service name, database service name, or net service alias.)

connect discriptor

使用一种特殊格式来描述连接的具体信息，信息包含了、数据库所在的位置(IP地址)、服务名、端口号等。

例如：tnsnames.ora

orcl = –网络服务名,数据库别名,等同于连接标识符(屏蔽客户端如何连接到服务器端的细节)
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.128)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = orcl.oracle.com)
)
)
DESCRIPTION内的信息即为连接描述信息。

Naming Method
1. Easy connect（EZCONNECT）
缺省的连接方式为Easy connect ，仅仅限制于使用TCP协议，不支持负载均衡
不支持connect-time failover、source routing、load balancing

SQL> connect username/password@host[:port][/service_name]
C:/>sqlplus scott/tiger@192.168.192.128:1521/orcl
  1. Local naming(本地名称解析)
    TNSNAMES
    使用本地配置文件tnsnames.ora
    支持所有的Oracle Net 协议
    支持高级连接选项：connect-time failover、source routing、load balancing
    在服务器端缺省路径为$ORACLE_HOME/network/admin
    tnsnames.ora可以使用TNS_ADMIN环境变量设定到任意位置

  2. Directory naming(目录名称解析)
    目录名称解析技术使得解析实现集中化管理，用户会被指向一个解析别名的LDAP目录服务器
    支持所有的Oracle Net协议及高级选项

  3. External Naming Method(外部名称解析方式)
    第三方名称解析方法如SUN的NIS等。

4.Service Registration

实例将数据库所提供的服务名及相关信息告知listener的过程称之为服务注册。
The listener determines whether a database service and its service handlers are available through service registration. During registration, the Listener Registration (LREG) process provides the listener with information about the following:

  • Names of the database services provided by the database
  • Name of the database instance associated with the services and its current and maximum load
  • Service handlers (dispatchers and dedicated servers) available for the instance, including their type, protocol addresses, and current and maximum load

  • 数据库的服务名

  • 实例名
  • 可用的服务处理程序(service handlers)，用于调度(共享模式)和派生子程序(专用模式)端口号等

The preceding information enables the listener to direct a client request appropriately.

The following figure shows two database instances registering information with two listeners. The figure does not represent all the information that can be registered. For example, listening endpoints, such as the port numbers, can be dynamically registered with the listener.

Figure 5-2 Service Registration

If the listener is not running when an instance starts, then the LREG process cannot register the service information. LREG attempts to connect to the listener periodically, but it may take up to 60 seconds before LREG registers with the listener after it has been started. To initiate service registration immediately after the listener is started, use the SQL statement ALTER SYSTEM REGISTER. This statement is especially useful in high availability configurations.
当一个实例启动时，如果listener没有运行，PMON就不能注册服务信息。PMON会定时尝试连接listener，但是在listener启动后60秒，PMON才能注册服务。为了在listener启动后马上注册服务，可以用SQL语句alter system register。

静态注册
指将实例的相关信息手动告知listener，可以使用netmgr,netca,oem以及直接vi listener.ora文件来实现:

SID_LIST_LISTENER =  -->定义LISTENER进程提供的数据库服务列表
    (SID_LIST =
        (SID_DESC =
            (GLOBAL_DBNAME = orcl.robinson.com)
            (ORACLE_HOME = /u01/app/oracle/10g)
            (SID_NAME = ORCL)
        )
    )
LISTENER =       -->监听器的名字，一个数据库可以有多个监听器
    (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = robinson)(PORT = 1521))
    )

Listener主动去找服务和实例,lsnrctl status里显示UNKNOWN。配置中的GLOBAL_DBNAME，可以写任意内容，与数据库无关，只要保证SID正确即可连上数据库。由于静态注册，参数是手动静态添加的，与数据库无关。数据库无法确认监听是否正确配置。因此，lsnrctl中的status显示状态为unkown。即不保证能连通数据库。
客户端在配置tnsnames.ora service_name时，“service_name”里填写内容要与服务端静态注册Listener时的GLOBAL_DBNAME一致。否则，无法连通数据库。

动态注册
实例在启动时使用PMON进程自动将instance_name和service_names等信息注册到已启动的缺省侦听器listener.ora, 不需要任何配置即可实现动态注册。 实例启动后会自动在本地主机默认的端口号上查找侦听器, 并在查找到后进行注册。可以在实例启动后的任何时候执行下面命令实现重新注册：
PMON只会动态注册port等于1521的监听，让PMON动态注册非1521端口的Listener，需要设置local_listener参数。

alter system register;

如果侦听器在非默认端口上运行，可以通过设置local_listener参数来指定侦听器所在的位置并手动进行注册。

SQL> alter system set local_listener = 'listener_dg';
SQL> alter system register;

建议设置service_names,instance_name参数保证成功注册：

alter system set service_names = 'orcl.oracle.com' scope =spfile;
alter system set instance_name = 'orcl' scope = spfile;
  • 服务名中有些状态为UNKNOWN，有些为READY
  • 对于动态注册的服务名，因为监听器知道实例的状态，所以正常状态通常显示为READY。
  • 对于静态注册的服务名，通常显示为UNKNOWN。

当客户端的请求到达listener时，listener选择一个合适的service handler为之服务。
之后listener就不再参与相关任务。

1) 缺省的动态注册
要用到service_names和instance_name, db_domain参数。如果没有设置service_names和instance_name，默认值为db_name, 不需要配置listener.ora文件，但需要配置初始化参数文件，参数service_names,可以设置多个服务名，区分不同业务。
PMON进程在数据库启动到mount或open时，动态从参数文件中读取service_names值。service_names可以为多个值。service_names缺省为dbca建立数据库时的全局数据库名。
2) 自定义端口的动态监听注册
需要设置service_names和local_listener参数，tnsnames.ora和listener.ora；另外还用到instance_name, db_name和db_domain参数, 如果想配置非默认端口，非默认监听名称，非TCPIP协议，那么需要配置listener.ora； 而且需要直接通过修改local_listener指定监听参数，或者配置local_listener参数，并在服务端配置tnsnames.ora指定监听参数。

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = orcl.oracle.com)(PORT = 1525))
    )
  )

方法一：修改local_listener参数：

alter system set local_listener='(ADDRESS = (PROTOCOL = TCP)(HOST =)(PORT = 1525))';

方法二：配置服务端的tnsnames.ora文件

tnsnames.ora中的条目只是单纯给local_listener使用，并不要求配置service_name的值，也就是说CONNECT_DATA不需要配置。

 ORCL =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = orcl.oracle.com)(PORT = 1525))
    )
  )

alter system set local_listener=ORCL;

以上两种方法效果是一样的。

5.Listener and Connection Requests

Each listener is configured with one or more protocol addresses that specify its listening endpoints. The protocol address defines the protocol the listener listens on and any other protocol-specific information. For example, the listener could be configured to listen at the following protocol address:

(DESCRIPTION=
   (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)))

The preceding example shows a TCP/IP address that specifies the host of the listener (sales-server) and a port number (1521).

Clients configured with a protocol address can send connection requests to the listener. When a client request reaches the listener, it selects an appropriate service handler to service the request and forwards the request to the handler. A service handler is a dispatcher or a dedicated server process that acts as a connection point to a database.

The following figure illustrates the role of the listener during the establishment of a connection. The figure shows a browser making an HTTP connection and a client making a database connection.

  1. The browser or client send a connection request to the listener.
  2. The listener parses the request and forwards it to the service handler for the database service requested.
  3. The browser or client connect to the database.

Figure 5-3 Listener Architecture

6.Oracle Restart

Oracle Restart enhances the availability of Oracle databases in a single-instance environment. Using the Server Control (SRVCTL) utility, you can add components such as the listener to an Oracle Restart configuration. The configuration enables the listener to start automatically when the listener fails or is not running.

When using Oracle Restart, note the following:

  • Use the SRVCTL utility to start and stop the listener. Do not use the listener control utility LSNRCTL.
  • Each listener must have a unique name.

7.Blocked Connection Requests

Blocked connection requests can occur when an incoming request occurs before the respective instance has been registered, or when a database is in restricted mode, such as when a shutdown of the database is in progress. If a database instance is in restricted mode, then LREG instructs the listener to block all connections to the instance. Clients attempting to connect receive one of the following errors:

  • ORA-12526: TNS: listener: all appropriate instances are in restricted mode
  • ORA-12527: TNS: listener: all appropriate instances are in restricted mode or blocking new connections
  • ORA-12528: TNS: listener: all appropriate instances are blocking new connections

The ORA-12528 error occurs when a database instance is not yet registered with the listener.

8.Shared Server

8.1.Shared Server Architecture

In a shared server architecture, a dispatcher directs multiple incoming network session requests to a pool of shared server processes

The shared pool eliminates the need for a dedicated server process for each connection. An idle shared server process from the pool picks up a request from a common queue.

The potential benefits of shared server are as follows:

  • Reduces the number of processes on the operating system
  • A small number of shared servers can perform the same amount of processing as many dedicated servers.
  • Reduces instance PGA memory
  • Every dedicated or shared server has a PGA. Fewer server processes means fewer PGAs and less process management.
  • Increases application scalability and the number of clients that can simultaneously connect to the database
  • May be faster than dedicated server when the rate of client connections and disconnections is high

Shared server has several disadvantages, including slower response time in some cases, incomplete feature support, and increased complexity for setup and tuning. As a general guideline, only use shared server when you have more concurrent connections to the database than the operating system can handle.

The following processes are needed in a shared server architecture:

  • A network listener that connects the client processes to dispatchers or dedicated servers (the listener is part of Oracle Net Services, not Oracle Database)
    Note: To use shared servers, a client process must connect through Oracle Net Services, even if the process runs on the same computer as the Oracle Database instance.
  • One or more dispatcher process (Dnnn)
  • One or more shared server processes

A database can support both shared server and dedicated server connections simultaneously. For example, one client can connect using a dedicated server while a different client connects to the same database using a shared server.

8.2.Dispatcher Request and Response Queues

A request from a user is a single API call that is part of the user’s SQL statement.

When a user makes a call, the following actions occur:

  1. The dispatcher places the request on the request queue, where it is picked up by the next available shared server process.
    The request queue is in the SGA and is common to all dispatcher processes of an instance.
  2. The shared server processes check the common request queue for new requests, picking up new requests on a first-in-first-out basis.
  3. One shared server process picks up one request in the queue and makes all necessary calls to the database to complete this request.
    A different server process can handle each database call. Therefore, requests to parse a query, fetch the first row, fetch the next row, and close the result set may each be processed by a different shared server.
  4. When the server process completes the request, it places the response on the calling dispatcher’s response queue. Each dispatcher has its own response queue.
  5. The dispatcher returns the completed request to the appropriate client process.

For example, in an order entry system, each clerk’s client process connects to a dispatcher. Each request made by the clerk is sent to this dispatcher, which places the request in the queue. The next available shared server picks up the request, services it, and puts the response in the response queue. When a request is completed, the clerk remains connected to the dispatcher, but the shared server that processed the request is released and available for other requests. While one clerk talks to a customer, another clerk can use the same shared server process.

Figure 18-9 shows how client processes communicate with the dispatcher across the API and how the dispatcher communicates user requests to shared server processes.

Figure 18-9 The Shared Server Configuration and Processes

8.3.Dispatcher Processes (Dnnn)

The dispatcher processes enable client processes to share a limited number of server processes.

You can create multiple dispatcher processes for a single database instance. The optimum number of dispatcher processes depending on the operating system limitation and the number of connections for each process.

Note: Each client process that connects to a dispatcher must use Oracle Net Services, even if both processes run on the same host.

Dispatcher processes establish communication as follows:

  1. When an instance starts, the network listener process opens and establishes a communication pathway through which users connect to Oracle Database.
  2. Each dispatcher process gives the listener process an address at which the dispatcher listens for connection requests.
    At least one dispatcher process must be configured and started for each network protocol that the database clients will use.
  3. When a client process makes a connection request, the listener determines whether the client process should use a shared server process:
  • If the listener determines that a shared server process is required, then the listener returns the address of the dispatcher process that has the lightest load, and the client process connects to the dispatcher directly.

  • If the process cannot communicate with the dispatcher, or if the client process requests a dedicated server, then the listener creates a dedicated server process and establishes an appropriate connection.

8.4.Shared Server Processes (Snnn)

Shared server processes are used in the shared server architecture, as shown in Figure 5-4. With shared server architectures, client processes ultimately connect to a dispatcher. The LREG process registers the location and load of the dispatchers with the listener, enabling the listener to forward requests to the least loaded dispatcher. This registration process is not shown in the figure.

A dispatcher can support multiple client connections concurrently. Each client connection is bound to a virtual circuit. A virtual circuit is a piece of shared memory used by the dispatcher for client database connection requests and replies. The dispatcher places a virtual circuit on a common request queue when a request arrives. An idle shared server picks up the virtual circuit from the request queue, services the request, and relinquishes the virtual circuit before attempting to retrieve another virtual circuit from the request queue. Shared servers place all completed requests into a dispatcher’s response queue. Each dispatcher has its own response queue in the SGA (System Global Area). This approach enables a small pool of server processes to serve a large number of clients.

Figure 5-4 Shared Server Architecture

9.Dedicated Server

9.1.Dedicated Server Architecture

In a dedicated server architecture, the server process created on behalf of each client process is called a dedicated server process (or shadow process).

A dedicated server process is separate from the client process and acts only on its behalf, as shown in Figure 18-8.

Figure 18-8 Oracle Database Using Dedicated Server Processes

A one-to-one ratio exists between the client processes and server processes. Even when the user is not actively making a database request, the dedicated server process remains—although it is inactive and can be paged out on some operating systems.

Figure 18-8 shows user and server processes running on networked computers. However, the dedicated server architecture is also used if the same computer runs both the client application and the database code but the host operating system could not maintain the separation of the two programs if they were run in a single process. Linux is an example of such an operating system.

In the dedicated server architecture, the user and server processes communicate using different mechanisms:

  • If the client process and the dedicated server process run on the same computer, then the program interface uses the host operating system’s interprocess communication mechanism to perform its job.
  • If the client process and the dedicated server process run on different computers, then the program interface provides the communication mechanisms (such as the network software and Oracle Net Services) between the programs.

Underutilized dedicated servers sometimes result in inefficient use of operating system resources. Consider an order entry system with dedicated server processes. A customer places an order as a clerk enters the order into the database. For most of the transaction, the clerk is talking to the customer while the server process dedicated to the clerk’s client process is idle. The server process is not needed during most of the transaction, and the system may be slower for other clerks entering orders if the system is managing too many processes. For applications of this type, the shared server architecture may be preferable.

9.2.Dedicated Server Processes

In a dedicated server architecture, each client process connects to a dedicated server process. The server process is not shared by any other client. Figure 5-5 illustrates a dedicated server architecture.

LREG registers information about dedicated server processes with the listener. This enables the listener to start a dedicated server process when a client request arrives and forward the request to it.

Note: Dedicated server architectures do not support HTTP, FTP, or WebDAV clients. Only database clients are supported.

Figure 5-5 Dedicated Server Architecture

10.Oracle Connection Manager Architecture

Oracle Connection Manager is a gateway through which client connection requests are sent either to the next hop or directly to the database server. Clients who relay connection requests through an Oracle Connection Manager can take advantage of the session multiplexing and access control features configured on Oracle Connection Manager. It carries no service information until a LREG process registers its services.

Oracle Connection Manager consists of three components:

  • listener
  • CMGW (Oracle Connection Manager Gateway)
  • CMADMIN (Oracle Connection Manager Administration)

The listener receives client connections and evaluates against a set of rules whether to deny or allow access. If it allows access, then the listener forwards a request to a gateway process, selecting the one with the fewest connections. The CMGW process, in turn, forwards the request to another Oracle Connection Manager or directly to the database server, relaying data until the connection terminates. If a connection to the server already exists, then the gateway multiplexes, or funnels, its connections through the existing connection. CMADMIN monitors the state of the gateway processes and the listener, shutting down or starting up processes as needed. In addition, it registers the location and load of the gateway processes with the listener, and it answers requests from the Oracle Connection Manager Control utility.

In the following figure, the listener screens connection requests. A gateway process registers with the CMADMIN process., and the CMADMIN process registers with the listener. Finally, the listener forwards the connection requests to the gateway process. After receiving the three valid client connections, the gateway process multiplexes them through a single network protocol connection to the database. The fourth connection is denied when it is evaluated against the set of rules.

Figure 5-6 Oracle Connection Manager Architecture

11.Database Resident Connection Pooling

Database Resident Connection Pooling (DRCP) provides a connection pool of dedicated servers for typical Web application scenarios.

A Web application typically makes a database connection, uses the connection briefly, and then releases it. Through DRCP, the database can scale to tens of thousands of simultaneous connections.

DRCP provides the following advantages:

  • Complements middle-tier connection pools that share connections between threads in a middle-tier process.
  • Enables database connections to be shared across multiple middle-tier processes. These middle-tier processes may belong to the same or different middle-tier host.
  • Enables a significant reduction in key database resources required to support many client connections. For example, DRCP reduces the memory required for the database and boosts the scalability of the database and middle tier. The pool of available servers also reduces the cost of re-creating client connections.
  • Provides pooling for architectures with multi-process, single-threaded application servers, such as PHP and Apache, that cannot do middle-tier connection pooling.

DRCP uses a pooled server, which is the equivalent of a dedicated server process (not a shared server process) and a database session combined. The pooled server model avoids the overhead of dedicating a server for every connection that requires the server for a short period.

Clients obtaining connections from the database resident connection pool connect to an Oracle background process known as the connection broker. The connection broker implements the pool functionality and multiplexes pooled servers among inbound connections from client processes.

As shown in Figure 18-10, when a client requires database access, the connection broker picks up a server process from the pool and hands it off to the client. The client is directly connected to the server process until the request is served. After the server has finished, the server process is released into the pool. The connection from the client is restored to the broker.

Figure 18-10 DRCP

In DRCP, releasing resources leaves the session intact, but no longer associated with a connection (server process). Unlike in shared server, this session stores its UGA in the PGA, not in the SGA. A client can reestablish a connection transparently upon detecting activity.

12.Complete Architecture

Oracle Net provides an architectural solution that allows for greater scalability in Internet and intranet environments.

Figure 5-7 shows how multiple connections to an Oracle database server are made more scalable with Oracle Connection Manager and a shared server architecture. Oracle Connection Manager is used to offload some of the network I/O of the application web servers, and a shared server is used to serve more concurrent users.

Figure 5-7 Scalable Architectural Solutions

13.Listener Log

  1. 监听器日志是一个纯文本文件，通常位于$ORACLE_HOME/network/log目录下，与sqlnet.log日志文件处于同一路径
  2. 其缺省的文件名为listener.log。对于非缺省的监听器，则产生的日志文件通常为listenername.log
  3. 该文件缺省由监听器自动创建，当日志文件丢失时或不存在时，会自动重新创建一个同名的文件，与alert_SID.log文件类似
  4. 该文件的尺寸会不断自动增长，当尺寸过大时或不便于阅读时，考虑将其备份
  5. Oracle监听器在运行时不允许对日志文件做删除，重命名操作
  6. 可以设置日志状态为ON或OFF来实现启用或关闭日志

设置日志文件目录的两种方法

lsnrctl SET LOG_DIRECTORY directory
LSNRCTL> SET LOG_DIRECTORY /usr/oracle/admin/log

设置日志文件的两种方法

 lsnrctl SET LOG_FILE file_name
 LSNRCTL> SET LOG_FILE file_name

设置日志的状态

lsnrctl SET LOG_STATUS {on | off}
LSNRCTL> SET LOG_STATUS {on | off}

14.配置sqlnet.ora限制IP访问

与防火墙类似的功能，Oracle 提供限制与允许特定的IP或主机名通过Oracle Net来访问数据库。这个功能由sqlnet.ora配置文件来实现。通过监听器的限制，实现轻量级访问限制，比在数据库内部通过触发器进行限制效率要高。

15.负载均衡与故障转移

Oracle负载均衡主要是指新会话连接到RAC数据库时,如何判定这个新的连接要连到哪个节点进行工作?通常情况下，负载均衡分为客户端负载均衡与服务器端负载均衡。客户端负载均衡通常是在客户端的tnsnames.ora中多添加一个链接地址以及LOAD_BALANCE与failover参数。而服务器端的负载均衡则相对复杂，下面具体描述服务器端负载均衡。

15.1.负载均衡

这里的负载均衡指的是连接的负载均衡，即客户可以随机从不同的实例中连接到数据库。
1.配置tnsnames.ora使得该文件中包含如下全部内容：

# LISTENERS_MASTDEV MASTDEV是数据库名，可以使用netmgr,netca编辑或直接使用Vim创建
LISTENERS_MASTDEV =
  (ADDRESS_LIST =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.oracle.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.oracle.com)(PORT = 1521))
  )

2.配置参数文件remote_listener

SQL> alter system set remote_listener='LISTENERS_MASTDEV' scope=both sid='*';

3.需要配置连接描述信息的两个IP地址、端口号、以及load_balance子项为yes (主要是load_balance子项)

MASTDEV =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.oracle.com)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.oracle.com)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = mastdev.oracle.com)
    )
  )

4.查看侦听器的状态，从下面可以看到mastdev.oracle.com服务中有两个实例为其提供服务

$ lsnrctl status
    Service "mastdev.oracle.com" has 2 instance(s).
      Instance "mastdev1", status READY, has 1 handler(s) for this service...
      Instance "mastdev2", status READY, has 2 handler(s) for this service...

5.测试负载均衡
使用shell脚本来进行测试负载均衡

    --编辑TestLoadBalance.sh
        #!/bin/bash
        #Usage: TestLoadBalance mastdev 1000
        count=0
        while [ count -lt2 ]   # Set up a loop control
        do                        # Begin the loop
            count='expr count + 1' # Increment the counter
            sqlplus -s system/oracle@1 @TestLoadBalance.sql  # Connect instance and execute sql statement
            sleep 1
        done
    --TestLoadBalance.sql 脚本
        col instance_name format a30
        select instance_name from vinstance;
    --实施测试
        ./TestLoadBalance.sh mastdev 1000

    --查看结果
        SQL> select inst_id,count(1) from gvinstance group by inst_d;
        INST_ID       COUNT(1)
        ----------    ----------
        mastdev        446
        mastdev        554

15.2.配置故障转移

负载均衡是用于实现基于连接的负载均衡，但不能解决节点是否可用，一旦一个节点损坏，已成功连接的客户端并不能转移到其他正常服务的实例中。而故障转移功能则使得该功能得以实现。可以使用srvctl 和dbca来创建服务。下面使用dbca来创建一个新的服务，客户端连接到实例后，对故障实现透明切换。

1.配置故障转移服务

在节点rac1使用oracle帐户启动dbca工具，
a.选择 Oracle Real Application Clusters database
b.选择 Services Management
c.集群数据库列表：单击 Next。
d.数据库服务：单击 Add。
添加服务：输入sales。
选择 mastdev1 作为首选实例。
选择 mastdev2 作为可用实例。
TAF 策略：选择 Basic。
单击 Finish。
e.数据库配置助手：单击 No 退出。
配置完毕后，在tnsnames.ora中多出了以下内容，注意是各个节点都会多出以下内容

    SALES =
      (DESCRIPTION =
        (ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip.oracle.com)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip.oracle.com)(PORT = 1521))
        (LOAD_BALANCE = yes)
         (CONNECT_DATA =
          (SERVER = DEDICATED)
          (SERVICE_NAME = sales.oracle.com)
         (FAILOVER =          --failover_mode是实现故障转移的关键选项
            (TYPE = SELECT)
            (METHOD = BASIC)  --TAF 策略：此处当前为 Basic
            (RETRIES = 180)
            (DELAY = 5)
          )
        )
      )

同时参数service_names会多出一个服务名，位于在配置数据库服务时选择的首选实例中

SQL> select instance_name from vinstance;
INSTANCE_NAME
----------------
devdb1
SQL> show parameter service_names
NAME                                 TYPE        VALUE
------------------------------------ ----------- ----------------------
service_names                        string      mastdev.oracle.com, sales
SQL> select instance_name from vinstance;
INSTANCE_NAME
----------------
mastdev1
SQL> show parameter service
NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------------
service_names                        string      mastdev.oracle.com

使用srvctl工具也可以看到该服务已经正常开始提供服务

SQL> !srvctl status service -d mastdev -s sales
Service sales is running on instance(s) mastdev
SQL> !lsnrctl status
Service "sales.oracle.com" has 1 instance(s).   --sales正常提供服务
  Instance "mastdev1", status READY, has 2 handler(s) for this service...

2.实现故障转移

下面使用帐户usr1，服务名sales从Windows客户端来登陆，注意要配置好客户端tnsnames，可以将服务器sales项内容全部复制到客户端tnsnames.ora中

C:\>sqlplus usr1/usr1@sales
SQL> col host_name format a20
SQL> select instance_number ins_no,instance_name,host_name,status from vinstance;
INS_NO     INSTANCE_NAME    HOST_NAME            STATUS
---------- ---------------- -------------------- ------------
 1         mastdev           rac1.oracle.com     OPEN
SQL> select failover_type,failover_method,failed_over from vsession
  2  where username='USR1';
FAILOVER_TYPE FAILOVER_M FAI
------------- ---------- ---
SELECT        BASIC      NO
--从其它会话使用sys帐户登陆到crm 并关闭该实例
SQL> show user;
USER is "SYS"
SQL> select instance_name from vinstance;
INSTANCE_NAME
----------------
mastdev

SQL> shutdown abort
ORACLE instance shut down.
--从先前登陆到sales的会话中验证会话故障切换功能
SQL> select instance_number ins_no,instance_name,host_name,status from vinstance;
INS_NO     INSTANCE_NAME    HOST_NAME            STATUS
---------- ---------------- -------------------- ------------
 2         mastdev           rac2.oracle.com    OPEN
SQL> select failover_type,failover_method,failed_over from vsession
  2  where username='USR1';  --第3列显示的为yes，也表明经过故障切换后提供的服务 
FAILOVER_TYPE FAILOVER_M FAI
------------- ---------- ---
SELECT        BASIC      YES
--由下面的查询中可以看到服务名sales被添加到可用实例devdb2，节点rac2 的service_names参数中
SQL> select instance_name from vinstance;
INSTANCE_NAME
----------------
mastdev2
SQL> show parameter service
NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------------------
service_names                        string      mastdev.oracle.com, sales

3.重新定位故障转移服务到首选实例
对于首选实例从故障中恢复后，需要手动来重新定位到首选实例

SQL> startup  --启动devdb1
SQL> show parameter service_names
NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------------
service_names                        string      mastdev.oracle.com
SQL> ! srvctl relocate service -d mastdev -s sales -i mastdev2 -t mastdev1
SQL> show parameter service_names
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------
service_names                        string      mastdev.oracle.com, sales

4.DML故障转移(不同于DQL，因此单独列出)
使用Windows客户端通过sales服务名登陆

C:\>sqlplus usr1/usr1@sales
SQL> show user;
USER is "USR1"
SQL> create table tb_temp (id int,ename varchar2(20));
Table created.
SQL> insert into tb_temp
  2  select 1,'Robinson' from dual
  3  union all
  4  select 2,'Jackson'  from dual;
2 rows created.
SQL> commit;
Commit complete.
SQL> select * from tb_temp;
ID         ENAME
---------- --------------------
 1         Robinson
 2         Jackson
SQL> delete from tb_temp;
2 rows deleted.
SQL> select * from tb_temp;
no rows selected

从另一个会话中使用sysdba关闭mastdev(shutdown abort)
再在刚刚执行表创建的会话中查询记录，收到提示，事务必须被回滚

SQL> select * from tb_temp;
select * from tb_temp
*
ERROR at line 1:
ORA-25402: transaction must roll back
SQL> rollback;
Rollback complete.
SQL> select * from tb_temp;
ID         ENAME
---------- --------------------
 1         Robinson
 2         Jackson
SQL> select failover_type,failover_method,failed_over from v$session
  2  where username='USR1';
FAILOVER_TYPE FAILOVER_M FAI
------------- ---------- ---
SELECT        BASIC      YES

对于DML 操作在实现故障转移时，将严格按照ACID原则来执行，大部分情况需要回滚事务。