Oracle9i Database Migration Release 2 (9.2) Part Number A96530-01 |
|
This appendix lists changes to initialization parameters and the data dictionary across different releases of Oracle. This appendix also discusses compatibility issues with certain initialization parameters.
This appendix covers the following topics:
Note: This appendix does not list changes to initialization parameters and the data dictionary that occurred in release 8.0. If you are upgrading from Oracle7, then see "Changes to Initialization Parameters and the Data Dictionary in Release 8.0" in addition to the changes outlined in this appendix. |
The following sections list changes to initialization parameters across different releases of Oracle:
See Also:
The "What's New in Oracle9i Database Reference" section of Oracle9i Database Reference for a list of new initialization parameters in Oracle9i |
The following sections list initialization parameters that have been deprecated. A deprecated parameter behaves the same way as a regular parameter, except that a warning message is displayed at instance startup if a deprecated parameter is specified in a parameter file. In addition, all deprecated parameters are logged to the alert log at instance startup:
The following initialization parameters were deprecated in release 9.2:
Deprecated | In Favor Of |
---|---|
|
|
The following initialization parameters were deprecated in release 9.0.1:
The following sections list initialization parameters that have been made obsolete:
The following initialization parameters were made obsolete in release 9.2:
|
|
|
|
The following initialization parameters were made obsolete in release 9.0.1:
The following initialization parameters were made obsolete in release 8.1:
The lists of deprecated and obsolete initialization parameters earlier in this appendix show changes to initialization parameters across different releases of Oracle. However, certain initialization parameter changes require special attention because they may raise compatibility issues for your database. These parameter changes are described in this section.
Starting with release 9.0.1, the DB_BLOCK_CHECKSUM
initialization parameter has a new default value. In previous releases, the default value was false
, but in release 9.0.1 and higher, the default value is true
.
See Also:
|
In Oracle9i, the maximum number of job queue processes that can be spawned per instance is 1000. In previous releases, the maximum number was 36. The JOB_QUEUE_PROCESSES
initialization parameter controls the number of job queue processes.
See Also:
|
Starting with release 8.1.7, the ORACLE_TRACE_ENABLE
initialization parameter is dynamic. The default value is false
.
To enable Oracle Trace collections for the server, use ALTER SYSTEM
or ALTER SESSION
to set ORACLE_TRACE_ENABLE
to true
. This setting alone does not start an Oracle Trace collection, but it allows Oracle Trace to be used with the server.
With ORACLE_TRACE_ENABLE
set to true
, Oracle Trace collection of server event data can then be performed in one of the following ways:
ORACLE_TRACE_COLLECTION_NAME
initialization parameter.
Starting with release 8.1.6, setting the SERIALIZABLE
initialization parameter to true
is no longer supported. This is not the same as "obsolete". The parameter still shows up as a valid parameter in the V$PARAMETER
data dictionary view.
The default behavior henceforth is as if SERIALIZABLE
were set to false
. Use the SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
command to achieve similar transaction isolation behavior. You can also use ALTER SESSION SET ISOLATION_LEVEL = SERIALIZABLE
to get the behavior for a full session.
The SORT_DIRECT_WRITES
initialization parameter is obsolete in release 8.1 and higher. If you had SORT_DIRECT_WRITES
set to FALSE or AUTO in a past release, then the sort buffers were kept in the buffer cache whenever possible. Because SORT_DIRECT_WRITES
is obsolete in release 8.1 and higher, the sort buffers could go directly to disk if you do not adjust your SORT_AREA_SIZE
initialization parameter.
You should increase the value of SORT_AREA_SIZE
if either of the following conditions were true in a past release:
SORT_DIRECT_WRITES
was set to FALSE.SORT_DIRECT_WRITES
was set to AUTO, and SORT_AREA_SIZE
was set to 640 KB or less.If either of these conditions were true in a past release, then increase the value of SORT_AREA_SIZE
for better performance.
Starting with release 8.1.5, the LOG_CHECKPOINT_TIMEOUT
initialization parameter has a new default value. In previous releases, the default value was zero seconds, but in release 8.1.5 and higher, the default value is 1800 seconds.
See Also:
|
The O7_DICTIONARY_ACCESSIBILITY
initialization parameter controls whether to continue Oracle7 data dictionary behavior. Use of this initialization parameter is only a temporary expedient. Starting with release 9.0.1, the default value of this initialization parameter is false
.
See Also:
"Data Dictionary Protection" for more information. |
Oracle9i systems typically consume more DML locks while performing DDL operations than are required for Oracle7 systems. Nevertheless, the Oracle7 DML_LOCKS
parameter default settings are usually adequate for Oracle9i systems, even for DML-intensive applications.
The default value of DML_LOCKS
is a multiple of the number of transactions, which is calculated from the number of rollback segments. However, in Oracle9i fewer transactions are used per rollback segment than are used in Oracle7. Consequently, DML_LOCKS
has a lower default value in Oracle9i. Under some extreme load conditions, you may need to increase the DML_LOCKS
parameter value.
You may also need to adjust the TRANSACTION_PER_ROLLBACK_SEGMENT
parameter setting, depending on the operating system-specific settings. An informational message about this change may be displayed during database startup operations.
Starting with release 8.1, if the DB_DOMAIN
initialization parameter is not set, then it is set to NULL by default. In prior releases of Oracle, the default setting was the following:
WORLD
A NULL setting for DB_DOMAIN
may cause database connection problems in some environments. If you are upgrading from release 8.0.6 or earlier, then make sure the DB_DOMAIN
initialization parameter in your initialization parameter file is set to one of the following:
If DB_DOMAIN
is not set in your current database, then set it to WORLD
before you upgrade.
If DB_DOMAIN
is set to a valid domain for your environment in your current database, then retain the setting in your initialization parameter file when you upgrade.
Starting with release 8.1, parallel execution message buffers are allocated from the large pool whenever PARALLEL_AUTOMATIC_TUNING
is set to true
. In previous releases, this allocation was from the shared pool. If you are upgrading from release 8.0.6 or earlier, and you choose to set PARALLEL_AUTOMATIC_TUNING
to true
, then you can avoid problems by modifying the settings for the following initialization parameters:
Typically, you should reduce the setting of SHARED_POOL_SIZE
and raise the setting of LARGE_POOL_SIZE
to avoid problems. Alternatively, you can reduce the setting of SHARED_POOL_SIZE
and let Oracle calculate the setting of LARGE_POOL_SIZE
. Oracle calculates a default LARGE_POOL_SIZE
only if PARALLEL_AUTOMATIC_TUNING
is set to true
and LARGE_POOL_SIZE
is unset.
The calculation is based on the settings of the following initialization parameters:
PARALLEL_MAX_SERVERS
PARALLEL_THREADS_PER_CPU
PARALLEL_SERVER_INSTANCES
MTS_DISPATCHERS
DBWR_IO_SLAVES
If PARALLEL_AUTOMATIC_TUNING
is unset or set to FALSE, and if LARGE_POOL_SIZE
is unset, then the value of LARGE_POOL_SIZE
defaults to zero.
Note: When |
See Also:
Oracle9i Database Reference and Oracle9i Database Performance Tuning Guide and Reference for more information about other effects of the |
The following scenarios illustrate the behavior that results from various initialization parameter settings when you upgrade to release 8.1 or higher.
You do not alter the parameters from their previous settings:
These settings are the most common scenario. In this case, you already have accounted for the space required for parallel execution in the shared pool.
You alter the parameters from their previous settings to the following settings:
In this case, parallel execution allocates buffers from the large pool based on Oracle's automatic calculation. Buffer allocation is more efficient, and failures to allocate are isolated from the clients of the shared pool.
You alter the parameters from their previous settings to the following settings:
In this case, parallel execution allocates buffers from the large pool. After initial testing with LARGE_POOL_SIZE
unset, you determined that the default calculation for LARGE_POOL_SIZE
did not reflect your requirements for the large pool. Therefore, you decided to manually set LARGE_POOL_SIZE
. After you set LARGE_POOL_SIZE
properly, buffer allocation is more efficient, and failures to allocate are isolated from the clients of the shared pool.
You alter the parameters from their previous settings to the following settings:
In this case, parallel execution allocates buffers from the large pool, but because you did not modify SHARED_POOL_SIZE
, it is likely that the SGA will be unnecessarily large, causing performance problems. Therefore, avoid setting PARALLEL_AUTOMATIC_TUNING
to true
without modifying the settings of SHARED_POOL_SIZE
and LARGE_POOL_SIZE
appropriately.
Release 8.1 and higher supports new archive log destination parameters. After you upgrade, you can dynamically convert from the old pre-release 8.1 parameters (LOG_ARCHIVE_DEST
and LOG_ARCHIVE_DUPLEX_DEST
) to the new release 8.1 and higher parameters (LOG_ARCHIVE_DEST_
n
and LOG_ARCHIVE_DEST_STATE_
n
). You can also dynamically revert to the old parameters.
After you determine the new archive destinations, associated states, and options, complete the following steps to change from the old archive log destination parameters to the new ones:
ALTER SYSTEM
to set LOG_ARCHIVE_MIN_SUCCEED_DEST
to 1.ALTER SYSTEM
to set LOG_ARCHIVE_DUPLEX_DEST
to NULL.ALTER SYSTEM
to set LOG_ARCHIVE_DEST
to NULL.ALTER SYSTEM
to set any LOG_ARCHIVE_DEST_STATE_
n
parameters to "defer" or "enable" as required. Although enable is the default, Oracle Corporation recommends that you explicitly set a state for each destination.ALTER SYSTEM
to set at least one LOG_ARCHIVE_DEST_
n
parameter to a value specifying a local destination.ALTER SYSTEM
to set other LOG_ARCHIVE_DEST_
n
parameters as required.ALTER SYSTEM
to set LOG_ARCHIVE_MIN_SUCCEED_DEST
to the required value.For example, assume there are the following two destinations:
Both destinations are mandatory (minimum succeed destination count is 2). The new destinations are the following:
The first destination, the standby destination, and either of the backup destinations are mandatory (minimum succeed destination count is 3).
With these assumptions, issue the following SQL statements to change your old archive log destination parameters to the new ones:
ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 1; ALTER SYSTEM SET LOG_ARCHIVE_DUPLEX_DEST = ' '; ALTER SYSTEM SET LOG_ARCHIVE_DEST = ' '; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1 = 'enable'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = 'enable'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_3 = 'enable'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_4 = 'enable'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION=/oracle/dbs/arclog MANDATORY'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=stndby1 MANDATORY'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_3 = 'LOCATION=/backup/dbs/arclog OPTIONAL'; ALTER SYSTEM SET LOG_ARCHIVE_DEST_4 = 'LOCATION=/backup2/dbs/arclog OPTIONAL'; ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 3;
Complete the following steps to change back to the old archive log destination parameters:
ALTER SYSTEM
to set LOG_ARCHIVE_MIN_SUCCEED_DEST
to 1.ALTER SYSTEM
to set all LOG_ARCHIVE_DEST_
n
parameters to NULL.ALTER SYSTEM
to set the LOG_ARCHIVE_DEST
parameter to a value specifying a local destination.ALTER SYSTEM
to set the LOG_ARCHIVE_DUPLEX_DEST
parameter as required.ALTER SYSTEM
to set LOG_ARCHIVE_MIN_SUCCEED_DEST
to the required value.For example, assume there are the following two destinations:
Both destinations are mandatory. The new destinations and minimum succeed count are the same.
With these assumptions, issue the following SQL statements to change your new archive log destination parameters to the old ones:
ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 1; ALTER SYSTEM SET LOG_ARCHIVE_DEST_4 = ' '; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = ' '; ALTER SYSTEM SET LOG_ARCHIVE_DEST = '/oracle/dbs/arclog'; ALTER SYSTEM SET LOG_ARCHIVE_DUPLEX_DEST = '/backup/dbs/arclog'; ALTER SYSTEM SET LOG_ARCHIVE_MIN_SUCCEED_DEST = 2;
When you follow the procedures described previously in this section for changing your archive destination parameters, you may encounter the following error messages in your log files if archiving is enabled:
You will not encounter these errors if archiving is disabled. The errors may occur during the procedure when there are no valid archive destinations. However, when the transition in parameters is complete, the errors should cease. You should not disable archiving during the transition to avoid these errors.
The following sections list changes to static data dictionary views across different releases of Oracle:
See Also:
The "What's New in Oracle9i Database Reference" section of Oracle9i Database Reference for a list of new static data dictionary views in Oracle9i |
The following sections list static data dictionary views that have been deprecated:
The following static data dictionary views were deprecated in release 9.2:
Deprecated | In Favor Of |
---|---|
|
|
|
|
|
|
The following static data dictionary views were deprecated in release 9.0.1:
The following static data dictionary views were deprecated in release 8.1:
The following sections list static data dictionary views that have been made obsolete:
The following static data dictionary views were made obsolete in release 8.1:
|
The following sections list static data dictionary views with renamed columns:
The static data dictionary view columns listed in Table A-5 were renamed in release 9.0.1:
The following sections list static data dictionary views with dropped columns:
The following static data dictionary view columns were dropped in release 9.0.1:
Static Data Dictionary View | Dropped Columns |
---|---|
|
|
|
|
The following static data dictionary view columns were dropped in release 8.1:
Starting with release 8.1, the static data dictionary view columns listed in Table A-6 may return nulls; in previous releases, these columns could not return nulls. If an application requires non-null values for one or more of these columns, then modify the application accordingly:
The following sections list changes to dynamic performance views (V$
views) across different releases of Oracle:
See Also:
The "What's New in Oracle9i Database Reference" section of Oracle9i Database Reference for a list of new dynamic performance views in Oracle9i |
The following sections list dynamic performance views that have been deprecated:
The following dynamic performance views were deprecated in release 9.2:
Deprecated | In Favor Of |
---|---|
|
|
|
|
The following dynamic performance views were deprecated in release 9.0.1:
The following sections list dynamic performance views that have been made obsolete:
The following dynamic performance views were made obsolete in release 9.2:
|
|
|
|
The following dynamic performance views were made obsolete in release 9.0.1:
|
|
The following dynamic performance views were made obsolete in release 8.1:
|
|
|
|
The following sections list dynamic performance views with renamed columns:
The dynamic performance view columns listed in Table A-7 were renamed in release 9.2:
The dynamic performance view columns listed in Table A-8 were renamed in release 9.0.1:
Dynamic Performance View | Pre-Release 9.0.1 Column Name | Release 9.0.1 and Higher Column Name |
---|---|---|
|
|
|
The dynamic performance view columns listed in Table A-9 were renamed in release 8.1:
The following sections list dynamic performance views with dropped columns. If an application requires one or more of these columns, then modify the application accordingly:
The following dynamic performance view columns were dropped in release 9.2:
Dynamic Performance View | Dropped Columns |
---|---|
|
|
|
|
|
|
The following dynamic performance view columns were dropped in release 9.0.1:
Dynamic Performance View | Dropped Columns |
---|---|
|
|
|
|
The following dynamic performance view columns were dropped in release 8.1:
Dynamic Performance View | Dropped Columns |
---|---|
|
|
|
|
|
|
|
|
|
![]() Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|