16 Application and Networking Architecture

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 16-1, the client and server are located on different hosts connected through Oracle Net Services.

Figure 16-1 Client/Server Architecture and Distributed Processing

Description of "Figure 16-1 Client/Server Architecture and Distributed Processing"

Figure 16-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 16-2 Client/Server Architecture and Distributed Database

Description of "Figure 16-2 Client/Server Architecture and Distributed Database"

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.

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.

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.

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 (see "Monitoring"). 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.

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 (see "PL/SQL Subprograms ")

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

A GDS configuration is a named, self-contained system of databases integrated into a single virtual server that offers one or more global services. Essentially, a GDS configuration provides benefits to a set of databases that are analogous to the benefits that Oracle Real Application Clusters (Oracle RAC) provides a single database.

The databases in a GDS configuration can be locally or globally distributed. Clients can connect to the GDS configuration by specifying a global service name, without needing to know about the components and topology of the GDS configuration. In this sense, client connections to a GDS configuration are analogous to client connections in Oracle RAC.

Figure 16-4 shows one GDS configuration that contains 11 databases. DB1, DB2, and DB5 are Oracle RAC databases that use GoldenGate for replication. All three databases are protected by Data Guard. CAT is a database, also protected by Data Guard, which stores the metadata needed for GDS. DB5 is an Oracle RAC database that is protected by standby database DB6.

A GDS pool is a named set of databases within a GDS configuration that provides a unique set of global services and belongs to the same administrative domain. Partitioning of databases into pools simplifies service management and provides higher security by allowing each pool to be administered by a different administrator.

A database can only belong to a single pool. All databases in a pool need not provide the same set of global services. However, all databases that provide the same global service must belong to the same pool.

Figure 16-4 shows two GDS pools, SALES and HR. Each pool is associated with its own set of global services.

A GDS region is a logical boundary that contains database clients and servers that are geographically or otherwise related to each other. For example, a region might correspond to a data center. Typically, the members of a region share network proximity and are members of the same local area network (LAN) or metropolitan area network (MAN).

A GDS configuration can contain multiple regions. Figure 16-4 shows a Western region and an Eastern region. Each region must have at least one global service manager.

A region can contain databases that belong to different pools. In Figure 16-4, databases DB1 and DB2 are in the same pool, but in different regions. However, all the pools must belong to the same GDS configuration.

A global service manager is the central software component of GDS, providing service-level load balancing, failover, and centralized management of services in the GDS configuration. Global Data Service clients use a global service manager to perform all operations on the GDS configuration.

A global service manager is analogous to the remote listener in an Oracle RAC database, except the manager serves multiple databases. For example, a global service manager does the following:

• Acts as a regional listener that clients use to connect to global services

• Provides connect-time load balancing for clients

A global service manager also does the following:

• Manages global services across the regions of a GDS configuration

• Collects performance metrics from databases in the GDS configuration and measures network latency between regions of a GDS configuration

• Creates run-time load balancing advisory and publishes it to client connection pools

A global service manager is associated with one and only one GDS configuration. Multiple global service managers can exist for a single GDS configuration to improve availability and performance. Every global service manager in a GDS configuration manages all global services supported by the configuration.

gdsctl is a command-line tool that provides user interface to the GDS framework. To execute a command, gdsctl may need to establish an Oracle Net connection to a global service manager, GDS catalog database, or a GDS database.

Figure 16-4 shows two global service managers in each region. Each manager can be on a different host. gdsctl issues commands to the global service managers.

A GDS catalog is a metadata repository that stores configuration data for a GDS configuration and all its global services. One and only one catalog exists for each GDS configuration.

A GDS catalog resides in an Oracle database. The catalog itself consists of tables, views, and related database objects and structures.

Figure 16-4 shows a GDS catalog database CAT in the Western region protected by a standby database in the Eastern region.

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 16-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 16-6 Multiple Services Associated with One Database

Description of "Figure 16-6 Multiple Services Associated with One Database"

In Oracle Net, service registration is a feature by which the LREG process dynamically registers instance information with a listener. This information enables the listener to forward client connection requests to the appropriate service handler. LREG 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 registration is dynamic and does not require configuration in the listener.ora file. Dynamic registration reduces administrative overhead for multiple databases or instances.

The initialization parameter SERVICE_NAMES lists the services an instance belongs to. On startup, each instance registers with the listeners of other instances belonging to the same services. During database operations, the instances of each service pass information about CPU use and current connection counts to all listeners in the same services. This communication enables dynamic load balancing and connection failover.

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 (see "Large Pool").

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 16-8 shows how client processes communicate with the dispatcher across the API and how the dispatcher communicates user requests to shared server processes.

Figure 16-8 The Shared Server Configuration and Processes

Description of "Figure 16-8 The Shared Server Configuration and Processes"

Specific administrative activities cannot be performed while connected to a dispatcher process, including shutting down or starting an instance and media recovery. These activities are typically performed when connected with administrator privileges. To connect with administrator privileges in a system configured with shared servers, you must specify that you are using a dedicated server process.