[Laskey99] Chapter 5. Oracle Networking

Chapter 5.

Few, if any, concepts are as important to the proper administration of an Oracle database as the concept of networking. Connectivity—the ability to make connections between clients and databases, as well as between databases—has been a key component of Oracle for over a decade. While some of the terminology and technology has changed, the need for a clear understanding of networking and how it functions with the Oracle framework is at least as critical today as it was when client/server was a brand new buzzword.

This chapter discusses networking and how it relates to Oracle. It also shows you the tools Oracle provides for managing its networking components and lays out the networking capabilities of the modern Oracle database.

5.1. Oracle Network Architecture

The complexity of Oracle networking arises to some extent from its basic simplicity. Although that statement appears to contradict itself, it points out a basic characteristic of the Oracle networking architecture: it is a simple structure that can be used to implement complex solutions. Oracle's networking architecture is simple because it is designed to allow any Oracle product, running on any supported platform, to "talk" to any other Oracle product without regard for network topologies or protocols. Figure 5.1 shows several Oracle databases and clients connected via a "cloud" with no network identification.

Figure 5.1. A simple view of the Oracle network architecture

Because Oracle is designed to run on almost any network, using almost any accepted protocol, the configuration of the Oracle components that interface with the network can be very complex, which often leads to frustration when the DBA is not sure where to turn in order to solve a problem. This is because Oracle often hides its underlying complexity. For example, the simple connection shown in Figure 5.1 could, in reality, look more like the more complex connection shown in Figure 5.2, where the physical and logical components of the network can be seen. That figure shows a client and server connected using TCP/IP, 10BaseT, and token ring with routers.

Figure 5.2. A more complex view of an Oracle network

5.1.1. SQL*Net and Net8

Oracle achieves its goal of transparent connectivity between and among its products through the use of a product called SQL*Net.

With the introduction of Oracle8, SQL*Net has been renamed Net8. However, except for some added functionality, Net8 and SQL*Net are the same product; thus, when we refer to SQL*Net, we will mean both SQL*Net and Net8 unless otherwise noted.

5.1.1.1. SQL*Net functionality

Simply put, SQL*Net provides all the facilities required for an Oracle client (that is, a network machine running a tool that will connect to the Oracle database) to connect to an Oracle database, to maintain that connection, and to process transactions on the database. This is done without regard for location (location transparency ), network protocol (network transparency ), host operating system, or any other factor. SQL*Net also supports the complexities of distributed transactions, and so is able to:

• Determine the location of each server involved in a transaction

• Resolve any issues arising from character set differences on the participating nodes

• Create and maintain connections to each required node, regardless of network attributes

• Handle any network disconnects or other errors

5.1.1.2. How SQL*Net works

SQL*Net is designed to run on top of an existing network protocol, and is therefore independent of the particular hardware and software being used to implement a network. As long as SQL*Net on both sides of the connection is using the same basic protocol (e.g., TCP/IP, LU6.2 or IPX), it won't matter to Oracle how the underlying network transports the information. Figure 5.3 shows the relationship between SQL*Net and the underlying network; it illustrates Oracle, SQL*Net, TCP/IP, and physical transport on both sides.

Figure 5.3. Relationship between SQL*Net and the underlying network

The key here is that connectivity to and from the Oracle database and tools is achieved by using SQL*Net, which presents a consistent interface to Oracle. By utilizing an appropriate protocol adapter (in this case, TCP/IP) on each side, SQL*Net is able to conform to the network protocol in use. SQL*Net creates data packets using the native network protocol, and it does not matter how the network is implemented to actually carry the SQL*Net packets. In fact, SQL*Net does not even know if a network exists, and it is possible to use SQL*Net without any network at all by making an internal connection between a client process and a server running on the same machine.

SQL*Net protocol adapters are available to support a variety of network protocols, including:

TCP/IP

Probably the most common universal protocol, TCP/IP originated on Unix systems but is now widely supported by a variety of operating systems and network hardware.

SPX/IPX

This protocol was developed by Novell for use in Netware and is available on a variety of operating systems.

LU6.2

This protocol was developed by IBM and is widely used in its SNA (System Network Architecture) strategy.

Named pipes

This protocol is used by Microsoft for Windows networking.

When Oracle is installed, both SQL*Net and one or more supported protocol adapters must be installed. Note that not all protocols are supported on every host operating system. For example, Oracle for Windows NT does not provide a protocol adapter for LU6.2, since this is not a protocol normally supported in a Windows environment.

5.1.1.3. Oracle services

