-------------------------------------------------------------------------
Oracle8 Server
Release 8.0.5
Production
-------------------------------------------------------------------------
Copyright (C) Oracle Corporation 1993, 1998
Editor: Paul Lane
Contributing Authors: Rita Moran, Tracy Lee, Tom Portfolio, Greg
Doherty, Alan Downing, Bill Maimone, Carol Sexton, Alex Cheng, Amit
Jasuja, Sandy Venning, Richard Sarwal, Hasan Rizvi, Joyo Wijaya,
Karleen Aghevli, Juan Loaiza, Jonathan Klein, Ray Roccaforte, Connie
Dialeris, Steven Wertheimer, Debashish Chatterjee, Thomas Kurian, Ben
Chang, Shirish Puranik, Alok Pareek, Greg Pongracz
This software/documentation contains proprietary information of Oracle
Corporation; it is provided under a license agreement containing restrictions on
use and disclosure and is also protected by copyright law. Reverse engineering
of the software is prohibited.
If this software/documentation is delivered to a U.S. Government Agency of the
Department of Defense, then it is delivered with Restricted Rights and the
following legend is applicable:
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the Government is subject to restrictions as
set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical
Data and Computer Software (October 1988).
If this software/documentation is delivered to a U.S. Government Agency not
within the Department of Defense, then it is delivered with "Restricted Rights,"
as defined in FAR 52.227-14, Rights in Data - General, including Alternate III
(June 1987).
Oracle Corporation, 500 Oracle Parkway, Redwood City,
CA 94065.
The information in this document is subject to change without notice. If you
find any problems in the documentation, please report them to us in writing.
Oracle Corporation does not warrant that this document
is error free.
Oracle, CASE*Dictionary, Pro*COBOL, SQL*Connect, SQL*Forms, SQL*Loader,
SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.
CASE*Designer, CASE*Method, Net8, Oracle7, Oracle8, Oracle Call Interface,
Oracle Parallel Server, Oracle Recovery Manager, PL/SQL, Pro*C/C++,
SQL*Module, Oracle Server Manager and Trusted Oracle are trademarks of
Oracle Corporation.
All trade names referenced are the service mark, trademark, or registered
trademark of the respective manufacturer.
----------------------------------------------------------------------------
TABLE OF CONTENTS
-----------------
Introduction
------------
0.1 Purpose of this README
0.2 Cover Letter and Licensing
0.3 Oracle8 and the Oracle8 Enterprise Edition
0.4 Oracle8, Release 8.0 Production Documentation
1.0 Compatibility
1.1 GLOBAL_NAMES initialization parameter
1.2 SELECT privilege will be required on tables that users update
1.3 Date Format Strings: Stricter Behavior
1.4 Serializable = TRUE
1.5 Partition Views
1.6 Sql.bsq
1.7 Sgadef File
1.8 Shutdown Changes
1.9 Index-organized tables with Long Primary Keys
1.10 Connect Internal Desupport
1.11 2 GB File Size Limit
2.0 ROWIDs and Oracle7 Compatibility
3.0 Desupport Notification for V6 Compatibility behavior
4.0 Non-deferred linking
4.1 Single-Task Linking
5.0 PL/SQL
5.1 FIPS Flagging
5.2 Implicit Columns and Number of Columns
5.3 Inter-version RPC and Default Arguments
5.4 Oracle7 PL/SQL Compatibility Issues
5.4.1 PLSQL_V2_COMPATIBILITY Flag
5.4.2 Behavior Change Caused by Bugfix 588671
5.4.3 Behavior Change Caused by Bugfix 633704
5.4.4 Behavior Change Caused by Bugfix 491827
5.4.5 Behavior Change Caused by Bugfix 237911
5.4.6 Behavior Change Caused by Bugfix 190119
5.4.7 Behavior Change Caused By Bugfixes 235190 and 235193
5.5 UTL_REF Package
5.6 Bugs
5.6.1 Significant Known Open Bugs
5.6.2 Closed Bugs
6.0 Utilities
6.1 Sql*Loader
6.2 Export/Import
7.0 SQL Execution
7.1 Optimizer
7.2 Parallel Query Execution
7.3 Parallel DML
7.4 Closed Bug
8.0 Migration
8.1 Known Open Bug
9.0 Object SQL
9.1 Known Open Bugs
9.2 Closed Bug
10.0 Oracle Call Interface (OCI)
10.1 OCI vs SQL Access to Objects
10.2 Failover
10.3 Changes to Defining Objects of Type SQL_NTY
10.4 Closed Bugs
11.0 XA
11.1 Closed Bug
12.0 Transparent Application Failover
12.1 Known Open Bug
13.0 Advanced Queuing
14.0 Initialization Parameters
14.1 New Parameters
14.2 Fix for Bug 666391
14.3 Known Open Bug
15.0 Backup and Recovery
15.1 Recovery Manager Compatibility and Upgrade Information
15.2 New Commands and Features
15.3 Linking with Media Management Software
15.4 Recovery Manager Error Codes
15.5 Recovery Manager Bugs Fixed
15.6 Recovery Manager Enhancements
16.0 Parallel Server
16.1 Known Open Bug
17.0 Database Security
17.1 Password Management
17.2 Known Open Bug
17.3 Closed Bug
18.0 LOBs
18.1 Initializing BFILEs in Objects
18.2 Known Open Bugs
19.0 Structured Query Language (SQL)
19.1 Documentation Errata
19.2 Constraint Clause
19.3 Syntax Diagrams
19.4 Object and Lob Column Restrictions
19.5 Grant (Object Privileges) Command
19.6 Closed Bug
20.0 National Language Support
20.1 LOBs
20.2 Known Open Bugs
20.3 Closed Bugs
21.0 Replication
21.1 Interoperability
21.2 Dbms_defer_sys.copy removed
21.3 Warning
21.4 Known Open Bugs
21.5 Closed Bugs
22.0 64-Bit Issues
23.0 Types
24.0 Patch Set Bug Fixes
-----------------------------------------------------------------------------
**********************
* *
* Introduction *
* *
**********************
0.1 Purpose of this README
--------------------------
This README file is relevant only to the delivered Oracle8 Server 8.0.5
and its integral parts, such as SQL, PL/SQL, the Oracle Call Interface (OCI),
SQL*Loader, Import/Export utilities, Enterprise Manager and so on.
There are separate README files for Net8 and precompilers.
**********************************************************************
For information on upgrading, downgrading, and migration, see
READMEMIG.doc, a separate 8.0.5 readme.
THERE ARE NEW UPGRADE/DOWNGRADE SCRIPTS FOR 8.0.5. THEY ARE REQUIRED.
**********************************************************************
This README documents any differences between the server (and its
integral parts) and its documented functionality, as well as fixed
bugs, and known problems and workarounds.
Each operating system release, such as UNIX, Windows NT, DEC Open VMS,
and so on, often also provides an operating system-specific README document.
There may also be additional README files for specific Oracle products such
as SQL*Forms. This README file is provided in lieu of release notes,
system bulletins, or similar publications.
0.2 Cover Letter and Licensing
------------------------------
Please read the cover letter that may be included with your Oracle8
8.0.5 package. It may contain important information about licenses
for Oracle8 product options.
0.3 Oracle8 and the Oracle8 Enterprise Edition
-----------------------------------------------
The biggest change is that, on install, customers will be able
to install only the product(s) they have licensed, and features that are
not installed will not function.
This README contains information relating to both Oracle8 and the Oracle8
Enterprise Edition. Some of the features documented in this README are
available only if you have purchased the Oracle8 Enterprise Edition.
Furthermore, some of these features are only available if you have purchased
a particular option, such as the Objects option.
For information about the differences between Oracle8 and the Oracle8
Enterprise Edition, please refer to Getting to Know Oracle8 and the
Oracle8 Enterprise Edition.
0.4 Oracle8, Release 8.0 Production Documentation
-------------------------------------------------
The following list of books and part numbers describes the Server printed
documentation set. The part number is A58405-01.
A58495-01 Oracle8 Generic Documentation Master Index
A58424-01 Oracle8 Concepts, Release 8.0
A58232-01 Pro*COBOL Precompiler Programmer's Guide,
Release 8.0
A58233-01 Pro*C/C++ Precompiler Programmer's Guide,
Release 8.0
A58397-01 Oracle8 Administrator's Guide, Release 8.0
A58396-01 Oracle8 Backup and Recovery Guide, Release 8.0
A58425-01 Oracle8 SQL Reference(2 volume set) Release 8.0
A58244-01 Oracle8 Utilities, Release 8.0
A58243-01 Oracle8 Migration, Release 8.0
A58238-01 Oracle8 Parallel Server Concepts & Administration, Release 8.0
A58246-01 Oracle8 Tuning, Release 8.0
A58241-01 Oracle8 Application Developer's Guide, Release 8.0
A58427-01 Oracle Call Interface Programmer's Guide, Release 8.0
A58236-01 PL/SQL User's Guide and Reference, Release 8.0
A58426-01 Oracle8 Error Messages, Release 8.0
A58245-01 Oracle8 Replication, Release 8.0
A58242-01 Oracle8 Reference Manual, Release 8.0
A58247-01 Oracle8 Distributed Database Systems, Release 8.0
A54660-01 SQL*Module for Ada Programmer's Guide, Release 8.0
A58228-01 Getting to Know Oracle8 and the Oracle8
Enterprise Edition, Release 8.0
A58373-01 Legato Storage Manager Administrator's Guide
A53718-01 SQL*Plus Quick Reference
A53717-01 SQL*Plus User's Guide and Reference
The following list of books and part numbers describes the Cartridges printed
documentation set. The part number is A58422-01.
A55713-02 Oracle8 Image Cartridge User's Guide, Release 8.0.4
A53264-02 Oracle8 Spatial Cartridge User's Guide and Reference,
Release 8.0.4
A57501-01 Oracle8 Time Series Cartridge User's Guide, Release 8.0.4
A55255-02 Oracle8 Visual Information Retrieval Cartridge
User's Guide, Release 1.0.1
A58165-01 Oracle8 ConText Cartridge Administrator's Guide
A58164-01 Oracle8 ConText Cartridge Application Developer's Guide
A57700-01 Oracle8 ConText Cartridge Workbench User's Guide
A58161-01 Oracle8 ConText Cartridge QuickStart
The following list of books and part numbers describes the Networking and
Security printed documentation set. The part number
is A58423-01.
A58230-01 Oracle Net8 Administrator's Guide, Release 8.0
A58229-01 Oracle Advanced Networking Option
Administrator's Guide, Release 8.0
A54082-02 Oracle Cryptographic Toolkit Programmer's Guide
A54088-01 Oracle Security Server Guide
1.0 COMPATIBILITY
=================
This current release, as well as future releases, will have changes for
which you can prepare now; for example, to comply with future SQL ANSI
standards. If you follow these recommendations, upgrading to newer
releases of Oracle will be simplified.
1.1 GLOBAL_NAMES INITIALIZATION PARAMETER
-----------------------------------------
Recommendation-
If you use or will use distributed processing, set this parameter to
TRUE to ensure a unique identifying name for your database in a
networked environment.
1.2 SELECT privilege will be required on tables that users update
-----------------------------------------------------------------
Recommendation-
Always grant the SELECT privilege to a user or role if you grant the
UPDATE or DELETE privileges on the table. See also Oracle8 Server
Reference for more information about the initialization parameter,
SQL92_SECURITY.
1.3 DATE FORMAT STRINGS: STRICTER BEHAVIOR
-------------------------------------------
In Oracle7, a space or punctuation character in the format string
caused the corresponding character in the date string to be discarded.
This caused incorrect dates to be entered into the database since
alphanumeric characters were thrown out. In Oracle8, an error occurs
if an alphanumeric character is found in the date string when a
punctuation character or space is found in the format string, with
one exception.
Example:
TO_CHAR(TO_DATE('0297', 'MM/YY'), 'MM/YY')
Oracle7 result: 02/07
Oracle8 result: ORA-1861
Exception:
TO_CHAR(TO_DATE('1996-05-19 12:37:48.196000',
'YYYY-MM-DD HH24:MI:SS."00000"')
Oracle8.0.4 result: 1996-05-19 12:37:48
This exception will be removed in future releases.
In addition, extraneous characters at the end of the date string will
also produce an error.
For example, given the date format mask 'YYYY-MM-DD HH24:MI:SS', the following
date strings will now produce errors in O8.0.4:
'1996-12-03 00:00:00 %'
'1996-12-03 00:00:00 X'
'1996-12-03 %'
Finally, use of the TH date format string suffix, e.g., 'FMMonth ddTH',
should not result in ORA-1801 anymore.
1.4 SERIALIZABLE=TRUE
-----------------------
The init.ora parameter SERIALIZABLE=TRUE is no longer supported in Oracle8
and beyond. The default behavior henceforth is as if SERIALIZABLE was set
to FALSE. Use the SET TRANSACTION ISOLATION LEVEL SERIALIZABLE command to
Achieve similar transaction isolation behavior.
1.5 PARTITION VIEWS
-------------------
In Oracle8, partitioned tables are strongly recommended in preference to
partition views. In general, partition views should not be used and will
be desupported in Oracle Version 9.
Guidelines for creating and maintaining partitioning views:
-----------------------------------------------------------
To use partition views, the PARTITION_VIEW_ENABLED
parameter must be set.
DDL commands must be issued separately for each underlying
table.
For example, to add an index to a partition view, you must add indexes to all
underlying tables. To analyze a partition view, you must analyze all underlying
tables. However, you can submit operations on each
partition in parallel.
Administrative operations must be performed as operations on the underlying
tables of the partition view, not on the partition
view itself.
For example, a split operation consists of either one or two CREATE TABLE AS
SELECT operations (one if the split is 'in place'), followed by a redefining of
the partition view's view text.
You can create referential integrity constraints on underlying tables, but for the
constraints to be true for the partition view, the primary key must contain the
partition column.
Similarly, you can have a unique index on underlying tables, but for uniqueness
to be true for the partition view, the partition column must be contained in the
unique index. You can have only one unique index.
Every partition has its own index, so any index lookup must be done in all indexes
for partitions that are not skipped.
A partition view cannot be the target of a DML statement.
Partition views do not support concatenated partitioning
keys.
SQL*Loader does not support partition views.
1.6 SQL.BSQ
-----------
For performance reasons, due to the large number of objects in a typical
installation, some customers have noticed performance improvements by
making modifications to sql.bsq before installation. An example of this is
increasing initial extents. Do not do this as it may jeopardize
customer supportability.
1.7 SGADEF FILE
---------------
The contents of this file have been deleted, but the file remains since
its existence is needed for purposes that have never been documented.
It is targeted for obsolescence in the 8.1 release.
1.8 SHUTDOWN CHANGES
--------------------
Processes are now killed during shutdown; consequently, the error(s)
returned to users will be different.
1.9 INDEX-ORGANIZED TABLES WITH LONG PRIMARY KEYS
-------------------------------------------------
Beginning with 8.0.5, index-organized tables with long primary keys
(e.g., > 4000 bytes) will not be allowed.
1.10 CONNECT INTERNAL DESUPPORT
-------------------------------
CONNECT INTERNAL is currently supported for backwards compatibility only.
It will be completely desupported in the first maintenance release after
Oracle 8.1, so that the CONNECT INTERNAL may no longer be used to connect to
Oracle. If you have not done so already, you should plan to migrate your
applications to use other connection syntax. See the Oracle8 Administrator's
Guide for further details.
1.11 2 GB FILE SIZE LIMIT
-------------------------
Oracle 8.0.4 is capable of accessing large files, subject to
Operating System dependencies. These dependencies can be
categorized as:
- file size: is the file size greater than 2 GBytes?
- file mode: is the file a file system file or a raw device file?
Many flavors of Unix support greater than 2 GBytes
file size only on raw devices.
- asynchronous IO: Does the OS supports asynchronous IO on files
for both, raw and file system files?
Is asynchronous IO supported for files that are greater
than 2 GBytes?
- OS revision: The OS release number. For example, in Solaris 2.5.1,
file size of greater than 2 GBytes is supported only on
raw devices. However, in Solaris 2.6, both raw and file systems
files can be greater than 2 GBytes.
- OS IO subsystem issues: As support for files greater than 2 GBytes
is fairly recent, many disk arrays or IO subsystems need
firmware upgrades to support large files. It is important
to determine from the OS vendor what firmware patches need to be
present for large file support.
It is very important to ascertain that the above OS dependencies
are checked before using files that are greater than 2 GBytes.
2.0 ROWIDs and Oracle7 Compatibility
====================================
Oracle8 is capable of addressing much larger databases than Oracle7.
This increased capability has imposed a limitation on the use of ROWIDs
in client applications that could influence Oracle7 applications'
compatibility with Oracle8.
The size of a ROWID, stored in either external binary format (datatype 11)
or a CHAR buffer, has not changed in Oracle8, therefore, the size and
datatypes of host variables used to hold Oracle8 ROWIDs has not changed.
Applications that employ ROWIDs to fetch rows from the database will be
compatible with Oracle8 as long as the ROWIDs are obtained from the
server and are otherwise unmodified.
However, in order to address a larger number of rows commensurate with
larger databases, the encoding scheme for ROWIDs has changed. When
fetching Oracle7 ROWIDs into CHAR datatype buffers it was possible to
interpret the string of digits as 'BBBBBBBB.SSSS.FFFF' (Block.Slot.File).
This interpretation no longer works under Oracle8. Oracle8 ROWIDs must
be treated as opaque data items whose constituent elements cannot be
accessed directly. Any applications that attempt to interpret or construct
ROWID contents will fail.
A number of functions have been provided to adapt your applications to
Oracle8. The DBMSUTIL.SQL script contains a PL/SQL package, DBMS_ROWID
that provides an API for constructing and extracting information elements
from an Oracle8 ROWID. Consult the documentation for the PL/SQL package
for more information.
Also note that, since Oracle8 ROWIDs are encoded differently from
Oracle7, any ROWIDs used by your applications that are fetched from and
stored in your Oracle7 database (for example, in CHAR or VARCHAR2
columns of tables), must be transformed to Oracle8 format. The
DBMS_ROWID package contains procedures for transforming stored Oracle7
ROWIDs to Oracle8 ROWID format. This must be done after migration to
Oracle8 8.0.3 has been successfully completed, but before applications
that depend on stored ROWIDs are run.
All indexes on ROWID columns must be dropped before
migration.
When an Oracle7 client attempts to perform operations which rely on
ROWID structure, it usually results in errors. Following are known
examples of the problem:
1. INSERT AS SELECT and CREATE AS SELECT ROWID FROM <Oracle8>.table
into <Oracle7>.table.
2. JOIN of ROWID column of Oracle8 table and Oracle7 table.
3. Fast refresh of Oracle8 master and Oracle7 snapshot.
3.0 Desupport Notification for V6 Compatibility behavior
========================================================
With Oracle7, Oracle offered a Version 6 [V6] Compatibility flag that allowed
application developers developing Oracle7 applications to emulate Oracle6
behavior. With the release of Oracle8.0.3, users are cautioned that the
Version 6 compatibility flag is being desupported effective immediately in all
of the Oracle8 products including PL/SQL8, all the Oracle Precompilers, the
Oracle8 Oracle Call Interface, SQL*Module, and SQL*PLUS. The desupport of the
V6 compatibility flag is consistent with Oracle's policy of supporting
backwards compatibility and behavior from one version release upgrade to
another, ie, from Oracle6 to Oracle7 but not for more than one version release
upgrade.
Users who do not absolutely need to maintain V6 behavior are encouraged to
upgrade their Oracle7 clients to Oracle8. Users who absolutely need to
continue to emulate V6 behavior for certain applications need to maintain one
$ORACLE_HOME with an Oracle7 client for those applications. They can create a
separate $ORACLE_HOME with an Oracle8 client for those applications for which
they do not need V6 behavior.
Specifically, the V6 Compatibility flag emulated the following aspects of
Oracle6 behavior with Oracle7:
- String literals are fixed length in Oracle7 but are treated as variable
length with the V6 flag
- PL/SQL Local char variables are fixed length in Oracle7 but are treated as
variable length with the V6 flag
- Return value of SQL Functions (e.g. USER) are fixed length characters in
Oracle7 but are treated as variable length characters with the V6 flag
- Select/Fetch of a NULL with no indicator raises an ORA-1405 error with
Oracle7 but returns no error with the V6 flag
- SQL group function is called at FETCH time with Oracle7 but is called query
execution time with the V6 flag
- Describe of a fixed length string returns Type=96 with Oracle7 but returns
Type=1 with the V6 flag
All of these behaviors are being desupported with the desupport of the V6
Compatibility Flag with Oracle8.
4.0 NON-DEFERRED LINKING
========================
Application developers are cautioned that Oracle plans to desupport
non-deferred mode linking beginning with the release of Oracle9 (it will
continue to be supported with all the releases of Oracle8). Recognizing these
plans, application developers should no longer use non-deferred mode linking
in developing new applications. Currently, Oracle supports two linking modes:
1. Non-deferred linking: The Version 6 OCI (client) only supported
non-deferred linking which meant that for each SQL statement, a parse, a bind
and a define call were each executed separately with individual round trips
between the client and the server. This significantly increased network
traffic between the client and the server and reduced both the performance and
scalability of OCI applications.
2. Deferred linking: Unlike the Version 6 OCI, the Version 7 OCI supports
both non-deferred linking and deferred linking. Deferred mode linking
essentially defers the bind and define steps until the statement executes -
that is it automatically bundles and defers the bind and define calls to
execution time. Further, when the application is linked with deferred mode and
a special parsing call is used (the OPARSE call with the DEFFLG set to a
non-zero value), even the parse call can be deferred to execution time. Note
that deferred mode linking does not depend on the specific OCI calls that the
application uses, only on the link option that is selected.
Deferred mode linking therefore significantly reduces the number of round
trips between the client and the server and as a result improves the
performance and scalability of OCI applications. The default behavior of
Version 7 OCI connected to the Oracle7 server is deferred mode linking.
However, Version 7 OCI also supports non-deferred linking by setting specific
link time options.
Further, Version 8 OCI has two types of calls: first, all the Version 7 OCI
calls are supported with Version 8 OCI, ie, they will work with a Version 8
OCI client by relinking the version 8 OCI libraries. Second, there are
additional Version 8-specific OCI calls. The default mode with the first type
of calls continues to be deferred mode linking; however, non-deferred mode
linking is supported for these calls through all releases of Oracle8 by
setting link time options. However, Version 8-specific calls use a different
paradigm and as a result non-deferred mode linking is not necessary.
The various combinations of client side libraries and server with which
non-deferred linking is currently supported are summarized below:
Server *****************************************************************
* * Default: * Default: * * *
* Not * deferred * deferred * Not * Not *
Oracle9 * supported * Non- * Non- * supported * supported *
* * deferred * deferred * * *
* * supported * supported * * *
*****************************************************************
* * Default: * Default: * * *
* Not * deferred * deferred * Not * Not *
Oracle8 * supported * Non- * Non- * supported * supported *
* * deferred * deferred * * *
* * supported * supported * * *
*****************************************************************
* * Default: * Default: * * *
* Non- * deferred * deferred * Not * Not *
Oracle7 * deferred * Non- * Non- * supported * supported *
* mode only * deferred * deferred * * *
* * supported * supported * * *
*****************************************************************
* * Default: * * * *
* Non- * deferred * Not * Not * Not *
Oracle * deferred * Non- * supported * supported * supported *
Version6 * mode only * deferred * * * *
* * supported * * * *
*****************************************************************
OCIv6 OCIv7 OCIv8 OCIv8 OCIv9
(v7 calls) (v8 calls)
Client side libraries
Oracle will continue to support deferred-mode linking with all the releases of
Oracle8 (all 8.* releases). This has the following implications:
Applications using Version 6 OCI libraries
Since the Version 6 OCI library is not supported against the Oracle8 database,
applications using the Version 6 library cannot be run against an Oracle8
database.
Applications using Version 7 OCI libraries
Applications using Version 7 OCI libraries can run in two configurations
against an Oracle8 database:
1. They can be run with Version 7 OCI libraries against an Oracle8 database in
non-deferred mode provided link time options are set appropriately.
2. They can also be relinked with the Version 8 OCI libraries and run in
non-deferred mode provided link time options are set appropriately.
Oracle will support the first configuration through all the releases of
Oracle8. However, the second configuration will not be supported in Oracle9.
Therefore, applications that require non-deferred linking will not be able to
upgrade to Oracle9 client-side libraries.
Applications using Version 8 OCI libraries
Applications using Version 8 specific OCI calls, such as those used to access
Oracle8's object types, do not need to use non-deferred mode linking since the
Version 8 OCI uses a different paradigm. Applications using only Version 7 OCI
calls will be able to use non-deferred mode linking but only through Oracle8.1
4.1 Single-task linking
-----------------------
Single-task linking is a feature used by a limited number of Oracle's
customers primarily on the OpenVMS platform. Application developers are
cautioned that Oracle will continue to support single-task linking with all
the releases of Oracle8 (all 8.* releases) but will desupport it beginning
with the first release after Oracle8.
With single-task linking, Oracle supports two configurations to link Oracle
products and user-written applications against the Oracle database:
1. Single-task linking: In this case, applications are directly linked against
the Oracle shareable image making single-task connection to Oracle
2. Two-task linking: In this case, applications linked in a standalone
configuration can only connect to Oracle using SQL*Net's two task drivers such
as SQL*Net DECnet or SQL*Net VMS Mailbox on the OpenVMS platform. This is the
typical configuration used in the large majority of client-server
applications. With two task linking applications and tools connect with the
Oracle7 database through a programmatic interface that creates a shadow
process for each user process. This shadow process runs a copy of the Oracle
shareable image on behalf of the user process using SQL*Net protocols to
communicate between the user and shadow processes. Therefore, with this
interface, user routines that invoke the Oracle7 Server functions run as one
process or task, and the Oracle7 routines that execute these functions run as
the second task.
Oracle will continue to support single-task linking with all the releases of
Oracle8 (all 8.* releases) but will desupport it beginning with the first
release after Oracle8. Application developers who would like to use
single-task linking to run their applications will not be able to do so
against the first server release after Oracle8.
5.0 PL/SQL
==========
5.1 FIPS FLAGGING
-----------------
FIPS flagging on non-compliant SQL introduced in Oracle8 is not supported
in the 8.0.3 (or higher) release of PL/SQL.
5.2 IMPLICIT COLUMNS AND NUMBER OF COLUMNS
------------------------------------------
Tables containing Row Objects (Object tables) or Column Objects also
have a 1000 column limit. Oracle creates a column for every leaf-level, scalar
attribute of an object type. Additionally, Oracle creates implicit columns for
storing the system-generated Object Identifier for a row object, and a Nested
Table Identifier for a Nested Table column. Therefore, the number of
leaf-level attributes in an object type used to create an object table must
be less than 1000.
5.3 INTER-VERSION RPC AND DEFAULT ARGUMENTS
-------------------------------------------
Function and procedure calls that are from a server to a second server
running a different version of Oracle, and using defaulted argument
values, may have problems. Customer-visible symptoms may vary
depending upon the source code involved; PLS-801[1411] and
PLS-801[1407] are quite likely, but other symptoms including silently
wrong results are possible. The suggested workaround is to provide an
explicit value for each argument on any call through a database link
if it is possible that the sending and receiving systems are running
different versions of Oracle.
5.4 ORACLE7 PL/SQL COMPATIBILITY ISSUES
---------------------------------------
5.4.1 PLSQL_V2_COMPATIBILITY FLAG
---------------------------------
A few new errors have been added in Oracle 8 for illegal syntax. However,
since there may be existing code that depends on the pl/sql compiler
accepting the illegal syntax, a flag, PLSQL_V2_COMPATIBILITY, is available
to disable the new errors. Please see the Oracle8 Migration Guide for more
information on this flag.
5.4.2 Behavior Change Caused by Bugfix 588671 After Upgrading to PL/SQL
8.0.5 or Any Higher Release from PL/SQL 8.0.4 or any lower release:
-------------------------------------------------------------------------
PL/SQL releases before 8.0.5 would incorrectly ignore the second, collation
sequence parameter to NLSSORT. This parameter is now correctly utilized.
Should you want to preserve the incorrect behavior that existed prior to PL/SQL
8.0.5, you may do so: contact Oracle Worldwide Customer
Support for assistance.
5.4.3 Behavior Change Caused by Bugfix 633704 After Upgrading to PL/SQL
8.0.5 or Any Higher Release from either PL/SQL 8.0.3 or 8.0.4;
-------------------------------------------------------------------
For assignments involving records declared using %rowtype (including records
that appear as cursor loop variables since these are implicitly declared
using %rowtype), PL/SQL needs to perform constraint checking on the individual
fields. Similarly, constraint checking needs to be performed when passing
such records as IN OUT or OUT parameters. Doing the checking would constitute
correct behavior.
These constraints were correctly being checked in PL/SQL 7.3.4.
However, because of a bug (see 633704) that was introduced in PL/SQL 8.0.3
and 8.0.4, these checks stopped being performed; this was a regression in
runtime behavior (constraint violations that were reported and possibly
caught in exception handlers in 7.3 were missed in PL/SQL 8.0.3 and 8.0.4).
This bug has now been fixed in PL/SQL 8.0.5; thus the constraints will be
enforced in PL/SQL 8.0.5 as well as future versions.
Note that assignments and parameters involving only named records
are strongly type-checked and thus don't pose this
problem.
To correct this, you have two options:
1) Fix your code so that you do not depend upon the previous, incorrect
behavior.
2) A backout event has been added which can be used to preserve the incorrect
PL/SQL 8.0.3 and 8.0.4 behavior. Contact Oracle Worldwide Customer Support
for assistance.
5.4.4 Behavior Change Caused by Bugfix 491827 After Upgrading to PL/SQL
8.0.4 or Any Higher Release from 8.0.3 or Any Lower Release
-----------------------------------------------------------------------
PL/SQL 8.0.3 and lower releases would not issue compile-time error messages
when IN was used inappropriately in expressions. In an expression of the
form "x IN y", the compiler would completely ignore the "IN y" part of
the expression.
Corrective Action:
If you have such incorrect usage, you must recode your program to fix the
error. In the above example, you would need to recode your program as follows:
DECLARE
bar number;
BEGIN
--foo(bar IN number); -- Incorrect!
foo(bar);
END;
5.4.5 Behavior Change Caused by Bugfix 237911 After Upgrading to PL/SQL
2.1.5 or Any Higher Release from 2.1.4 or Any Lower Release
-----------------------------------------------------------------------
The PL/SQL compiler must check that the elements of the INTO-target
list of a select statement or cursor fetch statement are assignable and
report errors PLS-00363 or PLS-00403 if they are not assignable. PL/SQL
2.1.4 and earlier releases failed to correctly check the assignability
of all but the last element in the INTO-target list of select and fetch
statements.
Corrective Action:
In 8.0.3 (or higher) releases you will need to fix the PL/SQL code.
Decide carefully if your procedure should use IN parameter
or an IN OUT parameter.
In prior releases, there was an backout event available to disable
bugfix 237911, but this event has been obsoleted as of PL/SQL 8.0.3.
5.4.6 Behavior Change Caused by Bugfix 190119 After Upgrading To PL/SQL
2.1.6 or Any Higher Release from PL/SQL 2.1.5 or Any Lower Release
-----------------------------------------------------------------------
The "end" identifier that is optional at the end of a package,
procedure or function must match the name of the entity it ends; if
there is a mismatch, the compiler must report error PLS-00113. PL/SQL
2.1.5 and lower versions did not report any errors if the identifiers
did not match.
You have two options:
a) If you are in a position to fix the PL/SQL code:
Fix the "end" identifier so that it matches or remove it and
recompile your procedure.
b) If fixing the PL/SQL code is not an option and you are running
2.2 or any higher release, then contact Oracle Worldwide Customer Support
for assistance in backing out this bug fix.
5.4.7 Behavior Change Caused by Bugfixes 235190 and 235193
After Upgrading to PL/SQL 2.1.6 or Any Higher Release
from PL/QL 2.1.5 or Any Lower Release
-----------------------------------------------------------
The PL/SQL compiler must flag multiple incomplete (forward) type
declarations for the same type with error PLS-00105. It must also
flag incomplete types that are not completed within the same compilation
unit (stored PL/SQL procedure/package/function) with error PLS-00311.
PL/SQL 2.1.5 and earlier releases failed to flag these errors
(see bugs 235190 and 235193). PL/SQL 2.1.6 and higher releases
now correctly flag these errors. However, because of this combination
of errors, certain PL/SQL programs that previously compiled without
errors will now compile with either error PLS-00105 or PLS-00311.
To correct this, you have two options:
a) If you are in a position to fix the PL/SQL code:
Remove all but one of the incomplete type-declarations and recompile the
procedure.
b) If fixing the PL/SQL code is not an option, and if you are running 2.2
or any higher release, then contact Oracle Worldwide Customer Support for
assistance in backing out this bug fix.
5.5 UTL_REF PACKAGE
-------------------
Oracle 8.0 supports user-defined composite type or object type. An instance
of an object type is called an object. An object type can be used as the type
of a column or the type of a table. In the latter case, each row of the table
is an object. This kind of table is called an object table.
An object stored in an object table can be identified by an object identifier.
A reference is a persistent pointer to an object, and each reference can
contain an object identifier. A reference allows a program to locate an object
without knowing the name of the object table. The UTL_REF package allows a
PL/SQL program to access an object by providing a reference to the object.
OPERATIONS
----------
The operations supported in the UTL_REF package are:
- SELECT an object given a reference
- LOCK an object given a reference
- SELECT and LOCK an object given a reference
- UPDATE an object given a reference
- DELETE an object given a reference
SECURITY
--------
The UTL_REF package can be used from anonymous PL/SQL blocks and stored PL/SQL
procedures on the server. When invoked, it will run with the invoker's
privileges since it needs to check if the invoker of this package has the
appropriate privileges to access object referenced to by the given REF.
Thus, if UTL_REF package is defined under user SYS and user A invokes
UTL_REF.SELECT to select an object from a reference, the privileges to check
for are those of A (the invoker).
EXCEPTIONS
----------
Exceptions can be returned during execution of UTL_REF package functions for
various reasons. For example, the following scenarios would result in
exceptions.
* The object that is being selected does not exist. The possible causes are
The object has been deleted. The given reference is dangling (invalid).
* The object table does not exist. The object table may have been dropped.
* The object cannot be modified or locked in a serializable transaction.
The object may have been modified by another transaction after the
serializable transaction has started.
* The user does not have the privilege to select or modify the object.
The caller of the UTL_REF routine must have the proper privilege on the
object that is being selected or modified.
The package does not define any named exceptions though. The caller of the
package may define exception handling blocks to catch specific exceptions and
handle them appropriately.
PACKAGE ROUTINES
----------------
SELECT_OBJECT procedure
-----------------------
SYNTAX
PROCEDURE SELECT_OBJECT (reference IN REF "<typename>",
object IN OUT "<typename>");
DESCRIPTION
This procedure selects an object given its reference. The selected
object is retrieved from the database and its value is put into the
PLSQL variable 'object'. The semantic of this routine is similar to
the following SQL statement:
SELECT VALUE(t)
INTO object
FROM object_table t
WHERE REF(t) = reference;
Unlike the above SQL statement, this routine does not require the
caller to specify the object table where the object resides.
LOCK_OBJECT procedure
---------------------
SYNTAX
PROCEDURE LOCK_OBJECT (reference IN REF "<typename>");
PROCEDURE LOCK_OBJECT (reference IN REF "<typename>",
object IN OUT "<typename>");
DESCRIPTION
This procedure locks an object given a reference. In addition, this
procedure allows the program to select the locked object. The semantic
of this routine is similar to the following SQL statement:
SELECT VALUE(t)
INTO object
FROM object_table t
WHERE REF(t) = reference
FOR UPDATE;
Unlike the above SQL statement, this routine does not require the
caller to specify the object table where the object resides.
It is not necessary to lock an object before updating/deleting it.
UPDATE_OBJECT procedure
-----------------------
SYNTAX
PROCEDURE UPDATE_OBJECT (reference IN REF "<typename>",
object IN "<typename>");
DESCRIPTION
This procedure updates an object given a reference. The referenced
object is updated with the value contained in the PLSQL variable
'object'. The semantic of this routine is similar to the following SQL
statement:
UPDATE object_table t
SET VALUE(t) = object
WHERE REF(t) = reference;
Unlike the above SQL statement, this routine does not require the
caller to specify the object table where the object resides.
DELETE_OBJECT procedure
-----------------------
SYNTAX
PROCEDURE DELETE_OBJECT (reference IN REF "<typename>");
DESCRIPTION
This procedure deletes an object given a reference. The semantic of
this routine is similar to the following SQL statement:
DELETE FROM object_table
WHERE REF(t) = reference;
Unlike the above SQL statement, this routine does not require the
caller to specify the object table where the object resides.
5.6 BUGS
---------
5.6.1 SIGNIFICANT KNOWN OPEN BUGS
---------------------------------
409391 If you try to declare a set of mutually-dependent types, where one of
the types has a REF reference to a second as-yet-undeclared type,
followed by a second reference to the same second as-yet-undeclared
type, and you then try to declare this second type such that this has a
non-REF reference to the first type, you would encounter an
ORA-600 [17069].
479400 PLS-103 when a remote procedure is called and the dblink contains the
identifier 'at'.
488295 SQL does not support references to pl/sql "collection methods"
(eg: COUNT, FIRST, LAST, EXISTS, PRIOR, NEXT, DELETE, LIMIT, TRIM,
EXTEND) on a collection-type column or attribute inside a SQL DML
statement.
494722 When remote_dependencies_mode = signature, PL/SQL RPC should
treat a change from record of index-table to record of nested table or
record of varray as an invalid change, but
does not do so.
503250 Cursor with 'union all' produces incorrect
results.
508327 Error, if we call a remote method from client side, outside SQL or
pro*c from client side.
559641 SQLCHECK=FULL DOESN'T CHECK THE "FOR
UPDATE OF" CLAUSE
562576 PL/SQL disallows the use of concatenation (|) (and presumably dblinks)
(@) when these characters are at a different code point in the
execution and compiler character sets.
573309 Utl_http cannot be used with utl_file on server
side.
590252 For functions with certain kinds of return types the function name
cannot be used as a scope qualifier in an
l-value position.
625396 If an ADT method defined in one schema is called in some other schema
works now.
642079 Do not constrain "real" types in PL/SQL. The usage is inconsistent
with SQL which does not allow "real" to be constrained. Also, it
produces unexpected constraint behavior where legal. A "real" is
a "float(63)" and should not be
reconstrained.
5.6.2 CLOSED BUGS
-----------------
This section lists some of the key bugs that were fixed in 8.0.5.
232407 Character bind variables into PL/SQL blocks are sometimes assumed to
have an incorrect length, thus certain SQL operations fail.
415613 PL/SQL (version 2 and above) allows a NULL argument to match a formal
with a record type during overloading (a change in behavior from
version 1).
472022 Cursor defined as a union in parenthesis core
dumps pl/sql compiler.
491959 The bug was due to incorrect argument in TABLE expression inside the
THE subquery. It has nothing to do with THE
itself.
491966 Comparing inner table column against outer table column in a query
from PL/SQL will cause an internal error.
493214 Client-side DESCRIBE does not handle some
cases correctly.
547255 Table Subexpression did not allow aliases to be defined for it.
This had resulted many query expression unusable.
549674 Use of bind variables with length > 32767
results in PLS-801 [20633].
557667 If an ALTER TYPE (w/ REPLACE option) statement has a PL/SQL compilation
error, this DDL statement is aborted and an ORA-2342 error is issued.
However, because the DDL is aborted and the original schema object for
the type is kept, the PL/SQL errors get lost and are neither displayed
nor are available through SHOW ERRORS.
571574 PL/SQL does not detect cases where there are more
PL/SQL formals than C parameters in an external
procedure.
587122 PL/SQL does not distinguish between FLOAT and NUMBER within a
collection or object. SQL does. Customers should probably avoid use
of NUMBER subtypes in collections/objects if they are referenced by
both SQL and PL/SQL.
592256 Re-raised EXCEPTION's message missing if any
nested exceptions
595316 Now, one can use :new.collection(index).field
and it will be marked correctly as out bind.
603292 Extend VARRAY beyond 32770 gives ORA-6532
603556 For weakly typed REF CURSOR's, numeric constraints on the INTO
list targets of the FETCH statement is not being enforced.
The fix is to the PL/SQL compiler. So the offending PL/SQL modules
should be recompiled.
603789 CANNOT INSERT DBCS KO16TSTSET CHARACTERS IN
PL/SQL BLOCK
608809 7445 WHEN UNION IN FROM CLAUSE
610464 The NOT NULL constraints on REF, LOB and Object variables are not
enforced.
615032 Extproc.c failed to compile because it didn't
#include time.h.
616870 Sysdate means server-side time. On the client-side we should
go to the server to get the time, implying a connection
must be present.
617560 Problem: "return x in (1,2);" or "return x between 1 and 4;" resulted
in a compiler internal error.
621055 Nested tables and varrays in Pro*C can only be passed to PL/SQL
routines that have formal arguments of exactly the same type. Only 'C'
host arrays can be coerced to PL/SQL index-by tables. No other
coercions are supported. Previous versions
did not report this error.
621959 Parameter type matching did not raise error on different %ROWTYPEs:
SELECT NULL AS ALIAS_NAME was treated as structurally equivalent of
SELECT COLUMN_NAME AS ALIAS_NAME
637175 Calling a remote callout function results
in a internal error.
638951 If the external library name in the external clause is not the name
of a valid alias library, the compiler gives
an internal error.
639684 When an Object type is created with zero data attributes a compile-
error should be given. This is the documented behavior in the PL/SQL
manual.
652239 A slow memory leak, especially problematic for long-running users not
cycling their UGA (eg, sescachesz > 0).
6.0 UTILIIES
============
6.1 SQL*LOADER
--------------
KNOWN OPEN BUGS
---------------
BUG 571751
Duplicate rows are loaded, but the index enforcing the constraint is
put into index unusable state. It is necessary to disable the constraint,
re-enable the constraint and filter out the duplicates.
BUG 525134
SQL*Loader returns an error when using OS authentication on a remote
procedural call.
BUG 561983
When processing a variable data file using the "VAR" option such that
each record starts with the 5 length bytes, if a record is rejected when
it is written to a bad file, the length bytes are not included, meaning
a) a new control file is needed to load the correct records or
b) the data contains linefeeds and you cannot load
it.
6.2 EXPORT/IMPORT
-----------------
KNOWN OPEN BUGS
---------------
BUG 574664
Create snapshot DDL is incorrect when exporting snapshot of another user
in user mode. The import of the snapshot returns an error. The
workaround is to do the export as the user.
BUG 573946
Export should create unique and primary keys enabled , rather than the two
step enable novalidate then enable, when the index is unique. Unique
indexes are physically incapable of storing duplicates, so the novalidate
state is effectively ignored in this case. This cannot be changed as long
as export depends on unique indexes by ENABLE NOVALIDATE
constraints.
CLOSED BUGS
-----------
374124
If a procedure referenced a private database link and a user mode export was
done by a DBA, when imported into another user, the following resulted:
ORA 4054: DATABASE LINK DOES NOT EXIST.
eg: USERX creates a private database link 'mylink'. Next he creates a
procedure 'foo' which refers to this db link 'mylink'.
Next a DBA exports user USERX.
On importing this file into USERY's schema, ORA 4054 resulted.
Workaround was to have the user perform his own export; i.e, let USERX
do a user level export. If the DBA must export the user, then
the database link should be created by the DBA.
398641
If a user with DBA privileges did a table level export
in which the tables belonged to other users as well as to
himself, and if the last table specified in the TABLES parameter
belonged to the DBA, then referential constraints, triggers and
bitmap indexes on tables other than those belonging to the user
performing the export would not get exported.
eg: USERX has DBA privileges and he performs the following export:
exp USERX/USERX file = a.dmp TABLES=scott.emp, scott.dept, USERX.test
This would result in any referential constraints, triggers and bitmap indexes
on tables scott.emp and scott.dept NOT being exported.
Workaround was to specify the last table in the TABLES list as one not
belonging to the user doing the export.
eg: exp USERX/USERX TABLES=USERX.test, scott.emp,
scott.dept
566692
Import failed to create certain users and their schema objects during
a full import operation. This occurred if the person running the import
had a connect id which prefixed those of users in
the database.
560276
Import of trigger where the trigger name was case sensitive
would fail for the ALTER TRIGGER enable statement.
606078
Export of the rows of a non-scalar nested table would
always fail.
7.0 SQL EXECUTION
=================
7.1 OPTIMIZER
-------------
OPEN BUG
--------
BUG 598861
Selecting from a view created from a union of two other views based on
joined tables will not work. The query will crash
or fail.
CLOSED BUG
----------
Bug 610010
A query using bit-mapped indexes returned no rows under "first_rows"
optimization, for example:
SQL> SELECT /*+ first_rows+/job from
emp where job like 'PRESIDENT';R
no rows selected
7.2 PARALLEL QUERY EXECUTION
----------------------------
CLOSED BUG
----------
BUG 490790
CREATE INDEX with NOSORT and PARALLEL raised an internal error
ORA-600, which resulted in ORA-12801.
7.3 PARALLEL DML
----------------
OPEN BUG
--------
Bug 640481
When attempting to perform a parallel update through a join view
where the SET clause accesses more than one table. Specifically:
- The update is performed through a join view.
- Parallelism is turned on for the update and/or the underlying scans
in the view
- The SET clause uses two or more tables.
Such update-set examples are common for refreshes using inline views
in datawarehousing applications. If the SET statement only accesses
one table then the parallel update will still work correctly.
Example: To update the salary field of emp using fresh data from
newemp.
update /*+ PARALLEL(JN, 2) */
(
select
newemp.salary new_salary
emp.salary old_salary
from emp, newemp
where emp.empno = newemp.empno
) JN
set
old_salary = new_salary;
Effect
------
The update will fail and the parallel slaves will return error ORA-1407.
Workaround
----------
Force the update and all scans in the view to run in serial mode.
7.4 CLOSED BUG
--------------
Bug 605809
An insert or update to a foreign table resulted in ORA-2291 when primary key
value existed if there was a reverse index on primary
key.
8.0 MIGRATION
=============
This section is now a separate readme, READMEMIG.doc. It can be
found in ?/rdbms/admin. There are new upgrade/downgrade scripts for
8.0.5. THEY ARE REQUIRED.
8.1 KNOWN OPEN BUG AND ITS WORKAROUND
-------------------------------------
Bug 602979
This only applies to you if you are attempting to
migrate Oracle 8.0.3 database files to Oracle 8.0.4 or
a later version AND
you have:
1. Created a 8.0.3 database where data files and/or control file are
created with the REUSE clause. AND
The database was created with initialization parameter
DB_BLOCK_SIZE that is smaller than the one that was
used to previously create the data files and/or control file.
2. OR, you have added a file with the REUSE option to an
existing 8.0.3 database, where the file was originally
created with a DB_BLOCK_SIZE that was larger than the
one used by the current database.
For example, if Sue had created a Oracle 8.0.3 database
with DB_BLOCK_SIZE = 8192:
create database newtest
controlfile reuse
datafile '/vobs/oracle/dbs/t_db1.f' size 32M
logfile '/vobs/oracle/dbs/t_log1.f' size 10M,
'/vobs/oracle/dbs/t_log2.f' size 10M
maxinstances 1
maxdatafiles 1022
maxlogfiles 20
maxlogmembers 3
maxarchlogs 0
;
But, she really wanted to create the database with
DB_BLOCK_SIZE = 2048. So she did the following:
create database newtest
controlfile reuse
datafile '/vobs/oracle/dbs/t_db1.f' size 32M reuse
logfile '/vobs/oracle/dbs/t_log1.f' size 10M reuse,
'/vobs/oracle/dbs/t_log2.f' size 10M reuse
maxinstances 1
maxdatafiles 1022
maxlogfiles 20
maxlogmembers 3
maxarchlogs 0
;
Sue will have problem migrating these database files to Oracle 8.0.4.
If Sue had run the DBVERIFY utility on her files, she would
have seen errors like:
dlsun227> dbv file=nt_cf1.f
DBVERIFY: Release 8.0.3.2.0 - Production on Sun
Jan 25 19:51:49 1998
(c) Copyright 1997 Oracle Corporation. All rights
reserved.
DBV-00103: Specified BLOCKSIZE (2048) differs
from actual (8192)
If Sue were to attempt bringing up a 8.0.4 Oracle with these
files she would see:
SVRMGR> startup pfile=t_init1.ora
ORACLE instance started.
Total System Global Area 13412420 bytes
Fixed Size 47172 bytes
Variable-Size 12414976 bytes
Database Buffers 417792 bytes
Redo Buffers 532480 bytes
Total System Global Area 13373440 bytes
Lock Manager 8192 bytes
Variable-Size 12414976 bytes
Database Buffers 417792 bytes
Redo Buffers 532480 bytes
ORA-00227: corrupt block detected in controlfile: (block 1, # blocks 1)
ORA-00202: controlfile: '/vobs/oracle/dbs/nt_cf1.f'
SVRMGR>
Note, if she had recreated the database with DB_BLOCK_SIZE = 16384
instead (i.e. used a larger DB_BLOCK_SIZE parameter), she would
not have had any problems in migrating to Oracle
8.0.4.
If the above applies to you, you will not be able to migrate
to Oracle 8.0.4, unless you run dbfmig standalone utility
on your files.
After sanitizing the files, you should run dbv (DBVERIFY)
utility to insure that the file has been migrated properly.
Note for field support personnel:
1. It is very important the customer keeps backup copies
of all files that are to be migrated. This utility
does not recover from crashes.
2. The utility applies only to those platforms that has
OSD specific block (or block 0). Typically, this is
done in UNIX platforms.
3. This is a 32-bit utility, that has been written for Solaris.
Porting groups please test this before releasing for
your platform.
4. Any Oracle Database files created in version 7.x or 8.0.4
or later, does not need to use this utility.
Usage Note:
==========
dbfmig -i <input file name > [-o output file name]
[-p current block size]
[-b new block size]
-i Fully qualified input file name. This is the file
that needs its OSD header block (block 0)
to be fixed.
-o Fully qualified output file name. This is an optional
parameter. If the output file name is not specified
dbfmig will write the results onto the input file.
Users are advised to use a distinct output file name
for additional precaution.
-p Previous block size that was used to create the original
file. This is an optional parameter.
-b The current block size used. This is an optional
parameter.
If previous block size and/or current block size parameter are
omitted, then the utility determines these from the metadata
maintained in the file. If these are specified, then the
input value is validated against the metadata values maintained
in the file header.
Invoking dbfmig without any qualifiers causes the utility to
generate a usage note.
9.0 OBJECT SQL
==============
9.1 KNOWN OPEN BUGS
-------------------
BUG 556122
Oracle does not support outer-join predicate which includes an
attribute reference via a scoped REF column or attribute.
Workaround:
Specify the table with the scoped REF column as a degenerate
derived table in the from clause. For example,
select ....
from customers c, (select * from orders) o
where.....
Bug 573746
Fetching of 10000 oracle number column values into DBMS_SQL array
results in a core dump.
BUG 590783
Dereferencing an object containing a large VARRAY, e.g., over 170
numbers or over 434 dates, can produce internal error
ORA-0600.
9.2 CLOSED BIG
--------------
629468
This bug could cause migration to fail. With mutually referencing types,
such that the dependencies between them formed a cycle, error 604[1000]
could arise.
10.0 ORACLE CALL INTERFACE (OCI)
================================
The following information on object access can be added to the release 8.0
Oracle Call Interface Programmer's Guide, Chapter 8.
10.1 OCI vs. SQL Access to Objects
----------------------------------
If an application needs to manipulate a graph of objects (inter-related via
object references) then it is more effective to use the OCI navigational
interface rather than the SQL interface for accessing objects. Retrieving a
graph of objects using the SQL interface may require executing multiple
SELECTs which would mean multiple network roundtrips. Using the complex object
retrieval capability provided by the OCI navigational interface, the
application can retrieve the graph of objects in one OCIObjectPin() call.
Consider the update case where the application retrieves a graph of objects
and modifies it based upon user interaction and then wishes to make the
modifications persistent in the database. Using the SQL interface, the
application would have to execute multiple UPDATE statements to update the
graph of objects. If the modifications involved creation of new objects and
deletion of existing objects then corresponding INSERT and DELETE statements
would also need to be executed. In addition, the application would have to do
more bookkeeping, such as keeping track of table names, because this
information is required for executing the INSERT/UPDATE/DELETE statements.
Using the navigational interface's OCICacheFlush() function, the application
can flush all modifications (insertion, deletion and update of objects) in a
single operation. The navigational interface does all the bookkeeping, thereby
requiring less coding on the part of the application. So for manipulating
graph of objects the navigational interface is not only efficient but also
provides an easy to use interface.
Consider a different case in which the application needs to fetch an object
given its REF. In the navigational interface this is achieved by pinning the
object via the OCIObjectPin() call. In the SQL interface this can be achieved
by dereferencing the REF in a SELECT statement (e.g. SELECT DEREF(ref) from
tbl;). Consider situations where the same REF (i.e. reference to the same
object) is being dereferenced multiple times in a transaction. By calling
OCIObjectPin() with the OCI_PIN_RECENT option, the object will be fetched from
the server only once for the transaction and repeated pins on the same REF
will result in returning a pointer to the already-pinned object in the cache.
In the case of the SQL interface, each execution of the SELECT DEREF...
statement would result in fetching the object from the server and hence would
result in multiple roundtrips to the server and multiple copies of the same
object.
Finally, consider the case in which the application needs to fetch a
non-referenceable object. For example,
CREATE TABLE department
(
deptno number,
deptname varchar2(30),
manager employee_t
);
employee_t instances stored in the manager column are non-referenceable. Only
the SQL interface can be used to fetch manager column instances. But if
employee_t has any REF attributes, OCI calls can then be used to navigate the
REF.
10.2 FAILOVER
-------------
The OCI's implementation of failover callbacks has been enhanced for Release
8.0.5. The following changes are implemented:
1) It is no longer necessary to be running the parallel server to use
application failover.
2) A new failover event, OCI_FO_ERROR is added to those events listed on page
7-37 of the 8.0.4 Oracle Call Interface Programmer's Guide. This addition
allows an OCI application to retry failover after an unsuccessful attempt. The
following documentation describes this procedure:
Handling OCI_FO_ERROR
A failover attempt is not always successful. If the attempt fails, the
callback function receives a value of OCI_FO_ABORT or OCI_FO_ERROR in the
fo_event parameter. A value of OCI_FO_ABORT indicates that failover was
unsuccessful, and no further failover attempts are possible. OCI_FO_ERROR, on
the other hand, provides the callback function with the opportunity to handle
the error in some way. For example, the callback may choose to wait a
specified period of time and then indicate to the OCI library that it should
reattempt failover.
Note: This functionality is only available to applications linked with the
8.0.5 or later OCI libraries running against any Oracle8 server.
Consider the following timeline of events:
Time=T0
Database crashes ( crash lasts until T5).
Time=T1
Failover triggered by user activity.
Time=T2
User attempts to reconnect; attempt fails.
Time=T3
Failover callback invoked with OCI_FO_ERROR.
Time=T4
Failover callback enters predetermined sleep period.
Time=T5
Database comes back up again.
Time=T6
Failover callback triggers new failover attempt; it is now successful.
Time=T7
User successfully reconnects
The callback function triggers the new failover attempt by returning a value
of OCI_FO_RETRY from the function.
The following example code shows a callback function which might be used to
implement the failover strategy similar to the scenario described above. In
this case the failover callback enters a loop in which it sleeps and then
reattempts failover until it is successful:
/*---------------------------------------------------------*/
/* the user defined failover callback */
/*---------------------------------------------------------*/
sb4 callback_fn(svchp, envhp, fo_ctx, fo_type, fo_event )
dvoid * svchp;
dvoid * envhp;
dvoid *fo_ctx;
ub4 fo_type;
ub4 fo_event;
{
OCIError *errhp;
OCIHandleAlloc(envhp, (dvoid **)&errhp, (ub4) OCI_HTYPE_ERROR,
(size_t) 0, (dvoid **) 0);
switch (fo_event)
{
case OCI_FO_BEGIN:
{
printf(" Failing Over ... Please stand by \n");
printf(" Failover type was found to be %s \n",
((fo_type==OCI_FO_NONE) ? "NONE"
:(fo_type==OCI_FO_SESSION) ? "SESSION"
:(fo_type==OCI_FO_SELECT) ? "SELECT"
:(fo_type==OCI_FO_TXNAL) ? "TRANSACTION"
: "UNKNOWN!"));
printf(" Failover Context is :%s\n",
(fo_ctx?(char *)fo_ctx:"NULL POINTER!"));
break;
}
case OCI_FO_ABORT:
{
printf(" Failover aborted. Failover will not take place.\n");
break;
}
case OCI_FO_END:
{
printf("\n Failover ended ...resuming services\n");
break;
}
case OCI_FO_REAUTH:
{
printf(" Failed over user. Resuming services\n");
break;
}
case OCI_FO_ERROR:
{
/* all invocations of this can only generate one line. The newline
* will be put at fo_end time.
*/
printf(" Failover error gotten. Sleeping...");
sleep(3);
printf("Retrying. ");
return (OCI_FO_RETRY);
break;
}
default:
{
printf("Bad Failover Event: %d.\n", fo_event);
break;
}
}
return 0;
}
The following is sample output from a program containing this failover
callback function:
executing select...
7369 SMITH CLERK
7499 ALLEN SALESMAN
Failing Over ... Please stand by
Failover type was found to be SELECT
Failover Context is :My context.
Failover error gotten. Sleeping...Retrying. Failover error gotten.
Sleeping...Retrying. Failover error gotten. Sleeping...Retrying. Failover
error gotten. Sleeping...Retrying. Failover error gotten.
Sleeping...Retrying. Failover error gotten. Sleeping...Retrying. Failover
error gotten. Sleeping...Retrying. Failover error gotten.
Sleeping...Retrying. Failover error gotten. Sleeping...Retrying. Failover
error gotten. Sleeping...Retrying.
Failover ended ...resuming services
7521 WARD SALESMAN
7566 JONES MANAGER
7654 MARTIN SALESMAN
7698 BLAKE MANAGER
7782 CLARK MANAGER
7788 SCOTT ANALYST
7839 KING PRESIDENT
7844 TURNER SALESMAN
7876 ADAMS CLERK
7900 JAMES CLERK
7902 FORD ANALYST
10.3 Changes to Defining Objects of Type SQLT_NTY
-------------------------------------------------
Following is the change to the memory management of objects
(type SQLT_NTY) defined via the OCIDefineObject() function.
For object defines, client applications wanting to pre-allocate
object memory must use the OCIObjectNew() function. Client
applications should not allocate the object in its own
private memory space (eg. via malloc() or on the the stack).
The OCIObjectNew() function allocates the object in the object
cache. The allocated object can be freed using OCIObjectFree().
Refer to chapter 11 for details on OCIObjectNew()/OCIObjectFree().
Note that there is no change to the behavior of OCIObjectDefine()
when the user does not pre-allocate the object memory and instead
initializes the output variable to null pointer value. In this case,
the object will be implicitly allocated in the object cache by the
OCI library.
10.4 CLOSED BUGS
----------------
Bug 617774
The Oracle server process memory usage was spiking temporarily when
executing a SQL query with COUNT(*) or ORDER BY with an IS NOT
DANGLING predicate in the WHERE clause. Memory management has
been changed to reuse memory thereby avoiding the spike in memory
usage.
Bug 635608
Fixed Memory leak in object cache when AQ performs 5000 dequeues of object
type payloads.
Bug 640090
OCI failed to return the meta-data attributes for
a result set.
Bug 641059
Cursors were not being closed after we free the statement handle which
resulted in "Maximum open cursors exceeded".
Bug 641812
Data was not being returned from a result set when a long varchar data element
was retrieved from the database using dynamic fetch. A two-task communication
protocol error was returned.
Bug 642133
Fixed memory leak in an OCI program when object instances are
retrieved by executing SQL SELECT statements and modified by
executing SQL INSERT and UPDATE statements.
11.0 XA
=======
When building a TP-monitor XA application ensure that the TP-monitors
libraries (that define the symbols ax_reg and ax_unreg) are placed in the link
line before Oracle's client shared library. If your platform does not support
shared libraries or if your linker is not sensitive to ordering of libraries
in the link line use Oracle's non-shared client library. These link
restrictions are required only when using XA's dynamic registration (Oracle XA
switch xaoswd).
V8 database will not support 7.1.6 XA calls (although it does support 7.3 XA
calls). The answer, hence, is that they need to relink the tuxedo applications
with Oracle 8 XA libraries.
11.1 CLOSED BUG
---------------
589828
When using XA under MTS with database links, an alter system kill session
could result in any of several internal errors, such as 16379, 1113 (on
a virtual circuit), 16252, or 16351. The errors could happen in either
PMON or a shared server.
12.0 TRANSPARENT APPLICATION FAILOVER
=====================================
Select Failover is implemented by transparently reexecuting the select
statement and then bringing the cursor up to the same point as it was before
the failure. Thus, if the original query to an hour, failing over the query
will also take about an hour. Also, Select Failover only occurs after Session
Failover has happened. Thus, if a client is doing a parallel query and a slave
dies, the query will not be transparently restarted.
12.1 KNOWN OPEN BUG
-------------------
Bug 402700
If the client loses its connection while reading a lob, the user must
manually replay the read command after the application fails over to
the surviving node.
13.0 ADVANCED QUEUING
=====================
Fine grain access control to AQ objects.
Oracle8's Advanced queuing packages DBMS_AQADM and DBMS_AQ are owned by
SYS and they operate under SYS's security domain. This allows any user who has
been granted AQ_ADMINISTRATOR_ROLE to create, drop, start and stop any queues
in any user schema. Similarly, any user who has been granted AQ_USER_ROLE role
can enqueue and dequeue to any queues. However, the user will not need any
other DML or DDL privileges to use or manage the queues.
When fine grain security is required, customers can build a simple
application wrapper on top of DBMS_AQADM and DBMS_AQ, that will limit the
application users to access or manage a specific set of queues.
Propagation jobs are owned by SYS but the propagation occurs in the security
context of the queue table owner. Previously propagation jobs were owned by
the user scheduling propagation and propagation was occurring in the security
context of the user setting up the propagation schedule. The queue table
owner must be granted execute privileges on the DBMS_AQADM package.
Otherwise, the Oracle snapshot processes will not propagate and generate trace
files with the error identifier SYS.DBMS_AQADM not defined. Private database
links owned by the queue table owner can be used for propagation. The user
name specified in the connection string must have execute access on the
dbms_aq and dbms_aqadm packages on the remote database.
14.0 INITIALIZATION PARAMETERS
==============================
14.1 NEW 8.0.5 PARAMETERS
-------------------------
optimizer_max_permutations
This parameter lets the user limit the amount of work the optimizer spends
on optimizing queries with large joins. By restricting the number of
permutations of the tables the optimizer will consider, the user can
ensure that the parse time for the query stays within acceptable limits.
However, in doing so, there is a slight risk that the optimizer will
overlook a good plan it would otherwise have found. The default value
for this parameter is 80000, which corresponds to the old behavior.
Setting this parameter to a value less than 1000 should ensure parse
times of a few seconds or less.
optimizer_index_cost_adj
This parameter lets the user tune the optimizer behavior for access
path selection to be more or less index friendly. Some users are
using the first_rows optimizer mode to get plans that use more index
access paths and that are more similar to those generated by the
rule-based optimizer. However, the first_rows mode was never intended
as a pure mechanism to force the use of indexes. The optimizer_index_cost_adj
parameter lets the user adjust the costing of index access paths in the
cost-based optimizer and thereby make the optimizer more or less prone
to selecting an index access path over a full table scan. The default
for this parameter is 100 percent, which makes the optimizer cost index
access paths a the regular cost. Any other value will make the optimizer
cost the access path at that percentage of the regular cost, e.g., setting
it to 50 percent, will make the index access path look half as expensive
as normal. The legal range of values for this parameter is 1 to 10000
percent. This parameter can be used to tune the performance of a system
where it is felt that the optimizer chooses too few or too many index
access paths.
(8.1.3 note: The adjustment does not apply to user-defined cost functions
for domain indexes.)
optimizer_index_caching
This parameter lets the user adjust the behavior of the cost-based
optimizer to select nested loops joins more often. The cost of executing
a nested loops join where an index is used to access the inner table
is highly dependent on the caching of that index in the buffer
cache. The amount of caching depends on factors, such as the load
on the system and the block access patterns of different users,
that the optimizer cannot predict. The user can modify the
optimizer's assumptions about index caching for nested loops
joins by setting this parameter to a value between 0 and 100
percent and thereby indicate what percentage of the index blocks
should be assumed to be in the cache. Setting this parameter
to a higher value makes nested loops join look less expensive
to the optimizer and it will be more likely to pick nested loops
joins over hash or sort-merge joins. The default for this parameter
is 0, which gives the old optimizer behavior.
14.2 Fix for bug 666391
-----------------------
This fix resolves a failure to use Heterogeneous Services (HS)
initialization parameters in an ORACLE server's data dictionary
for an HS database link. The problem could occur in ORACLE
8.0.3 or 8.0.4.
The error occurred when the HS database link connected to
a non-Oracle data store whose class name (FDS_CLASS_NAME)
was already registered in the ORACLE server's DD but whose
instance name (FDS_INST_NAME) was not registered in the DD.
In that case (connecting to an unregistered instance of a
registered class) the ORACLE server failed to retrieve
class initialization parameters.
The server had accessed both class and instance initialization
parameters with a single SELECT on the HS_ALL_INITS view.
This view was intended to select rows representing HS init
parameters for use on a particular connection when queried
with a SQL statement of this form:
select * from hs_all_inits
where fds_class_name = <non-Oracle system's class name>
and fds_inst_name = <non-Oracle system's
instance name>
The HS_ALL_INITS view is a four-way join which in fact
returned class initialization information from the HS$_CLASS_INIT
table only if the instance name was defined in the HS$_FDS_INST
table.
The fix is for the server to perform separate accesses to
the HS_CLASS_INITS and HS_INST_INITS views.
DBA's should be aware that the HS_ALL_INITS view works correctly
with a query of this form ONLY when both the class and instance
have been registered. It works correctly for queries using
WHERE clauses which do not specify an instance
name.
Non-Oracle system classes and instances normally are
registered automatically in the ORACLE DD on the initial
connection to an HS agent. Bug 666391 is most likely to
occur in ORACLE 8.0.3 and 8.0.4 when
(a) A prior HS connection has been made to one instance
of a previously unknown FDS class; this causes the
class and the first instance to be registered.
(b) A new HS connection goes to a second (unregistered)
instance of the same FDS class.
14.3 KNOWN OPEN BUG
-------------------
Bug 484006
When the fixed_date init.ora parameter is set, objects do not get
invalidated when they should.
15.0 BACKUP AND RECOVERY
========================
15.1 Recovery Manager Compatibility and Upgrade Information
-----------------------------------------------------------
15.1.1 Executables, Recovery Catalogs and Target Databases
-----------------------------------------------------------
If you are using 8.0.5, all components used in Recovery Manager
backups, (the RMAN executable, the recovery catalog, and the
target database) can be 8.0.4 or 8.0.5.
If you are using 8.0.4, all components used in Recovery Manager
backups, (the RMAN executable, the recovery catalog, and the
target database) must all be 8.0.4.
If you are using 8.0.3, all components used in Recovery Manager
backups, (the RMAN executable, the recovery catalog, and the
target database) must all be 8.0.3.
It is not possible to combine RMAN components from
8.0.3 and 8.0.4.
15.1.2 Backup compatibility
----------------------------
Backups and datafile copies of an 8.0.3 database are still
usable for restore and recovery with 8.0.4.
15.1.3 Upgrading
-----------------
Run these 4 scripts (in /admin) to move from 8.0.4
to 8.0.5:
-dbmsrman.sql
-prvtrmnu.plb
-dbmsrvct.sql
-prvtrvct.plb
To move from 8.0.3 to 8.0.4, run RMAN804.SQL in the recovery
catalog owner schema.
15.2 New Commands and Features
------------------------------
Auto Archivelog deletion during Recovery
A new option has been added which will automatically delete an archive log
after the log has been applied during recovery. This saves on used space
in the archivelog restore destination. The new keywords DELETE ARCHIVELOG
have been added to the RECOVER command.
CATALOG DATAFILECOPY <filename> LEVEL=0;
Allows a user-created datafile copy to be cataloged as a level 0 file copy.
In 8.0.3 it was only possible to catalog these backups as 'full' file copies.
The ability to catalog O/S file copies as level 0 backups in the recovery
catalog allows subsequent incremental backups to be based on the user-created
Operating System copies.
Inline command files.
@cmdfile has been added so that a series of RMAN commands stored in an
Operating System file can be executed from within Recovery Manager
e.g. RMAN> @cmdfile
The specified file is processed as if its contents had appeared in place of
the @ command. Note that the file must contain only complete Recovery
Manager commands. A syntax error will result if the file contains a
partial command. @@cmdfile is also supported, the difference being that
the filename need not be a full pathname: in the case of @@, the current
working directory is assumed (was 491049 and 433605).
SETSIZE parameter
This is a new optional parameter for the BACKUP command. It specifies
the maximum size of a backup set. The value is specified in units of
kilobytes (1024 bytes). The actual size of the backup sets that are
created will never be larger than the specified SETSIZE value. For
archivelog backup sets, the actual size will usually be close to the
specified SETSIZE value. For datafile and datafile copy backup sets, the
actual backup set size will usually be less because of unused block
compression and because of incremental backup. Operationally speaking
SETSIZE defines the maximum number of blocks read by each server process.
The recommended usage is to make archivelog backup sets approximately the
same size.
sbttest
A new client program, sbttest, is being shipped. It is a standalone
test of the media management software that is linked with Oracle to perform
backups to tape. Sbttest should only be used at the direction of Oracle
support, when Oracle is unable to create or restore backups using either the
bundled Legato Storage Manager or another vendor's
media management product.
15.3 Linking with Media Management Software
-------------------------------------------
Using Legato Storage Manager (LSM)
----------------------------------
See LSM.doc, the separate readme for Legato for further
details.
If you opt to install the bundled Legato Storage Manager (LSM) when
installing Oracle, then the Oracle executable will automatically be
relinked so that Recovery Manager can create backups using the LSM, and
your system will be configured so that any subsequent relinks of the Oracle
executable will use the correct LSM interface library.
Using Third Party Media Management Software
-------------------------------------------
If you install another media management product, you will need to relink
the Oracle executable. The examples given here are UNIX specific. Please
see your Media Manager's documentation for information on how to link
Oracle with the Media Manager.
Below is an example of how to integrate Oracle with two Media Managers.
The examples assume the media management software's interface library is
located in location is in '/usr/lib', and name of the library is
'libobk.so' on Solaris, and 'libobk.sl' on HP/UX.
WARNING:
You must perform all steps required to successfully complete the
process:
Linking with the Media Manager
------------------------------
1. Ensure all databases using this ORACLE_HOME are
shut down.
2. Rename all the following files.
If the LSM is installed, rename the LSM:
mv $ORACLE_HOME/lib/libobk.so $ORACLE_HOME/lib/libobk.so.save
If the LSM is not installed, rename the following library:
mv $ORACLE_HOME/lib/libobk.a $ORACLE_HOME/lib/libobk.a.save
3. Link the Third Party Media Manager with Oracle.
Below are examples of typical commands used to link Oracle with
Media Management software:
To relink on Solaris, using Legato Networker:
Copy the Vendor's libobk to the $ORACLE_HOME/lib directory,
or make a softlink in that directory which points to the
Vendor's library:
cp /usr/lib/libobk.so $ORACLE_HOME/lib
OR
ln -s /usr/lib/libobk.so $ORACLE_HOME/lib/libobk.so
Then:
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk ioracle
To relink on HP, using EMC's Epoch:
Copy the Vendor's libobk to the $ORACLE_HOME/lib directory,
or make a softlink in that directory which points to the
Vendor's library:
cp /usr/lib/libobk.sl $ORACLE_HOME/lib
OR
ln -s /usr/lib/libobk.sl $ORACLE_HOME/lib/libobk.sl
Then:
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk ioracle
Removing a Media Manager
------------------------
If you choose, you may return to the original configuration
by performing the same actions as above, but by replacing the
library with the library backed up in 3.2.1 above:
1. Ensure all databases using this ORACLE_HOME
are shut down.
2. Rename all the following files.
If the LSM is installed, restore the LSM to it's previous name:
mv $ORACLE_HOME/lib/libobk.so.save $ORACLE_HOME/lib/libobk.so
If the LSM is not installed, restore the following library:
mv $ORACLE_HOME/lib/libobk.a.save $ORACLE_HOME/lib/libobk.a
3. Relink Oracle using the following commands:
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk ioracle
15.4 Recovery Manager Error Codes
----------------------------------
Recovery Manager SBT API Error codes (457970)
When errors occur through the SBT interface, the true error
is shown by Recovery Manager as an 'Additional Information'
message.
Below is the list of 'Additional information' message numbers,
and the corresponding error text. The errors prefixed with
'*' are internal and should never be seen during
normal operation:
7001 Backup file not found
* 7002 Bad mode specified
* 7003 Bad tpblksiz, should be multiple of 512
7004 No Tape device found
7005 Device found but busy, try again later
7006 tape volume not found
7007 tape volume is in-use
7008 I/O Error
7009 can't connect with Media Manager
7010 permission denied
7011 system error - eg. malloc, fork errors
* 7012 invalid argument(s) to sbtopen
7013 Backup file exists
* 7040 bad th to sbtwrite
7042 I/O error
7043 system error
* 7044 invalid argument(s) to sbtwrite
* 7060 bad th to sbtread
7061 EOF encountered
7063 I/O error
7064 system error
* 7065 invalid argument(s) to sbtread
7080 backup file not found
7081 backup file being used
7082 I/O Error
7083 can't connect with Media Manager
7084 permission denied
7085 system error
* 7086 invalid argument(s) to sbtremove
7090 backup file not found
7091 I/O Error
7092 can't connect with Media Manager
7093 permission denied
7094 system error
* 7095 invalid argument(s) to sbtinfo
* 7110 invalid argument(s) to sbtinit
7111 system error - eg. malloc, fork errors
* 7120 th was not of a previously sbtpopened one (sbtclose)
* 7121 Bad Flags to sbtclose
7122 I/O ERROR
7123 System Error
7124 Can't connect with Media Manager
* 7125 Invalid Argument to sbtclose
15.5 Recovery Manager Bugs Fixed
--------------------------------
637118: the RESTORE CONTROLFILE; command would SIGSEGV.
This command now works and will do the following:
1. restore the controlfile to the first filename listed in the CONTROL_FILES
parameter in the init.ora file.
2. automatically replicate the restored controlfile to the other controlfile
filename(s) listed in the CONTROL_FILES parameter,
if any.
624305: Catrman.sql dropped the recovery catalog
tables.
The script no longer drops the tables, so an existing recovery catalog is not
destroyed by running this script.
620877: Tablespace point-in-time recovery failed with ORA-258 if target
database was in NOARCHIVELOG mode.
613614: Tablespace point-in-time recovery of a read-only
tablespace failed.
613166: LIST COPY command showed deleted datafile
copies.
612344: Datafiles with filename of MISSING<fno>
could not be restored by RMAN.
607287: After a tablespace point-in-time recovery, the tablespaces
could not be backed up.
598694: RMAN terminated with a fatal error when media recovery requested
a log that could not be found.
637162: RMAN COPY would create a file of the wrong size when the datafile was
on a raw device. This file would be larger than necessary, which
would cause problems if the datafile copy was used with the CATALOG
command. This was fixed in patch release
8.0.4.1.
610435: RMAN could not apply incremental restores to raw devices. This was
fixed in patch release 8.0.4.1, and is the subject of a support
alert. See also related bugs 630288 and 609836, which also affect
RMAN operations with files on raw devices.
15.6 Recovery Manager Enhancements
----------------------------------
1. SET DBID command:
Each database has a unique identifier associated with it called the DBID. The
DBID is a 32 bit number which is computed when the database is created. The
DBID is stored in the recovery catalog in the DB table. To obtain the DBID of
the database you wish to restore, you must query the recovery catalog.
Since the database names of the databases which are registered in the recovery
catalog are presumed non-unique in this scenario, some other unique piece of
information must be used to determine the correct DBID. If you know the
filename of a datafile or on-line redo log associated with the database you
wish to restore, and this filename is unique across all databases registered
in the recovery catalog, then this filename can be used to determine the DBID
by performing one of the following queries:
select distinct db_id
from db, dbinc, dfatt
where db.db_key = dbinc.db_key
and dbinc.dbinc_key = dfatt.dbinc_key
and dfatt.fname = '<filename>';
select distinct db_id
from db, dbinc, orl
where db.db_key = dbinc.db_key
and dbinc.dbinc_key = orl.dbinc_key
and orl.fname = '<filename>';
New SET DBID command:
Syntax:
set dbid [=] <integer> ;
This command is only needed to restore the controlfile when all of the
four following conditions are met:
1) The controlfile has been lost and must be restored from a backup
2) A recovery catalog is being used
3) There are multiple databases registered in the recovery catalog, with
one or more databases which have the same dbname
4) "RMAN-20005: target database name is ambiguous"
is being received when attempting to restore the
controlfile
If these conditions are not met, this new command
is not necessary as RMAN will correctly identify the controlfile
to restore.
This new command is accepted only when RMAN has not yet connected to the target
database. I.e., it must precede the "connect target" command. If the
target database is mounted, then RMAN verifies that the DBID the user-specified
matches the DBID from the database, else an error is signaled.
If the target database is not mounted, RMAN will
use the user-specified DBID to restore the controlfile.
Once the controlfile is restored, the database can be started up and mounted
(suggested), to restore the rest of the database.
2. NOREDO Option
The RECOVER command now has an option to suppress the media recovery phase
(application of redo logs). This restricts RMAN to applying incremental
backups only. The syntax is:
RECOVER <object-list> NOREDO ;
16.0 PARALLEL SERVER
====================
In 8.0.x, all Oracle databases on a hardware cluster that are linked
in Parallel Server mode must match the word size of the GMS executable.
Therefore, they must all run a 32 or 64 bit executable. Mixing word sizes
of parallel server executables, even across different databases, will
not work in 8.0.x. This restriction, which may be relaxed in 8.1, does not
apply to executables that are not linked in Parallel
Server modes.
Oracle basic replication and Oracle advanced replication do not
support rolling upgrade.
16.1 KNOWN OPEN BUG
-------------------
BUG 655426
In multiple node-multiple instance mode, a large number of users may cause
the system to run out of swap space. This would cause the users to be logged
out with the message that there is no more memory available. If this happens,
increase the amount of swap space to increase the number of simultaneous users.
17.0 DATABASE SECURITY
=======================
17.1 PASSWORD MANAGEMENT
------------------------
Some of the Password Management features are not supported by svrmgrl.
This means that when a password is about to expire and is in the grace period,
if the user connects through svrmgrl, the warning message that the password is
about to expire will not appear.
Also, if the password has already expired, it simply returns the error and
does not allow the user to connect. Whereas SQLPlus does display the message
that password has expired and asks for the old and new passwords and changes
the password after authentication, verification, etc.
17.2 KNOWN OPEN BUG
-------------------
Bug 523359
In dedicated server mode, you can successfully connect to the
database with OSS authentication. But on multi-threaded server mode, you fail
to establish connection with OSS authentication and ORA-3113 "end of file in
communication channel" occurs.
17.3 CLOSED BUG
---------------
Bug 562225
The server-to-server mutual authentication step performed as part of
a privileged database link did not check that all prior databases in
a chain of links were trusted.
18.0 LOBs
=========
The user will not be able to specify the LOB index clause in
future releases of Oracle. The user should *NOT* put the
LOB index in a different tablespace than the LOB data. In a future
Oracle release, if the LOB index is in a different tablespace than
the LOB data, export/import will coalesce the LOB index with
the LOB data.
Current LOB demos work for non-multi-byte database
character sets only.
18.1 INITIALIZING BFILES IN OBJECTS
-----------------------------------
OCIObjectNew() --
If the object contains a bfile, the user must set the bfile value
before flushing the object to the database thereby inserting a new
row. In other words, the user must call OCILobFileSetName() after
OCIObjectNew() and before OCIObjectFlush(). It is an error to
insert/update a bfile without indicating a directory alias and
filename.
This rule also applies to users using an OCI bind variable
for a bfile in an insert/update statement. The OCI bind variable
must be initialized with a directory alias and filename before
issuing the insert or update statement. Note that OCISetAttr() does
not allow the user to set a bfile locator to null.
General rule: Before using SQL to insert or update a row with a bfile,
the user must either initialize the bfile
a. to null (not possible if using an oci bind variable) or
b. to a directory alias and filename
18.2 KNOWN OPEN BUGS
--------------------
BUG 626910
In a single server manager session if any of the BFILE functionalities are
used and then if the Oracle instance is shutdown and started up again the
instance sometimes crashes the next time any BFILE functionality is used.
This could be avoided if the server manager is also brought down and brought
up with the instance.
BUG 640995
When using lob buffering, you will see the following problem:
If you write to the lob through the lob buffers and then overwrite a portion
of the data you already wrote to the lob buffers (without first flushing the
buffer), the portion of data after the overwritten data will be lost.
For example:
OCILobEnableBuffering(...loc1);
offset = 1;
amount = 2000;
OCILobWrite(...loc1, offset, &amount, ....);
/* maybe do some other processing but don't flush and don't
* disable buffering.
*/
offset = 10; /* choose an offset within 1 and 2000 */
amount = 40; /* choose an amount that does not write beyond the
* 2000th byte.
*/
OCILobWrite(...loc1, offset, &amount, ...);
/* byte 51 through 2000 will be lost */
In order to avoid this problem, flush the buffer, discarding the old contents
of the buffer, and then do the second write. In other words, don't write to
the buffers more than once if you will be overwriting data that's already in
the lob buffers.
For example:
OCILobEnableBuffering(...loc1);
offset = 1;
amount = 2000;
OCILobWrite(...loc1, offset, &amount, ....);
OCILobFlushBuffer(...loc1, OCI_LOB_BUFFER_FREE);
offset = 10;
amount = 40;
OCILobWrite(...loc1, offset, &amount,
...);
19.0 STRUCTURED QUERY LANGUAGE (SQL)
====================================
19.1 Documentation Errata
-------------------------
Documentation regarding the DBMS_UTILITY schema (Chapter 10 in the Application
Developer's Guide) is not completely correct. Currently, it is as follows:
"This procedure is equivalent to calling alter_compile
on all procedures, functions, and packages accessible by you.
Compilation is completed in dependency order."
It should read:
"This procedure is equivalent to calling alter_compile
on all procedures, functions, packages and triggers accessible by
you. Compilation is completed in dependency order."
ALTER TABLE command
Note that, in addition to the privileges named in the "Prerequisites"
section, if you are not the owner of the table, you need the DROP ANY TABLE
privilege in order to use the DROP PARTITION and TRUNCATE PARTITION options.
You must also have space quota in the tablespace in which space is to be
acquired in order to use the ADD PARTITION, MODIFY PARTITION, MOVE PARTITION,
and SPLIT PARTITION options.
In Chapter 8 of the documentation, in the section "String-to-Date
Conversion Rules", please note: The three "additional formatting rules"
listed do NOT apply if you have used the FX or FXFM modifies in the format
to control exact format checking.
19.2 CONSTRAINT CLAUSE
----------------------
Oracle does not support constraints on columns or attributes whose type
is an object, nested table, VARRAY, REF, or LOB. The only exception is
that NOT NULL constraints are supported for columns or attributes whose
type is object VARRAY, REF, or LOB.
19.3 SYNTAX DIAGRAMS
--------------------
Some of the syntax diagrams in the Oracl8 SQL Reference did not filter
properly into the HTML version of the online documentation. If you find
the syntax diagram for a given command illegible or confusing in the HTML
version, please refer to the PDF version of the online documentation, or to
the printed SQL Reference, Volume 2.
19.4 OBJECT AND LOB COLUMN RESTRICTIONS
---------------------------------------
Parallel query, parallel DML, parallel DDL against Object and LOB columns
are not supported in 8.0.5.
19.5 GRANT (Object Privileges) COMMAND
--------------------------------------
Note that, in addition to the privileges listed in Table 4-12 of The SQL
Reference, you can grant the EXECUTE privilege on an object type. Doing so
allows the grantee to use and reference the specified type and to invoke
its methods.
19.6 CLOSED BUG
---------------
Bug 450760
In 8.0.2, if you declared a forward declaration for a type and then
attempted to ALTER the type with REPLACE option, the RDBMS failed to
issue an error message. This would then get you into a state where you could
incorrectly create a valid, but rather unusable type without any
attributes in it.
Example:
create type t1;
alter type t1 replace (member function f1 return number);
# The above compiles validly, but has no meaning because there are
# no attributes.
20.0 NATIONAL LANGUAGE SUPPORT
==============================
20.1 LOBS
---------
Current LOB demos work for non-multi-byte database
character sets only.
20.2 OPEN BUGS
--------------
Bug 454867
The banner displayed at import start up time has a garbage date in a
Korean NLS environment.
Bug 469386
Character set conversion fails when the character sets are same but
the nchar character sets are different.
Bug 366933
Nonsense years in the Japanese Imperial calendar
are possible.
20.3 CLOSED BUGS
----------------
Bug 375613
Some platforms under multibyte environment could not recognize '@' or '|'
as special characters therby giving parsing errors
like ORA-942.
Bug 433822
Quoted identifiers in triggers in multibyte charsets were incorrectly
parsed which sometimes led to dictionary corruption.
Bug 558889
When describing a query with more than 32 columns in an environment that
required multibyte conversion between the client and server, the length of
the internal buffer used to retrieve describe information was modified by
a power of 3. In the case of an oracle server querying a gateway, this led
an ora-9199 when attempting to allocate a buffer with an inflated size of
12+Mb.
Bug 605615
If ORA_NLS33 contained an invalid location, either ORA-01019 or ORA-24322
would be returned by a connect request. If the application retried the
connect, it would then succeed. The retry behaviour distinguished this
problem from other situations where the error codes were validly being
reported.
Bug 613253
7.x OCI calls using bind variable linked with 8.0 OCI library sometimes
corrupted some JA16SJIS characters.
21.0 REPLICATION
================
21.1 INTEROPERABILITY
---------------------
Oracle8 Masters can interoperate with masters on Oracle7.3.3 and above.
Snapshots with Oracle8 Masters must be on Oracle7.3.4 or above.
Updatable Oracle 8 snapshots can have masters on Oracle 7.3.3
and above. Read-only Oracle 8 snapshots can have masters on Oracle 7.1.3
and above.
21.2 DBMS_DEFER_SYS.COPY REMOVED
--------------------------------
The COPY procedure of the DBMS_DEFER_SYS package
has been removed.
21.3 WARNING
------------
Oracle basic replication and Oracle advanced replication do not
support rolling upgrade.
21.4 KNOWN OPEN BUG
-------------------
Bug 574881
Replication manager connects as SYSTEM to create users and grant privileges
for replication administration. In particular, sys.dbms_repcat_admin is used
to grant repadmin privileges to users. This does not work in a database
with dictionary protection enabled because SYSTEM does not have
execute privileges for this package. But SYSTEM is granted the
EXECUTE_CATALOG_ROLE role. Therefore, this problem can be resolved by
by granting execute on sys.dbms_repcat_admin to EXECUTE_CATALOG_ROLE:
GRANT EXECUTE ON dbms_repcat TO EXECUTE_CATALOG_ROLE
21.5 CLOSED BUGS
----------------
Bug 591389
The rep_delete procedure in the $RP package deleted a row in the
table. The WHERE clause assumes every column may or may not be
sent. This is not true for the key columns, which are always sent.
The bug forced a full table scan as opposed to an
index look up.
Bug 588595
Having a subset of replicated columns for an updatable snapshot was
not supported. However, creating such a snapshot succeeded. An error
would be raised when a refresh is attempted for that
snapshot.
Bug 559218
Attempting to create a snapshot that uses in-line views would core dump.
This has now been fixed.
Bug 599580
This bug caused Replicated transactions not to be propagated and
to be deleted from the queue after the queue has been pushed.
The conversion of the SCN to oracle number was being stored
incorrectly after the SCN got large enough to wrap. The
bug can be confirmed by checking if
system.def$_aqcall.cscn <= system.def$_destination.last_delivered
Bug 648343
Lob replication didn't work when the primary key was more than one
column. Any insert or update in the lob column resulted in ORA-1403 (no data
found) in deferror at the remote site.
22.0 64-BIT ISSUES
==================
Oracle now provides support for 64-bit computers. This support eliminates
the 2GB addressing limitation of 32-bit releases. Therefore, SGAs
(System Global Aresas) and PGAs (Program Global Areas) are limited only
by the physical memory on the computer system.
64-bit addressing can improve performance by allowing very large buffer
caches to be configured, therby reducing I/Os. Further, by eliminating
the limit on the maximum size of the shared pool, 64-bit addressing
can allow more users to be logged into Oracle.
In 8.0.x, all Oracle databases on a hardware cluster that are linked
in Parallel Server mode must match the word size of the GMS executable.
Therefore, they must all run a 32 or 64 bit executable. Mixing word sizes
of parallel server executables, even across different databases, will
not work in 8.0.x. This restriction, which may be relaxed in 8.1, does not
apply to Oracle executables that are not linked in
Parallel Server modes.
Each platform which can support 64-bits will receive two CDs, one for
32-bits, and one for 64-bits.
23.0 TYPES
==========
Type specifications and their bodies can be kept in shared memory, so that
they will not be aged out with the normal LRU mechanism. A user needs to have
execute privilege on a type to be able to keep it pinned in shared memory. An
attempt to keep a type TY whose body does not exist will result in only
keeping the type spec TY. Once the type body for TY is created, the user will
have to keep the type again if they wish to keep the type body for TY also
pinned in shared memory. The following example demonstrates how a type TY in
u1's schema can be kept pinned in shared memory by user u2 (u2 is assumed to
have execute privilege on u1.TY) :
begin
sys.dbms_shared_pool.keep('u1.TY', 'T'); -- the flag can be either 'T' or 't'
end;
24.0 PATCH SET BUG FIXES
========================
24.1 8.0.4.2 Bug Fixes
----------------------
A process which repeatedly opened and closed
414036 RDBMS 8.0.4.2 database link connections resulted in a memory
leak, especially for snapshot
processes.
Use of resource limits (ie profiles) together with
472762 RDBMS 8.0.4.2 parallel query could incorrectly exceed a resource
limit.
511898 RDBMS 8.0.4.2 Index_desc hint sometimes caused wrong output from
query.
513922 RDBMS 8.0.4.2 Slaves were not released after input DFO was
completed if UNION ALL ran serially.
Statements with more than 12 bind variables and a
LONG column in the middle of the table had the
516301 RDBMS 8.0.4.2 cursor instantiation object bind structure pointing
to the wrong address. This happened executing SQL
statements from PL/SQL blocks.
564060 RDBMS 8.0.4.2 With large joins, parse time
was unacceptable.
Distributes query with cost based optimizer
572478 RDBMS 8.0.4.2 sometimes returned wrong results when it involved
fixed length join columns
from remote tables.
When using an XA transaction with more than one
branch, if an error occurred during the
transaction, the transaction could erroneously roll
591775 RDBMS 8.0.4.2 back earlier successful changes in the transaction.
(Some TP Monitors create multiple branches in a
transaction if more than one process is in the
transaction).
An incorrect result was returned sometimes when using
596702 RDBMS 8.0.4.2 PQ and SMJ with at least one of the join keys being
constant.
596709 RDBMS 8.0.4.2 SHUTDOWN will now properly close the file handle to
the message file.
Addition of a primary key constraint now correctly
604833 RDBMS 8.0.4.2 validates the existence of NULLS in the column(s)
used for the primary key.
615863 RDBMS 8.0.4.2 Time-based recovery sometimes recovered to a time
before or after the stop time
specified.
Query involving nested/inline views sometimes
617497 RDBMS 8.0.4.2 resulted in ORA-600[15598] when NO_MERGE hint was
used in view base queries.
On some platforms, the sga was not removed
618002 RDBMS 8.0.4.2 sometimes following an instance failure during
startup.
Conventional loading into a table with bitmap
618960 RDBMS 8.0.4.2 indexes and regular indexes sometime resulted in
ORA-600 [20000]
SQL*Loader could not write records that are longer
621824 RDBMS 8.0.4.2 than 270 bytes to a bad file or discard file;
SQL*Loader-523: Error -2 writing to file was
issued.
623661 RDBMS 8.0.4.2 Improved the diagnostic information that is dumped
with an ora-600 [13004]
During array updates of longs where a long column
625780 RDBMS 8.0.4.2 is being set to null, internal error 6588 may
occur. This could also happen during inserts,
resulting in internal error
6592.
A query which contains inlists and other OR
642998 RDBMS 8.0.4.2 predicates could sometimes return the incorrect
result.
The for loop that populates the multiblock read
646480 RDBMS 8.0.4.2 buffer pointers will now iterate not more than
KCFMXRREQ times.
Queries with partition views,
646985 RDBMS 8.0.4.2 PARTITION_VIEW_ENABLED=TRUE, and inlist predicates
sometimes got an internal error or returned wrong
rows.
This bug caused Replicated transactions not to be
599580 8.0.4.2 propagated and to be deleted from the queue after
the queue has been pushed.
24.2 8.0.4.1 Bug Fixes
----------------------
391422 PL/SQL 8.0.4.1 New elements of Index table of records were not
getting initialized properly when created.
Various internal errors or core dumps were
388927 RDBMS 8.0.4.1 encountered during heavy library cache activity.
This problem manifested itself when users changed
the SQL optimizer goal sometime
during a session.
Attempting to recompile a procedure which is a
dependent of a package specification and a
dependency for the same packages's body would
481855 RDBMS 8.0.4.1 result in the death of the process. This has been
rectified. The instantiations that need to be
deleted when a procedure is recompiled are now
deleted in an appropriate
order.
Multirow inserts into a table with regular
486828 RDBMS 8.0.4.1 index(es) and bitmap index(es) resulted in ORA-600
[20062] errors, if the insert caused a constraint
violation on the regular indexes.
Parallel queries with date subtraction and 'group
504420 RDBMS 8.0.4.1 by' or 'order by' clause no longer fail with
ORA-01841 or ORA-00932.
524786 RDBMS 8.0.4.1 Blank data of zoned type with defaultif=BLANKS
resulted in ORA-2358 during
direct load.
555554 RDBMS 8.0.4.1 The wrong number of rows were updated under CBO for
OR or IN predicates.
Referencing view constant columns in an outer-join
556406 RDBMS 8.0.4.1 within a where clause sometimes resulted in
ORA-7445 error during sort.
558160 RDBMS 8.0.4.1 Granting privileges lots of times sometimes led to
ORA-00600 [17059].
566612 RDBMS 8.0.4.1 Use of PQO with index-only tables sometimes failed
with an ORA-2031.
Running OCI programs in non-blocking mode sometimes
585122 RDBMS 8.0.4.1 caused wrong data to be returned for certain
datatypes. Thsi was more likely
on Win NT.
586807 RDBMS 8.0.4.1 Hash join dumped core when select list contained
view const columns.
589539 RDBMS 8.0.4.1 "False" latch contention happened sometimes
resulting in ORA-00600 [525].
The xa trace file contained garbage instead of
589987 RDBMS 8.0.4.1 transaction ids when the transaction ids were very
long.
591675 RDBMS 8.0.4.1 Create view statements issued against base objects
with many mandatory columns
has been speeded up.
This bug prevents application failover from working
591818 RDBMS 8.0.4.1 if there is no backup available when failover is
attempted. The fix allows application developers to
retry failover until it succeeds.
602979 RDBMS 8.0.4.1 Datafiles reused in 8.0.3 with a smaller block size
could not be opened after
upgrade to 8.0.4.
DML on a synonym for a table in another user's
604475 RDBMS 8.0.4.1 schema failed if the table contained any nested
table columns.
Oracle segfaulted when attempting parallel query if
606415 RDBMS 8.0.4.1 running with multiple instances and some instances
were down and running on an SP2 or Pyramid Mesh
which have true shared disk.
In Oracle8, if a user attempted to truncate a large
608417 RDBMS 8.0.4.1 LOB or table, the server sometimes signalled an
internal error.
On some platforms, doing ALTER DATABASE BACKUP
609836 RDBMS 8.0.4.1 CONTROLFILE TO 'xyz.f' when the controlfile was on
a raw device resulted in errors ORA-1587 and
ORA-27072.
RMAN failed with the ora-19665 error message while
610435 RDBMS 8.0.4.1 applying incremental restores to datafiles on raw
devices during the rman 'recover'
command.
With a small queue table (< 4 blocks) it was
612794 RDBMS 8.0.4.1 possible for messages to be returned in an order
different from the sort order.
613013 RDBMS 8.0.4.1 %, _ were not recognized in JA16EUCFIXED character
set.
Incorrect results could be returned if date
constants were used to probe a partition view and
executed in parallel for a class of queries. With
616447 RDBMS 8.0.4.1 PARTITION_VIEW_ENABLED set to true, a parallel
query against a partitioned view that included a
date column in the predicate compared with a date
literal sometimes returned
wrong results.
616939 RDBMS 8.0.4.1 Any OCI program that tried to fetch NULL ADTs
encountered a memory leak.
When a v7 client selected more than 255 columns
618076 RDBMS 8.0.4.1 from a v8 server using a join, it got OER(24340):
This operation cannot support
more than 255 columns
If a processed message was dequeued again by
630057 RDBMS 8.0.4.1 specifying the message id in a multi-consumer
queue, internal error ORA-600[kwqidghi: ref < 1]
sometimes occurred.