Oracle Net8 Administrator's Guide Release 8.0 A58230-01 |
Library | Product | Contents | Index

# 9
Migrating to Net8

This chapter outlines migration paths and considerations for upgrading previous releases of SQL*Net version 2 to Net8. It includes the following section:

- Section 9.1, "Migrating from SQL*Net version 2"
- Section 9.2, "Why Migrate to Net8?"
- Section 9.3, "Considerations for Migrating to Oracle Names version 8"
- Section 9.4, "Using Oracle Connection Manager instead of Oracle MultiProtocol Interchange"
- Section 9.5, "Migration Scenarios"

## 9.1 Migrating from SQL*Net version 2

Net8 is backwards compatible with SQL*Net version 2 (release 2.0.14 and later). This means that Net8 clients can transparently connect to an Oracle7 database. It also means that existing SQL*Net version 2 clients can connect to an Oracle8 database.

Oracle Corporation no longer supports SQL*Net version 1.

## 9.2 Why Migrate to Net8?

Though it is not required, upgrading your network to Net8 is recommended for the following reasons:

- Minimal configuration. Net8 simplifies the process of setting up your network components. With Net8, you can start a client, network listener, Names Server, and Oracle Connection Manager with default settings. This minimizes the need to create and maintain configuration files. With Net8, the Oracle Net8 Assistant replaces most of the functionality previously provided with Oracle Network Manager. Use the Oracle Net8 Assistant to create or modify your existing local naming files, profile and Oracle Names configuration file.
- Extended network functionality. Net8 has replaced many of the features previously available with SQL*Net version 2 with equivalent or enhanced functionality.

  Table 9-1 lists the networking features supported in each Oracle release.

  ##### Table 9-1 Network Products Compatibility

  Oracle Release | 7.1.4 | 7.1.5 | 7.1.6 | 7.2.2 | 7.2.3 | 7.3.2 | 7.3.3 | 8.0.3
  --- | --- | --- | --- | --- | --- | --- | --- | ---
  Net8 |  |  |  |  |  |  |  | 8.0.3
  Oracle Connection Manager |  |  |  |  |  |  |  | 8.0
  Oracle Advanced Networking Option |  |  |  |  |  | 2.3.2 | 2.3.3 | 8.0
  SQL*Net | 2.1.4 | 2.1.5 | 2.1.6 | 2.2.2 | 2.2.3 | 2.3.2 | 2.3.3 |
  Oracle Multiprotocol Interchange |  |  |  |  | 2.0 | 2.0.2 | 2.0.3 |
  Secure Network Services | 1.0.1 | 1.0.2 | 1.0.3 | 1.1 | 2.0 |  |  |
  Oracle Names | 1.0 | 1.0 | 1.0 | 1.1 | 1.1 | 2.0.2 | 2.0.3 | 8.0

## 9.3 Considerations for Migrating to Oracle Names version 8

Oracle Names version 8 is backward compatible with SQL*Net version 2. This implies that clients running on SQL*Net version 2 can access Names Servers using Oracle Names version 8 to connect to an Oracle8 server.

If you wish to take advantage of the new features provided with Oracle Names version 8, you must upgrade all of your existing Names Servers in a region to version 8 by installing Oracle Names version 8 on every existing Names Server node.

### 9.3.1 Migrating from Oracle Names version 2 using a Database

To upgrade and transfer data from an existing Names Server database to a version 8 database, run the namesupg.sql script on the node where Oracle Network Manager stored your network definition.

### 9.3.2 Migrating from Oracle Names version 2 using the Dynamic Discovery Option

If you were previously running Oracle Names version 2 using the Dynamic Discovery Option, and you want to configure a database as a repository for your Oracle Names information, you will need to:

1. Run the namesini.sql script on the Names Server node where you want the database to reside.
2. Use the Oracle Net8 Assistant to configure a NAMES.ADMIN_REGION parameter in every Names Server configuration file (NAMES.ORA).
3. Reload Names Server information into at least one Names Server by issuing a NAMESCTL REORDER_NS command on every listener node.

If you were previously running Oracle Names version 2 using the Dynamic Discovery Option, and you do not want to configure a database, you must issue a REORDER_NS command on every node.

### 9.3.3 Checklist for Ensuring Proper Migration to Oracle Names version 8

The following checklist is provided to ensure proper migration to Oracle Names version 8.

##### Table 9-2 Checklist for Ensuring Proper Migration to Oracle Names version 8

