Understanding SQL*Net Go to Product Documentation Library
Library		 Go to books for this product
Product		 Go to Contents for this book
Contents		 Go to Index
Index


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

Migrating from an Earlier Version of SQL*Net

This chapter describes issues the network administrator must resolve when migrating from an earlier version or release of the SQL*Net product. The chapter discusses three issues:

Coexistence of SQL*Net Version 1 and Version 2.x

Note: SQL*Net version 1 cannot communicate with SQL*Net version 2, but it can coexist with it. Different releases of SQL*Net version 2 can communicate with each other. Therefore, the migration issues from version 1 to version 2, 2.1 or 2.2 are somewhat different from those from 2.0 to 2.1 or 2.2. In this section SQL*Net version 1 is contrasted with SQL*Net version 2.0, 2.1, or 2.2. In fact ,version 2 and later releases are similar in regard to migration issues from version 1.

If you already have a SQL*Net version 1 network, you must decide which of your nodes you will upgrade immediately to version 2.x, and which will continue to use only version 1.

Ideally, all platforms would run SQL*Net version 2.x supporting all protocols, and this section of the manual would not exist. In reality, there will be a period of time during which some platforms will have SQL*Net version 2.x available, and others will have SQL*Net version 1. During the transition, you may want to have some platforms with both SQL*Net version1 and SQL*Net version 2.x installed, so that they can communicate with all other platforms.

Note: SQL*Net version 1 nodes can communicate only with other SQL*Net version 1 nodes; however, version 2 and release 2.1 and 2.2 nodes can communicate with each other.

Version 1 Coexistence

In any SQL*Net installation, for each node there are three options directly related to the type of clients or servers with which each node communicates:

This model allows version 1 service to continue in your existing network until such time as all nodes are running version 2.x.

Distinguishing Version 1 and Version 2.x Connections

The version of SQL*Net that is used for a given connection is determined by the format of the connect string. Where a version 1 connect string is sent, the version 1 software and version 1 listener (on the server) are used. Where a TNS connect descriptor is sent, the version 2.x software and listener (on the server) are used.

Most of the time people use aliases for connect strings (in SQL*Net version 1) or service names for connect descriptors (in SQL*Net version 2.x). The way these aliases and service names are handled is operating system specific. On UNIX and VMS systems, if version 2.x is installed, the version 1 configuration files for mapping aliases to connect strings are not read. Therefore, to continue to use version 1 aliases, you must import them into the version 2.x network definition and generate the TNSNAMES.ORA configuration file. Network Manager makes this easy to do. See Chapter 5 in the Oracle Network Manager Administrator's Guide for further information. In general, personal computers will continue to read the version 1 configuration files to connect to the database indicated by the version 1 alias. See the Oracle operating system-specific documentation for your platform for details.

Note: If you are using Oracle Names, the TNSNAMES.ORA file is not necessary. Instead, the Names Servers read the destination addresses from the network definition database created by the Network Manager.

Types of SQL*Net Installations

With respect to compatibility with SQL*Net version 1, there are four significant types of SQL*Net version 2 networks:

Each of these is discussed in the following sections.

Single Community with Version 2.x Nodes

The simplest possible type of SQL*Net version 2.x installation is a single TNS community where all clients and servers use SQL*Net version 2.x for communication. Figure 4 - 1 shows a TNS community based on Novell's SPX/IPX where all of the clients and servers are using SQL*Net version 2.x for SPX/IPX.

Figure 4 - 1. Community with Only V2.x Nodes

In this example, because SQL*Net version 2.x is installed on both the clients and servers, any client can talk to any server in the community. For all connections, the version 2 syntax on the client and the listener on the server is used.

If SQL*Net version 2.x is available for all of the platforms in your client-server network, and all nodes run the same protocol, this is the layout you would choose.

Single Community with Version 1 and Version 2.x Nodes

During the initial release of SQL*Net version 2.x, there will be platforms on which SQL*Net version 2.x is available, and platforms on which SQL*Net version 1 is still the latest release. This is simply because the porting process on some platforms takes longer than on others.

As a result you may have a network in which both SQL*Net version 1 and SQL*Net version 2.x coexist. Figure 4 - 2 shows a network of TCP/IP hosts, some of which have SQL*Net version 2.x available, and some of which still run only SQL*Net version 1.

