Oracle7 Server Migration Guide Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

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

System Requirements for Migration

This chapter discusses the system requirements that must be satisfied to ensure successful migration, upgrading, and downgrading operations. When migrating from an early version, such as Oracle Version 6, to a Release 7.x database, it is necessary to consider the configuration requirements for both the operating system and hardware.

The topics presented in this chapter are

General Memory Requirements

Oracle7 requires at least 16 megabytes of RAM for a minimal configuration. However, optimum use of Oracle7, in conjunction with the entire Oracle product suite of Developer/2000 tools, network utilities, and special applications, requires 32 megabytes or more. (Minimum recommended RAM for an Oracle Version 6, minimum configuration was 16 megabytes.) Your memory requirements will be based on the following factors:

Additional Information: See your operating system-specific Oracle documentation for more information on memory requirements specific to your operating system.

The Shared Global Area (SGA)

The total size of the SGA is dependent upon several factors that are controlled within the initialization file (also known as the INIT.ORA file on most platforms). In Oracle7 (Release 7.0 and higher), the system parameters having the most impact on the total size of the SGA are

Figure 6 - 1 below is a simplified block diagram of the Oracle7 SGA.

Additional Information: On UNIX platforms, the Oracle Corporation recommends that the entire SGA be placed in one, shared memory segment. See your operating system-specific Oracle documentation for more information.

Figure 6 - 1. Shared Global Area

The Shared Pool Area (SPA)

The Shared Pool Area (SPA) is an enhancement that was introduced in the Oracle7 releases; it is governed by the parameter SHARED_POOL_SIZE. The SGA of an Oracle7 database requires additional memory to accommodate the SPA. The default shared pool size is approximately 3.5 megabytes. It is not recommended that the shared pool size be reduced during an Oracle7 installation.

The Buffer Cache

The DB_BLOCK_BUFFERS parameter specifies the number of database buffers comprising the buffer cache of an Oracle7 instance. The size of each buffer is defined by the system parameter DB_BLOCK_SIZE. Thus, the size of the buffer cache of the SGA is

buffer cache size = (DB_BLOCK_BUFFERS * DB_BLOCK_SIZE)

For example, suppose that DB_BLOCK_SIZE is 4096 and DB_BLOCK_BUFFERS is set to 5000. Then,

buffer cache size = (4096 * 5000) = 20,480,000 bytes

The value for DB_BLOCK_SIZE is set at the time of database creation and remains at that value for the life of the database. You cannot change the value of DB_BLOCK_SIZE once the database has been created. Note that DB_BLOCK_SIZE, DB_BLOCK_BUFFERS, and the above calculations are the same as they were for Oracle Version 6. The recommended minimum DB_BLOCK_SIZE should be equal to, or greater than, 4096 bytes. See page 6 - 10 for more information on block size.

The Redo Log Buffer Cache

The LOG_BUFFER system parameter specifies the size (in bytes) of the redo log buffer. The size of the redo log buffer is typically small; the information in this buffer is not scanned for reuse as it is for data blocks. In addition, when the redo log buffer reaches two-thirds of its capacity, it is flushed to disk. The redo log buffer is also flushed to disk when a commit occurs to ensure that the changes are permanent. It is recommended that the size of the redo log buffer be set within a range of 8192 bytes to 262144 bytes.

The Program Global Area (PGA)

The process architecture for systems not configured for multi-threaded shared (MTS) servers is essentially the same as that for Version 6. Most operating systems start (or fork) a shadow process, which is a database server process for the application session, when an Oracle application is invoked. Figure 6 - 2 shows a SQL*Plus application process, its Oracle shadow process, and an approximation of its PGA. SQL*Plus can only have one cursor open at a time, so its memory utilization is simplified. The circles shown in Figure 6 - 2 represent processes; the squares represent memory allocation.

Figure 6 - 2. Process Global Area

Figure 6 - 2 shows the cursor for the SELECT SQL statement. Under Version 6, the cursor is synonymous with context area. In Oracle7, if the SELECT cursor computes a join, sort, or uses an aggregate function such as SUM(), AVG(), and so forth, the sort area is allocated based on a fraction of the value (in bytes) specified by the system parameter SORT_AREA_SIZE. The size of the sort area increases up to the value specified. All cursors for a given Oracle7 session use the same sort area to achieve more efficient use of memory than is possible in Oracle Version 6.

