Oracle7 Server Migration Guide 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

Summary of Changes in Oracle7, Release 7.0

This appendix provides an overview of the changes in the Oracle7 Server. It covers the following topics:

Terminology

Some new terms have been introduced with Oracle7 that describe Version 6 features. The concepts behind these terms are not new; the new terms are used to better explain the concepts. The following list summarizes the new terms:

initialization parameters and parameter files

Parameters placed in the parameter file are used to specify configuration settings when starting an instance. In Version 6 documentation, initialization parameters were commonly referred to as INIT.ORA parameters.

In Version 6 documentation, the file containing initialization parameters was referred to as the INIT.ORA file. In Oracle7 documentation, it is known as the parameter file.

schema

A schema is a logical space in which a user can create objects. In Version 6, there was no distinction between a user and a collection of objects that the user owns. In Oracle7, that distinction is introduced with the term schema.

Every user has one schema in which objects can be created. The name of that schema is the same as the user's Oracle username. Objects are uniquely identified by the schema to which the object belongs and the object name. For example, the table EMP created in SCOTT's schema is identified as SCOTT.EMP.

schema objects

In Version 6, it was only necessary to talk about tables, views, and users. In Oracle7, there are tables, views, snapshots, roles, profiles, users, procedures, packages, triggers, and integrity constraints, among other entities. These are known collectively as database objects.

server process

A process that handles requests (program interface calls) from user processes. A server process can be either dedicated to one user process, or shared among many user processes, depending on the configuration of your database system. In Version 6, these processes were known as "shadow processes".

session

A logical connection by a user to the database. One user can have several sessions. The Version 6 term "user process" has been replaced by "user session" in Oracle7.

shared SQL areas

In Version 6, the parsed form of SQL statements were stored in user context areas. In Oracle7, they are stored in shared SQL areas. See page A - 17 for more information.

Functionality Enhancements

This section contains the following topics:

Enforced Integrity Constraints

Data verification can now occur within Oracle, as well as at the application level. By checking data at the application level, you can ensure that the users of a particular application receive immediate useful and appropriate help and error messages when they access a table. Checking at the database level ensures that no incorrect data can be entered in the table, regardless of which application or tool is used. Data checking at the database level is accomplished by using integrity constraints.

Integrity constraints can be defined to specify logical relationships of data in a database. Version 6 introduced syntactic support for data integrity constraints. Oracle7 supports the enforcement of integrity constraints to ensure that a database contains consistent data. If a Data Manipulation Language statement violates an integrity constraint, the statement is rolled back and an error is returned.

Enabling Constraints

Integrity constraints can be enabled or disabled. When constraints are enabled on existing data, an exception table can be generated to list all rows that violate constraints along with the constraints they violate.

Unique Constraints

In Version 6, the fact that table indexes were unique was frequently used to enforce uniqueness constraints. This is no longer necessary in Oracle7 since the UNIQUE constraint can now be used to guarantee uniqueness.

Delete Cascade

When deleting a master row that is referenced by foreign keys in other tables, you can choose to cascade the delete, dropping all foreign key rows, as well as the master row.

Standards Compliance

The integrity constraints implemented in the Oracle7 Server fully comply with the SQL89 Level 2 standard set forth by ANSI X3.135-1989 and ISO 9075-1989.

Along with Oracle7, the Release 1.5 precompiler is 100% compliant with the ANSI SQL89 standard, including integrity features.

In addition, the Release 1.5 precompiler passes 100% of the tests contained in the National Institute of Standards and Technology (NIST) SQL89 test suite. It also contains the FIPS Flagger (required by the Federal Information Processing Standard) to call attention to any non-ANSI-standard extensions that are used.

Enforced Default Values

You can now specify a default value to be used for a column by supplying an expression for the DEFAULT clause of the ALTER or CREATE TABLE statement. If you issue an INSERT statement without providing a column value, this default value will be used. Version 6 introduced syntactic support for default values, whereas Oracle7 supports the use of default values.

Extended National Language Support

National Language Support (NLS) in Oracle7 supports the use of multi-byte character sets used in many Asian languages. It also provides greater flexibility in specifying language or territory, either for a session or for the entire database.

New NLS initialization parameters allow the specification of default date format, currency symbol, number-group separator, and decimal character. These format characteristics can also be specified explicitly in SQL functions to override the default values.

The values of all NLS parameters are defined with systemwide defaults, and can be overridden on a per-session basis. Different sessions connected to the same instance can use different values for NLS parameters. These values can be changed during a session.

For more information on NLS features supported by the Oracle7 Server, see Oracle7 Server Concepts and Oracle7 Server Reference.

PL/SQL

The PL/SQL programming language now permits a stored procedure or function to be defined and compiled once, stored in the database, and then executed by multiple users and applications. Stored procedures and functions consist of a set of SQL and PL/SQL statements that are stored in a compiled form in the database. In addition, PL/SQL now allows stored packages and database triggers.

Packages

Packages provide a method of encapsulating and storing related procedures, functions, cursors, variables, constants, and exception handlers as a unit. Global package variables and constants can be declared and used by any procedure in the package. Between calls, variables and cursors retain their state for each session. Only public data, procedures, and functions can be accessed from outside the package.

The Oracle7 Server Application Developer's Guide contains a detailed description of stored procedures, functions, and packages.

Triggers

Triggers are shared procedures that are automatically executed as a result of an insertion into, update of, or deletion from a table. A trigger consists of an event to signal the firing (execution) of the trigger, trigger restriction, and the action to take when the trigger fires. A trigger is implicitly fired by the Oracle7 Server when the triggering event occurs, no matter which user is connected or which application is being used.

The Oracle7 Server Application Developer's Guide contains a detailed description of triggers and their uses.

Compilation of Procedural Objects

Procedures, functions, packages, and triggers are automatically recompiled, as needed, whenever they are referenced. All of these procedural objects can also be compiled manually. With either method, all dependent objects are marked for automatic recompilation so that the most recent version of a routine is always used.

PL/SQL Language Changes

PL/SQL in Oracle7 supports remote procedure calls if both the distributed option and PL/SQL are licensed. Remote procedure calls include support for two-phase commit (described in the next section).

Several new commands, functions, and datatypes have been added to the PL/SQL language, and many changes have been made to existing commands. Refer to the changes appendix of the PL/SQL User's Guide and Reference for a detailed description of the changes.

Pipes and Alerts

Several new packages supplied with PL/SQL implement process-to-process communication pipes and procedural alerts. Pipes allow different processes to communicate by sending messages to one another. By registering an alert, a process can be informed when a specified event occurs in the database; for example, when a field reaches a particular value. For more information on pipes and alerts, see the Oracle7 Server Application Developer's Guide.

Interactive Output from Stored Procedures