Figure 4 - 2. Single Community with V1 and V2.x Nodes

Each of the nodes in this community may require connectivity with any of the other nodes. Therefore, the nodes running SQL*Net version 2.x also have SQL*Net version 1 installed so that they can communicate with the SQL*Net version 1 nodes.

On nodes that can run only one SQL*Net driver at a time, such as MS-DOS, the lowest common denominator theory applies. If that node connects only to version 2.x servers, it should use SQL*Net version 2.x. If there are still SQL*Net version 1 servers it must communicate with, it should use SQL*Net version 1. However, it will be unable to connect to servers that have only version 2.x running.

Multiple Communities with Version 2.x Nodes

The third noteworthy type of network is a multi-community network running only SQL*Net version 2.x. This is a TNS network of at least two communities in which all of the members use SQL*Net version 2.x. Figure 4 - 3 shows a sample network of clients and servers based on the SPX/IPX and TCP/IP protocols.

Figure 4 - 3. Multiple Communities with V2.x Nodes

In the network shown, any of the clients can communicate with any of the servers:

For more information on the MultiProtocol Interchange, see the Oracle MultiProtocol Interchange Administrator's Guide.

Multiple Communities with Version 1 and Version 2.x Nodes

The last type of network to consider is a network with multiple communities in which not all of the nodes have SQL*Net version 2.x.

Figure 4 - 4 shows a sample network in which a TCP/IP community and an SPX/IPX community are joined by an Interchange.

Figure 4 - 4. Multiple Communities with V1 and V2.x Nodes

In the sample network shown, all of the nodes in the SPX/IPX community use SQL*Net version 2.x, but some of the nodes in the TCP/IP community only have SQL*Net version 1 available. All version 2.x servers have version 1 installed as well. In the picture shown, the nodes can communicate as follows:

Note: Using the Interchange for cross-protocol connectivity requires SQL*Net version 2.x on both the client and the server. For example, if there were a server in the TCP/IP community that ran only SQL*Net version 1, the SPX/IPX clients could not access it through the Interchange. Similarly, if there were a server running SQL*Net version 2.x in the SPX/IPX community, the SQL*Net version 1 clients in the TCP/IP community could not access it.

The ability of SQL*Net version 2.x to connect clients and servers in different networks using the MultiProtocol Interchange is a feature unavailable on SQL*Net version 1. However, even in a single-protocol network, where both SQL*Net version 1 and version 2.x are available, there are many good reasons to move toward SQL*Net version 2.x. These reasons include:

Upgrading from Version 1 to Version 2.x

The act of upgrading from SQL*Net version 1 to version 2.x requires few actual changes. You mustdo the following:

Locating Connect Strings

Before you can update SQL*Net version 1 connect strings into SQL*Net version 2.x connect descriptors you must first understand the scope of the potential change. Depending on your SQL*Net version 1 installation, there may be connect strings in both the client application and server, and particularly on the client, they can be in any number of places.

Application Connect Strings

For example, at the application, connect strings can be found in: 

	   runform think scott/tiger@connect_string

Server Connect Strings

On the server, connect strings are usually found only in the data dictionary tables USER_DBLINKS or DBA_DBLINKS, where they are inserted by a CREATE DATABASE LINK statement.

Changing Connect Strings

This section lists the procedure for migrating your SQL*Net version 1 connect strings to SQL*Net version 2.x connect descriptors:

Note: Service names and global database names are often the same; for example, HR.US.ACME.COM.

Note: If the network includes Oracle Names, the service names and connect descriptors are stored in a database and resolved by Oracle Names, so TNSNAMES.ORA is not necessary. Similarly, if Oracle service names are stored in a native naming service such as NIS or DCE's CDS, then TNSNAMES.ORA files are not necessary.

