Oracle7 Server Distributed Systems Manual, Vol. 1 Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Understanding Distributed Systems

This chapter introduces the concepts behind distributed systems and explains how the client-server model, networks, and distributed databases can create an efficient distributed environment. Replication issues (basic replication, the advanced replication option, among others) are discussed in Oracle7 Server Distributed Systems, Volume II.

This chapter covers the following topics:

It is assumed that you are familiar with the concepts and terminology in the Oracle7 Server Concepts manual. Much detailed information is also provided in the Oracle7 Server Administrator's Guide, and other Oracle7 Server documentation. For introductory Networking issues, you should be familiar with Understanding SQL*Net.

Information in this book is relevant only to Oracle7 Server, release 7.3 and higher with the distributed option.


A distributed system is one in which both data and transaction processing are divided between one or more computers connected by a network, each computer playing a specific role in the system.

Understanding distributed systems requires a knowledge of a number of areas including system architecture, networking, transaction processing, security, among others. Oracle7 Server Distributed Systems, Volume I provides you with an introduction to the basic concepts and terminology required to understand distributed systems. It also discusses the components of a distributed system (for example, computers, workstations, networks, and security).

Replication (insuring that the data at all sites in a distributed system reflects any changes made anywhere in the system) is discussed in detail in Oracle7 Server Distributed Systems, Volume II, which covers both basic replication (standard with the distributed option) and the advanced replication option.

In this chapter, the client-server model is discussed first because this model is essential to distributed systems. You will be introduced to the concept of computers that act as clients and/or servers. Subsequently, you will be shown how the client-server model fits into a distributed system and how networks facilitate

Subsequent chapters of Oracle7 Server Distributed Systems, Volume I introduce networking concepts, terminology, and related Oracle networking products. Utilities for both network and database administration are also discussed, as is transaction recovery management (the mechanism that insures that all sites in a distributed system participating in a transaction that updates data do the same thing).

Although developing applications for a distributed system is similar to developing for non-distributed systems, the application development chapter discusses certain issues that can affect an application in a distributed system. It also documents Oracle's support for X/Open's XA Library.

Oracle7 Server Distributed Systems, Volume I does not attempt to instruct you in implementing your distributed system. All of this information already exists in the Oracle7 Server and Oracle Network Products documentation sets. This book does provide pointers, wherever possible, to the manuals that contain instructions specific to completing certain tasks.

The Client-Server Model and Distributed Systems

The client-server model is basic to distributed systems. It is a response to the limitations presented by the traditional mainframe client-host model, in which a single mainframe provides shared data access to many dumb terminals. The client-server model is also a response to the local area network (LAN) model, in which many isolated systems access a file server that provides no processing power.

Client-server architecture provides integration of data and services and allows clients to be isolated from inherent complexities, such as communication protocols. The simplicity of the client-server architecture allows clients to make requests that are routed to the appropriate server. These requests are made in the form of transactions. Client transactions are often SQL or PL/SQL procedures and functions that access individual databases and services.

The Components of the Client-Server Model

The client-server model consists of three parts:

The Client

The client is the machine (workstation or PC) running the front-end applications. It interacts with a user through the keyboard, display, and pointing device such as a mouse. The client also refers to the client process that runs on the client machine.

The client has no direct data access responsibilities. It simply requests processes from the server and displays data managed by the server. Therefore, the client workstation can be optimized for its job. For example, it might not need large disk capacity, or it might benefit from graphic capabilities.

This simple client view is necessary to allow many different client-server implementations, ranging from PCs to mainframes and different client interfaces to store and retrieve data. To support this client environment, Oracle7 fully implements the ANSI/ISO SQL standard and interfaces.

The Server

The server is the machine that runs Oracle7 software and handles the functions required for concurrent, shared data access. It is often referred to as the back-end. Server also refers to the server process that runs on the server machine.

The server receives and processes SQL and PL/SQL statements originating from client applications. The server can also be optimized for its duties. For example, it can have large disk capacity and fast processors. It can also take the load of disk I/O, printing, file transfer, and so on.

The Network

The network enables remote data access through client-server and server-to-server communication. Oracle's Network Products allow databases and applications to reside on different machines with different operating systems while still communicating as peer applications.

What is the Client-Server Model?

Certain features are always present in the client-server model.

