Liren Large Software Subsidy 5

home *** CD-ROM | disk | FTP | other *** search

/ Liren Large Software Subsidy 5 / 05.iso / a / a525 / 56.ddi / README.DOC < prev next >

Wrap

Text File | 1992-12-29 | 42.8 KB | 1,133 lines

... ... $Header: README.doc 7001200.3 92/12/23 14:17:39 twang Osd<base> $ ... README ORACLE7 Release 7.0.12 README README README README README ORACLE7 Release 7.0.12 README README README ORACLE7 Release 7.0.12 README README README ORACLE7 Release 7.0.12 README ORACLE7 Release 7.0.12 README ORACLE7 Release 7.0.12 README ORACLE7 Release 7.0.12 README ORACEE7 Release 7.0.12 README ORACLE7 Release 7.0.12 README ORACLE7 Release 7.0.12 README ORACLE7 Release 7.0.12 Copyright (C) Oracle Corporation December 22nd, 1992 This software contains propriety information of Oracle Corporation; it is provided under a license agreement containing restrictions on use and disclosure and is also protect by copyright law. Reverse engineering of software 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 of the Programs 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). Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065. 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). 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*Ada, Pro*COBOL, Pro*FORTRAN, Pro*Pascal, Pro*PL/I, SQL*Connect, SQL*DBA, SQL*Forms, SQL*Loader, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation. CASE*Designer, CASE*Method, ORACLE7, ORACLE Parallel Server, ORACLE*XA, PL/SQL, Pro*C, SQL*Module, and Trusted ORACLE7 are trademarks of Oracle Corporation. ----------------------------------------------------------------------------- TABLE OF CONTENTS ----------------- 0.0 Introduction 1.0 Information for New users and for Upgrading from ORACLE Version 6 1.1 Before You Install ORACLE7 1.2 Migration to ORACLE7 1.3 PL/SQL 1.4 SQL*DBA 1.5 Initialization Parameters 1.6 Data Dictionary Views 1.7 Preparing for Future Versions 1.8 New features NOT Documented 1.9 National Language Support 2.0 Information for Upgrading from ORACLE Version 5 2.1 Before You Install ORACLE7 2.2 Migration to ORACLE7 3.0 Information for Upgrading from Pre-Production ORACLE7 3.1 Before You Install ORACLE7 3.2 Migration to ORACLE7 3.3 Other Server Changes 4.0 Known Restrictions ----------------------------------------------------------------------------- 0.0 Introduction ================== ================== ================== Purpose of this Document ------------------------ This README document notes differences between the delivered ORACLE7 server and its documented functionality. If you are unfamiliar with ORACLE, please read the introductory chapter of the ORACLE7 Server Concepts Manual, part number 6693-70. Cover Letter and Licensing -------------------------- Please read the cover letter included with your ORACLE7 package. It contains important information about your package and which options are licensed for installation and usage. Oracle Products and Different Operating Systems ----------------------------------------------- This README document is only relevant to the ORACLE7 server and its integral parts, such as SQL, PL/SQL, SQL*Loader, Import/Export utilities and so on. Each operating system, such as DEC VAX/VMS, MS-DOS, AOS/VS, and so on, has its own README document. Oracle products, such as SQL*Forms, may have an additional README document. A README equivalent would be "release notes," a "system bulletin," or similar. Documentation Currently Available --------------------------------- The following documentation listed by part number and title is available: 800-20 PL/SQL User's Guide and Reference 778-70 SQL Language Reference Manual 6693-70 ORACLE7 Server Concepts Manual 6694-70 ORACLE7 Server Database Administrator's Guide 6695-70 ORACLE7 Server Application Developer's Guide 3605-70 ORACLE7 Server Messages and Codes Manual 6617-70 ORACLE7 Migration Guide 3602-70 ORACLE7 Utilities User's Guide 5990-70 ORACLE7 Parallel Server Administrator's Guide 6610-70 Trusted ORACLE7 Administrator's Guide 5411-70 Programmer's Guide to OCI's 5315-15 Programmer's Guide to the ORACLE Precompilers 5452-15 Pro*C Precompiler Supplement 5451-15 Pro*COBOL Precompiler Supplement 5453-15 Pro*FORTRAN Precompiler Supplement 5454-15 Pro*PASCAL Precompiler Supplement 5454-15 Pro*PL/I Precompiler Supplement 1.0 Information for Upgrading from ORACLE Version 6 ===================================================== ===================================================== ===================================================== 1.1 Before You Install ORACLE7 ================================ Normal Shutdown and Full Offline Backup --------------------------------------- When upgrading to a newer version or release of ORACLE you should do a normal shutdown and full offline backups. 1.2 Migration to ORACLE7 ========================== Migrating ORACLE Version 6 to ORACLE7 is supported. **All** ORACLE Version 6 tablespaces MUST be online for the migration utility. ONCE YOU MIGRATE A DATABASE TO ORACLE7, YOU MUST **NOT** RUN ORACLE VERSION 6 AGAINST THAT DATABASE. Migrating from ORACLE Version 6 is documented in the ORACLE7 Server Migration Guide, part number 6617-70. 1.3 PL/SQL ============ REMINDER: Use of PL/SQL with ORACLE servers requires that your site be licensed for the procedural option. See your cover letter for more details. Triggers and Handling Remote Exceptions --------------------------------------- A trigger that accesses a remote site cannot do remote exception handling if the network link is unavailable. For example: create trigger EXAMPLE after insert on EMP for each row begin insert into EMP@REMOTE -- <- compilation fails here values ('X'); -- when dblink is inaccessible exception when others then insert into EMP_LOG values ('X'); end; A trigger is compiled the first time it is called; thus, if a dblink is down when the trigger must compile, ORACLE cannot validate the statement accessing the remote database, and the compilation fails. The example exception statement cannot execute because the trigger does not complete compilation. Since stored procedures are stored in a compiled form, the work-around for the above example would be to do the following: create trigger EXAMPLE after insert on EMP for each row begin INSERT_ROW_PROC; end; create procedure INSERT_ROW_PROC begin insert into EMP@REMOTE values ('X'); exception when others then insert into EMP_LOG values ('X'); end; The trigger in this example compiles successfully and calls the stored procedure which already has a validated statement for accessing the remote database; thus, when the remote INSERT statement fails because the link is down, the exception is caught. 1.4 SQL*DBA ============= When running SQL*DBA in screen mode, your terminal will have a default terminal type dependent on your operating system; for example, on VAX/VMS the default terminal type might be a VT100. You may be able to override your default terminal type by setting an environment variable at the operating system prompt. For example, on VAX/VMS, you can set the ORA_SQLDBA_TERM logical to VT220. 1.5 Initialization Parameters =============================== GLOBAL_NAMES ------------ The documented default for this parameter is NO, but the initialization file you receive with your ORACLE7 package may have GLOBAL_NAMES set to YES. When this parameter is not given a value, it defaults (as documented) to NO. LOG_CHECKPOINTS_TO_ALERT ------------------------ Default : NO Range of values : YES/NO This parameter allows you to log your checkpoints to the alert file. This parameter is occasionally useful when determining whether more checkpoint processes are required. MAX_COMMIT_PROPAGATION_DELAY ---------------------------- Default : 90000 Range of values : 0..90000 OK to change? : No Multiple instances: Must have identical values. This initialization parameter should not be changed except under a limited set of circumstance specific to using the Parallel Server. This parameter indicates the maximum amount of time allowed before the system change number (SCN) held in the SGA of an instance is refreshed by LGWR. Units are in hundredths of seconds. Under very unusual circumstances, involving rapid updates and queries of the same data from different instances, the SCN may not be refreshed in a timely manner. Setting the parameter to zero enforces that the SCN is refreshed immediately after a commit. The default value of 90,000 hundredths of a second, or fifteen minutes, is an upper bound that allows the preferred existing high performance mechanism to remain in place. PRE_PAGE_SGA ------------ Default value : NO Range of values : NO/YES OK to change : No When set to YES, this parameter touches all the SGA pages, causing them to be brought into memory. As a result, it increases instance startup time and user login time, but it can reduce the number of page faults that occur shortly thereafter. The reduction in page faults allows the database to reach its maximum performance capability quickly, rather than an incremental build up. It is most useful on systems that have sufficient memory to hold all the SGA pages without degrading performance in other areas. SNAPSHOT_REFRESH_PROCESSES -------------------------- Default : 0 Range of values : 0..10 Multiple instances: May have different values This parameter sets the number of snapshot refresh processes per instance. If you wish to have your snapshots done automatically, you must set this parameter to a value of one or higher. One snapshot refresh process will usually be sufficient unless there is a requirement for a large number of snapshots which refresh simultaneously. This parameter is relevant to the new Snapshot Refresh process as described in the "Snapshot Refresh Process" section of part 1.8, "New features NOT Documented." SNAPSHOT_REFRESH_INTERVAL ------------------------- Default : 60 (one minute) Range of values : 1..3600 seconds (1 second to 60 minutes) Multiple instances: May have different values This parameter sets the interval between wake-ups for the snapshot refresh processes on the instance. This parameter is relevant to the new Snapshot Refresh process as described in the "Snapshot Refresh Process" section of part 1.8, "New features NOT Documented." SNAPSHOT_REFRESH_KEEP_CONNECTIONS --------------------------------- Default : FALSE Range of values : TRUE / FALSE Multiple instances: May have different values This parameter specifies whether the snapshot refresh processes should keep remote database connections after all snapshots are refreshed. If set to FALSE, remote database connections made for the purpose of refreshing snapshots are closed after all the refreshes are complete. 1.6 Data Dictionary Views =========================== The following data dictionary views are new in ORACLE7 but were introduced after the documentation was completed. NLS_SESSION_PARAMETERS ---------------------- This view is only relevant if you use National Language Support; it provides a list of the session based NLS settings. There are three levels of NLS settings. This view along with NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS you allow to clearly see which NLS parameter is active. Column Name Description PARAMETER The name of the NLS parameter. It can be any of the following: NLS_LANGUAGE, NLS_TERRITORY, NLS_CURRENCY, NLS_ISO_CURRENCY, NLS_NUMERIC_CHARACTERS, NLS_DATE_FORMAT, NLS_DATE_LANGUAGE, NLS_SORT VALUE The value of the NLS parameter. NLS_INSTANCE_PARAMETERS ----------------------- This view is only relevant if you use National Language Support; it provides a list of the instance based NLS settings. There are three levels of NLS settings. This view along with NLS_SESSION_PARAMETERS and NLS_DATABASE_PARAMETERS you allow to clearly see which NLS parameter is active. Column Name Description PARAMETER The name of the NLS parameter. It can be any of the following: NLS_LANGUAGE, NLS_TERRITORY, NLS_CURRENCY, NLS_ISO_CURRENCY, NLS_NUMERIC_CHARACTERS, NLS_DATE_FORMAT, NLS_DATE_LANGUAGE, NLS_SORT VALUE The value of the NLS parameter. NLS_DATABASE_PARAMETERS ----------------------- This view is only relevant if you use National Language Support; it provides a list of the database based NLS settings. There are three levels of NLS settings. This view along with NLS_SESSION_PARAMETERS and NLS_INSTANCE_PARAMETERS allow you to clearly see which NLS parameter is active. Column Name Description PARAMETER The name of the NLS parameter. It can be any of the following: NLS_LANGUAGE, NLS_TERRITORY, NLS_CURRENCY, NLS_ISO_CURRENCY, NLS_NUMERIC_CHARACTERS, NLS_DATE_FORMAT, NLS_DATE_LANGUAGE, NLS_SORT VALUE The value of the NLS parameter. V$MTS ----- This view gives tuning information pertinent to the multi-threaded server. Column Name Datatype Description MAXIMUM_CONNECTIONS The maximum number of connections each dispatcher NUMBER can support. This value is determined at startup time using SQL*Net constants and other port specific information. shared server processes x3.instead of mt servers... SERVERS_STARTED The total number of multi-threaded servers started NUMBER since the instance started (but not including started during startup). SERVERS_TERMINATED The total number of multi-threaded servers stopped NUMBER by ORACLE since the instance started. SERVERS_HIGHWATER The high-water mark for the number of multi- NUMBER threaded servers. This value is the highest number of servers running at one time since the instance started. If this value reaches the value set for the MTS_MAX_SERVERS initialization parameter, the DBA should consider raising the value of MTS_MAX_SERVERS. V$SESSION_EVENTS ---------------- This view gives wait statistics for each session and each event. Column Name Datatype Description SID NUMBER Session Identification number. EVENT VARCHAR2 Event description. TOTAL_WAITS NUMBER Total number of waits for the event. TIME_WAITED NUMBER Total time waited for event in hundredths of seconds. AVERAGE_WAIT NUMBER Average time waited for event in hundredths of seconds. V$SYSTEM_EVENTS --------------- This view is a system-wide collation of the per session event statistics. Column Name Datatype Description EVENT VARCHAR2 Event description. TOTAL_WAITS NUMBER Total number of waits for the event. TIME_WAITED NUMBER Total time waited for event in hundredths of seconds. AVERAGE_WAIT NUMBER Average time waited for event in hundredths of seconds. New DELETE_RULE Column ---------------------- The following views (documented in the ORACLE7 Server Adminstrator's Guide, part number 6694-70): ALL_CONSTRAINTS DBA_CONSTRAINTS USER_CONSTRAINTS have the following new column added: DELETE_RULE This column has the following values: NULL indicating a non-referential constraint CASCADE indicating a delete cascade referential constraint NO ACTION indicating any other referential constraint type New Status Column ----------------- The new column STATUS is added to the V$LOG view and has the following values: UNUSED indicates the online redo log has not been written to. This is the state of a redo log that was just added or just after a RESETLOGS when it is not the current redo log. CURRENT indicates this is the current redo log. This implies that the redo log is active. The redo log could be open or closed. ACTIVE indicate the log is active but is not the current log. It is needed for crash recover. It may be in use for block recovery. It might or might not be archived. INACTIVE indicate the log is no longer needed for crash recovery. It may be in use for media recover. It might or might not be archived. 1.7 Preparing for Future Versions =================================== Beyond ORACLE7, future versions will have changes that can be prepared for now. The following recommendations, if followed, will simplify migration to newer versions of ORACLE. Change Recommendation --------------------------------- ---------------------------------------- A string of zero length ('') Your application should use a NULL when will not be equivalent to a NULL. the value is unknown. The VARCHAR datatype is currently Use only the VARCHAR2 datatype for synonymous with the VARCHAR2 variable-length character strings. datatype. The VARCHAR datatype uses different comparison semantics and will distinguish zero length strings from null. Rule-based optimization will no To tune queries, use hints in SQL longer be supplied. statements to direct the optimizer. Do not rely on the syntax of the SQL statement to guide the optimizer. 1.8 New features NOT Documented ================================= Snapshot Refresh Process (SNPn) ------------------------------- A new type of process exists for the ORACLE server, called a snapshot refresh process. An instance can have up to 10 of these processes, name SNP0 to SNP9. These processes wake up periodically and refresh any snapshots that are scheduled to be automatically refreshed. If an instance has multiple snapshot refresh processes, the task of updating the snapshots can be shared across these processes. Snapshot refresh processes differ from other background processes as follows: o the SNPn trace filename does not include the process name o failure of the SNPn process does NOT cause the instance to fail You use three initialization parameters to control the operation of the snapshot refresh processes. Set these in the initialization parameter file for an instance and they take effect the next time you start the instance. (Modifying the initialization parameter file is explained in the ORACLE7 Server Administrator's Guide, part number 6694-70.) The snapshot refresh process parameters are as follows: o SNAPSHOT_REFRESH_PROCESSES o SNAPSHOT_REFRESH_INTERVAL o SNAPSHOT_REFRESH_KEEP_CONNECTIONS These parameters are described in 1.5, "Initialization Parameters." DBMS_SNAPSHOT.REFRESH --------------------- The 'refresh_all' option does NOT return any errors, regardless of the results of the refresh. Any errors encountered are logged in a trace file. An unsuccessfully refreshed snapshot remains as it was and is NOT refreshed by the automatic snapshot mechanism until a manual refresh is done. (Of course, the manual refresh will not work until the underlying problem is fixed.) DBMS_TRANSACTION.PURGE_MIXED ---------------------------- The purge_mixed procedure is added to the dbms_transaction supplied package. Manually forcing in-doubt transactions (rather than allowing automatic recovery) can compromise these transactions; some sites may commit while other sites may rollback. The transaction is said to be of 'mixed outcome.' Such inconsistencies cannot be resolved by ORACLE, but the server notes the in-doubt transactions in DBA_2PC_PENDING, where the MIXED column is set to 'YES'. ORACLE never deletes information about in-doubt transactions that are of mixed outcome. When the DBA (or application) is sure all inconsistencies that arose as a result of the mixed outcome are resolved, the DBMS_TRANSACTION.PURGE_MIXED can be used to purge the information. Input Parameters Description ---------- ----------- XID This must be set to the value of the LOCAL_TRAN_ID column in the DBA_2PC_PENDING table. Output Parameters Description ---------- ----------- - none - DBMS_UTILITY.NAME_RESOLVE ------------------------- The name_resolve procedure is added to the dbms_utility supplied package. This routine does name resolution with any necessary synonym translation and authorization checking. Input Parameters Description ---------- ----------- NAME The object name to be resolved. This can be of the form [[a.]b.]c[@d] where a, b, and c are SQL identifiers and d is a dblink. No syntax checking is perform on the dblink (see output parameter DBLINK). a, b, and c may be delimited identifiers and may contain single and multi-byte NLS characters. CONTEXT Not currently used, but should be set to 1 for future compatibility. Output Parameters Description ---------- ----------- SCHEMA The object schema name. If no schema is specified in the input NAME, then the schema name is determined by resolving NAME. PART1 The first of name. The type of this name is specified by the output PART1_TYPE parameter described below. PART2 If this is not null, then this a procedure name within the package indicated by PART1. DBLINK If this is not null, then a dblink is specified in input NAME or NAME is a synonym and the name resolution found a dblink (in which case, the PART1 output parameter indicates a synonym). PART1_TYPE The object type: 5 = synonym 7 = procedure 8 = function (top level) 9 = package (top level) If the object type indicates a synonym, then the translation of input NAME found a dblink; if further translation is required, you must call dbms_utility.name_resolve on the remote node indicated by the dblink. OBJECT_NUMBER If not null, then input NAME was successfully resolved and OBJECT_NUMBER is the resolved object number. 1.9 National Language Support =============================== This section is relevant only to users who use National Language Support features. NLS_LANGUAGE ------------ Before upgrading to ORACLE7, ensure that the NLS_LANGUAGE initialization parameter is set to the character set of the data. CHARSET ------- The CHARSET parameter on the Import utility command line is only relevant for ORACLE Version 6 export files. CHARSET is used to indicate the character set of the data in the export file. (ORACLE7 export files are created with the character set name embedded in the file.) See also next paragraph. Import/Export and Single-Byte Character Sets -------------------------------------------- Some 8-bit characters can be "lost" when importing an 8-bit character set export file if the client machine has a native 7-bit character set or is started with the NLS_LANG operating system environment parameter set to a 7-bit character set. By "lost" is meant that some 8-bit characters are converted to 7-bit equivalents; typically, European characters which have accents lose the accent and become the letter without the accent. This problem occurs because the 8-bit characters in the export file are converted to 7-bit characters via the client application and when sent to the database are converted by the server into 8-bit characters. To avoid this problem it is necessary to turn off one of these conversions. One possibility is by setting NLS_LANG to the character set of the export file data. When importing an ORACLE Version 6 export file with a character set different than that of the native operating system or the setting for NLS_LANG, you need to set the CHARSET import parameter to indicate the characterset of the export file data. 2.0 Information for Upgrading from ORACLE Version 5 ===================================================== ===================================================== ===================================================== 2.1 Before You Install ORACLE7 ================================ Normal Shutdown and Full Offline Backup --------------------------------------- When upgrading to a newer version or release of ORACLE you should do a normal shutdown and full offline backups. 2.2 Migration to ORACLE7 ========================== Migrating from ORACLE Version 5 to ORACLE7 is supported using the import/ export utitilities. The following are known problems when exporting from ORACLE Version 5 and importing to ORACLE7. COLUMN LEVEL GRANTS ORACLE Version 5 column grants are NOT imported into ORACLE7. After the import, you must grant the user the appropriate privileges per column. DEPENDENCIES IN VIEWS AND SYNONYMS ORACLE Version 5 views and synonyms are NOT created in the correct order when dependencies exists. Re-run the import each time there is a dependency error (with the qualifiers IGNORE=Y, ROWS=N, INDEXES=N, and CONSTRAINTS=N), until all database objects are created. Then, re-run the import with the qualifiers IGNORE=Y, ROWS=Y, INDEXES=Y, and CONSTRAINTS=Y. EXPVEW and EXPTAB Error messages generated when creating these views when importing ORACLE Version 5 to ORACLE7 can be ignored. 3.0 Information for Upgrading from Pre-Production ORACLE7 =========================================================== =========================================================== =========================================================== *** MAKE SURE YOU READ THE MIGRATION PART 3.2 *** Part 3 of the README is relevant only to users who have a developer's release of ORACLE7 and wish to upgrade to the production release of ORACLE7. For this part of the README it is assumed that you have a pre- production release; that is, either 7.0.9, 7.0.10, or 7.0.11. Note: You should also read Part 1 of this README, as it describes features that are not documented in the production manuals. (You may have noted that this README is much smaller than previous pre-production READMEs. This is because almost all issues are fully documented in the production manuals.) 3.1 BEFORE YOU INSTALL RELEASE 7.0.12 ======================================= Normal Shutdown and Full Offline Backup --------------------------------------- When upgrading to a newer version or release of ORACLE you should do a normal shutdown and full offline backups. If you are upgrading from 7.0.9, 7.0.10, or 7.0.11, you MUST do a normal shutdown due to changes in the redo log format. ALL ORACLE7 Servers Must be Upgraded to 7.0.12 ---------------------------------------------- Due to small changes between releases the pre-production releases cannot communicate with each other or wih the production release. All production releases are guaranteed to be fully interoperable. Once you upgrade to the production release, you MUST NOT access the database with an older pre-production release of ORACLE7 or you might encounter problems. For example, if after upgrading you brought a database up with an old release, you might encounter the following type of problem: users created with a newer password encryption method might not be able to connect; a dblink might not work because of changes in SQL*Net; an application might give unpredictable results because it is linked with a newer object library. To upgrade to production ORACLE7, you MUST DO THE FOLLOWING: o re-link ALL servers and applications with the 7.0.12 libraries o upgrade all older ORACLE7 databases to 7.0.12 Once you upgrade to production ORACLE7, you should continue to use the production release. Downgrading ----------- If you upgrade from 7.0.11, then fallback to 7.0.11 is supported. To downgrade to 7.0.11, ensure that rollback segments with a PARTIAL-AVAILABLE status are returned to INUSE status and brought online before the database shutdown. If you upgrade from 7.0.9 or 7.0.10 to 7.0.12 and want to fallback, you must restore the database from the offline backup taken prior to upgrading and then downgrade all servers and clients applications; an export from one release is not guaranteed to be importable to a prior release. Scripts to Run -------------- See the section below on "Migration." 3.2 Migration to ORACLE7 ========================== TO MIGRATE UPWARD FROM 7.0.11, 7.0.10, 7.0.9 OR AN EARLIER RELEASE OF ORACLE7, YOU MUST USE THE EXPORT/IMPORT UTILITY. Upgrading 7.0.11 to 7.0.12 ========================== AFTER UPGRADING 7.0.11 TO 7.0.12, YOU MUST RUN THE FOLLOWING SCRIPTS IN THE EXACT ORDER GIVEN: cat712 catalog catproc (run this script **only** if you have the procedural option) catparr (run this script **only** if you have the Parallel Server option) Upgrading 7.0.10 to 7.0.12 ========================== After upgrading 7.0.10 to 7.0.12, YOU **CANNOT** DOWNGRADE TO 7.0.10. (Changes were made to the bootstrap segment to ensure interoperation for post-7.0.12 versions.) BEFORE UPGRADING 7.0.10 TO 7.0.12, YOU MUST DO A CLEAN SHUTDOWN AND A FULL BACKUP. THEN, RESTART YOUR DATABASE, AND DO THE FOLLOWING: delete from idl_ub1$ where obj# in (select obj# from obj$ where name in ('TAB$','CLU$','FET$','UET$','SEG$','UNDO$',TS$','FILE$','OBJ$','IND$', 'ICOL$','COL$','USER$','CON$','CDEF$','CCOL$','BOOTSTRAP$')) / delete from idl_char$ where obj# in (select obj# from obj$ where name in ('TAB$','CLU$','FET$','UET$','SEG$','UNDO$',TS$','FILE$','OBJ$','IND$', 'ICOL$','COL$','USER$','CON$','CDEF$','CCOL$','BOOTSTRAP$')) / delete from idl_ub2$ where obj# in (select obj# from obj$ where name in ('TAB$','CLU$','FET$','UET$','SEG$','UNDO$',TS$','FILE$','OBJ$','IND$', 'ICOL$','COL$','USER$','CON$','CDEF$','CCOL$','BOOTSTRAP$')) / delete from idl_sb4$ where obj# in (select obj# from obj$ where name in ('TAB$','CLU$','FET$','UET$','SEG$','UNDO$',TS$','FILE$','OBJ$','IND$', 'ICOL$','COL$','USER$','CON$','CDEF$','CCOL$','BOOTSTRAP$')) / commit AFTER UPGRADING 7.0.10 TO 7.0.12, YOU MUST RUN THE FOLLOWING SCRIPTS IN THE EXACT ORDER GIVEN: cat711 cat712 catalog catproc (run this script **only** if you have the procedural option) catparr (run this script **only** if you have the parallel server option) 3.3 Other Server Changes ========================== Import/Export and Multi-Byte Character Sets ------------------------------------------- If you use National Language Support, note that a multi-byte character set export file must be imported on a system that uses the same multi-byte character set. Auditing -------- This section is only relevant if you are upgrading from 7.0.10 to 7.0.12. Each statement privilege or object privilege audited has a 'numeric audit trail action type code.' (The AUDIT_ACTIONS data dictionary view can be used to see which audit actions are active.) Prior to 7.0.11, some codes were used to represent both a statement privilege and an object privilege. From 7.0.11 onwards, one code represents only one privilege type. If you are upgrading from pre-7.0.11, then do the following: o make a note of the audit commands that create your current audit trail o upgrade to 7.0.12 o re-enter all audit commands to ensure a valid audit trail Leading Zero ------------ Prior to the 7.0.11 release, the following statement: select .1234 small from dual; produced: SMALL ====== 0.1234 From 7.0.11 onwards --- as in ORACLE Version 6 --- the same statement produces the following: SMALL ====== .1234 Note that the difference is pre-7.0.11 releases behavior show a leading zero, and behavior thereafter produces a leading blank space. Hints ----- The NOCOST hint is now the RULE hint. The COST hint is replaced with the FIRST_ROWS and ALL_ROWS hints. See the production documentation for further details. See also Part 3.5, "Initialization Parameters." Obsolete OCI Calls ------------------ Obsoleted OCI calls that were still available in pre-7.0.12 object libraries are no longer supported. Using Tables of LONGS Problem Fixed ----------------------------------- In 7.0.11, it was possible to run out of memory if repeatedly passing and getting large indexed tables (large elements or many elements) to and from procedures. This problem no longer occurs. Size Constraints on VARCHAR and VARCHAR2 ---------------------------------------- Beginning with PL/SQL Version 2, size constraints for VARCHAR and VARCHAR2 are consistent with SQL in ORACLE7. Both the ORACLE server and PL/SQL require size constraints; that is, a maximum size, since there are no defaults for VARCHAR and VARCHAR2. In PL/SQL Version 1, used with ORACLE Version 6, there were no size constraints on VARCHAR and VARCHAR2 datatypes, and when declared with no size, defaulted to a size of one. PL/SQL Version 1 behavior does not match that of ORACLE Version 6 and is corrected in ORACLE7 as noted above. Bind Data Types using OCI or Precompilers ----------------------------------------- Trying to bind data of type SQLT_AVC to an indexed-table that is declared with element type VARCHAR2, returns an error indication. Trying to bind data of type SQLT_CHR to an indexed-table that is declared with element type CHAR (that is, ANSI fixed char), returns an error indication. Initialization Parameters ------------------------- The following parameters were deleted in 7.0.12: OPTIMIZER_COMP_WEIGHT The following parameters were renamed in 7.0.12: Old Name New Name OPEN_COMPATIBLE COMPATIBLE_OPEN OPTIMIZER_OVERRIDE OPTIMIZER_MODE RECOVERY_COMPATIBLE COMPATIBLE Note also that the OPTIMIZER_MODE values differ from OPTIMIZER_OVERRIDE as described in the ORACLE7 Server Administrator's Guide, part number 6694-70. System Scripts -------------- A consistent naming convention was implemented in 7.0.12 for supplied SQL scripts. For example, STDEXT.SQL became DBMSSTDE.SQL. Here is the convention for the cat*.sql files: catalog.sql is for all installations catproc.sql is for installations with procedural option catparr.sql is for installations with the parallel server option catddb.sql is for installations with the distributed database option Here is a complete list of supplied SQL scripts: Old Name New Name -------- -------- audit cataudit blocking catblock bstat utlbstat catalog catalog catalog6 catalog6 catalog5 catalog5 chainrow utlchain dba_syn catdbsyn dbmsalrt dbmsalrt dbmslock dbmslock dbmsmail dbmsmail dbmspipe dbmspipe dbmsutil dbmsutil deptree utldtree dispidxs utlidxsd estat utlestat except utlexcpt expeob6 utlexp6 expvew catexp expvew6 catexp6 idxstat utlidxss kglr catddb locktree utllockt m710711 cat711 m711712 cat712 mailupgd utlmail monitor utlmontr noaudit catnoaud noprctrg catnoprc oneidxs utlidxso prctrg catproc psviews catparr snapshot dbmssnap snapvew catsnap sqlbld utlsampl stdext dbmsstdx trusted dbmstrst xplainpl utlxplan 4.0 Known Restrictions ======================== ======================== ======================== GENERAL NOTE: The known restrictions listed below that require fixes will soon be corrected in patch releases. Multi-Threaded Server --------------------- The multi-threaded server is available for development purposes only. A production release will be available in the near future. Pre-7.0.12, resource limits did not always work correctly when running the multi-threaded server. This problem is fixed. Do NOT Analyze System Tables ---------------------------- You should not use the analyze command on the tables owned by user SYS. Using the analyze command to gather or compute statistics on certain sys tables will cause deadlocks. In this release the data dictionary views which reference the sys tables are designed to execute efficiently using rule based optimization. Different STANDARD.SQL Versions at Sites ---------------------------------------- If the two ORACLE7 sites have different versions of STANDARD.SQL and one site makes a remote procedure call to the other, internal errors occur. To use remote procedure calls, all ORACLE7 sites must use the same STANDARD.SQL. Incremental Import and Constrained Table ---------------------------------------- Incremental import does not work when there are referential integrity constraints on the table being imported. One work around is to create the table before beginning the import, defining the constraints in the disabled state. Alternatively, you can pre-create the table without constraints and define the constraints after the data is loaded. In either case, you must select the import option that directs import to ignore errors due to object existence. UNIQUE Constraint and EXCEPTIONS Clause --------------------------------------- The EXCEPTIONS clause does not work when adding a UNIQUE constraint on a table. PL/SQL Tables of LONGS ---------------------- It is currently not possible to bind host-language arrays of PL/SQL tables of LONGs. A single LONG or a table of VARCHARs may be used as a work-around. Cursors and Packages -------------------- Currently a package specification and a package body can be compiled separately. When a package specification contains a cursor specification and the package body contains the cursor body, it is possible for an inconsistent cursor state to arise. Consider the following scenario: o a stored procedure opens a cursor spread across a package specification/body o the package body instantiation gets dropped (because, for example, the package body got re-compiled automaically because of dependency checking) At this point, the cursor specification/body state is inconsistent; the package specification "thinks" the cursor is open and the package body "thinks" the cursor is closed. To minimize or prevent this problem use the following techniques: o declare the cursor in the package body outside the definition of any procedure, making it a private package object o always re-compile the package body and the package specification o ensure that all references to a cursor are from procedures within the same package that defines the cursor ALTER SYSTEM KILL SESSION and the Parallel Server ------------------------------------------------- The ALTER SYSTEM KILL SESSION command is restricted when running in parallel mode (which requires the Parallel Server option) and has no effect; rather than using this command, you must shutdown and restart the instance. Importing Very Large Objects ---------------------------- If your Import BUFFER size is too small, trying to import a very large object will fail. This is not inconsistent with the functionality of the utility. The solution is too simply increase the BUFFER size as described in the ORACLE7 Server Utilities Guide, part number 3602-70. Unfortunately, it is not always obvious when the BUFFER size is too small; a variety of different messages are generated depending on the object type and it may be confusing if you do not know that the object being imported is very large. For example, while message, "IMP-00020, column (size 50000) in export file too large for column buffer (size 32767)" is meaningful, message "IMP-00008, unrecognized statement in export file" is not. When importing, if you know ahead of time that you are importing a large object, you can watch out for this problem with confusing messages. <End_Of_README_Document>