Oracle Net Application Topologies
Understanding the possible application topologies involved in Oracle Net is essential. This knowledge helps you recognize which network problems demand debugging at each layer and which you can tackle by elimination: monitoring each stage and making sure the error is not occurring at that layer. Topologies also help you analyze performance problems by judging the volume of traffic, the number of repeated calls, and the bulk of character conversions taking place across the network.
The following are the topologies you are likely to encounter (each will be discussed in detail below):
- Client/server architectures
- Server application architectures
- Web application architectures
- Database links
- External procedures
- Heterogeneous connectivity
Irrespective of the programming interfaces you use (OCI, Pro*C, ODBC, etc.), application topologies influence the application design from the point of view of performance, error handling, and recovery.
Figure 3 illustrates a scenario in which the client application accesses the database across the network. The Oracle Net pieces lie on either end of the network (say, LAN/WAN). Every user connection from the client connects to a server process on the server side. If the configuration is a dedicated server configuration, one server process is spawned by the listener per client connection.
|Figure 3: Client Application Talking to the DB|
Such a configuration is not scalable. In case the configuration is of shared server type, no one-to-one correspondence exists between the client connections and the server processes spawned. To know your configuration, you can query the SERVER column of the V$SESSION view.
Figure 4 illustrates a scenario in which the client application talks via a communication layer to the server application/middleware. The bridge between the ends of the network is the communication layer. The server application/middleware will access the Oracle Instance via Oracle Net. Another variant of this topology is when the server application/middleware and the database server are on different machines.
|Figure 4: Client Application Talking to the Server Application|
Server Application Architectures
Figure 5 illustrates a scenario in which the server application accesses the database on the same machine. This is a minor variant of Figure 3, except that this scenario likely will reduce issues of network latency.
|Figure 5: Server Application Talking to the DB|
Web Application Architectures
Figure 6 illustrates a scenario in which the Web browser connects to the Web server. The Web server talks to the Oracle database using a Web server module, an application server, a transaction server, a server component, or a CGI handler. As in Figure 4, another variant of this topology is when the application server/server component and the database server are on different machines.
|Figure 6: Client Application Talking to the Server Application|
Figure 7 illustrates a scenario of a database link that accesses objects from another database. The other database may be on the same machine or on another machine. A database link is like a stub object that exists in database A, while operations over the link actually take place on database B.
|Figure 7: Two Variants of a Database Link Topology|
Note that in these figures, the database and the server process are mentioned separately. The database link is a persistent object and its lifetime is not limited to the lifetime of the instance. Just to clarify, the server processes, the background processes, and the SGA together form the instance. The database is the collection of files containing data and configuration/state information.
The basis of replication is a database link. The refreshing of data, from the materialized view log to the materialized view, happens over the database link and conversely over Oracle Net (see Figure 8).
External procedures (ExtProcs) are procedures in libraries declared in the database, but they are defined externally and run in a separate process space (see Figure 9). This is a mechanism by which database functionality may be extended to provide more OS interaction by means of a shared library or DLL. These are also used to perform computation-intensive operations in a more suited language like C. The listener spawns the ExtProc process in a manner similar to the server processes (hence the dotted line). Once the process is spawned, the communication happens via IPC.
The purpose of heterogeneous gateways is to make non-Oracle databases seem like Oracle databases to client programs. The same SQL and APIs to be run against an Oracle database work against other databases. Oracle provides transparent gateways for commercial/popular DBMSs (see Figure 10). Observe that, conceptually, Figure 10 is similar to Figure 9.
A variant of Figure 10, Figure 11 illustrates the heterogeneous connectivity to those DBMSs for whom no transparent gateway exists and for which Oracle needs to fall back upon generic interfaces like ODBC or OLEDB and the other DBMSs native drivers to communicate.