There is a server process that can process requests from one or more client processes concurrently over a network connection. The client machine provides front-end application software for accessing the data on the server (it may include a graphical interface).

The client initiates transactions, the server processes the transactions (though it can also activate stored procedures), triggers, and stored business rules. Typically, there is a structured query language (for example, SQL) that can be used to access data stored on the server side.

Other aspects of a client-server architecture are:

Benefits of the Client-Server Model

A client-server system is one that uses network resources and shared processing (by both client and server), to provide front-end applications with concurrent, shared data access.

Many clients can share the resources provided by a single server, thus moving the non-critical data and functions to the desktop workstation, leaving the server free for critical processing needs.

Other benefits include:

Server-to-Server Communication

Client-server architecture alone does not always meet the needs of a single logical database. The server also requires advanced server-to-server capabilities. These include SQL language requests to Oracle7 Servers and remote procedure calls (RPCs) to Oracle7 Servers.

It must be possible to make changes in the location, number, and function of servers in a complex environment as the information processing needs of the organization change over time. It is only through a complete server-to-server implementation that this can be achieved.

Oracle7 Server and the Client-Server Model

Oracle Corporation has implemented a server technology in which multiple servers are accessible to clients through the services provided by a single server. Clients can communicate with multiple servers (and gateways) through advanced server-to-server communication, as shown in Figure 1 - 1.

Oracle7 Server provides a client with a single consolidated view of an organization's data and services. An Oracle7 Server client's view of a distributed system is that of a single logical database comprising a distributed database with multiple independent databases.

Figure 1 - 1. Oracle7 Using Dedicated Server Processes

An essential requirement for a server in a client-server environment is a symmetric implementation. This means that any Oracle7 Server must and will support all of the services needed to implement the client's view of a single logical database.

The services implemented by Oracle7 include:

Server Configurations

Oracle7 Server can be configured in three ways, as a:

Dedicated Server

Figure 1 - 2 illustrates Oracle7 running on two computers using the dedicated server architecture.

Figure 1 - 2. Oracle7 Using Dedicated Server Processes

Notice that, in this type of system, the database application is executed by a user process on one machine, and the associated Oracle7 Server code is executed by a server process on another machine. These two processes are separate, distinct processes.

Dedicated Server Process

The separate server process created for each user process is called a dedicated server process (formerly referred to as "shadow process") because this server process acts only on behalf of the associated user process. In this configuration (sometimes called two-task Oracle7), every user process connected to Oracle7 has a corresponding dedicated server process.

Therefore, there is a one-to-one ratio between the number of user processes and server processes in this configuration. Even when the user is not actively making a database request, the dedicated server process remains (although it is inactive and may be paged out on some operating systems).

The dedicated server architecture of Oracle7 allows client applications being executed on client workstations to communicate with another computer running Oracle7 across a network.

This configuration of Oracle7 is also used if the same computer executes both the client application and Oracle7 Server code and, the host operating system cannot maintain the separation of the two programs if they are run in a single process. A common example of such an operating system is UNIX.

The Program Interface

The program interface allows communication between the two programs. In the dedicated server configuration, communication between the user and server processes occurs using different mechanisms:

Additional Information: These communications links are operating system- and installation-dependent; see your Oracle operating system-specific documentation and Understanding SQL*Net for more information.

Additional Information: See "The Program Interface" in Chapter 1 of the Oracle7 Server Concepts manual for additional information.

Combined User/Server Process

Figure 1 - 3 illustrates the combined user/server configuration of Oracle7. Notice that in this configuration, the database application and the Oracle7 Server code all run in the same process, termed a user process.

Figure 1 - 3. Oracle7 Using Combined User/Server Processes

This configuration of Oracle7 (sometimes called single-task Oracle7) is only feasible in operating systems that can maintain a separation between the database application and the Oracle7 code in a single process (such as on the VAX VMS operating system). This separation is required for data integrity and privacy. Some operating systems, such as UNIX, cannot provide this separation, so they must have separate processes run application code and server code to prevent damage to Oracle7 by the application.

Note: The program interface is responsible for the separation and protection of Oracle7 Server code and is responsible for passing data between the database application and the Oracle7 user program. For more information about the program interface, see the Oracle7 Server Concepts manual.

Only one Oracle7 connection is allowed at any time by a process using the above configuration. However, in a user-written program, it is possible to maintain this type of connection while concurrently connecting to Oracle7 using a network (SQL*Net) interface.