Figure 6 - 3 illustrates an Oracle7 session with multiple cursors.

Figure 6 - 3. Oracle7 Session with Multiple Cursors

The PGA size is affected by the sort area, the number of open cursors, and the value of SORT_AREA_SIZE. In Oracle7, the cursor state, SQL text string, and execution plan reside in the Shared Pool. The memory needed for cursors in the PGA is approximately 4 KB per cursor. The Sort Area Size is 64 KB, by default, on most operating systems. Figure 6 - 3 shows a SQL*Forms application with multiple cursors and one sort area.

Any given Oracle application session may have from one to several hundred cursors opened. However, only one sort area is used. Only one cursor can be executing within an Oracle7 session; it remains blocked until the execution/fetch is complete.

As illustrated in Figure 6 - 3, memory is consumed fairly quickly by having too many open cursors. For example, SQL*Forms, Version 3 applications that use SQL*Forms, Release 2.3 style triggers are likely to exceed OPEN_CURSORS. Also note that each Oracle Forms (previously referred to as SQL*Forms) block, based on database tables, will automatically open four cursors: INSERT, UPDATE, DELETE, and SELECT, provided the block attributes are defined. If you have 10 such SQL*Forms blocks, you will have 40 open cursors, in addition to any cursors that may be opened with SQL*Forms triggers.

One final item you should consider is the private memory allocated by the front-end application. When the application connects to an Oracle7 instance, whether it be SQL*Net, multi-threaded shared servers, or a local TWO-TASK connection, the connection will result in the application allocating additional memory for the Local Data Area (LDA). In addition, the application will allocate private data structures for accomplishing its tasks. Figure 6 - 2 and Figure 6 - 3 provide a schematic representation of the application private memory area.

Oracle7 Executables

The size of Oracle7 executables is 1.5 to 2 times larger than Version 6 Oracle executables. (This is due to new functionality added to Oracle7.) The size of the executables also depends on which options you choose to include in your Oracle7 environment, such as distributed transactions, Oracle Parallel Server, and various SQL*Net adapters. You should adjust your system memory to accommodate the inclusion of such options when migrating from Version 6 to Oracle7.

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 the new functionality of the Oracle7 releases.

Concurrent Access

The remaining issue for determining the memory size of an Oracle7 system is concurrent access and how that access is accomplished. In Oracle7, you have the following connect options:

Option 1 requires more memory than options 2 or 3. In option 1, if both the 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 Oracle7 result in 100 additional Oracle server processes on the system, totaling 200 in all.

For option 2, only the Oracle processes reside on the system since the clients are connected remotely. Thus, you need to pay attention to the size of the Oracle server processes and the size of the SGA.

Option 3, using the multi-threaded shared servers, is new in Oracle7. The multi-threaded shared servers feature allows the processes of several local and/or remote clients to connect to a single dispatcher process instead of having a dedicated Oracle shadow process. While not meant as a performance enhancement, multi-threaded shared servers allow more concurrent connections on an Oracle7 server, thereby improving throughput. Since multiple clients can connect to a single dispatcher, the memory utilization for concurrent user connections decreases. For further information on the multi-threaded shared server feature of Oracle7, refer to the September 1992 IOUW paper #243 entitled "Taking Advantage of the Multi-Threaded Server".

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. The requirements for using TP monitors will vary greatly and will not be discussed in this manual. Please consult the appropriate TP monitor vendor for system requirements.

In summary, you should be able to obtain a good estimate of your system memory requirements, for a single system, by considering the following factors:

Disk Capacity and Input/Output (I/O)

All Oracle7 releases perform most efficiently when datafiles are spread out over several disk devices. If you are planning to migrate an existing Oracle Version 6 database to an Oracle7, Release 7.x database, the database can be migrated in place without requiring additional disk space for the database files. However, for any expansion plans you may have, it may be necessary to examine the current disk resources to determine if additional disks will be required to meet future administration and performance requirements.

For sites implementing a very large database (VLDB), approximately 50 gigabytes or larger, see the Oracle publication The OFA Standard, Oracle7 for Open Systems, Part Number A19308-1, which provides device and file naming conventions for better administration.