Oracle7 stored procedures can display output interactively using the DBMS_OUTPUT package. Output can be enabled or disabled for debugging. Output lines are automatically displayed by SQL*DBA and SQL*Plus when output is enabled. You can also access debugged output from within your procedures. For more information, see the Oracle7 Server Application Developer's Guide.

Distributed Option

In Version 6, only queries were permitted to remote databases. Oracle7 with the distributed option supports all Data Manipulation Language operations, including queries, insertions, updates, and deletions of remote table data. When both the distributed option and PL/SQL are installed, calls to remote procedures are supported, as is the use of table snapshots.

You might want to distribute your database to improve performance or accommodate organizational structure. You should investigate and implement any changes that are necessary to the architecture of your applications to allow them to store data where it is used most often. See Oracle7 Server Distributed Systems, Volume I, for a complete description of the distributed database features.

Two-Phase Commit

The two-phase commit mechanism transparently maintains data consistency throughout a distributed database by guaranteeing that a distributed transaction either commits at all nodes or rolls back at all nodes, no matter what type of system or network failure occurs. Any inserts, updates, or deletes in a distributed transaction (whether from SQL statements or stored procedures) are protected by the two-phase commit mechanism.

In the event of a node failure, two-phase commit automatically coordinates the recovery of all nodes involved in a transaction.

Deadlock Detection and Resolution

The Oracle7 distributed option also detects and resolves distributed deadlock conditions.

Multi-Node Read Consistency

For a single query that spans multiple nodes, read-consistency is guaranteed. For multiple queries, the ability to specify a read-only transaction guarantees read-consistency between distributed queries.

Snapshot Capability

If you have both the distributed option and PL/SQL, then you can make read-only copies of master tables (snapshots) at remote sites. Snapshots can reduce network traffic, improve access times, and allow remote sites to continue functioning in the event of network failure or central system failure.

Snapshots can contain a subset of a table's rows, or they can summarize the information in multiple rows. They can also join data from multiple master tables.

A master table can have multiple snapshots in different locations. Snapshots can be refreshed either manually or automatically, using either a complete copy of the master table or a log that contains master table changes.

Global Naming

In Oracle7, every object in a distributed database can be uniquely specified with global names. Following this convention paves the way for the future use of external name servers. With such servers, the work of resolving the path to an external object is done by the server, instead of within the database. To ensure that the current system is correctly configured, the GLOBAL_NAMES parameter can be set, as described in Oracle7 Server Reference. The global names capability is designed to work with external name servers, such as the OSF's Distributed Computing Environment (DCE).

If you rename a database with a global name and begin enforcing global naming, the change in database name must also be reflected in the following areas:

You may choose to enable global naming gradually by enforcing it in selected databases in a distributed system. A database with global naming enabled can successfully query a database where global naming is not enabled as long as the links to the database are named properly. A database where global naming is not enabled can successfully query a database where global naming is enabled.

Global names will be required in future releases of Oracle; however, in Oracle7, you can disable global naming. Disabling global naming allows database link names to have no correspondence to global database names, as with earlier versions of Oracle.

DB_DOMAIN Parameter

The Oracle7 initialization parameter DB_DOMAIN replaces the Version 6 parameter DB_DIRECTORY. DB_DOMAIN's default value is ".WORLD". You should change it to a unique value for every system in a distributed network to identify objects uniquely in a distributed system.

Closing Database Links

A database link can now be closed when it is no longer needed without terminating the session by using the ALTER SESSION command. This can decrease your telecommunication charges, and reduce resource consumption at the site of the remote database.

LONGs Supported

In Oracle7, LONG data items can be referenced in distributed queries, updates, and deletes.

Improvements in Distributed Query Processing

If all of the data referenced by a query is located on a remote node, then the Oracle7 query processor evaluates the query at the remote node, returning only the result to the originating node. Multi-node queries are divided into parts, and each part is sent to the remote node for evaluation. This mechanism can dramatically reduce network traffic.

In addition, the optimizer can use information on indexes as well as statistics from remote tables to develop the execution plan. Using this information, queries are optimized in the same way that they would be if the tables were local. For example, Oracle7 may be able to perform a nested-loop join, where Version 6 may have been constrained to perform a sort/merge join.

Heterogeneous Distributed Database Systems

New coordination mechanisms make it possible for the Oracle7 Server to operate in a distributed arrangement with non-Oracle7 databases.

Standards Compliance

To interface to TP monitors for transaction coordination, the Oracle7 Server supports the XA interface, as defined in the X/OPEN specification.

Parallel Server Option

The Parallel Server option to the Oracle7 Server supports simultaneous database access from two or more loosely coupled systems to achieve high availability and performance. For a discussion of the new Parallel Server features, see the changes appendix in Oracle7 Parallel Server Concepts & Administration.

Backup and Recovery Enhancements

This section contains the following topics:

Recovery Capabilities

The following changes have been made to recovery features in Oracle7:

Refer to Oracle7 Server Concepts and the Oracle7 Server Administrator's Guide for more information about recovery and recovery structures. See Oracle7 Server Utilities for more information about the RECOVER command.

Parallel Server Recovery Enhancements

In Oracle7, it is possible to perform the same tablespace and datafile operations in parallel mode as when running in exclusive mode. For example, the database can remain running while a tablespace is taken offline for backup, or brought back online as part of a recovery operation. For details, see the changes appendix in Oracle7 Parallel Server Concepts & Administration.

SCN-based Recovery

System Change Numbers (SCNs) can be used in Oracle7 recovery operations, allowing you to recover up to a specific transaction. Details are given in the Oracle7 Server Administrator's Guide.

Mirrored Online Redo Log Files

The Oracle7 Server provides the capability to maintain "mirror images" of the online redo logs. When mirrored online redo log files are configured, the LGWR background process concurrently writes the same redo log information to multiple active online redo log files, thereby eliminating a potential single point of redo log failure.

You should mirror your online redo log files to reduce the chance of losing a log file in the event of media failure. Since mirrored redo log files do not significantly affect performance, the only additional overhead is space to contain the additional log files. See Oracle7 Server Concepts for a detailed description of how to configure mirrored redo log files.

Security Enhancements

This section contains the following topics:

System and Object Privileges

Many new system privileges have been added to Oracle7 to replace the three Version 6 system privileges: CONNECT, RESOURCE, and DBA. For example, statements like the following give users the privilege to create tables in their schemas:

GRANT CREATE TABLE TO SCOTT;

The new system privileges in Oracle7 allow for more specific control of system operations. The Version 6 system privileges have become predefined roles in Oracle7 for backward compatibility (roles are discussed later in this section).

An object privilege gives a user the right to perform a selected operation on a specific database object. See Oracle7 Server Concepts for more information about system and object privileges.