Multi-Threaded Server

The multi-threaded server (MTS) configuration (or "shared server" configuration) allows many user processes to share very few server processes.

In a non-multi-threaded server configuration, each user process requires its own dedicated server process; a new server process is created for each client requesting a connection. A dedicated server process remains associated to the user process for the remainder of the connection.

In a multi-threaded server configuration, client processes connect to a SQL*Net listener process which provides the network address of a dispatcher process to the client. The client then connects to this dispatcher process. Requests for services from the client are placed in a request queue where they wait for the next available server process. Results are returned to the client by the dispatcher process. In this way, the listener routes client requests to the next available shared server process.

The advantage of the multi-threaded server configuration is that system overhead is reduced, so the number of users that can be supported is increased. For more information about the multi-threaded server and the network listener, see "How SQL*Net Establishes Connections to the Multi-Threaded Server" [*]. and "SQL*Net and the Network Listener" [*].

Contrasting Dedicated Server Processes and Multi-Threaded Server Processes

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 on the telephone talking to the customer, and the server process dedicated to the clerk's user process remains idle. The server process is not needed during most of the transaction, and the system is slower for other clerks entering orders.

The multi-threaded server configuration eliminates the need for a dedicated server process for each connection. A small number of shared server processes can perform the same amount of work, and the memory required for each user is relatively small. Because less memory and process management are required, more users can be supported.

The Database Server

A database client-server system is a subset of the client-server model. The machine on which the database resides is the database server. Typically, the database also holds stored procedures, event alerts and triggers. It also provides services, such as row-level locking, security, logging, recovery, concurrency management, among others. Other types of servers include file servers, mail servers, and name servers.

The database server allows many users to access data from a single location. However, this architecture can be extended to allow many users to access data from many databases, and it allows those databases to cooperate in maintaining consistency.

Oracle7 Server provides extensive server functionality. The simplicity of the client-server architecture allows clients to make requests that are routed to the appropriate server. These requests are in the form of transactions. Client transactions can be SQL or PL/SQL procedures and functions that access the individual databases and services.

Front-End Client Applications

A front-end application queries a host or server-based database and extracts information for use with report writers, spreadsheets, and so on. It may also provide protocol processing and has access to server-based resources.

The front-end application runs on a workstation and provides a character-based or graphic interface to help the user to access the remote data store(s). These applications can be written in-house or purchased from Oracle Corporation or third-party vendors. Oracle Corporation also provides many tools for the development of these applications.

The function of client-side applications is multi-faceted:

Back-End Services

Besides acting as a database server, a server can provide other multi-user service applications for mail, document management, and so on.


The most basic tool for data access is the structured query language (SQL). Many SQL and SQL-generating tools have been developed for accessing remote data. Although the front-end application presents a much simplified method of creating queries for the user, the result of the query that is passed to the server is SQL.

Remote Procedure Calls

Similar to local procedure calls where frequently used code is stored as a procedure or routine, remote procedure calls (RPCs) allow the same functionality over a network of systems. When a program executes the stored code, it passes on any necessary parameters in the call.

Because the procedure is located remotely, however, it must be coded to understand what to do at the remote location, and how to return the results to the requesting application.

Network Issues in a Client-Server System

Although a client-server system can consist of a server process and client process that exist on the same machine, this book assumes that the typical client-server system consists of a client machine and a server machine.

Client-server systems cannot function without communication. Designing any client-server system requires a knowledge of and an ability to implement appropriate networking using SQL*Net, Oracle Names and other network products.

Other communications software may be supplied by Oracle Corporation but is often purchased separately from the hardware vendor or a third-party software supplier.

The simplest network connection, single client to single server, requires only a single protocol, usually provided by the host operating system. DECnet, TCP/IP, LU6.2, and ASYNC are examples.

However, most companies require connections from many types of machines using different operating systems and communication protocols. Such systems grow quickly in complexity.

SQL*Net uses the communication protocols or application program interfaces (APIs) supported by a wide range of networks to provide for a distributed Oracle7 system. A communications protocol is a set of standards, implemented in software, that govern the transmission of data across a network. An API is a set of program functions or calls that allow an application to make use of, or communicate with, an underlying program or system.. In the case of networks, the API provides the means to establish remote process-to-process communication over a communication protocol