In addition, to distribute I/O requests across disks, consider adding disk controllers when adding disk drives to your hardware configuration. Placing all of your disk drives onto one or two controllers can lead to I/O bottlenecks.

If your migration plan requires continuous operation, even during media failures, you must configure your hardware and operating system to support volume/disk mirroring. A minimum configuration, for an operating system that supports mirroring, should mirror the redo log files, the rollback segment tablespace datafiles, and all data tablespace datafiles. Such a configuration, of course, requires additional disk drives and controllers; however, it also provides further flexibility in system availability and administration.

Keep in mind that mirroring volumes can encompass several disk devices per volume. Ensure that you have sufficient disk drives to support the entire volume, if you wish to mirror Oracle datafiles. Consult your hardware vendor for further information.

Sites that cannot afford to be down due to media failure or time-consuming backups should use triple mirrors.

Do not use all disk drives (or file systems) on the system for Oracle database files. Some drives should be reserved for user files, for placing small export files, or for maintenance operations that require a significant amount of space.

Use of the Oracle Parallel Server requires that each node have its own copy of Oracle7 software. Thus, many platforms, such as IBM RS6000, NCR 3XXX series, Pyramid MIS Server, Sequent Symmetry, Sun SPARKCenter, and others, may require additional private disks.

Block Size

The Oracle7 releases require a minimum block size of 1024 bytes. The use of long VARCHAR2 datatypes requires specification of special block sizes.

Minimum block size 1 KB
Minimum block size recommended 2 KB
Default block size for a new database 4 KB

CPU Resources

The Oracle7 releases are well suited for symmetric multi-processors (SMP) and massively parallel processors (MPP) systems. SMP systems are tightly coupled; the memory is shared among a pool of CPUs. MPP systems are loosely coupled; only message buffers and disk drives (or disk controlling processes) are shared. An MPP system is composed of separate and independent nodes.

Each Oracle7, Release 7.x server process (or shared server for MTS configuration) performs the requested task without going through a centralized database server. Thus, all Oracle7 releases rely on the operating system to handle process scheduling. Various, unrelated database tasks can be performed on different CPUs (for SMP systems) or on separate nodes on MPP systems.

Thus, for applications with high Online Transaction Processing (OLTP), a single CPU system can become CPU bound because the CPU resource becomes exhausted. SMP and MPP systems can distribute the workload across CPUs. The CPU utilization should be monitored to determine if additional CPU bandwidth is required.

Oracle Parallel Server

The Oracle7 Parallel Server technology allows multiple, homogeneous systems to share the same database. This is accomplished by hardware and software technology that allows disk volumes to be shared. You must configure the Distributed Lock Manager (DLM) provided by your hardware vendor if you intend to use the Oracle7 Parallel Server. The DLM configuration is dependent on the configuration of the Oracle7 Parallel Server database.

Oracle RDBMS releases earlier than Release 6.0.35 (or 6.2) did not contain the generic Oracle Parallel Server (OPS) feature. The Oracle7 releases can be configured with the OPS option. Install the OPS option only if your hardware and operating system support an Oracle-certified Distributed Lock Manager.

Distributed Transactions and Network Considerations

While Oracle, Version 6 supported distributed queries, the Oracle7 releases support distributed queries and DLM transactions protected by two-phase commits. If your applications require distributed transactions, it may be necessary to examine the network costs for performance for such applications. While distributed transactions is an important feature and provides further flexibility for the application, it also adds to the existing network traffic and may degrade performance. If the application heavily utilizes distributed transactions, it might be a good idea to install an additional network interface card or use a different, infrequently used subnet.

In addition, distributed queries that cause large tables to be brought over to the local server through SQL*Net may also cause performance degradations on the network. The application performing such queries should first be examined to see if other possible solutions can be found.

If the users of your applications connect to the database server from PC clients or other types of workstations using SQL*Net, the application should be tested to determine how much traffic it will introduce to the existing network. The amount of traffic can indicate if network bottlenecks will occur. If input/output (I/O) bottlenecks occur, either modify the application to reduce network traffic, use an existing, infrequently used subnet, or install additional network interface cards to distribute the network load.

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