Creating Users

In Version 6, users were created as a side-effect of the GRANT CONNECT command. For Oracle7 it is recommended that you use the new CREATE USER command to create a user.

Users created in this manner have no privileges after creation. The GRANT CREATE SESSION command can then be employed to give the user the CREATE SESSION system privilege. (This privilege is the equivalent of the Version 6 CONNECT system privilege.) For backward compatibility, GRANT CONNECT currently creates a user, but this behavior may not always be supported.

RESTRICTED SESSION Privilege

The Oracle7 privilege CREATE RESTRICTED SESSION limits database access to privileged users. In Oracle7, you grant this privilege to create a special class of users who can use the database when it is not completely open, rather than assigning the DBA role, as was done in Version 6.

Roles

Oracle7 simplifies privilege management with roles. Roles are groups of related privileges that are granted to users or other roles.

You can create roles with specific privileges for classes of users, such as computer operators and data entry clerks. When you assign a role to a user, that user is given all of the associated privileges. In addition, when you change the privileges granted to a role, the change affects all users with that role. Roles can be password-protected, and they can be dynamically enabled.

For more details on roles and privilege management, see Oracle7 Server Concepts.

SET ROLE Command

Issuing a SET ROLE command at the start of an application automatically enables the designated role for the user (provided the user has been granted that role) and disables any previously enabled roles. Users can have default roles, and passwords can limit which applications can use each role.

Predefined Roles

Version 6 had three system privileges: CONNECT, RESOURCE, and DBA. Oracle7 defines roles with the same names, containing the equivalent Oracle7 system privileges. These roles can be modified by the system administrator, and new roles can be created.

The roles IMP_FULL_DATABASE and EXP_FULL_DATABASE allow users to perform full and incremental imports and exports. These roles can be assigned to DBAs and non-DBAs.

The predefined roles OSOPER and OSDBA have also been added to Oracle7. The OSOPER role is intended for operators and others who need some of a DBA's privileges to perform system maintenance, but who should not be granted full DBA privileges, as contained in OSDBA.

Table A - 1 lists the predefined roles that are provided for backward compatibility to Version 6.

Role Name Privileges
CONNECT 1 ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE, CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW
RESOURCE 1,2 CREATE CLUSTER, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER
DBA 1,3 All system privileges WITH ADMIN OPTION
Table A - 1. Predefined Roles

1 created by SQL.BSQ
2 grantees of the RESOURCE role also receive the UNLIMITED TABLESPACE system privilege as an explicit grant (not part of the RESOURCE role)
3 grantees of the DBA role also receive the UNLIMITED TABLESPACE system privilege with the WITH ADMIN OPTION as an explicit grant (not as part of the DBA role)

During migration, Version 6 users with the CONNECT, RESOURCE, or DBA system privileges are granted the respective roles in the Oracle7 database. After migration, you should consider how you want to control access to your database and create appropriate roles. You will probably want to have a variety of roles for users and developers of different applications, as well as the various people who administer your system. After creating and assigning these roles, you should revoke the CONNECT, RESOURCE, and DBA roles from users in your database. However, you should not alter or drop the predefined roles.

There are a few small differences between the Version 6 DBA privilege and the Oracle7 DBA role. Views that could be created in Version 6 only because the view owner had DBA privilege cannot be created in Oracle7. The Migration Utility migrates these views, but they are inaccessible to other users because Oracle7 views cannot use privileges granted to the view owner via the DBA role. To access the view, the privileges required for the view's creation must be granted directly to the owner of the view.

Oracle7 Server Concepts gives a more complete description of the new system privileges and strategies for creating roles, as well as how you can use your operating system for role management.

Improved Operating System Security Interface

The operating system can be used to maintain a list of Oracle7 roles, manage the grants and revokes of roles, and, if desired, manage the verification process for roles that require authorization. For details, see Oracle7 Server Concepts.

As in Version 6, users can be authenticated by the operating system as well as by the Oracle7 Server. However, in Oracle7 the prefix OPS$ (used to identify operating system authenticated roles) can be changed by adjusting the OS_AUTHENT_PREFIX initialization parameter.

Auditing Changes

Statement execution and the use of system privileges can now be audited on a per-user basis. Table access can be audited, as can the execution of SQL statements. In addition, new Oracle7 constructs such as triggers, procedures, and roles can be audited. To accommodate the new auditing functionality, changes have been made to most of the auditing views defined in CATAUDIT.SQL.

In Version 6, auditing of SQL statements occurred at parse time. In Oracle7, auditing occurs at execution time, since the parsed form of SQL statements are frequently already stored in shared SQL areas. But if an application explicitly controls statement processing in order to execute a statement many times but only parse it once, then only a single audit record is generated.

In Oracle7, table auditing and view auditing options are independent. If a table is accessed through a view, audit records may be generated for the table, for the view, or for both, depending on which auditing options are enabled. If a table is audited, an audit record is generated whenever that table is accessed, whether directly or through a view. An audit record is only generated on the view if auditing is enabled for the view, regardless of the audit-status of the table.

Auditing is discussed in the Oracle7 Server Administrator's Guide.

PUBLIC Quotas

Although the UNLIMITED TABLESPACE system privilege can still be granted to PUBLIC, there is no Oracle7 equivalent for the Version 6 action of granting a tablespace quota to PUBLIC. In Oracle7, quotas are assigned as part of the CREATE USER or ALTER USER statements. See Oracle7 Server SQL Reference for more details.

Standards Compliance and Trusted Oracle7

The Oracle7 Server is designed to comply with level C2 of the National Computer Security Center (NCSC) standard for computer security, as defined in the Orange Book. Oracle7 provides discretionary access control.

Trusted Oracle7 is designed to comply with level B1. Trusted Oracle7 contains all features and functions of the Oracle7 Server. In addition, it provides Mandatory Access Control (MAC) allowing for the definition of data sensitivity levels (for example secret, restricted, and unclassified) and user clearance up to a particular level. For more information on the Trusted Oracle7 Server, see the Trusted Oracle7 Server Administrator's Guide.

Performance Enhancements

This section contains the following topics:

Multi-Threaded Server Architecture

The Multi-Threaded server architecture can reduce system overhead on multi-user systems, allowing you to increase the number of concurrent users. Oracle7 Server Concepts contains a full description of the multi-threaded server architecture.

In Version 6, when using the "two task" architecture, a shadow process was associated with each user process to communicate with the database. In Oracle7, dedicated server processes and shared server processes replace shadow processes. Dedicated server processes are used in a normal two-task configuration and have the same functionality as shadow processes. Shared server processes are used when you configure your database to run with dispatcher processes that route requests from user processes to the servers.