Communication protocols define the way a network transmits and receives data. In a networked environment, Oracle7 Server communicates with client workstations and other Oracle7 Servers using SQL*Net. SQL*Net supports communications on all major network protocols, ranging from those supported by PC LANs, to those used by the largest mainframe computer systems.

Without SQL*Net, an application developer must manually code all communications in an application that operates in a networked, distributed processing environment. If the network hardware, topology, or protocol changes, the application has to be modified accordingly.

However, by using SQL*Net, the application developer does not have to be concerned with supporting network communications in a database application. If the underlying protocol changes, the database administrator makes some minor changes, while the application continues to function with no modification.

How SQL*Net Works

SQL*Net drivers provide an interface between Oracle7 processes running on the database server and the user processes of Oracle7 tools running on other computers of the network.

The SQL*Net drivers take SQL statements from the interface of the Oracle7 tools and package them for transmission to Oracle7 over one of the supported industry-standard, higher-level protocols or programmatic interfaces. The drivers also take replies from Oracle7 and package them for transmission to the tools over the same higher-level communications mechanism. This is all done independently of the network operating system.

Additional Information: Depending on your operating system, the SQL*Net software may include the driver software and start an additional Oracle7 background process. See your Oracle operating system-specific documentation for details.

Database Links

For client machines to access a remote database on the server, the communications protocol must be told where the database resides through a database link. A database link is a string that uniquely identifies to the communication software the location and name of the remote database.

Note: Oracle7 requires the database link name to be the same as the global database name (or service name). For more information on naming issues in a distributed system, see page 2 - 26.

Location Transparency

Oracle7 server provides the means to make data objects such as tables in remote databases look like they are in the local database to an application developer or user of that data object. Once a client-server system has been set up, users should be able to access the remote database with complete location transparency, provided the database link has been properly defined. For more information on location transparency, see page 2 - 6.

Introduction to Distributed Systems

An Oracle7 distributed system can be a blend of distributed database and distributed processing systems.

Distributed Processing and Distributed Databases

Distributed processing and distributed databases are not the same thing, although they have similarities. In a distributed processing system, processing data (searching for information, storing results) is distributed. In a distributed database, the data is distributed in databases on more than one machine.

Distributed Database System Basics

A distributed database system appears to a user as a single server but is, in fact, a set of two or more servers. The data on each server can be simultaneously accessed and modified via a network. Each server in the distributed system is controlled by its local database administrator (DBA), and each server cooperates to maintain the consistency of the global database.

Note that in Figure 1 - 4, the workstations are the clients and connect to the database servers over the communications network. The two servers, HQ and SALES also communicate over the network to maintain data consistency, as changes to the SALES database may have impact on the HQ database as when data replication has been implemented.

Figure 1 - 4. A Distributed Environment

Figure 1 - 5 illustrates how the HQ and SALES database servers work together.

Figure 1 - 5. An Example of Cooperative Server Architecture

Note also that the INSERT statement includes the location of the database to be accessed (SALES) because the client from which the SQL statement is issued is connected directly to the HQ database server only.

Concepts and Terminology

The following sections outline some of the general terminology and concepts used to discuss distributed systems.


A node in a distributed system can be a client, a server, or both. Every computer in a system is a node.

For example, in Figure 1 - 5, the HQ node acts as a server when the DELETE statement is issued against the table DEPT.

It acts as a client when it issues the INSERT and SELECT statements against remote data in the table EMP which resides in the SALES database.


The ability to insure reliable data replication is an extremely important (and potentially complex) factor in a distributed system. Data replication means that any given data object can have several stored representatives at several different sites and that, if each representative is potentially updatable, there must be a mechanism for insuring that all representatives reflect the changes.

Oracle7 Server provides a variety of mechanisms for replicating your data. The methods you select will depend on your specific needs:

If you simply need to view the data at multiple sites, without updating it, you might choose to use read-only snapshots. If you need to be able to update multiple copies of the same data, you will need to use Oracle's symmetric replication facility.

See page 5 - 2 for a brief introduction to replication and how it fits into the scheme of a distributed system.

Oracle7 Server Distributed Systems, Volume II provides an introduction to the Oracle7 Server replication capabilities and detailed instructions on how to implement and maintain replication for your system.

Direct and Indirect Connections

