Oracle8 Migration Release 8.0 A58243-01 |
Library | Product | Contents | Index

# E
General System Requirements for Migration

This appendix covers the system requirements for successfully migrating, upgrading, and downgrading an Oracle RDBMS. Migrating a database from version 7 (or version 6, by using Export/Import) to version 8 requires some specific configurations of your operating system and hardware.

The following topics are covered in this appendix:

- Memory Requirements
- Using Oracle Parallel Server
- Version 8 New Sizes and Limits

## Memory Requirements

Version 8 memory requirements include basic memory requirements, memory needed for executables, and amount of concurrent access.

### Basic Memory Requirements

Version 8 requires at least 48 megabytes of RAM to run a database; this is a minimum configuration without much operating system memory swapping to disk. To support connections to multiple users, the system should have additional memory. Concurrent use of the Enterprise Manager requires an additional 20MB.

See Also: Your platform-specific Oracle documentation for more information about memory requirements on your platform.

### Version 8 Executables

The version 8 executables are three times larger than version 7 executables, primarily because of new version 8 features. If you have a typical 3-megabyte set of version 7 executables, the space required for these executables upon migration to version 8 is approximately 9 megabytes. This threefold increase can require special attention on large batch systems (which may generate dozens or hundreds of executables). The space required for executables also depends on the options you choose for the version 8 environment, such as:

- Oracle Parallel Server (see Oracle8 Parallel Server Concepts and Administration)
- Net8 or SQL*Net use (see Oracle Net8 Administrator's Guide)

Make sure you adjust system memory to accommodate the inclusion of options when you are migrating from version 7 to version 8.

Note: The use of shared objects on many platforms provides some reduction in the size of client applications. However, the size of some shared objects (or libraries) can be quite large due to new functionality in version 8.

### Concurrent Access

The memory size of a version 8 system depends on concurrent access and the way in which concurrent access is accomplished. Version 8 supports the following connect options:

Option 1: | Use local connections in dedicated server architecture (also called "two-task Oracle"). This option is the same as version 7.
Option 2: | Use remote connections through SQL*Net. This option is the same as version 7.
Option 3: | Use multithreaded shared servers for local and remote connections.
Option 4: | Use transaction processor (TP) monitors.

Option 1 requires more memory than Option 2 or Option 3. With Option 1, if both client application and its Oracle server (or shadow) process reside on the same machine, memory is required for both. For example, 100 client application processes connected to version 8 results in 100 additional Oracle server processes on the system, totaling 200 in all.

With Option 2, only the Oracle processes reside on the system, and the client processes are connected remotely. Thus, you need to consider only to the size of the Oracle server processes and the size of the available shared memory.

Option 3, using multithreaded server architecture, is the same as version 7. The multithreaded server feature allows the processes of several local or remote client processes to connect to a single dispatcher process, instead of having a dedicated Oracle shadow process. While not designed as a performance enhancement, multithreaded server configuration allows more concurrent connections on a version 8 server, thereby improving throughput. Multiple clients can connect to a single dispatcher, so the memory utilization for concurrent user connections decreases. For further information on the multithreaded server feature of version 8, refer to Oracle8 Concepts.

Option 4, use of TP monitors, is an alternative for systems requiring a high number of users (greater than several hundred) all performing OLQP/OLTP type transactions. Such transactions are usually short-lived and do not require the user to make a direct connection to the database. All transactions are performed with messages routed by the TP (transaction processor) monitor service. The TP layer provides named services and coordinates service requests with various DBMS systems, including Oracle.

Note: The requirements for using TP monitors vary greatly and are beyond the scope of this manual. Please consult the appropriate TP monitor vendor for system requirements.

In summary, you can estimate system memory requirements, for a single system, by considering the following factors:

- the average number of open cursors and cursors that may cause sorts for a given Oracle application session
- the average size of the Oracle shadow processes that will include open cursors and sort areas
- the peak number of concurrent users on the system
- the average memory size of the Oracle front-end application

## Using Oracle Parallel Server

Migration of Oracle Parallel Server (including DLM) requires that each node have its own copy of version 7 and version 8 software. Many platforms, including IBM RS6000, NCR 3XXX series, Pyramid MIS Server, Sequent Symmetry, and
Sun SPARCcenter may require additional private disks.

## Version 8 New Sizes and Limits

Version 8 increases various capacity limits, as shown in the following lists:

Datatypes:

- CHAR increased to 2000 bytes.
- VARCHAR/VARCHAR2 increased to 4000 bytes.
- NCHAR holds up to 2000 bytes.
- NCHAR VARYING holds up to 4000 bytes.

Columns and indexes:

- Database size is limited only by capacity of the platform.
- Maximum number of datafiles per tablespace is 1022.
- Maximum number of columns in a table increased to 1000.
- Primary key is limited to 16 fields.

## CHAR and NCHAR Maximum Size Support

Version 8 supports increased maximum string lengths for several datatypes:

- CHAR maximum length of 2000 bytes (also for RAW datatype)

  (Oracle 7.3 supports CHAR and RAW length maxima of 255 bytes)

- VARCHAR2 maximum length of 4000 bytes

  (Oracle 7.3 supports a VARCHAR2 length maximum of 2000 bytes)

The version 8 datatype string length maxima accord with the NTT/MIA specification, which requires the following string lengths:

- CHAR maximum length of at least 255 bytes
- NCHAR maximum length of 127 characters
- NCHAR VARYING (NVARCHAR) max length of 2000 characters
- VARCHAR2 maximum length of 4000 bytes

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