In Version 6, shadow processes often had a high percentage of idle time. They were either waiting for the user to enter a request, or for the application to process data. In Oracle7, the shared server versions of those processes use that time to service other users. Thus, only a few shared server processes are needed to serve many users, with no loss in throughput. In Oracle7, the system resources that were previously dedicated to shadow processes are available for additional users.

Checkpoint Process

In Oracle7, the checkpoint process (CKPT) can be enabled. It helps on heavily loaded systems by taking over the work of checkpointing from LGWR. For more information, see Oracle7 Server Concepts.

The Version 6 optimizer used only the rule-based method to determine the execution plan for a SQL statement. The rule-based method considers only the syntax of the statement, table indexes, and table clusters when formulating a plan. The Oracle7 optimizer can choose an execution plan with the lowest expected "cost" using statistics collected with the ANALYZE command. Hints can also be provided to control the optimization manually.

ANALYZE Command

The ANALYZE command introduced in Oracle7 computes or estimates statistics on tables, clusters, and indexes. Statistics are then stored in the data dictionary for performance tuning and query optimization.

ANALYZE can also identify chained rows and validate the structure of tables and indexes. In this capacity, it replaces the VALIDATE INDEX command. (Although VALIDATE INDEX is supported in Oracle7, it may not be supported in future versions.)

You should familiarize yourself with the statistics that are collected by the ANALYZE command (see Oracle7 Server SQL Reference and Oracle7 Server Tuning) and how these statistics are used by the cost-based optimization approach. You should then establish a plan for collecting these statistics at appropriate time intervals. Note that you must re-collect statistics for data that has been exported and imported.

Rule-Based Optimization

If you do not collect statistics, or if the initialization parameter OPTIMIZER_MODE is set to RULE, Oracle continues to use the rule-based optimization approach. There are some minor changes in this method between Version 6 and Oracle7:

If you have manually tuned your SQL statements to force a particular execution plan (for instance, by concatenating null or adding 0 to a numeric column), Oracle7 continues to recognize these constructs, and you should generally notice no difference in the execution time for the statement.

Because future versions of Oracle will not support the rule-based optimization approach, you should begin removing this manual tuning information. In general, you can simply remove this tuning information and use the cost-based optimization method with no new tuning being needed. The cost-based optimization method generally selects an execution path for the untuned SQL statement that is as good as, or better than, the path selected for the tuned statement.

However, there are certain rare cases, such as when you have a non-uniform distribution of data, when you might need to provide "hints" to the cost-based optimizer. Additionally, there are situations where it might be necessary to provide hints to the cost-based optimizer for a query that did not need to be tuned when using the rule-based optimization approach. Once again, these usually involve non-uniform distributions of data.

Oracle7 Server Tuning contains more information on Oracle7's cost-based optimizer.

Refer to Oracle7 Server SQL Reference for a complete description of the syntax and function of the ANALYZE command. See the ALL_TABLES, USER_TABLES, and DBA_TABLES views in Oracle7 Server Reference.

Hashing

Hash clusters permit more efficient retrieval of data stored in clusters. Hashing may be used instead of an index to locate a row more quickly, usually in one read operation. This is useful when you want to fetch one row. See the Oracle7 Server Administrator's Guide for details.

Shared SQL Areas

Shared SQL areas are the memory buffers that hold the parsed form of SQL statements. In Version 6 they were called context areas, and they were stored in each user process's private PGA. Oracle7 stores the parsed form of SQL statements in the SGA and shares them among concurrent users.

When different applications issue identical SQL statements, the shared SQL area used to process the first occurrence of a statement is reused when processing subsequent occurrences of the same statement, regardless of the process that issues it. Shared SQL areas reduce memory usage and save parsing time, without any change to existing applications.

However, the SQL statements must be identical in order to take advantage of this feature. You should develop some guidelines for how SQL statements should be written. This includes spacing, capitalization, bind variables, and object names. For instance, if two identical SQL statements are issued, but one uses a synonym to refer to the table, these statements are stored separately in the SGA.

TRUNCATE Command

The TRUNCATE command quickly deletes all rows in a table or cluster and optionally shrinks the corresponding segment by deallocating unnecessary extents. Removing rows with the TRUNCATE command is faster than removing them with the DELETE command, and TRUNCATE is more convenient when you want to empty a table without removing it. For more information about the TRUNCATE command, see Oracle7 Server SQL Reference and the Oracle7 Server Administrator's Guide.

Additional Improvements

The following additional improvements have been made to the Oracle7 architecture in order to improve performance:

Administration Enhancements

This section contains the following topics:

Rollback Segments

Rollback segments are more efficient and are easier to manage in Oracle7. Not only can rollback segments grow as needed, but they can dynamically shrink to a specifiable optimal size if space in the segment is not being used. Rollback segments can be taken offline and brought back online to facilitate rollback segment management. It is also possible to specify which rollback segment to use for a given transaction. See the Oracle7 Server Administrator's Guide for a complete discussion of rollback segments.

PCTINCREASE and MAXEXTENTS Not Applied

PCTINCREASE is no longer applied to the allocation of new rollback segment extents in Oracle7. Because of this change, all extents within a rollback segment are of uniform size, which helps to reduce disk fragmentation. MAXEXTENTS is also no longer specifiable for rollback segments.

Resource Limits

In Oracle7, limits can be set on the system resources available to a user. By explicitly setting resource limits, the database administrator can prevent uncontrolled consumption of valuable system resources.

Resource limits apply on a per call or per session basis. They can be set for

Profiles

Resource limits are easily managed with user profiles. A profile is a named set of resource limits that can be assigned to users. Profiles are only needed if resource limits are a requirement of a database's security policy. The database administrator can universally enable or disable the enforcement of profile resource limits at the database level.

User Definitions

In Version 6, users could not be created without granting them connect access. In Oracle7, user definitions can be created without automatically granting access to them, and a user's right to log on can be dropped while leaving the associated schema intact. For more information, see the Oracle7 Server Administrator's Guide.

ALTER SYSTEM Command

The SQL command ALTER SYSTEM can be used to change Oracle7 configuration with respect to files, resource limits, multi-threaded server processes, and distributed recovery. For more information, see Oracle7 Server SQL Reference.

SQL*DBA Changes

Interactive Menu Interface

Version 6 introduced SQL*DBA to facilitate common database administrator activities, such as monitoring database activity and database recovery. SQL*DBA in Oracle7 is further enhanced with a menu-driven interface to make database administration easier. New monitors have also been introduced.

As in Version 6, any SQL statement can be executed from SQL*DBA, as well as stored procedures and functions. Refer to Oracle7 Server Utilities for more information about SQL*DBA's menu interface, commands, and monitoring capabilities.

CONNECT Required before STARTUP or SHUTDOWN