A client can connect directly or indirectly to a server. In Figure 1 - 5, when the client application issues the first and third statements for each transaction, the client is connected directly to the intermediate HQ database and indirectly to the SALES database that contains the remote data.

Site Autonomy

Site autonomy means that each server participating in a distributed system is administered independently (for security and backup operations) from the other servers. Although all the servers can work together, they are distinct, separate repositories of data and are administered individually. Some of the benefits of site autonomy are:

Name Resolution

A schema object (for example, a table) is accessible from all nodes that form a distributed system. Therefore, just as a non-networked local database architecture must provide an unambiguous naming scheme to distinctly reference objects within the local database, so must a distributed system use a naming scheme to ensure that objects throughout the system can be uniquely identified and referenced.

To resolve references to objects (a process called name resolution) within a single database, the database usually forms object names using a hierarchical approach. For example, within a single database, each schema has a unique name, and that within a schema, each object has a unique name.

Because uniqueness is enforced at each level of the hierarchical structure, an object's local name is guaranteed to be unique within the database, and references to the object's local name can be easily resolved.

Distributed systems simply extend the hierarchical naming model by enforcing unique database names within a network. As a result, an object's global object name is guaranteed to be unique within the distributed system, and references to the object's global object name can be resolved among the nodes of the system.

See page 2 - 26 for more information on global naming issues.

Remote/Distributed Queries and Updates

A remote query is a query that selects information from one or more remote tables, all of which reside at the same remote node.

A remote update is an update that modifies data in one or more tables, all of which are located at the same remote node.

Note: A remote update may include a subquery that retrieves data from one or more remote nodes. Because the update is performed at only a single remote node, however, the statement is classified as a remote update.

A distributed query retrieves information from two or more nodes.

A distributed update modifies data on two or more nodes. A distributed update is possible using a procedure or trigger, which includes two or more remote updates that access data on different nodes. Statements in the program unit are sent to the remote nodes, and the execution of the program succeeds or fails as a unit.

Remote and Distributed Transactions

A remote transaction is a transaction that contains one or more remote statements, all of which reference the same remote node. A distributed transaction is any transaction that includes one or more statements that, individually or as a group, update or query data on two or more distinct nodes of a distributed system. If all statements of a transaction reference only a single remote node, the transaction is remote, not distributed.

Remote Procedure Calls (RPCs)

Oracle7 supports RPCs with full PL/SQL datatypes as parameters and return values. Because PL/SQL datatypes are a superset of SQL datatypes, PL/SQL procedures and functions are ideal for managing Oracle7 services on remote servers. All parameters and return values provided by a remote server can be examined and stored by the calling server. This allows the local server to maintain the client's calling interface and semantics - even if the service is reimplemented, or the remote site decides to change the RPC's interface.

Access to Non-Oracle Data and Services through Oracle Open Gateway Technology

Oracle Open Gateway Technology provides access to non-Oracle data through gateway servers, which are a part of a distributed system like any other distributed server. Open Gateway technology is tightly integrated with the Oracle7 Server. This permits integration of both SQL and non-SQL data and services. For more information, see your Oracle Open Gateway documentation.

Gateway servers access the target system directly. Oracle7 client applications do not connect directly to a gateway server, but indirectly by first connecting to an integrating server. An integrating server communicates with a gateway server in the normal Oracle7 server-to-server manner using SQL*Net. See Figure 1 - 1.

A gateway server is a single process and does not start background processes. On some platforms, such as MVS, the gateway server starts once, and maintains multiple user sessions in memory, where one session handles the requests from a single Oracle7 client application. On other platforms, such as UNIX platforms, a gateway server starts for each user session.

Transparent Gateway Server

A transparent gateway server emulates an Oracle7 Server and usually resides in the target system environment. The database administrator creates database links and local synonyms at all Oracle7 Servers that require access to the data source. The gateway server is then transparent for Oracle7 client applications that access what appear to be Oracle7 tables or views.

A client application connects directly to an integrating Oracle7 Server, which is responsible for connecting to the transparent gateway server. A transparent gateway does not execute PL/SQL stored procedures, but a stored procedure on an Oracle7 Server can issue SQL statements that access the data source via the gateway.

An Oracle7 client application queries and modifies a data source using ANSI/ISO SQL via the transparent gateway. Transparent gateways always perform automatic data conversion. In some cases, this is driven by gateway data definition language (GDDL) for non-SQL data sources.