SQL*Net connections to Oracle databases are made through services, which are actually processes running on the Oracle Server host machine. Each Oracle server maintains one or more listener processes, which are used to monitor the network for incoming connection requests. When such a request is received, the listener process is responsible for determining which Oracle instance the incoming request is seeking a connection with, and establishing an appropriate server process for that connection. The server process may be established as a dedicated process, or may use the Multi-Threaded Server, depending on how the Oracle instance is configured. For more information, see Chapter 10.

In order to identify the Oracle instance to connect with, the SQL*Net connection request specifies the name of a service (sometimes called a database alias ), which in turn corresponds to a particular Oracle instance on a specific host machine. The relationships between service names and specific instances and hosts are typically maintained in the file tnsnames.ora (discussed in more detail later in this chapter). For example, the service name "test" might actually refer to an Oracle database instance with an SID of TST23, which is accessible via TCP/IP at address 123.234.210.001 using port 1526. It is certainly simpler to refer to "test"!

5.1.2. Advanced Networking Option

In addition to the standard functionality provided by SQL*Net and Net8, Oracle now offers the Advanced Networking Option (ANO) as an extra-cost option. This option provides additional security-related functionality to Oracle connectivity. Among the capabilities of the Advanced Networking Option are:

• Network security

• Single sign-on

• DCE integration

5.1.2.1. Network security

Improved network security is provided through the following security features:

Encryption

The transformation of data so that it is unreadable by anyone without a (secret) decryption key. Encryption ensures the confidentiality of information by keeping its content hidden from anyone for whom it is not intended, even those who can see the encrypted data. The Advanced Networking Option also utilizes public key encryption. In this scheme, each person receives a pair of keys: a public key and a private key.

Each person's public key is published, while the private key is confidential. Messages encrypted with a public key can only be decrypted with the corresponding private key. Messages encrypted with a private key can only be decrypted with the corresponding public key. Keys may not be deduced from each other. The sender and receiver of an encrypted message do not share confidential information, since all communications involve only public keys. Private keys are neither transmitted nor shared.

Digital signature

A non-forgeable way of authenticating the sender of a message that supports non-repudiation of messages. Use of a digital signature ensures that only the purported sender of a message could actually have sent the message. The sender cannot later claim that someone impersonated her or him.

Digital certificate

A mechanism used to establish confidence in the identity associated with a public key by incorporating public keys. A digital certificate is a binding of a public key to a user by a trusted third party known as a Certificate Authority ( CA). The public key and user identity, together with other information such as the certificate expiration date, are digitally signed by the CA. CAs serve as electronic notaries, attesting to the identity of users and the validity of their public keys.

5.1.2.2. Single sign-on

The single sign-on feature allows users to access multiple accounts and applications with a single password. This feature eliminates the need for multiple passwords for users and simplifies management of user accounts and passwords for system administrators. Authentication adapters provide centralized, secure authentication services that confirm the identity of users, clients, and servers in distributed environments. Network authentication services also can provide the benefit of single sign-on for users. The following authentication adapters are supported:

• Kerberos

• CyberSAFE

• SecurID

• Biometric (Identix)

5.1.2.3. DCE integration

Distributed Computing Environment (DCE) integration enables users to transparently use Oracle tools and applications to access Oracle servers in a DCE environment. The Oracle DCE integration product consists of two major components:

• DCE communications/security adapter

• DCE CDS (cell directory service) naming adapter

The DCE communications/security adapter provides:

Authenticated remote procedure call (RPC)

RPC is the transport mechanism that enables multivendor interoperability for DCE integration. RPC also uses additional DCE services, including directory and security services, to provide location transparency and secure distributed computing.

Integrated security

DCE integration works with the DCE security service to provide security within DCE cells. It enables a user logged onto DCE to securely access any Oracle application without specifying a username or password. This function is referred to as external authentication to the database. In addition, clients and servers not running DCE authentication services can interoperate with systems that have DCE security by specifying an Oracle password.

Data privacy and integrity

DCE integration uses multiple levels of security to ensure data authenticity, privacy, and integrity. Users are provided with a range of choices, from no protection to full encryption for each connection, with a guarantee that no data has been modified in transit.

5.1.2.4. DCE naming adapter

The DCE CDS naming adapter offers a distributed, replicated repository service for the names, addresses, and attributes of objects across the network. Because servers register their name and address information in the DCE CDS naming adapter, Oracle clients can make location-independent connections to Oracle servers. An Oracle utility is provided to load the Oracle service names with corresponding connect descriptors into the DCE CDS naming adapter. After the names are loaded, Oracle connect descriptors can be viewed from a central location with standard DCE tools, and services can be relocated without any changes to the client configuration.