In order to issue a SQL*DBA STARTUP or SHUTDOWN command, you must first CONNECT to the database. This is a new requirement in Oracle7. It was not necessary in Version 6. Accordingly, scripts similar to the following no longer work:

SQLDBA> STARTUP

For Oracle7, such commands should be embedded in scripts that include a CONNECT clause. The script can then be invoked with a command line similar to the following:

SQLDBA> @START_SCRIPT.SQL

Also, there are several new options to the STARTUP command; see Oracle7 Server Utilities for more information.

Monitors

The SQL*DBA monitor commands no longer take arguments. Instead, fields in the monitor screens take values to customize the monitor displays. Also, the monitor screens are no longer available when using the Version 6-compatible line-mode interface. They are only available when using the Oracle7 window and menu interface.

Starting a Database in Restricted Mode

Rather than using the Version 6 command STARTUP DBA, you use the Oracle7 command STARTUP RESTRICTED to limit database access to users who have been granted the RESTRICTED SESSION privilege.

Controlling Restricted Sessions

Using the SQL command ALTER SYSTEM, restricted session mode can be enabled and disabled without having to restart the database. See Oracle7 Server SQL Reference for details.

KILL SESSION Command

The SQL*DBA KILL SESSION command allows the database administrator to terminate user sessions remotely.

DESCRIBE Command

SQL*DBA supports the DESCRIBE command in Oracle7. This command describes tables, views, procedures, functions, and packages.

New Reserved Words

V6 and V7 are now reserved words in SQL*DBA.

Debug Output Supported

Output lines generated in stored procedures and functions are automatically displayed by SQL*DBA when you enable the SERVEROUTPUT function, either from the menu interface or with the SET command. The output routines are described in the Oracle7 Server Application Developer's Guide.

Changes to Utilities

This section contains the following topics:

Import/Export Changes

The Oracle7 Import/Export utilities handle all of the new Oracle7 objects. Among other improvements, error-managing facilities have improved, and messages can be stored in a log file. Major changes include the following:

For more information, see Oracle7 Server Utilities.

SQL*Loader Changes

SQL*Loader's direct path greatly reduces data loading times. This path bypasses SQL processing and loads data directly into the database. Other improvements to SQL*Loader include the following:

For more information, see Oracle7 Server Utilities.

Changes to Views

This section contains the following topics:

Creating a View with Errors

In Version 6, it was not possible to create a view if the view could not be immediately queried. So, for example, it was impossible to create a view if an underlying table did not exist, or if its definition did not match that of the view.

In Oracle7, such views can be created. The underlying table can then be created or modified later. Until the underlying tables are corrected, any attempt to use the view produces an error. This change relaxes the strict sequence of table-before-view creation, permitting greater flexibility in database definition.

When accessing a view that has been created with errors, the view is "compiled" to determine if it has become usable. A new SQL command, ALTER VIEW ... COMPILE, lets you force the recompilation at any time, without waiting for the view to be accessed.

View Still Valid after Changing Table

In Version 6, a view failed if its underlying table was modified or if it was deleted and re-created. Because Oracle7 implements object dependencies, such a view is marked for recompilation when the underlying table changes. The view is then recompiled the next time it is accessed, or after an ALTER VIEW ... COMPILE command, so it functions normally as long as all of the columns it accesses still exist.

Replacing a View

An existing view can be dropped and re-created in one statement using the syntax

CREATE OR REPLACE VIEW

When a view is replaced in this manner, existing GRANTS and references by other views remain intact.

SELECT * In View Definitions

In Version 6, views created with "SELECT *" would operate only so long as new columns were not added to the underlying table, because the wildcard (*) was expanded dynamically during the select. As a result, the number of columns in the changed table no longer matched the view definition.

Oracle7 adopts SQL's standard behavior of expanding such wildcards when the view is defined. The number of columns is then statically defined, because a statement like

SELECT *

is transformed into one like

SELECT column1, column2, column3

As a result, the view remains valid even when additional columns are added to the underlying table. (If there is an error when the view is created, the wildcard is expanded at the first successful compilation of the view.)

Oracle Datatype Changes

This section contains the following topics:

Conversion of Datatypes

Refer to "Data Dictionary Conversion" [*] for more information on how your existing Version 6 datatypes will be converted to Oracle7 datatypes using different migration options.

Character Datatypes

Version 6 supported one datatype, CHAR, for handling variable-length character strings, and one synonym for that datatype, VARCHAR. Oracle7 uses two datatypes for character strings, as described in the following sections.

CHAR

Values of this datatype are fixed-length character strings with a maximum length of 255. CHAR values are compared using padded comparison semantics. The Oracle7 CHAR datatype is not equivalent to the Version 6 CHAR datatype.

VARCHAR2

Values of this datatype are variable-length character strings of maximum length 2000. VARCHAR2 values are compared using non-padded comparison semantics. The Oracle7 VARCHAR2 datatype is equivalent to the Version 6 CHAR datatype except for the difference in maximum lengths.

VARCHAR

VARCHAR is a synonym for the VARCHAR2 datatype in Oracle7, but future versions may use VARCHAR as a separate datatype, so use of VARCHAR is not recommended. Refer to Oracle7 Server SQL Reference for a description of the different comparison semantics.

LONG and LONG RAW Datatypes

The LONG and LONG RAW datatypes can store a variable-length character string of up to 2 gigabytes (231-1 bytes) in length, as opposed to 64 Kb in Version 6. One piece at a time can be fetched with the new OCI call OFLNG.

MLSLABEL

The MLSLABEL type was added for compatibility with Trusted Oracle. For more information, see the Trusted Oracle7 Server Administrator's Guide.

Addition of ROWLABEL Column

ROWLABEL is a new virtual column in Oracle tables. Like ROWID, it is automatically generated when a table is created. It has the datatype MLSLABEL. This column exists for compatibility with Trusted Oracle, which uses it to store the security label of each row in a table. For more information, see the Trusted Oracle7 Server Administrator's Guide.

Change in ROWID Format

In order to support more files per database, the number of bits in the ROWID used to identify file number and block id have been reallocated. This change has no effect in the externally visible ROWID.

SQL Command Changes

Many new commands and functions have been added to the SQL language in Oracle7, and many changes have been made to existing commands. New format models and datatypes have also been added, along with new built-in trig and math functions, the UNION ALL operator, and a new comment facility. Two new keywords have been added: ROWLABEL and VARCHAR2. For additional information, see Oracle7 Server SQL Reference for a detailed description of the changes.

New Features of the Oracle Precompilers, Release 1.5

This section contains the following topics:

Release 1.5 of the Oracle Precompilers was introduced with Oracle7, and incorporated many new features designed to enhance precompiler functionality and application performance, as well as allow your applications to access new Oracle7 capabilities. Most users will upgrade to Release 1.5 at the same time they upgrade to Oracle7. Use of Release 1.3 and 1.4 of the Precompilers is supported against Oracle7. However, if you wish to use the enhanced functionality of Oracle7, you must use Release 1.5 of the Precompilers.

The following changes have been introduced since Release 1.3 of the Precompilers. Some changes appeared in Release 1.4 as well, but are listed here for convenience.

Datatype Equivalencing

You can now selectively override the datatypes assigned to host variables in the Declare Section, and use those variables in static embedded SQL statements. In C and Pascal, you can also associate an Oracle datatype with user-defined datatypes. This ability to equivalence datatypes adds flexibility to your applications.

Bundled Database Calls

Whenever possible, only a single bundled database call is made per embedded SQL statement, speeding up communication with Oracle, especially in a networked environment.

Concise, Faster Generated Code

The interface to the Oracle runtime library has been revised, reducing the amount of precompiler-generated code required to execute embedded SQL statements. This code is not only easier to read, but allows applications to run faster.

More Flexible Error Handling

An enhanced SQL WHENEVER statement allows you to embed host-language procedure calls in a precompiled program. If a SQL statement fails, you can have your program transfer control to a routine, and return when it ends.

Smart Resizing

Private SQL areas are automatically resized and the AREASIZE option is now obsolete.

Smart Rebinding

Host variables are rebound only when necessary, making the REBIND option obsolete.

Full Reentrance

Reentrant code is generated automatically for systems that require it and the REENTRANT option is now obsolete.

Separate Executables for Each Language

The precompilers are now distributed as separate executables, each designed for a specific host language. As a result, the HOST option is no longer needed for specifying the host language, but it remains for port-specific and COBOL-specific purposes.

Standards Compliance

The Release 1.5 precompilers have been verified as 100% compliant by the National Institute of Standards and Technology. Additionally, the new FIPS (Federal Information Processing Standard) flagger option issues warning messages whenever it detects the existence of an Oracle SQL extension, or usage of a standards-mandated feature in a non-standard manner.

New Debugging Aid

Now the SQLCA stores more runtime information about the outcome of SQL operations. Specifically, SQLERRD(5) stores a parse error offset to help you debug SQL statements.

Initialization Parameters

The following tables list the obsolete and renamed Version 6 initialization parameters and the new Oracle7 parameters. Refer to Oracle7 Server Reference for a complete description of all initialization parameters.

Obsolete Parameters
BG_PRIORITY FREE_LIST_PROC
CALLS GC_SORT_LOCKS
CONTEXT_AREA INSTANCES
CONTEXT_INCR LANGUAGE
CPU_COUNT LOG_ALLOCATION
DP_BLOCK_CACHE_ PROTECT LOG_BLOCKS_DURING_ BACKUP
DP_BLOCK_COMPUTE_ CHECKSUMS LOG_BUFFERS_DEBUG
DB_BLOCK_HASH_ BUCKETS LOG_DEBUG_MULTI_ INSTANCE
DB_BLOCK_MAX_ CLEAN_PCT LOG_ENTRY_PREBUILD_ THRESHOLD
DB_BLOCK_MAX_MOD_PCT LOG_IO_SIZE
DB_BLOCK_MAX_SCAN_CNT MESSAGES
DB_BLOCK_MAX_SCAN_PCT ROW_CACHE_BUFFER_SIZE
DB_BLOCK_MULTIPLE_ HASHCHAIN_LATCHES ROW_CACHE_ ENQUEUES
DB_BLOCK_TIMEOUT_ WRITE_PCT ROW_CACHE_ INSTANCE_LOCKS
DB_BLOCK_WRITE_ BATCH ROW_CACHE_MULTI_ INSTANCE
DB_HANDLES ROW_CACHE_PCT_FREE
DB_HANDLES_CACHED SAVEPOINTS
DC_*(All DC_parameters) SCN_INCREMENT
DDL_LOCKS SCN_THRESHOLD
ENQUEUE_DEBUG_ MULTI_INSTANCE SORT_READ_FAC
ENQUEUE_HASH USE_ROW_ENQUEUES
ENQUEUE_LOCKS USER_SESSIONS
FREE_LIST_INST WAIT_FOR_SYNC
If you use Version 6 National Language Support, you must alter your Oracle7 parameter file to include the appropriate initialization parameters. Additionally, the specification of the NLS_SORT parameter has changed. For more information on NLS_SORT, see Oracle7 Server Reference.

Renamed Parameter New Name
MI_BG_PROCS GC_LCK_PROCS
New Parameters
AUTO_MOUNTING MTS_MAX_DISPATCHERS
CHECKPOINT_PROCESS MTS_MAX_SERVERS
COMMIT_POINT_STRENGTH MTS_SERVERS
CURSOR_SPACE_FOR_TIME MTS_SERVICE
DB_BLOCK_CHECKPOINT_BATCH NLS_CURRENCY
DB_DOMAIN NLS_DATE_FORMAT
DB_MOUNT_MODE NLS_DATE_LANGUAGE
DISCRETE_TRANSACTIONS_ ENABLED NLS_ISO_CURRENCY
DISTRIBUTED_LOCK_TIMEOUT NLS_LANGUAGE
DISTRIBUTED_RECOVERY_ CONNECTION_HOLD_TIME NLS_NUMERIC_CHARACTERS
DISTRIBUTED_TRANSACTIONS NLS_TERRITORY
GC_LCK_PROCS OPEN_COMPATIBLE
GLOBAL_NAMES OPEN_MOUNTS
INSTANCE_NUMBER OPTIMIZER_COMP_WEIGHT
LABEL_CACHE_SIZE OPTIMIZER_OVERRIDE
LICENSE_MAX_SESSIONS OS_AUTHENT_PREFIX
LICENSE_MAX_USERS OS_ROLES
LICENSE_SESSIONS_WARNING RECOVERY_COMPATIBLE
LOG_ARCHIVE_BUFFERS REMOTE_OS_AUTHENT
LOG_ARCHIVE_BUFFER_SIZE REMOTE_OS_ROLES
LOG_ARCHIVE_FORMAT RESOURCE_LIMIT
LOG_CHECKPOINT_TIMEOUT SHARED_POOL_SIZE
MAX_ENABLED_ROLES SMALL_TABLE_THRESHOLD
MAX_ROLLBACK_SEGMENTS_MLS SORT_AREA_RETAINED_SIZE
MLS_LABEL_FORMAT TEMPORARY_TABLE_LOCKS
MTS_DISPATCHERS THREAD
MTS_LISTENER_ADDRESS

Data Dictionary Changes

This section contains the following topics:

This section describes the changes to the Oracle7 data dictionary. See Oracle7 Server Reference for descriptions of the standard tables and views that are available to developers and lists all tables and views.

Views

Oracle7 introduces a new set of data dictionary views. The views are created by the database administrator under the schema of user SYS. Several data dictionary views from Version 6 have either changed or become obsolete. Others have been renamed. In addition, new views have been added in Oracle7. The following tables summarize the changes:

Obsolete Views
ACCESSIBLE_COLUMNS DBA_AUDIT_RESOURCE
ACCESSIBLE_TABLES DBA_CROSS_REPS
CONSTRAINT_COLUMNS MYPRIVS
CONSTRAINT_DEFS USER_AUDIT_CONNECT
DBA_AUDIT_CONNECT USER_AUDIT_RESOURCE
DBA_AUDIT_DBA USER_CROSS_REFS
Changed Views
ALL_CONSTRAINTS DBA_ROLLBACK_SEGS
ALL_DEF_AUDIT_OPTS DBA_TABLES
ALL_INDEXES DBA_TAB_COLUMNS
ALL_OBJECTS DBA_USERS
ALL_TAB_COLUMNS TABLE_PRIVILEGES
ALL_TABLES USER_AUDIT_TRAIL
COLUMN_PRIVILEGES USER_CLUSTERS
DBA_AUDIT_EXISTS USER_CONSTRAINTS
DBA_AUDIT_TRAIL USER_INDEXES
DBA_CLUSTERS USER_OBJECTS
DBA_CONSTRAINTS USER_TABLES
DBA_INDEXES USER_TAB_COLUMNS
DBA_OBJECTS USER_USERS
Renamed Views
Old Name New Name
ALL_COL_GRANTS ALL_COL_PRIVS
ALL_COL_GRANTS_MADE ALL_COL_PRIVS_MADE
ALL_COL_GRANTS_RECD ALL_COL_PRIVS_RECD
ALL_TAB_GRANTS ALL_TAB_PRIVS
ALL_TAB_GRANTS_MADE ALL_TAB_PRIVS_MADE
ALL_TAB_GRANTS_RECD ALL_TAB_PRIVS_RECD
AUDIT_OPTION_MAP STMT_AUDIT_OPTION_MAP
DBA_COL_GRANTS DBA_COL_PRIVS
DBA_TAB_GRANTS DBA_TAB_PRIVS
DBA_SYS_AUDIT_OPTS DBA_STMT_AUDIT_OPTS
DBA_TAB_AUDIT_OPS DBA_OBJ_AUDIT_OPS
USER_COL_GRANTS USER_COL_PRIVS
USER_COL_GRANTS_MADE USER_COL_PRIVS_MADE
USER_COL_GRANTS_RECD USER_COL_PRIVS_RECD
USER_TAB_AUDIT_OPTS USER_OBJ_AUDIT_OPTS
USER_TAB_GRANTS DBA_TAB_PRIVS
USER_TAB_GRANTS_MADE USER_TAB_PRIVS_MADE
USER_TAB_GRANTS_RECD USER_TAB_PRIVS_RECD
New Views
ALL_DEPENDENCIES DBMS_ALERT_INFO
ALL_ERRORS DBMS_LOCK_ALLOCATED
ALL_OBJECT_SIZE DEPTREE
ALL_SNAPSHOTS EXCEPTIONS
ALL_SOURCE GLOBAL_NAME
ALL_TRIGGERS IDEPTREE
CHAINED_ROWS INDEX_HISTOGRAM
DBA_2PC_PENDING INDEX_STATS
DBA_2PC_NEIGHBORS PLAN_TABLE
DBA_AUDIT_OBJECT PUBLIC_DEPENDENCY
DBA_AUDIT_SESSION RESOURCE_COST
DBA_AUDIT_STATEMENT ROLE_ROLE_PRIVS
DBA_BLOCKERS ROLE_SYS_PRIVS
DBA_CONSTRAINTS ROLE_TAB_PRIVS
DBA_DDL_LOCKS ROLE_TAB_TABS
DBA_DEPENDENCIES SESSION_PRIVS
DBA_DML_LOCKS SESSION_ROLES
DBA_ERRORS USER_AUDIT_OBJECT
DBA_LOCKS USERT_AUDIT_SESSION
DBA_OBJECT_SIZE USER_AUDIT_STATEMENT
DBA_PROFILES USER_DEPENDENCIES
DBA_ROLE_PRIVS USER_ERRORS
DBA_ROLES USER_OBJECT_SIZE
DBA_SNAPSHOTS USER_RESOURCE_LIMITS
DBA_SNAPSHOT_LOGS USER_ROLE_PRIVS
DBA_SOURCE USER_SNAPSHOTS
DBA_SYS_PRIVS USER_SNAPSHOT_LOGS
DBA_TRIGGERS USER_SOURCE
DBA_WAITERS USER_SYS_PRIVS
USER_TRIGGERS
Additional Views These are new tables and views that have been created for use by the Oracle Server or Oracle utility programs. They are mentioned for the sake of completeness, but are of little interest to the user or administrator.

CODE_PIECES LOADER_TAB_INFO
CODE_SIZE LOADER_TRIGGER_INFO
ERROR_SIZE PARSED_PIECES
LOADER_COL_INFO PARSED_SIZE
LOADER_CONSTRAINT_INFO SOURCE_SIZE
LOADER_INDCOL_INFO STMT_AUDIT_OPTION_MAP
LOADER_IND_INFO SYSTEM_PRIVILEGE_MAP
LOADER_PARAM_INFO TABLE_PRIVILEGE_MAP

Dynamic Performance Tables

This section lists the changes to the dynamic performance tables.

Changed V$ Views
V$ACCESS V$PROCESS
V$FILESTAT V$ROLLNAME
V$LATCH V$ROLLSTAT
V$LOCK V$SESSION
V$LOGFILE V$WAITSTAT
V$PARAMETER
New V$ Views
V$ARCHIVE V$OPEN_CURSOR
V$BACKUP V$QUEUES
V$CIRCUITS V$RECOVERY_LOG
V$DATABASE V$RECOVER_FILE
V$DATAFILE V$REQDIST
V$DB_OBJECT_CACHE V$SESSION_WAIT
V$DISPATCHERS V$SGASTAT
V$ENABLEDPRIVS V$SHARED_SERVERS
V$LIBRARYCACHE V$SQLAREA
V$LICENSE V$SQLTEXT
V$LOADCSTAT V$THREAD
V$LOADSTAT V$TIMER
V$LOG V$TYPE_SIZE
V$LOG_HISTORY V$VERSION
V$LOGHIST V$VERSION
V$NLS_PARAMETERS

Trusted Oracle Views

The following views and dynamic tables are new in Trusted Oracle7:

ALL_LABELS V$SECONDARY
ALL_MOUNTED_DBS V$SYSLABEL

Version 6 Compatibility

This section contains the following topics:

Version 6 to Oracle7 Migration Utility

The Oracle7 Migration Utility converts a Version 6 database into Oracle7 form. The conversion happens "in place"; the database does not need to be reloaded from backup files. For more information, see Chapter 4 "The Migration Utility".

Release 7.0 Backward Compatibility

Release 7.0 is completely backward compatible with Version 6 of the Oracle7 Server.

Warning: If the COMPATIBILITY parameter is set to Version 6, the functionality of certain Release 7.0 features will not be available.

Version 6 SQL Compatibility Mode

Each of the Oracle7 utilities makes it possible to select Version 6 SQL command compatibility. In SQL*DBA, for example, the SET COMPATIBILITY command is used. For more information on the SET command, see the SQL*DBA Commands section of Oracle7 Server Utilities. For more information on the effects of setting the compatibility mode, see Oracle7 Server SQL Reference. The effects include the following:

CATALOG6.SQL

This command file augments the Oracle7 data dictionary by re-creating obsolete Version 6 views and views that were replaced in Oracle7. The file DROPCAT6.SQL can be used later to undo these changes to the Oracle7 data dictionary.

EXPVEW6.SQL

Running EXPVEW6.SQL allows remote Version 6 sites to do exports from Oracle7 databases. See Oracle7 Server Utilities for more details.

EXPEOB6.SQL

This script lists the objects that are excluded when Version 6 sites do exports from an Oracle7 database. See Oracle7 Server Utilities for more details.

New and Renamed SQL Scripts

The names of many SQL scripts were changed in order to make them easier to identify. In addition, many new scripts were added to support Oracle7's extended functionality. The new and changed scripts are listed below.

By convention, scripts that begin with CAT are intended to be run by SYS. They create views and tables in the data dictionary. Scripts that begin with DBMS are also run by SYS. They create stored procedures, functions, and packages. Scripts that begin with UTL are intended to be run by individual users. For more information, see the Oracle7 Server Administrator's Guide and Oracle7 Server Reference.

Renamed Scripts
Old Name
New Name
AUDIT.SQL CATAUDIT.SQL
BLOCKING.SQL CATBLOCK.SQL
BSTAT.SQL CATBSTAT.SQL
DBA_SYN.SQL CATDBSYN.SQL
DISPIDXS.SQL UTILDXSD.SQL
ESTAT.SQL UTLIDXSS.SQL
EXPVEW.SQL CATEXP.SQL
IDXSTAT.SQL UTLESTAT.SQL
LOCKTREE.SQL UTLLOCKT.SQL
MONITOR.SQL UTLMONTR.SQL
NOAUDIT.SQL CATNOAUD.SQL
ONEIDXS.SQL UTILDXSO.SQL
PSVIEWS.SQL CATPARR.SQL
SAMPLE1.SQL..SAMPLE4.SQL UTLSAMPL.SQL (combined)
ULVIEW.SQL CATLDR.SQL
XPLAINPL.SQL UTLXPLAN.SQL
New Scripts
CATEXP6.SQL DBMSALRT.SQL UTLCHAIN.SQL
CATNOPRC.SQL DBMSLOCK.SQL UTLDTREE.SQL
CATPROC.SQL DBMSMAIL.SQL UTLEXCPT.SQL
CATSTAT.SQL DBMSPIPE.SQL UTLMAIL.SQL
DBMSSNAP.SQL
DBMSTRST.SQL
DBMSUTIL.SQL

Other Changes

This section contains the following topics:

Larger Control Files

Oracle7 control files can be larger than they were in Version 6, although the maximum size is still operating system dependent. On most systems, the maximum has been increased from 500 blocks to 2500 blocks.

Additional Information: Consult your operating system-specific Oracle documentation for more information.

More Data Files

Although the maximum number of operating system files that can be in the database is operating system dependent, the maximum has been increased. In Oracle Version 6, the maximum was typically 255 files. In Oracle7, the maximum is typically 1022 or more.

Additional Information: Consult your operating system-specific Oracle documentation for more information.

Fewer Data Blocks

The number of data blocks per database may have shrunk for your system's implementation of the Oracle7 Server. If it has, then the database blocksize may need to be increased in order to create a database of the same size.

MAXEXTENTS

The default value for MAXEXTENTS depends on the database block size in Oracle7, as well as the maximum value. The details are operating system specific.

Additional Information: Consult your operating system-specific Oracle documentation for more information.

Change in Use of PCTINCREASE

When a new extent is allocated in Oracle7, the size of the new extent is based on the last automatically allocated extent in that segment. As a result, changing PCTINCREASE produces an incremental change in extent size, regardless of how many extents have been previously allocated. (In Version 6, the size of the new extent depended on the total number of allocated extents, which magnified the effects of changes to PCTINCREASE.) For details, consult the Oracle7 Server Administrator's Guide.

Assigning Tablespace Quotas

In Version 6, tablespace quotas were assigned with the GRANT command. In Oracle7, tablespace quotas are assigned with the CREATE USER and ALTERUSER commands.

The Version 6 syntax made it appear to be legal to assign tablespace quotas to PUBLIC, although in fact it was not. The Oracle7 syntax precludes that possibility.

Accessing Tables During Index Creation

In Version 6, it was not possible to select from a table while a CREATE INDEX statement was operating. In Oracle7, rows can be selected from tables while indexes are being created.

Blocks in Rollback Segments Dedicated to Transactions

Blocks in Oracle7 rollback segments are not shared by multiple transactions. Instead, each Oracle7 rollback segment block is exclusively dedicated to a single transaction. As a result, you may need to increase the size of your rollback segments if your transactions are very small relative to the rollback segment block size.

Messages and Codes

Because of increased functionality, many new messages have been added to Oracle7, and some Version 6 messages have become obsolete. If your programs use any hardcoded message numbers, please verify that the message number and message text have remained the same for any messages for which your programs test.

In addition, some message numbers have been reused. See Oracle7 Server Messages for a listing of the message codes used in Oracle7.

ALERT Filenames

Previously, ALERT filenames had the following format:

ALERT_instanceName.LOG

In Oracle7, they usually have the following format:

nodename_instanceName_ALERT.LOG

Additional Information: The format depends on your operating system. Consult your operating system-specific Oracle documentation for details.

TRACE Files

Previously, TRACE filenames had the following format:

imageName_instanceID_process#.LOG

In Oracle7, they usually have the following format:

nodename_instanceID_imageName_FG_process#.LOG

Previously, each background process wrote a trace file at instance startup. This is no longer true with Oracle7.

Additional Information: The format depends on your operating system. Consult your operating system-specific Oracle documentation for details.


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