A target system is unlikely to have all Oracle7 functionality. For queries, missing functionality is often fulfilled by the gateway server or integrating server. For example, where a target system has a limited capability to conditionally retrieve data, the gateway can make up for this missing functionality by means of a post-filter.

Procedural Gateway Server

A procedural gateway server emulates Oracle7 Server's remote procedural capabilities and usually resides in the target system environment. The database administrator creates database links and local synonyms at all Oracle7 Servers that require access to the data source. The gateway server is then transparent for Oracle7 client applications, which access what appear to be Oracle7 PL/SQL stored procedures.

A client application connects directly to an integrating Oracle7 Server, which is responsible for connecting to the procedural gateway server.

A procedural gateway does not execute SQL requests. An Oracle7 client application executes calls at a target system using PL/SQL remote procedure calls. Automatic data conversion to and from the datatypes of the arguments in the procedure call and the call at the target system is driven by gateway data definition language.

Transaction Recovery Management

An efficient system, distributed or non-distributed, must guarantee that all statements in a transaction are either committed or rolled back as a unit, so that the data in the logical database can be kept consistent. The effects of a transaction should be either visible or invisible to all other transactions at all nodes. This should be true for transactions that include any type of operation, including queries, updates, or remote procedure calls.

The general mechanisms of transaction control in a non-distributed system are discussed[*]. In a distributed system, Oracle7 must coordinate transaction control over a network and maintain data consistency, even if a network or system failure occurs.

Transaction recovery management guarantees that all database servers participating in a distributed transaction either all commit or all roll back the statements in the transaction. Transaction recovery management also protects implicit DML operations performed by integrity constraints, remote procedure calls, and triggers. Transaction recovery management is described[*].


The functionality of a distributed system must be provided in such a manner that the complexities of the system are transparent to both users and administrators.

For example, a distributed system should provide methods to hide the physical location of objects throughout the system from applications and users. Location transparency exists if a user can refer to the same table the same way, regardless of the node to which the user connects. Location transparency is beneficial for the following reasons:

A distributed system should also provide query, update, and transaction transparency. For example, standard SQL commands, such as SELECT, INSERT, UPDATE and DELETE, should allow users to access remote data without the requirement for any programming. Transaction transparency occurs when the DBMS provides the functionality described below using standard SQL COMMIT, SAVEPOINT, and ROLLBACK commands, without requiring complex programming or other special operations to provide distributed transaction control:

A distributed architecture should also provide facilities to transparently replicate data among the nodes of the system. Maintaining copies of a table across the databases in a distributed system is often desired so that:

A database server that manages a distributed system should make table replication transparent to users working with the replicated tables.

Finally, the functional transparencies explained above are not sufficient alone. The distributed system must also perform with acceptable speed.

National Language Support (NLS)

Oracle7 supports heterogeneous client/server environments where clients and servers use different character sets. The character set used by a client is defined by the value of the NLS_LANG parameter for the client session. The character set used by a server is its database character set. Data conversion is done automatically between these character sets if they are different. For more information about National Language Support features, see the Oracle7 Server Reference.

SQL Statement Execution in a Distributed System

SQL statement execution of remote and distributed statements is essentially the same in a distributed system as in a non-distributed database. However, depending on the type of statement issued, the location of statement execution can vary.

Remote Queries and Updates

All remote queries and remote updates are sent to the remote node for statement execution. The remote node executes the statement and returns any results back to the local node, which returns them to the user or application.

Distributed Queries and Distributed Updates

The statements in a procedure or trigger that constitute a distributed update are sent individually to the correct remote node for execution. Results are returned to the local node and then to the calling user or application.

Values for Environmentally- Dependent SQL Functions

In a distributed system, environmentally-dependent SQL functions, such as SYSDATE, USER, UID, and USERENV, are evaluated always with respect to the local node regardless of where the statement (or portion of a statement) is executed. The USERENV function is supported only for queries.

Shared SQL for Remote and Distributed Statements

The mechanics of a remote or distributed statement using shared SQL are essentially the same as those of a local statement. The SQL text must match, the referenced objects must match, and the bind types of any bind variables must be the same. If available, shared SQL areas can be used for the local and remote handling of any statement (or decomposed query).

Optimization of SQL Statements in a Distributed System

The optimization approach available for SQL statements can vary depending on the type and complexity of the statement.

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index