Task | Description
--- | ---
Upgrade all Names Servers in each region to the same version. |
Set up at least two Names Servers in each region to provide for fault tolerance. |
Change or delete the following parameters in any existing profile. | NAMES.PREFERRED_SERVERS. If you have already generated a Names Server Lists file or if one already exists, and you wish to continue using Names Servers discovered by it, you should delete or comment out the NAMES.PREFERRED_SERVERS parameter. Any Names Servers specified in the NAMES.PREFERRED_SERVERS parameter will override the results of the discovery process. NAMES.DIRECTORY_PATH. If you have upgraded your network to Net8 and wish to use Oracle Names version 8, edit the NAMES.DIRECTORY_PATH parameter to specify that Oracle Names is the first naming method attempted. NAMES.DEFAULT_DOMAIN. If you upgrade all or part of your network to Net8 and Oracle Names, you will need to decide whether to continue to use the .WORLD domain set by default. If you choose to use it, add the NAMES.DEFAULT_DOMAIN parameter to all new Net8 clients which will contact existing services. To maintain consistent naming conventions, be sure that the .WORLD domain is part of the names of the services that register themselves.

### 9.3.4 Other Obsolete Parameters

If you are upgrading your entire environment to Net8, you will not need the following configuration parameters:

- COMMUNITY
- NAMES.DEFAULT_ZONE
- NAME.PREFERRED_SERVERS

You may choose to delete these parameters or leave them. Though they are no longer required, they will not interfere with any network operations.

The COMMUNITY parameter used to a required part of all network service addresses. Thus, it appears anywhere you might find an address (for example, local naming and listener configuration files).

The NAMES.DEFAULT_ZONE and NAME.PREFERRED_SERVERS used to be included in profiles as slight variants of the NAMES.DEFAULT_DOMAIN and NAMES.PREFERRED_SERVERS parameters.

## 9.4 Using Oracle Connection Manager instead of Oracle MultiProtocol Interchange

If you have migrated your clients to Net8, and you still require multiprotocol support, you will need to install Oracle Connection Manager, and route your sessions through it. Oracle Multiprotocol Interchange is no longer supported past SQL*Net release 2.3.

To ensure proper functioning of Oracle Connection Manager, verify that you have deleted the following files on those nodes:

- TNSNET.ORA
- TNSNAV.ORA
- INTCHG.ORA

Other migration considerations are specific to your network configuration.

## 9.5 Migration Scenarios

The following migration scenarios are provided to help you understand the migration issues when:

- Migrating an existing Oracle7 Database to Oracle8
- Installing a new Oracle8 database in an existing Oracle7 network
- Migrating SQL*Net v2 clients to Net8
- Migrating to Oracle8 with Oracle Names

### 9.5.1 Migrating an existing Oracle7 Database to Oracle8

If you plan to upgrade an existing Oracle7 database to Oracle8, but do not wish to upgrade your SQL*Net v2 clients, proceed as follows:

1. Run a migration utility to install the Oracle8 tables on your server node.
2. Start the database.
3. Continue to use Oracle Network Manager to configure naming methods.

### 9.5.2 Installing a new Oracle8 database in an existing Oracle7 network

If you plan to install a new Oracle8 database in your existing Oracle7 network, and do not wish to upgrade your SQL*Net v2 clients, proceed as follows:

1. Install the Oracle8 database.
2. Start a network listener.
3. Start the Oracle8 database.
4. Continue to use Oracle Network Manager to configure naming methods.

### 9.5.3 Migrating SQL*Net v2 clients to Net8

If you plan to upgrade existing SQL*Net v2 clients to Net8 to connect to both Oracle7 and Oracle8 servers, proceed as follows:

1. Install Net8 on each client node.
2. Use the Oracle Net8 Assistant to modify any existing client profiles.
3. If you are using local naming, use the Oracle Net8 Assistant to modify your existing local naming configuration files to include new service addresses.

   Note:: If you are using the Oracle Net8 Assistant to configure default domains, keep in mind that "null" is the new default value. Oracle Network Manager appended a ".world" extension to every address by default.

### 9.5.4 Migrating to Oracle8 with Oracle Names

If you plan to upgrade both an existing Oracle7 database to Oracle8, and Oracle Names version 2 to version 8, proceed as follows:

1. Install Oracle8.
2. Install Oracle Names version 8 on each node with an existing Names Server.
3. If you were previously running Oracle Names version 2, and you want to update your database as a repository for your Oracle Names information, you will need to run the namesupg.sql script on the node where your network definition is stored.
4. If you were previously running Oracle Names version 2 using the Dynamic Discovery Option, and you want to configure a database as a repository for your Oracle Names information, you will need to:
   1. Run the namesini.sql script on the node where you wish to install the database.
   2. Use the Oracle Net8 Assistant to configure a NAMES.ADMIN_REGION parameter in every Names Server configuration file. For more information about the NAMES.ADMIN_REGION parameter, refer to Appendix B, "Configuration Parameters".
5. Verify that a well-known Names Server exists in your local region. If a well-known Names Server does not exist in your local region, you may need to configure the address of a preferred names server in your client profile.
6. Execute a REORDER_NS command from the Oracle Names Control Utility (NAMESCTL) on every node.
7. Delete or comment out any remaining parameters specifying a Preferred Names Server in all client profiles. This will ensure that each client will use the results of the discovery process to find a Names Server.

Prev | Next
| Copyright © 1997 Oracle Corporation. All Rights Reserved. |
Library | Product | Contents | Index