Note: If the network includes Oracle Names, global database links are available, and can be edited using the Network Manager. See Chapter 5 in the Oracle Network Manager Administrator`s Guide for details.

Sample Upgrade for Two Nodes

This section provides a simple example of the eight-step procedure described in the previous section, "Changing Connect Strings". If you think in terms of pairings, upgrading any number of nodes from SQL*Net version 1 to version 2.x should not be difficult.

This example uses three nodes, one client and two servers, as shown in Figure 4 - 5. It shows how the client changes to access either server over version 2.x, and how the DETROIT server changes to access the CLEVELAND server.

Figure 4 - 5. Sample Nodes for V2 Upgrade

	T:CLEVELAND:JOINTS 

	T:DETROIT:PARTS 

	CREATE DATABASE LINK CAR
	CONNECT TO MOTOR IDENTIFIED BY CITY
	USING 'T:DETROIT:PARTS' 

	CLEVELAND.SALES.ACME = 
		(DESCRIPTION=
			(ADDRESS=
			(	COMMUNITY=TCP.SALES.ACME)
				(PROTOCOL=TCP)
				(HOST=CLEVELAND.SALES.ACME)
			(	PORT=1521)) 
			(CONNECT_DATA=
				(SID=JOINTS))) 

	DETROIT.SALES.ACME =
		(DESCRIPTION=
			(ADDRESS=
				(COMMUNITY=TCP.SALES.ACME)
				(PROTOCOL=TCP)
				(HOST=DETROIT.SALES.ACME)
				(PORT=1521))
			(CONNECT_DATA=
				(SID=PARTS)))
 

	runform max/python@DETROIT.SALES.ACME 
	runform max/python@CLEVELAND.SALES.ACME 

	CREATE DATABASE LINK DETROIT
	CONNECT TO MOTOR IDENTIFIED BY CITY
	USING 'DETROIT'

	CREATE PUBLIC DATABASE LINK CAR
	CONNECT TO MOTOR IDENTIFIED BY CITY

Coexistence of Version 1 and Version 2

If you have a large number of SQL*Net version 1 connect strings to update, you can install SQL*Net version 2.x beside SQL*Net version 1 in both the clients and servers as a temporary method of allowing version 2.x functionality to coexist with version 1 connect strings. All existing connect strings will continue to function within their version 1 limitations. This may make the migration more manageable.

Note: It is not possible to have both SQL*Net version 1 and SQL*Net version 2 running simultaneously on an MS-DOS machine.

Relinking 3GL Applications

All user-written 3GL programs that perform connections to a remote database must be relinked with the SQL*Net version 2.x libraries appropriate for your platform. For details refer to your Oracle platform specific installation guide for SQL*Net version 2.x.

Moving from SQL*Net Release 2.0 to a Later Release

SQL*Net release 2.3 is designed to be backward compatible with previous SQL*Net 2.x releases. The network may include nodes running SQL*Net release 2.0, 2.1 or 2.2. If you have a SQL*Net release 2.0 network up and running at your site, the configuration files you have distributed will continue to be valid after release 2.3 is installed. However, you will not be able to take advantage of some of the new features of release 2.3 without recreating the files using Oracle Network Manager release 3.1, which is included with SQL*Net release 2.3. Specifically, you must create new files to use listener load balancing, and to use Network Manager in conjunction with Oracle Names release 2.0 and the Dynamic Discovery option.

For information on configuring Oracle Native Naming Adapters see your operating system-specific documentation. See the Oracle Advanced Networking Option Administrator's Guide for information on configuring Oracle Advanced Networking Option. See Chapter 6, "Configuring Oracle SNMP Support" in this guide for information on configuring the SNMP Support feature and the Oracle SNMP Support Reference Guide. For information on Oracle DCE Integration, see the Oracle Advanced Networking Option Administrator's Guide.

Network Manager releases 2.1 and 2.2 include a utility, NETCONV, to make the migration from version 2.0 to release 2.1 or later easy. See Appendix C in the Oracle Network Manager Administrator's Guide for further information. If you are upgrading your network from release 2.1 or 2.2 to 2.3, you will not need to use NETCONV--Network Manager will convert the network definition automatically for you.

Attention: When you use Oracle Network Manager, the default is to encrypt the passwords in LISTENER.ORA. If your network includes some nodes that are running SQL*Net release 2.0, be careful that the passwords for those listeners are not encrypted. Encrypted passwords are not recognized by SQL*Net release 2.0.

Note: For information about using Oracle Names release 2.0 with the Dynamic Discovery Option in a network that includes various versions of SQL*Net, see Chapter 5 in the Oracle Names Administrator's Guide.


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