Understanding SQL*Net

Contents Glossary Index Home Previous Next

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.


Contents Glossary Index Home Previous Next