oracle®rdb7foropenvms releasenotesdownload.oracle.com/otn_hosted_doc/rdb/pdf/rdbrn_7031.pdf ·...

Oracle®Rdb7 forOpenVMSReleaseNotes

Release 7.0.3.1

October 1999

Oracle Rdb7 Release Notes

Release 7.0.3.1

Copyright © 1999, Oracle Corporation. All rights reserved.

The Programs (which include both the software and documentation) contain proprietary informationof Oracle Corporation; they are provided under a license agreement containing restrictions on useand disclosure and are also protected by copyright, patent, and other intellectual and industrialproperty laws. Reverse engineering, disassembly, or decompilation of the Programs is prohibited.

The information contained in this document is subject to change without notice. If you find anyproblems in the documentation, please report them to us in writing. Oracle Corporation does notwarrant that this document is error free. Except as may be expressly permitted in your licenseagreement for these Programs, no part of these Programs may be reproduced or transmitted inany form or by any means, electronic or mechanical, for any purpose, without the express writtenpermission of Oracle Corporation.

If the Programs are delivered to the US Government or anyone licensing or using the Programs onbehalf of the US Government, the following notice is applicable:

RESTRICTED RIGHTS NOTICE

Programs delivered subject to the DOD FAR Supplement are ’commercial computer software’ anduse, duplication and disclosure of the Programs including documentation, shall be subject to thelicensing restrictions set forth in the applicable Oracle license agreement. Otherwise, Programsdelivered subject to the Federal Acquisition Regulations are ’restricted computer software’ and use,duplication and disclosure of the Programs shall be subject to the restrictions in FAR 52.227-19,Commercial Computer Software - Restricted Rights (June, 1987). Oracle Corporation, 500 OracleParkway, Redwood City, CA 94065.

The Programs are not intended for use in any nuclear, aviation, mass transit, medical, or otherinherently dangerous applications. It shall be licensee’s responsibility to take all appropriate fail-safe, back up, redundancy and other measures to ensure the safe use of such applications if thePrograms are used for such purposes, and Oracle disclaims liability for any damages caused bysuch use of the Programs.

Oracle is a registered trademark, and Oracle7, Oracle Expert, Oracle Rally, Oracle Rdb, OracleSQL/Services, and Rdb7 are trademarks or registered trademarks of Oracle Corporation. Allother company or product names mentioned are used for identification purposes only and may betrademarks of their respective owners.

This document was prepared using VAX DOCUMENT, Version 2.0.

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

1 Installing Oracle Rdb7 Release 7.0.3.1

1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–11.2 Invoking VMSINSTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–11.3 Stopping the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–21.4 After Installing Oracle Rdb7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–21.5 New Documentation HTML Save Sets Available . . . . . . . . . . . . . . . . . . . . 1–21.6 Alpha EV6 Processor Support Added . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–31.7 Maximum OpenVMS Version Check Added . . . . . . . . . . . . . . . . . . . . . . . . 1–3

2 Software Errors Fixed in Oracle Rdb7 Release 7.0.3.1

2.1 Software Errors Fixed That Apply to All Interfaces . . . . . . . . . . . . . . . . . . 2–12.1.1 Leaf Cardinality Problem in Sorted Ranked Indexes . . . . . . . . . . . . . . 2–12.1.2 Corruption of Ranked Index Node During Duplicate Deletion . . . . . . . 2–12.1.3 Deadlock on AIP Larea Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22.1.4 Online ALTER STORAGE AREA Operations and Row Cache . . . . . . . 2–22.1.5 Inconsistent Enforcement of RESERVE Limits . . . . . . . . . . . . . . . . . . 2–22.1.6 ABS Initialization of AIJ Journal Causes System Slowdown . . . . . . . . 2–32.1.7 Transaction Checkpoint Determination of Switchover or Backup . . . . . 2–42.1.8 Non-Update Read/Write Transactions Do Not Validate Checkpoint

Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–42.1.9 Lowercase Characters Cannot Be Used as Escape Character in a

LIKE Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–42.1.10 ACCVIO if RDM$BIND_STT_NETWORK_TRANSPORT Logical

Defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–52.1.11 RMU/SHOW Statistic Cluster Collection Failure . . . . . . . . . . . . . . . . . 2–52.1.12 Error Creating RUJ When Default RUJ Directory Does Not Exist . . . 2–52.1.13 Process May Stall in an Infinite Wait for a GBPT Slot Latch . . . . . . . 2–62.1.14 RDMS-F-NOREQIDT Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–62.1.15 AIJ Work File Search List Capability . . . . . . . . . . . . . . . . . . . . . . . . . 2–72.1.16 Failed Backup of Extensible AIJ Causes Gap in Sequence

Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–72.1.17 Improper Column Reference in CREATE TRIGGER Now Detected . . . 2–72.1.18 Bugcheck in DIO$FREE_CURRENT_LOCK . . . . . . . . . . . . . . . . . . . . 2–82.2 SQL Errors Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–82.2.1 Improved Optimization for NULLIF Expression with Subselect . . . . . 2–82.2.2 Correct JOIN Syntax Generated Error and Bugcheck . . . . . . . . . . . . . 2–102.2.3 Incorrect Results from Oracle7 Outer Join Syntax . . . . . . . . . . . . . . . . 2–102.2.3.1 Outer Joins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–122.2.3.2 Outer Join Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–13

iii

2.2.4 MAPPING VALUES Not Supported for CREATE INDEX inIMPORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16

2.2.5 SELECT Returns Incorrect Values for GROUP BY Queries . . . . . . . . . 2–162.2.6 Restrictions on CURRENT_TIMESTAMP Default Value Lifted . . . . . . 2–172.2.7 SQL Uses Read/Write Transactions Against Standby Database . . . . . . 2–182.2.8 Domain Constraints Did Not Support Function Calls Passing

VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–192.2.9 CREATE VIEW May Fail on Large or Complex View Definition . . . . . 2–192.2.10 Incomplete Support for Multischema Databases for Query

Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–202.2.11 UNKNOWN_VAR Error Reported During Select from a View . . . . . . . 2–212.2.12 SQL Module Language Compiler Fails Unexpectedly . . . . . . . . . . . . . 2–212.2.13 ORDER BY Select Query from a View with ORDER BY on the Same

COMPUTED BY Column Returns Wrong Result . . . . . . . . . . . . . . . . . 2–222.3 Oracle RMU Errors Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–232.3.1 Lock ID Hidden by Stall Message in RMU/SHOW Statistics . . . . . . . . 2–232.3.2 Terminal Width Checked by RMU/SHOW Statistics . . . . . . . . . . . . . . 2–232.3.3 RMU/SHOW Statistic Physical-Area Event Creation Bugchecks . . . . . 2–242.3.4 Ignore Row Caches when Writing RMU/SHOW Statistic Report . . . . . 2–242.3.5 RMU/LOAD from a Record-Oriented Device Caused RMS-F-IOP

Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–242.3.6 RMU/EXTRACT Sometimes Bugchecks when Processing Many

Storage Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–252.3.7 Problem in Reporting Recovered AIJ Sequence Number . . . . . . . . . . . 2–252.3.8 Truncate Table Could Generate RMU/VERIFY Errors . . . . . . . . . . . . 2–252.4 Row Cache Errors Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–262.4.1 Row Cache of One Slot Causes Loop . . . . . . . . . . . . . . . . . . . . . . . . . . 2–262.5 Hot Standby Errors Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–262.5.1 Stopping Hot Standby on Standby then Master Hangs Standby for 15

Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–262.5.2 Monitor ENQLM Minimum Increased to 32767 . . . . . . . . . . . . . . . . . . 2–262.6 Oracle Trace Errors Fixed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–262.6.1 Incorrect Completion Status Reported by Oracle Trace . . . . . . . . . . . . 2–27

3 Documentation Corrections

3.1 Documentation Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–13.1.1 Partition Clause is Optional on CREATE STORAGE MAP . . . . . . . . . 3–13.1.2 Oracle Rdb Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–13.1.3 Waiting for Client Lock Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–13.1.4 Documentation Error in Oracle Rdb7 Guide to Database Performance

and Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–33.1.5 SET FLAGS Option IGNORE_OUTLINE Not Available . . . . . . . . . . . 3–33.1.6 SET FLAGS Option INTERNALS Not Described . . . . . . . . . . . . . . . . . 3–33.1.7 Documentation for VALIDATE_ROUTINE Keyword for SET

FLAGS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–43.1.8 Documentation for Defining the RDBSERVER Logical Name . . . . . . . 3–43.1.9 Undocumented SET Commands and Language Options . . . . . . . . . . . 3–53.1.9.1 QUIET COMMIT Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–53.1.9.2 COMPOUND TRANSACTIONS Option . . . . . . . . . . . . . . . . . . . . . 3–63.1.10 Undocumented Size Limit for Indexes with Keys Using Collating

Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–73.1.11 Changes to RMU/REPLICATE AFTER/BUFFERS Command . . . . . . . 3–83.1.12 Change in the Way RDMAIJ Server is Set Up in UCX . . . . . . . . . . . . 3–8

iv

3.1.13 CREATE INDEX Supported for Hot Standby . . . . . . . . . . . . . . . . . . . . 3–93.1.14 Dynamic OR Optimization Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–9

4 Known Problems and Restrictions

4.0.1 AIJSERVER Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14.0.2 Lock Remastering and Hot Standby . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14.0.3 RDB_SETUP Privilege Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24.0.4 Dynamic Optimizer Problem with Zigzag Match . . . . . . . . . . . . . . . . . 4–24.0.5 Starting Hot Standby on Restored Standby Database May Corrupt

Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34.0.6 Restriction on Compound Statement Nesting Levels . . . . . . . . . . . . . . 4–34.0.7 Back Up All AIJ Journals Before Performing a Hot Standby

Switchover Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44.0.8 Concurrent DDL and Read-Only Transaction on the Same Table Not

Compatible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44.0.9 Oracle Rdb and the SRM_CHECK Tool . . . . . . . . . . . . . . . . . . . . . . . . 4–54.0.10 Oracle RMU Checksum_Verification Qualifier . . . . . . . . . . . . . . . . . . . 4–54.0.11 Do Not Use HYPERSORT with RMU/OPTIMIZE/AFTER_JOURNAL

(Alpha) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64.0.12 Restriction on Using /NOONLINE with Hot Standby . . . . . . . . . . . . . 4–64.0.13 SELECT Query May Bugcheck with

PSII2SCANGETNEXTBBCDUPLICATE Error . . . . . . . . . . . . . . . . . . 4–74.0.14 DBAPack for Windows 3.1 is Deprecated . . . . . . . . . . . . . . . . . . . . . . . 4–74.0.15 Determining Mode for SQL Non-Stored Procedures . . . . . . . . . . . . . . . 4–74.0.16 DROP TABLE CASCADE Results in %RDB-E-NO_META_UPDATE

Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–94.0.17 Bugcheck Dump Files with Exceptions at COSI_CHF_SIGNAL . . . . . 4–104.0.18 Interruptions Possible when Using Multistatement or Stored

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–104.0.19 Row Cache Not Allowed on Standby Database While Hot Standby

Replication Is Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–114.0.20 Hot Standby Replication Waits when Starting if Read-Only

Transactions Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–124.0.21 Error when Using the SYS$LIBRARY:SQL_FUNCTIONS70.SQL

Oracle Functions Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–124.0.22 DEC C and Use of the /STANDARD Switch . . . . . . . . . . . . . . . . . . . . . 4–124.0.23 Excessive Process Page Faults and Other Performance Considerations

During Oracle Rdb Sorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–134.0.24 Performance Monitor Column Mislabeled . . . . . . . . . . . . . . . . . . . . . . 4–144.0.25 Restriction Using Backup Files Created Later than Oracle Rdb7

Release 7.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–144.0.26 RMU Backup Operations and Tape Drive Types . . . . . . . . . . . . . . . . . 4–154.0.27 Use of Oracle Rdb from Shared Images . . . . . . . . . . . . . . . . . . . . . . . . 4–154.0.28 Interactive SQL Command Line Editor Rejects Eight-Bit

Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–154.0.29 Restriction Added for CREATE STORAGE MAP on Table with

Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–164.0.30 ALTER DOMAIN...DROP DEFAULT Reports DEFVALUNS Error . . . 4–164.0.31 Oracle Rdb7 Workload Collection Can Stop Hot Standby

Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–174.0.32 RMU Convert Command and System Tables . . . . . . . . . . . . . . . . . . . . 4–184.0.33 Converting Single-File Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18

v

4.0.34 Restriction when Adding Storage Areas with Users Attached toDatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–18

4.0.35 Restriction on Tape Usage for Digital UNIX V3.2 . . . . . . . . . . . . . . . . 4–194.0.36 Support for Single-File Databases to be Dropped in a Future

Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–194.0.37 DECdtm Log Stalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–194.0.38 Cannot Run Distributed Transactions on Systems with DECnet/OSI

and OpenVMS Alpha Version 6.1 or OpenVMS VAX Version 6.0 . . . . . 4–204.0.39 Multiblock Page Writes May Require Restore Operation . . . . . . . . . . . 4–204.0.40 Oracle Rdb7 Network Link Failure Does Not Allow DISCONNECT to

Clean Up Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–214.0.41 Replication Option Copy Processes Do Not Process Database Pages

Ahead of an Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–214.0.42 SQL Does Not Display Storage Map Definition After Cascading Delete

of Storage Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–224.0.43 ARITH_EXCEPT or Incorrect Results Using LIKE IGNORE

CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–224.0.44 Different Methods of Limiting Returned Rows from Queries . . . . . . . . 4–224.0.45 Suggestions for Optimal Usage of the SHARED DATA DEFINITION

Clause for Parallel Index Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–234.0.46 Side Effect when Calling Stored Routines . . . . . . . . . . . . . . . . . . . . . . 4–254.0.47 Nested Correlated Subquery Outer References Incorrect . . . . . . . . . . . 4–264.0.48 Considerations when Using Holdable Cursors . . . . . . . . . . . . . . . . . . . 4–284.0.49 INCLUDE SQLDA2 Statement Is Not Supported for SQL Precompiler

for PL/I in Oracle Rdb Release 5.0 or Higher . . . . . . . . . . . . . . . . . . . . 4–294.0.50 SQL Pascal Precompiler Processes ARRAY OF RECORD Declarations

Incorrectly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–294.0.51 RMU Parallel Backup Command Not Supported for Use with SLS . . . 4–304.0.52 Oracle RMU Commands Pause During Tape Rewind . . . . . . . . . . . . . . 4–304.0.53 TA90 and TA92 Tape Drives Are Not Supported on Digital UNIX . . . . 4–304.1 Oracle CDD/Repository Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–304.1.1 Oracle CDD/Repository Compatibility with Oracle Rdb Features . . . . 4–304.1.2 Multischema Databases and CDD/Repository . . . . . . . . . . . . . . . . . . . 4–324.1.3 Interaction of Oracle CDD/Repository Release 5.1 and Oracle RMU

Privileges Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–324.1.3.1 Installing the Corrected CDDSHR Images . . . . . . . . . . . . . . . . . . . 4–344.1.3.2 CDD Conversion Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34

5 Enhancements

5.1 Enhancements Provided in Oracle Rdb7 Release 7.0.3.1 . . . . . . . . . . . . . . 5–15.1.1 Per-Process Monitoring for SHOW STATS . . . . . . . . . . . . . . . . . . . . . . 5–15.1.2 New DOMAINS Option for RMU/EXTRACT . . . . . . . . . . . . . . . . . . . . 5–15.1.3 New NO REORGANIZE clause for ALTER STORAGE MAP . . . . . . . 5–25.1.4 New Options for the GET DIAGNOSTICS Statement . . . . . . . . . . . . . 5–45.1.5 RMU/SHOW Statistic OPCOM Message Tracking . . . . . . . . . . . . . . . . 5–55.1.6 New Restricted_Access Qualifier for RMU/LOAD . . . . . . . . . . . . . . . . 5–85.1.7 RDO EDT Editor on OpenVMS Alpha Now Available . . . . . . . . . . . . . 5–85.1.8 New Options Added to SQL EXTRACT Function . . . . . . . . . . . . . . . . . 5–8

vi

Tables

3–1 Object Type Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24–1 Oracle CDD/Repository Compatibility for Oracle Rdb Features . . . . . . 4–31

vii

Preface

Purpose of This ManualThis manual contains release notes for Oracle Rdb7 Release 7.0.3.1. Thenotes describe changed and enhanced features; upgrade and compatibilityinformation; new and existing software problems and restrictions; and softwareand documentation corrections. These release notes cover both Oracle Rdb7 forOpenVMS Alpha and Oracle Rdb7 for OpenVMS VAX, which are referred to bytheir abbreviated name, Oracle Rdb7.

Intended AudienceThis manual is intended for use by all Oracle Rdb7 users. Read this manualbefore you install, upgrade, or use Oracle Rdb7 Release 7.0.3.1.

Document StructureThis manual consists of five chapters:

Chapter 1 Describes how to install Oracle Rdb7 Release 7.0.3.1.

Chapter 2 Describes software errors corrected in Oracle Rdb7 Release 7.0.3.1.

Chapter 3 Provides information not currently available in the Oracle Rdb7documentation set.

Chapter 4 Describes problems, restrictions, and workarounds known to exist inOracle Rdb7 Release 7.0.3.1.

Chapter 5 Describes enhancements introduced in Oracle Rdb7 Release 7.0.3.1.

vii

1Installing Oracle Rdb7 Release 7.0.3.1

This software update is installed using the standard OpenVMS Install Utility.

1.1 RequirementsThe following conditions must be met in order to install this software update:

• Oracle Rdb7 must be shutdown before you install this update kit. That is,the command file SYS$STARTUP:RMONSTOP(70).COM should be executedbefore proceeding with this installation. If you have an OpenVMS cluster, youmust shutdown all versions of Oracle Rdb7 on all nodes in the cluster beforeproceeding.

• Oracle Rdb7 Release 7.0.3 must have already been installed on your system.

• The installation requires approximately 100,000 free blocks on your systemdisk for OpenVMS VAX systems; 200,000 blocks for OpenVMS Alpha systems.

1.2 Invoking VMSINSTALTo start the installation procedure, invoke the VMSINSTAL command procedure:

@SYS$UPDATE:VMSINSTAL variant-name device-name OPTIONS N

variant-name

The variant names for the software update for Oracle Rdb7 Release 7.0.3.1 are:

• RDBSE1C070 for Oracle Rdb7 for OpenVMS VAX standard version.

• RDBASE1C070 for Oracle Rdb7 for OpenVMS Alpha standard version.

• RDBMVE1C070 for Oracle Rdb7 for OpenVMS VAX multiversion.

• RDBAMVE1C070 for Oracle Rdb7 for OpenVMS Alpha multiversion.

device-name

Use the name of the device on which the media is mounted.

• If the device is a disk drive, such as a CD-ROM reader, you also need tospecify a directory. For CD-ROM distribution, the directory name is the sameas the variant name. For example:

DKA400:[RDBSE1C070.KIT]

• If the device is a magnetic tape drive, you need to specify only the devicename. For example:

MTA0:

OPTIONS N

This parameter prints the release notes.

Installing Oracle Rdb7 Release 7.0.3.1 1–1

The following example shows how to start the installation of the VAX standardkit on device MTA0: and print the release notes:

$ @SYS$UPDATE:VMSINSTAL RDBSE1C070 MTA0: OPTIONS N

1.3 Stopping the InstallationTo stop the installation procedure at any time, press Ctrl/Y. When you pressCtrl/Y, the installation procedure deletes all files it has created up to that pointand exits. You can then start the installation again.

If VMSINSTAL detects any problems during the installation, it notifies youand a prompt asks if you want to continue. You might want to continue theinstallation to see if any additional problems occur. However, the copy of OracleRdb7 installed will probably not be usable.

1.4 After Installing Oracle Rdb7This update provides a new Oracle Rdb7 Oracle TRACE facility definition. AnyOracle TRACE selections that reference Oracle Rdb7 will need to be redefinedto reflect the new facility version number for the updated Oracle Rdb7 facilitydefinition, ‘‘RDBVMSV7.0-31’’.

If you have Oracle TRACE installed on your system and you would like to collectfor Oracle Rdb7, you must insert the new Oracle Rdb7 facility definition includedwith this update kit.

The installation procedure inserts the Oracle Rdb7 facility definition into alibrary file called EPC$FACILITY.TLB. To be able to collect Oracle Rdb7 event-data using Oracle TRACE, you must move this facility definition into the OracleTRACE administration database. Perform the following steps:

1. Extract the definition from the facility library to a file (in this case,RDBVMS.EPC$DEF).

$ LIBRARY /TEXT /EXTRACT=RDBVMSV7.0-31 -_$ /OUT=RDBVMS.EPC$DEF SYS$SHARE:EPC$FACILITY.TLB

2. Insert the facility definition into the Oracle TRACE administration database.

$ COLLECT INSERT DEFINITION RDBVMS.EPC$DEF /REPLACE

Note that if you are installing the multiversion variant of Oracle Rdb7, theprocess executing the INSERT DEFINITION command must use the versionof Oracle Rdb7 that matches the version used to create the Oracle TRACEadministration database or the INSERT DEFINITION command will fail.

1.5 New Documentation HTML Save Sets AvailableIncluded with this release is a new backup save set (RDB_702_HTML.BCK) anda new self-extracting archive file (RDB_702_HTML.EXE) for Windows NT andWindows 95. These new files contain the Oracle Rdb V7.0 (and related products)documentation in HTML format. Documentation is included for the followingproducts:

• Oracle Rdb, Release 7.0

• Rdb Web Agent, Release 2.2

• SQL*Net for Rdb7, Release 7.1.2

• Hot Standby for Oracle Rdb and CODASYL DBMS, Release 7.0

1–2 Installing Oracle Rdb7 Release 7.0.3.1

• Distributed Option for Rdb, Release 7.0

When you expand the RDB_702_HTML.BCK backup save set, the WWW andDOC sub-directories are created and product-specific sub-directories are createdbelow DOC. Be sure to maintain the directory structure by specifying thefollowing command:

$ BACKUP RDB_702_HTML.BCK/SAVE disk:[directory...]

To access this library of documentation, point to LIBRARY.HTML using yourfavorite web browser.

When you expand the RDB_702_HTML.EXE self-extracting archive file foryour Windows NT or Windows 95 system, the rdbhtmldocs directory is createdwith product-specific directories below that. Again, access this library ofdocumentation by pointing to LIBRARY.HTML from your favorite web browser.

The PostScript format of this documentation is available in the RDB7PS.BCKbackup save set.

1.6 Alpha EV6 Processor Support AddedAs of Oracle Rdb7 Release 7.0.3, the Alpha EV6 processor is supported. Thisis the only thing that changed between Oracle Rdb7 Release 7.0.2.1 and OracleRdb7 Release 7.0.3.

1.7 Maximum OpenVMS Version Check AddedAs of Oracle Rdb7 Release 7.0.1.5, a maximum OpenVMS version check hasbeen added to the product. Oracle Rdb has always had a minimum OpenVMSversion requirement. With 7.0.1.5 and for all future Oracle Rdb releases, we haveexpanded this concept to include a maximum VMS version check and a maximumsupported processor hardware check. The reason for this check is to improveproduct quality.

OpenVMS Version 7.2-n is the maximum supported version of OpenVMS.

As of Oracle Rdb7 Release 7.0.3, the Alpha EV6 processor is supported.

The check for the OpenVMS operating system version and supported hardwareplatforms is performed both at installation time and at runtime. If either anon-certified version of OpenVMS or hardware platform is detected duringinstallation, the installation will abort. If a non-certified version of OpenVMS orhardware platform is detected at runtime, Oracle Rdb will not start.

Installing Oracle Rdb7 Release 7.0.3.1 1–3

2Software Errors Fixed in Oracle Rdb7 Release

7.0.3.1

This chapter describes software errors that are fixed by Oracle Rdb7 Release7.0.3.1.

2.1 Software Errors Fixed That Apply to All Interfaces2.1.1 Leaf Cardinality Problem in Sorted Ranked Indexes

A problem in storage of the cardinality fields of sorted ranked index entriesresulted in errors in RMU index verification.

This problem only occurred in duplicate entries where the number of duplicatedbkeys stored for a single entry is greater than 65535. Update of the entrycardinality caused problems with correct interpretation of the associated leafcardinality.

The following is an example of the verification error that may be encountered dueto this problem:

%RMU-W-BTRLEACAR, Inconsistent leaf cardinality (C2) of 6 specifiedfor entry 3 at dbkey 62:1087:0 using precision of 33.Dbkey 62:3057:0 at level 2 specified a cardinality of 2

%RMU-I-BTRERPATH, parent B-tree node of 62:1087:0 is at 62:696:0%RMU-I-BTRROODBK, root dbkey of B-tree is 62:696:0

A workaround for the problem is to use a normal sorted index instead of a sortedranked index.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1.

2.1.2 Corruption of Ranked Index Node During Duplicate DeletionOn very rare occasions the deletion of a duplicate record from a sorted rankedindex may cause corruption of the index node from which the duplicate dbkey wasremoved.

This problem occurred in duplicate entries where the number of duplicate dbkeysstored in the bitmap was already greater than could be held in a single indexnode and thus the entry had overflow nodes attached to it.

Most deletions of duplicate dbkeys from the ranked index bitmap result in thereduction of the size of the bitmap, however, on rare occasions is it possible forthe bitmap to increase in size. If this occurs and there is insufficient room in thecurrent index node for the new larger bitmap, the node will be split.

A problem with the splitting of the duplicate node during duplicate dbkey deletionresulted in the corruption of the duplicate entry.

The corruption of the index showed up during RMU index verification and causeda bugcheck dump when attempting to access duplicate dbkeys held within thecorrupt bitmap.

Software Errors Fixed in Oracle Rdb7 Release 7.0.3.1 2–1

The following is an example of the routine stack as may be seen in a bugcheckcaused by this problem:

%SYSTEM-F-ACCVIO, access violation, reason mask=00,virtual address=000000003A800210, PC=FFFFFFFF8090A13C, PS=00000009Saved PC = 00E7E8C8 : PSII2SCANINVALIDATESCANSREM + 000000A8Saved PC = 00E62B68 : PSII2REMOVEDUPBBC + 000000C8Saved PC = 00E5FBC0 : PSII2REMOVEBOTTOM + 00000490Saved PC = 00E5C908 : PSII2REMOVET + 00000228Saved PC = 00E5CB54 : PSII2REMOVET + 00000474Saved PC = 00E5D238 : PSII2REMOVETREE + 000001D0Saved PC = 0102FC54 : RDMS$$KOD_REMOVE_TREE + 00001784Saved PC = 00FF0F10 : RDMS$$EXE_ACTION + 00000A40

A workaround for the problem is to use a normal sorted index instead of a sortedranked index.


2.1.3 Deadlock on AIP Larea SyncWhen concurrently creating indexes, occasionally deadlocks would be returnedwith the message: -RDMS-F-DEADLOCK, deadlock on AIP larea synch.Customers encountering other deadlocks are encouraged to reoprt them totheir support personnel.

The following example shows a complete set of the errors encountered when thisproblem occurs:

%RDB-E-DEADLOCK, request failed due to resource deadlock-RDB-E-NO_META_UPDATE, metadata update failed-RDMS-F-DEADLOCK, deadlock on AIP larea synch


2.1.4 Online ALTER STORAGE AREA Operations and Row CachePreviously, it was possible to cause database recovery failures when using the rowcache feature and making online modifications to storage areas. For example,if storage areas were marked read-only after they had been modified, it waspossible for cached changes to be unable to be written back to the database at alater time.

This problem has been corrected. Online ALTER STORAGE AREA operationsnow request that the RCS process flush all modified rows from all caches back tothe database before the storage area modification is performed. This means thata ALTER STORAGE AREA operation may stall while the RCS flushes modifiedrows back to the database.

2.1.5 Inconsistent Enforcement of RESERVE LimitsBug 972253

Oracle Rdb7 did not consistently enforce the number of reserved storage areas,journals, or caches that could be created in a database. For example, Oracle Rdb7would allow a user to repeatedly add reserved storage areas to a database untilthe database had more storage areas than are allowed by Oracle Rdb7, as shown:

2–2 Software Errors Fixed in Oracle Rdb7 Release 7.0.3.1

$ SQLCREATE DATABASE FILENAME SLOT_LIMITS

RESERVE 1000 STORAGE AREASCREATE STORAGE AREA AREA_1 FILENAME AREA_1;DISCONNECT ALL;ALTER DATABASE FILENAME SLOT_LIMITS

RESERVE 200 STORAGE AREAS;%RDMS-W-DOFULLBCK, full database backup should be done to ensure future recoveryDISCONNECT ALL;EXPORT DATABASE FILENAME SLOT_LIMITS INTO SLOT_LIMITS;DROP DATABASE FILENAME SLOT_LIMITS;IMPORT DATABASE FROM SLOT_LIMITS FILENAME SLOT_LIMITS;Exported by Oracle Rdb V7.0-3 Import/Export utility...IMPORT DATABASE FROM SLOT_LIMITS FILENAME SLOT_LIMITS;Exported by Oracle Rdb V7.0-3 Import/Export utility...IMPORTing STORAGE AREA: RDB$SYSTEMIMPORTing STORAGE AREA: AREA_1%SQL-F-ERRCRESCH, Error creating database filename SLOT_LIMITS-RDB-E-BAD_DPB_CONTENT, invalid database parameters in the database parameter block (DPB)-RDMS-F-BADPARAM, reserved storage area count (1200) is out of valid range (0...1024)

A workaround for the failed IMPORT is to respecify the RESERVE...STORAGEAREAS clause on the IMPORT statement to a lower value.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. Oracle Rdb7will now disallow adding more reserved areas, journals, or caches than the totalallowed for a database.

2.1.6 ABS Initialization of AIJ Journal Causes System SlowdownThe initialization of AIJ journals, which occurs after the journal has been backedup, is extremely I/O intensive and often impacts the ability of the database toconcurrently generate new AIJ information. Currently, there are two logicals thatcontrol the impact of the AIJ initialization operation. However, the default valueswere originally defined when only extensible AIJ journals existed. These defaultvalues are not conducive to circular AIJ journal initialization.

The workaround is to define explicit values for the RDM$BIND_AIJ_INITIALIZATION_IO_COUNT and RDM$BIND_AIJ_INITIALIZATION_IO_SIZE logicals when using fixed-size circular AIJ journals.


The default values for the RDM$BIND_AIJ_INITIALIZATION_IO_COUNT andRDM$BIND_AIJ_INITIALIZATION_IO_SIZE logicals are now based on whetherextensible or circular AIJ journals are active. The new default values are thefollowing:

Logical NameExtensible AIJDefault

Circular AIJDefault

RDM$BIND_AIJ_INITIALIZATION_IO_COUNT 15 2

RDM$BIND_AIJ_INITIALIZATION_IO_SIZE 127 32


In addition, these two logicals have been added to the database ‘‘AIJ dashboard.’’This means that the AIJ journal initialization values can be non-persistentlymodified at runtime using the RMU Show Statistics database dashboard utility.

2.1.7 Transaction Checkpoint Determination of Switchover or BackupIt is sometimes possible for a committing transaction to checkpoint even thoughno checkpoint thresholds have been exceeded. This problem occurs morefrequently when the current AIJ journal is located on an extremely fast I/Odevice or serviced by an extremely fast device controller such as an HSJ diskcontroller with write-back caching enabled.

The problem is caused by a race condition between the process committing thetransaction and the process performing the AIJ group commit I/O to the AIJjournal.

There is no workaround to this problem. However, this problem does not causedatabase corruption or cause other database integrity problems.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1.

2.1.8 Non-Update Read/Write Transactions Do Not Validate CheckpointThresholds

Currently, a read/write transaction that does not modify any database objectsdoes not validate its checkpoint thresholds. This strategy has the advantageof allowing the transaction to re-use the ‘‘Transaction Sequence Number’’ andreducing the amount of AIJ journal information being submitted. However,this strategy has the disadvantage of the process checkpoint not gettingadvanced, which can result in an increased recovery duration if the processwere to terminate prematurely.

Users can see the transaction commit behavior, using the new logical nameRDM$BIND_RW_TX_CKPT_ADVANCE. This logical name can be placed in theLNM$FILE_DEV table.

The value ‘‘0’’ indicates that read/write non-update transactions do not advancethe checkpoint; this is the current behaviour and the default value. The value ‘‘1’’indicates that read/write non-update transactions will advance the checkpoint ifthe checkpoint thresholds are exceeded.

2.1.9 Lowercase Characters Cannot Be Used as Escape Character in a LIKEClause

Bug 905784

When lowercase characters are used as escape characters within an SQLstatement, Rdb may not be able to correctly locate matching records.

This problem only occurs when a sorted index is used by the optimizer to preselecta range of records which will be filtered using the LIKE pattern.

The following example shows the problem:


SQL> create table ttable (tname char(10));SQL> insert into ttable (tname) value (’my_table1’);SQL> insert into ttable (tname) value (’my_table2’);SQL> set flags ’strategy’;SQL> select tname from ttablecont> where tname like ’myz_table%’ escape ’z’;Conjunct Get Retrieval sequentially of relation TTABLETNAMEmy_table1my_table22 rows selectedSQL> create index tind on ttable(tname);SQL> select tname from ttablecont> where tname like ’myz_table%’ escape ’z’;Conjunct Index only retrieval of relation TTABLEIndex name TIND [1:1]

0 rows selected

Two possible workarounds can be used to prevent this problem:

• Use only uppercase or case-independent characters as the escape characterwithin the LIKE clause.

• Prevent the optimizer from using index retrieval by either deleting the indexor by using a query outline to change the selected strategy.


2.1.10 ACCVIO if RDM$BIND_STT_NETWORK_TRANSPORT Logical DefinedIt is possible for the RMU/SHOW Statistic utility to access violate when theRDM$BIND_STT_NETWORK_TRANSPORT logical is defined to the value‘‘DECNET’’. This problem occurs on OpenVMS Alpha systems only, and appearsto occur for OpenVMS Version 6.2 and later.

The only workaround is to not define the RDM$BIND_STT_NETWORK_TRANSPORT logical.


2.1.11 RMU/SHOW Statistic Cluster Collection FailureIt is sometimes possible for the RMU/SHOW Statistic utility to not connect tothe remote statistics collection server (RDMSTTnn.EXE). This problem occurs onOpenVMS Alpha systems only, and appears to occur for OpenVMS Version 7.1and later.

There is no workaround to this problem.


2.1.12 Error Creating RUJ When Default RUJ Directory Does Not ExistBug 860794

Errors are returned if a database is altered such that the default recovery journal(RUJ) location has a non-existent directory. For example:


SQL> create database filename foo;SQL> alter database filename foo recover journalcont> (location is ’sys$disk:[nosuchdir]’);SQL> disconnect all;SQL> att ’fi foo’;SQL> create table foo (f1 int);%RDB-F-SYS_REQUEST, error from system services request-RDMS-F-FILACCERR, error creating run-unit journal file DEV:[NOSUCHDIR]FOO$0001‘-RMS-E-DNF, directory not found-SYSTEM-W-NOSUCHFILE, no such fileSQL>SQL> alter database filename foo recover journalcont> (location is ’sys$disk:[gooddir]’);%RDB-F-SYS_REQUEST, error from system services request-RDMS-F-FILACCERR, error creating run-unit journal file DEV:[NOSUCHDIR]FOO$0001‘-RMS-E-DNF, directory not found-SYSTEM-W-NOSUCHFILE, no such fileSQL>

The workarounds are:

1. Create the directory so that it becomes valid.

2. EXPORT/IMPORT the database.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. If the defaultrecovery journal location contains an invalid directory, it will now be ignored.

2.1.13 Process May Stall in an Infinite Wait for a GBPT Slot LatchBug 714899

Under some rare conditions, it is possible to get a deadlock between a globalbuffer page table (GBPT) latch and a global page lock. Such a deadlock is notdetected and so you get a process stall waiting indefinitely f or a GBPT slot latch,blocking all other processes with its locks.

The code has been changed to bugcheck after 3 minutes if you do not get a latchinstead of looping infinitely.

There is no workaround to this problem.


2.1.14 RDMS-F-NOREQIDT ErrorsBugs 870987 and 890405

In situations with high Oracle Rdb7 lock contention and substantial RMS activity,it was possible to have an application fail with the following error:

%RDMS-F-NOREQIDT, reached internal maximum number of simultaneous timer requests

This error could be returned to the application program or sometimes a bugcheckdump would be written with this error as the exception.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. Oracle Rdb7 hasbeen changed to no longer use as many timer requests when handling blockingAST requests for database locks.


2.1.15 AIJ Work File Search List CapabilityIn previous releases of Oracle Rdb, the RDB$BIND_AIJ_WORK_FILE logicalcould be used to designate a device and directory in which the AIJ work fileswould be created. However, when that device became full and no more work filescould be created or extended, Hot Standby would be shutdown.

In this release, a search list can be specified by defining logicals RDB$BIND_AIJ_WORK_FILE1, RDB$BIND_AIJ_WORK_FILE2, ... RDB$BIND_AIJ_WORK_FILEn with each logical pointing to a different device/directory. The numbersmust start with 1 and increase sequentially without any gaps. When an AIJwork file cannot be created due to a "device full" error, Rdb will look for the nextdevice in the search list by translating the next sequential work file logical. IfRDB$BIND_AIJ_WORK_FILE is defined, it will be used first.

This AIJ work file search list capability is available in Oracle Rdb7 Release7.0.3.1.

2.1.16 Failed Backup of Extensible AIJ Causes Gap in Sequence NumbersIn previous releases of Oracle Rdb, a failed backup of an extensible AIJ causeda gap in the AIJ sequence numbers. This gap caused RMU/RECOVER and HotStandby to fail.

In this release, a failed backup of an extensible AIJ no longer causes a gap in thesequence numbers.


2.1.17 Improper Column Reference in CREATE TRIGGER Now DetectedBug 592660

In prior versions of Oracle Rdb, an application error in a trigger definition wasnot detected by the SQL interface. The resulting trigger generated a confusingdiagnostic. This error is shown in the following example:

SQL> create table T (ta integer);SQL> create table S (sa integer, sb integer);SQL>SQL> -- bad column reference in INSERTSQL> create trigger T_Scont> before update of TA on Tcont> referencing new as C2cont> (insert into S (ta) values (ta))cont> for each row;%RDB-E-NO_META_UPDATE, metadata update failed-RDB-E-INVALID_BLR, request BLR is incorrect at offset 13-RDMS-E-INVASSIGNMENT, illegal target for assignment

The problem was that the SQL interface allowed a column of the triggering table(T in the example) to be listed in the column list of an INSERT statement, evenwhen it did not belong on the table targeted by the INSERT statement. Thisproblem only occurs for the INSERT statement if the REFERENCING clause ispresent in a trigger definition.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. SQL now detectsthe invalid column reference as shown in this example:


SQL> -- bad column reference in INSERTSQL> create trigger T_Scont> before update of TA on Tcont> referencing new as C2cont> (insert into S (ta) values (ta))cont> for each row;%SQL-F-FLDNOTCRS, Column TA was not found in the tables in current scope

2.1.18 Bugcheck in DIO$FREE_CURRENT_LOCKBug 728613

A bugcheck occurred with an exception in the routine DIO$FREE_CURRENT_LOCK if the transaction type was READ COMMITTED and a hold cursor wasused containing a query whose strategy employed a backward scan and the rowsfrom the cursor were fetched over multiple transactions. The problem occurredbecause Oracle Rdb mistakenly released a lock prematurely. Later, when OracleRdb was truly finished with the resource, a bugcheck occurred trying to releasethe lock that had previously been released.

The following query on the PERSONNEL database shows an example of theproblem:

SQL> ATTACH ’FILE PERSONNEL’;SQL>SQL> DECLARE TRANSACTION READ WRITE ISOLATION LEVEL READ COMMITTED;SQL>SQL> DECLARE T2 TABLE CURSOR WITH HOLD PRESERVE ALL FORcont> SELECT *cont> FROM EMPLOYEEScont> WHERE EMPLOYEE_ID > ’00300’cont> AND EMPLOYEE_ID < ’00400’cont> ORDER BY EMPLOYEE_ID DESC;SQL>SQL> OPEN T2;SQL> FETCH T2;EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIALADDRESS_DATA_1 ADDRESS_DATA_2 CITY

STATE POSTAL_CODE SEX BIRTHDAY STATUS_CODE00374 Andriola Leslie Q.111 Boston Post Rd. NULL Salisbury

NH 03268 M 19-Mar-1955 1

SQL>SQL> COMMIT;SQL>SQL> FETCH T2;%RDMS-I-BUGCHKDMP, generating bugcheck dump file DISK:[DIR]RDSBUGCHK.DMP;

The only workaround the problem is to restructure the transaction to use isolationlevel serializable; or use a standard, non-hold cursor; or avoid the backward scan;or fetch all the rows using one transaction.


2.2 SQL Errors Fixed2.2.1 Improved Optimization for NULLIF Expression with Subselect

Bug 903619


In prior versions of Oracle Rdb, queries using NULLIF might have a sub-optimzaloptimizer strategy if it included a subquery, as shown in this example:

SQL> set flags ’strat’;SQL> select nullif ((select count(*)cont> from job_history jhcont> where jh.employee_id = e.employee_id),cont> 0),cont> employee_idcont> from employees econt> where employee_id < ’00166’;Match

Outer loopCross block of 2 entriesCross block entry 1Index only retrieval of relation EMPLOYEESIndex name EMP_EMPLOYEE_ID [0:1]

Cross block entry 2Aggregate Index only retrieval of relation JOB_HISTORYIndex name JOB_HISTORY_HASH [1:1]

Inner loop (zig-zag)Aggregate Conjunct Index only retrieval of relation JOB_HISTORYIndex name JOB_HISTORY_SORT [0:0]

EMPLOYEE_ID2 001644 00165

2 rows selected

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. NULLIF nowshares an optimization with COALESCE and the simple CASE expression wherethe subselect is evaluated just once. This allows the Oracle Rdb server to performless table accesses as shown in the example run on the latest release:

SQL> set flags ’strategy’;SQL> select nullif ((select count(*)cont> from job_history jhcont> where jh.employee_id = e.employee_id),cont> 0),cont> employee_idcont> from employees econt> where employee_id < ’00166’;Match

Outer loopIndex only retrieval of relation EMPLOYEESIndex name EMP_EMPLOYEE_ID [0:1]

Inner loop (zig-zag)Aggregate Conjunct Index only retrieval of relation JOB_HISTORYIndex name JOB_HISTORY_SORT [0:0]

EMPLOYEE_ID2 001644 00165

2 rows selected

Note that a side effect of this change is that the query outline ID generated forthe query and the query structure will change and thus the query outline will notbe used for the query. This will require regeneration of these query outlines.


2.2.2 Correct JOIN Syntax Generated Error and BugcheckBug 941621

In a SELECT expression, a result table is derived from some combination of thetable references identified in the FROM clause of the expression. In the followingexample, the table reference is a joined table in which one of the latter tablereferences is a derived table. The syntax is correct, yet was generating an error.This problem has been fixed and the syntax is now accepted. This example showsthe syntax error which had been generated:

select col1,table1.col2 from table1left join(

(select col1 from table2 where col2 = 1) t2inner join table3 using (col1)

)using (col1);

%SQL-W-LOOK_FOR_STT, Syntax error, looking for:%SQL-W-LOOK_FOR_CON, JOIN, LEFT, FULL, UNION, CROSS, RIGHT,%SQL-W-LOOK_FOR_CON, INNER, LIMIT, ORDER, NATURAL, ),%SQL-F-LOOK_FOR_FIN, found T2 instead

In the next example, the correlation name clause has been omitted. In such acase, SQL was generating a bugcheck dump. For example:

select col1,table1.col2 from table1left join(

(select col1 from table2 where col2 = 1)inner join table3 using (ch1)

) using (ch1);

%SQL-I-BUGCHKDMP, generating bugcheck dump file DISK1:[TEST]SQLBUGCHK.DMP;%SQL-F-BUGCHK, There has been a fatal error. Please contact your Oraclesupport representative. SQL$SEMRSE - WALK_TABLE_REF - UNKNOWN TYPE

The following example shows the error message SQL now generates:

select ch1,table1.ch2 from table1left join(

(select ch1 from table2 where ch2 = 1)inner join table3 using (ch1)

)using (ch1);%SQL-F-CORNAMREQ, A correlation name is required for a derived table

These problems have been corrected.

2.2.3 Incorrect Results from Oracle7 Outer Join SyntaxBugs 782901 and 693636

Oracle Rdb release 7.0.1.1 introduced new SQL syntax for performing outerjoins between two or more tables. The syntax and semantics were designed toduplicate the syntax available in Oracle7 and Oracle8 SQL and therefore enhancethe compatibility between these two products. The special operator (+) can beplaced in the WHERE clause to instruct SQL to join tables using outer joinsemantics.


In prior releases, this syntax could produce the incorrect results listed below.However, the ANSI/ISO SQL standard syntax (SQL92) for LEFT, RIGHT,and FULL OUTER JOIN does not have these problems and can be used as aworkaround for these limitations.

• Using outer join syntax to join a table to itself may only perform an innerjoin. For example:

select e.eid, e.ename, m.ename as "Manager"from employees e, employees mwhere e.manid = m.eid (+)order by m.eid, e.eid;

• If a table was joined to itself and three or more table sources were specified,the query did not work and the error FLDNOTCRS would be erroneouslygenerated as shown in this example:

SQL> select o.order_id, b1.comp_name, b2.comp_namecont> from t_order o, company b1, company b2cont> where b1.comp_id (+) = o.customercont> and b1.comp_type(+) = o.cust_typecont> and b2.comp_id(+) = o.transportcont> and b2.comp_type(+) = o.trans_type;%SQL-F-FLDNOTCRS, Column B1.COMP_NAME was not found in the tables in currentscope

In some cases on OpenVMS Alpha, an SQL bugcheck could be generated.

• Predicates which compared an outer join marked table column with a simpleexpression were not correctly used for the outer join.

In this example, the condition job (+) = ’Clerk’ was treated as though ithad no outer join marker as in job = ’Clerk’. If the column is not qualifiedwith (+), it becomes part of the WHERE clause as a filter to the final resulttable. However, the query had wanted to place this condition on the outerjoin to force NULL-filled rows to be returned. The difference in the result canbe seen in the correct results from these queries:

SQL> select ename, job, dept.deptno, dnamecont> from emp, deptcont> where emp.deptno (+) = dept.deptnocont> and job (+) = ’Clerk’;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEMiller Clerk 10 AccountingSmith Clerk 20 ResearchAdams Clerk 20 ResearchJames Clerk 30 SalesNULL NULL 40 Operations5 rows selected

SQL>SQL> select ename, job, dept.deptno, dnamecont> from emp, deptcont> where emp.deptno (+) = dept.deptnocont> and job = ’Clerk’;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEMiller Clerk 10 AccountingSmith Clerk 20 ResearchAdams Clerk 20 ResearchJames Clerk 30 Sales4 rows selectedSQL>

• Complex multitable outer joins were not supported by Oracle Rdb.


When more than one column from a table is referenced for an outer joinSQL erroneously diagnoses an invalid form of join. The following exampleis a valid SQL query and should not have caused an error message to bedisplayed:

SQL> select e.employee_id, sh.salary_amount, jh.job_startcont> from employees e, job_history jh, salary_history shcont> wherecont> e.employee_id = sh.employee_id (+)cont> and e.employee_id = jh.employee_id (+)cont> and e.department_code = jh.department_code (+)cont> and e.employee_id = ’00164’;%SQL-F-ONETABLEJOIN, a table may be outer joined to at most one other table

These problems have been corrected in Oracle Rdb7 Release 7.0.3.1. SQL nowprocesses this style of join operator correctly and more generally than in previousreleases.

2.2.3.1 Outer JoinsAn outer join extends the result of a simple join. An outer join returns all rowsthat satisfy the join condition and those rows from one table for which no rowsfrom the other satisfy the join condition. Such rows are not returned by a simplejoin. To write a query that performs an outer join of tables A and B and returnsall rows from A, apply the outer join operator (+) to all columns of B in the joincondition. For all rows in A that have no matching rows in B, Oracle Rdb returnsNULL for any select list expressions containing columns of B.

Outer join queries are subject to the following rules and restrictions:

• The (+) operator can appear only in the WHERE clause and can be appliedonly to a column of a table or view.

• If A and B are joined by multiple join conditions, you must use the (+)operator in all these conditions. If you do not, Oracle Rdb will return only therows resulting from a simple join, but without a warning or error to adviseyou that you do not have the results of an outer join.

• The (+) operator can be applied only to a column, not to an arbitraryexpression. However, an arbitrary expression can contain a column markedwith the (+) operator.

• A condition containing the (+) operator cannot be combined with anothercondition using the OR logical operator.

• A condition cannot use the IN comparison operator to compare a columnmarked with the (+) operator with an expression.

• A condition cannot compare any column marked with the (+) operator with asubquery.

If the WHERE clause contains a condition that compares a column from table Bwith a constant, the (+) operator must be applied to the column so that OracleRdb returns the rows from table A for which it has generated NULLs for thiscolumn. Otherwise Oracle Rdb will return only the results of a simple join.

In a query that performs outer joins of more than two pairs of tables, a singletable can be the NULL-generated table for only one other table. For this reason,you cannot apply the (+) operator to columns of B in the join condition for A andB, and the join condition for B and C.


2.2.3.2 Outer Join ExamplesThe examples in this section extend the results of an inner join (Equijoin)between the EMP and the DEPT tables.

SQL> SELECT ename, job, dept.deptno, dnamecont> FROM emp, deptcont> WHERE emp.deptno = dept.deptno;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEKing President 10 AccountingBlake Manager 30 SalesClark Manager 10 AccountingJones Manager 20 ResearchFord Analyst 20 ResearchSmith Clerk 20 ResearchAllen Salesman 30 SalesWard Salesman 30 SalesMartin Salesman 30 SalesScott Analyst 20 ResearchTurner Salesman 30 SalesAdams Clerk 20 ResearchJames Clerk 30 SalesMiller Clerk 10 Accounting14 rows selected

The following query uses an outer join to extend the results of the Equijoinexample above:

SQL> SELECT ename, job, dept.deptno, dnamecont> FROM emp, deptcont> WHERE emp.deptno (+) = dept.deptno;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEKing President 10 AccountingClark Manager 10 AccountingMiller Clerk 10 AccountingJones Manager 20 ResearchFord Analyst 20 ResearchSmith Clerk 20 ResearchScott Analyst 20 ResearchAdams Clerk 20 ResearchBlake Manager 30 SalesAllen Salesman 30 SalesWard Salesman 30 SalesMartin Salesman 30 SalesTurner Salesman 30 SalesJames Clerk 30 SalesNULL NULL 40 Operations15 rows selected

In this outer join, Oracle Rdb returns a row containing the Operationsdepartment even though no employees work in this department. Oracle Rdbreturns NULL in the ENAME and JOB columns for this row. The join query inthis example selects only departments that have employees.

The following query uses an outer join to extend the results of the precedingexample:


SQL> SELECT ename, job, dept.deptno, dnamecont> FROM emp, deptcont> WHERE emp.deptno (+) = dept.deptnocont> AND job (+) = ’Clerk’;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEMiller Clerk 10 AccountingSmith Clerk 20 ResearchAdams Clerk 20 ResearchJames Clerk 30 SalesNULL NULL 40 Operations5 rows selected

In this outer join, Oracle Rdb returns a row containing the Operationsdepartment even though no clerks work in this department. The (+) operator onthe JOB column ensures that rows for which the JOB column is NULL are alsoreturned. If this (+) were omitted, the row containing the Operations departmentwould not be returned because its JOB value is not CLERK.

SQL> SELECT ename, job, dept.deptno, dnamecont> FROM emp, deptcont> WHERE emp.deptno (+) = dept.deptnocont> AND job = ’Clerk’;EMP.ENAME EMP.JOB DEPT.DEPTNO DEPT.DNAMEMiller Clerk 10 AccountingSmith Clerk 20 ResearchAdams Clerk 20 ResearchJames Clerk 30 Sales4 rows selected

This example shows four outer join queries on the CUSTOMERS, ORDERS,LINEITEMS, and PARTS tables:

SQL> SELECT custno, custnamecont> FROM customerscont> ORDER BY custno;

CUSTNO CUSTNAME1 Angelic Co2 Believable Co3 Cables R Us

3 rows selected

SQL>SQL> SELECT orderno, custno, orderdatecont> FROM orderscont> ORDER BY orderno;

ORDERNO CUSTNO ORDERDATE9001 1 1999-10-139002 2 1999-10-139003 1 1999-10-209004 1 1999-10-279005 2 1999-10-31

5 rows selected

SQL>SQL> SELECT orderno, lineno, partno, quantitycont> FROM lineitemscont> ORDER BY orderno, lineno;

ORDERNO LINENO PARTNO QUANTITY9001 1 101 159001 2 102 109002 1 101 259002 2 103 509003 1 101 159004 1 102 109004 2 103 20

7 rows selected


SQL>SQL> SELECT partno, partnamecont> FROM partscont> ORDER BY partno;

PARTNO PARTNAME101 X-Ray Screen102 Yellow Bag103 Zoot Suit

3 rows selected

The customer Cables R Us has placed no orders, and order number 9005 has noline items.

The following outer join returns all customers and the dates they placed orders.The (+) operator ensures that customers who placed no orders are also returned:

SQL> SELECT custname, orderdatecont> FROM customers, orderscont> WHERE customers.custno = orders.custno (+)cont> ORDER BY customers.custno, orders.orderdate;CUSTOMERS.CUSTNAME ORDERS.ORDERDATEAngelic Co 1999-10-13Angelic Co 1999-10-20Angelic Co 1999-10-27Believable Co 1999-10-13Believable Co 1999-10-31Cables R Us NULL6 rows selected

The following outer join builds on the result of the previous one by adding theLINEITEMS table to the FROM clause, columns from this table to the selectlist, and a join condition joining this table to the ORDERS table to the WHEREclause. This query joins the results of the previous query to the LINEITEMStable and returns all customers, the dates they placed orders, the part number,and the quantity of each part they ordered. The first (+) operator serves the samepurpose as in the previous query. The second (+) operator ensures that orderswith no line items are also returned:

SQL> SELECT custname, orderdate, partno, quantitycont> FROM customers, orders, lineitemscont> WHERE customers.custno = orders.custno (+)cont> AND orders.orderno = lineitems.orderno (+)cont> ORDER BY customers.custno, orders.orderdate, lineitems.partno;CUSTOMERS.CUSTNAME ORDERS.ORDERDATE LINEITEMS.PARTNO LINEITEMS.QUANTITYAngelic Co 1999-10-13 101 15Angelic Co 1999-10-13 102 10Angelic Co 1999-10-20 101 15Angelic Co 1999-10-27 102 10Angelic Co 1999-10-27 103 20Believable Co 1999-10-13 101 25Believable Co 1999-10-13 103 50Believable Co 1999-10-31 NULL NULLCables R Us NULL NULL NULL9 rows selected

The following outer join builds on the result of the previous one by adding thePARTS table to the FROM clause, the PARTNAME column from this table to theselect list, and a join condition joining this table to the LINEITEMS table to theWHERE clause. This query joins the results of the previous query to the PARTStable to return all customers, the dates they placed orders, the quantity, andthe name of each part they ordered. The first two (+) operators serve the samepurposes as in the previous query. The third (+) operator ensures that rows withNULL part numbers are also returned:


SQL> SELECT custname, orderdate, quantity, partnamecont> FROM customers, orders, lineitems, partscont> WHERE customers.custno = orders.custno (+)cont> AND orders.orderno = lineitems.orderno (+)cont> AND lineitems.partno = parts.partno (+)cont> ORDER BY customers.custno, orders.orderdate, parts.partno;CUSTOMERS.CUSTNAME ORDERS.ORDERDATE LINEITEMS.QUANTITY PARTS.PARTNAMEAngelic Co 1999-10-13 15 X-Ray ScreenAngelic Co 1999-10-13 10 Yellow BagAngelic Co 1999-10-20 15 X-Ray ScreenAngelic Co 1999-10-27 10 Yellow BagAngelic Co 1999-10-27 20 Zoot SuitBelievable Co 1999-10-13 25 X-Ray ScreenBelievable Co 1999-10-13 50 Zoot SuitBelievable Co 1999-10-31 NULL NULLCables R Us NULL NULL NULL9 rows selected

2.2.4 MAPPING VALUES Not Supported for CREATE INDEX in IMPORTIn previous releases of Oracle Rdb, the SQL IMPORT statement did not allow anindex to be created or replaced which used the MAPPING VALUES clause. Thisrestriction has now been lifted. The SQL IMPORT statement now supports thefull CREATE INDEX syntax as a subclause, allowing indexes to be created andreplaced during the IMPORT operation.

The following example shows the error which was generated in previous releases:

SQL> import databasecont> from pppcont> filename MAPPcont> create index PERSON_INDEXcont> on PERSON (employee_id mapping values 0000.00 to 2001.9)cont> ;%SQL-F-NOMAPIMPO, Mapping Values on CREATE INDEX within an IMPORT is notsupported

A workaround to this problem is to use the DROP INDEX statement to removethe index (either before the EXPORT or after the IMPORT) and then re-createthe index when the database is complete. The corrected behavior in this updateto Oracle Rdb will be more efficient, as the index will only be built once.


2.2.5 SELECT Returns Incorrect Values for GROUP BY QueriesBug 882722

Prior releases of Oracle Rdb7 would return incorrect results when similarexpressions appeared in the select list of a GROUP BY query. SQL attempted toeliminate common expressions and incorrectly folded together the results of thesesimilar expressions.

This problem affected the use of the functions CAST, EXTRACT, TRIM and thesubtraction operator that resulted in different INTERVAL data types.

The following example shows this problem where the EXTRACT of the MONTHfield is incorrectly returning the year:


SQL> select fundnum,cont> extract(year from distribution_date) as yr,cont> extract(month from distribution_date) as mth,cont> count(*),cont> sum(distribution_rate)cont> from fund_distributionscont> group by fundnum,cont> extract(year from distribution_date),cont> extract(month from distribution_date);

FUNDNUM YR MTH202 1999 1999 1 2.533465999999999E-003245 1999 1999 1 6.772000000000000E-002

.

.

.


2.2.6 Restrictions on CURRENT_TIMESTAMP Default Value LiftedIn previous versions of Oracle Rdb, the CURRENT_TIMESTAMP built-inFUNCTION was controlled by the setting of the DEFAULT DATE FORMAT,or DIALECT of the session. When these were set to SQL92, CURRENT_TIMESTAMP could only be used as a default for a TIMESTAMP domain orcolumn. When set to VMS or the default dialect SQL040, then CURRENT_TIMESTAMP could only be used as a default for a DATE VMS domain or column.

This restriction was problematic when tables were created with columns of bothDATE VMS and TIMESTAMP and these columns wished to use the default ofCURRENT_TIMESTAMP. SQL would reject the CREATE TABLE definition nomatter what setting was active for the DEFAULT DATE FORMAT. In a similarway, when different tables were created the DEFAULT DATE FORMAT orDIALECT had to be changed between each CREATE/ALTER DOMAIN or TABLEstatement.

This restriction has been lifted in this release of Oracle Rdb. SQL now usesthe column or domain data type when checking the usage of the CURRENT_TIMESTAMP as a default value. If the column or domain is of type TIMESTAMPthen CURRENT_TIMESTAMP returns a value of type TIMESTAMP, otherwise itwill be DATE VMS.

Oracle Rdb has also relaxed the fractional seconds precision used by theDEFAULT clause for CURRENT_TIMESTAMP, CURRENT_TIME, TIMESTAMP,TIME, and INTERVAL literals. They no longer need to exactly match those of thecolumn or domain. Obviously, if the DEFAULT allows more precision than thecolumn, then truncation will occur during assignment.

The following example shows the errors reported when the DIALECT is set toSQL92:


SQL> create table C_T_TEST1cont> (a timestamp default current_timestamp);SQL>SQL> create table C_T_TEST2cont> (a timestamp(1) default current_timestamp(2));%SQL-F-DEFVALINC, You specified a default value for A which is inconsistentwith its data typeSQL>SQL> create table C_T_TEST3cont> (a integer,cont> b timestamp(0) default timestamp’1999-7-2:12:00:00.99’);%SQL-F-DEFVALINC, You specified a default value for B which is inconsistentwith its data typeSQL>SQL> create table C_T_TEST4cont> (a date vms default current_timestamp);%SQL-F-DEFVALINC, You specified a default value for A which is inconsistentwith its data type

The following example shows the new behavior:

SQL> set dialect ’sql92’;SQL> attach ’file db$:scratch’;SQL>SQL> create table C_T_TEST1cont> (a timestamp default current_timestamp);SQL>SQL> create table C_T_TEST2cont> (a timestamp(1) default current_timestamp(2));SQL>SQL> create table C_T_TEST3cont> (a integer,cont> b timestamp(0) default timestamp’1999-7-2:12:00:00.99’);SQL> insert into C_T_TEST3 (a) values (0);cont> (a integer,cont> b timestamp(0) default timestamp’1999-7-2:12:00:00.99’);SQL> insert into C_T_TEST3 (a) values (0);1 row insertedSQL> select * from C_T_TEST3;

A B0 1999-07-02 12:00:00

1 row selectedSQL>SQL> create table C_T_TEST4cont> (a date vms default current_timestamp);


2.2.7 SQL Uses Read/Write Transactions Against Standby DatabaseIn prior releases of Oracle Rdb7, the SQL interface, in particular interactive anddynamic SQL, would attempt to execute a read/write transaction on a databasewhich was currently a standby database. This type of database is consideredread-only and starting a read/write transaction fails. This problem may causeconnections from ODBC, SQL*Net for Rdb, and SQL/Services to fail.

A workaround for this problem is to restore the standby database using theRMU/RESTORE/TRANSACTION_MODE=READ_ONLY command which permitsonly read-only transactions on the database. Current releases of SQL do detectthis setting and will then operate correctly. When the standby database isrequired as the master database (following a system failure), the ALTERDATABASE ... ALTER TRANSACTION MODE (READ WRITE) statementshould be used to enable read/write transactions for the database.


This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. SQL nowdetermines that the database is a standby database and uses by default READONLY transactions for metadata queries.

2.2.8 Domain Constraints Did Not Support Function Calls Passing VALUEBug 808378

In prior releases of Oracle Rdb, attempts to pass the special VALUE keyword toa user-defined function (external or stored) would cause the CREATE or ALTERDOMAIN statement to bugcheck.

The following example shows the resulting exception:

SQL> create module myModule language sqlcont> function myFunction( in :x char(1)) return char(1);cont> begincont> return case :x when ’A’ then :x else null end;cont> end;cont> end module;SQL> create domain myDomain char(1)cont> check( myFunction(value) is not null) not deferrable;%SQL-I-BUGCHKDMP, generating bugcheck dump file DISK1:[TEST]SQLBUGCHK.DMP;%SQL-F-BUGCHK, There has been a fatal error. Please contact your Oracle supportrepresentative. SQL$SEMASS - 9

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. SQL nowsupports the passing of the VALUE keyword (or the name of the domain) to auser-defined function in a domain CHECK constraint.

2.2.9 CREATE VIEW May Fail on Large or Complex View DefinitionBug 909035

Definitions of very complex views, view definitions referencing long table andcolumn names, or views based on tables with many columns may fail with one ofthe following errors:

• Obsolete metadata

%RDB-E-NO_META_UPDATE, metadata update failed-RDB-E-OBSOLETE_METADA, request references metadata objects that no longerexist-RDMS-F-BAD_SYM, unknown field symbol - XXX

Here XXX represents a partial or corrupt column name from the viewdefinition.

• Invalid BLR

%RDB-E-NO_META_UPDATE, metadata update failed-RDB-E-INVALID_BLR, request BLR is incorrect at offset NNN

Here NNN represents some numeric offset into the definition.

These problems occur when SQL attempts to build a binary version of the viewrow selection expression (RSE) which exceeds 65,535 (64K) bytes in length. Thiswas the maximum size supported in prior versions of Oracle Rdb, and remainsthe limit for Oracle CDD/Repository and older versions of Oracle Rdb.

There is no simple workaround for this restriction. However, you could useshorter table and column names, or break the view definition into references toother views.


This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. Oracle Rdbhas been enhanced to support much larger view definitions. SQL will use a newformat for the view definition if it requires more than 65,535 bytes to describe.However, this new format is not supported by Oracle CDD/Repository or olderversions of Oracle Rdb, and these view definitions cannot be created in theseproducts.

2.2.10 Incomplete Support for Multischema Databases for Query OutlinesBug 886825

In prior releases of Oracle Rdb, the support for multischema databases wasincomplete for query outlines for the following reasons:

• The CREATE OUTLINE statement did not support the STORED NAMEIS clause. Therefore, user-specified names could not be provided for queryoutlines.

The workaround for this problem was to accept the unique names generatedby SQL.

• The OPTIMIZE USING clause on the DECLARE CURSOR, SELECT,UPDATE, and DELETE statements did not allow a fully-qualified queryoutline name.

A workaround for this problem was to specify the query outline name withoutthe catalog or schema reference.

The following example shows the error reported when an attempt was made touse a fully-qualified name for the outline SAMPLE:

SQL> select count(a)cont> from SAMPLE_TABLEcont> where b <> CURRENT_TIMESTAMPcont> optimize using outer_space.inner_space.sample;optimize using outer_space.inner_space.sample;

^%SQL-W-LOOK_FOR_STT, Syntax error, looking for:%SQL-W-LOOK_FOR_CON, AS, FOR, USING, ;,%SQL-F-LOOK_FOR_FIN, found . instead

These problems have been corrected in Oracle Rdb7 Release 7.0.3.1. SQL nowsupports the STORED NAME IS clause for the CREATE OUTLINE statement,and the fully-qualified name can be used in the OPTIMIZE USING clause.

Note

If a fully-qualified name is used for the OPTIMIZE USING clause, thenthe catalog and schema must exist within the database. However, forconsistency with single schema databases, the outline need not exist atthe time of the query processing. If the outline is not created prior toexecution of the query, then this name will be ignored by the Oracle Rdboptimizer.

CREATE OUTLINE <outline-name> -+---------------------------------+--+| | |+-> STORED NAME is <stored-name> -+ |

|+------------------------------------<--------------------------+|+- ...etc...


2.2.11 UNKNOWN_VAR Error Reported During Select from a ViewBug 903619

In prior versions of Oracle Rdb, the error, ‘‘unknown variable 1 found in the querystring’’ may be reported when selecting rows from a view.

The problem only occurs when the conditional expressions CASE, COALESCE,NVL, and DECODE are used in a SELECT DISTINCT clause as part of aCREATE VIEW statement. Typically these conditional expressions containsubselects that reference other table contexts. Although the view can be created,it could never be used successfully, as shown in this example:

SQL> select * from sample_view;%RDB-E-INVALID_BLR, request BLR is incorrect at offset 66-RDMS-E-UNKNOWN_VAR, unknown variable 1 found in the query string

This error is caused by an incorrect definition stored in the database by theCREATE VIEW statement. Once this release of Oracle Rdb is installed, the viewcan be deleted and re-created to correct this problem.

A workaround for this problem is to rewrite the view SELECT clause to useGROUP BY or a derived table in place of the DISTINCT clause. The resultingview will probably be more efficient and perform less table accesses because thecomplex expressions will not be used for the unique row selection.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. The CREATEVIEW statement now correctly handles conditional expressions with subselects inthe view SELECT clause.

2.2.12 SQL Module Language Compiler Fails UnexpectedlyBug 496320

It is possible that the SQL module language compiler could fail when processing aFETCH statement. The failure occurs when parameters have the same names ascolumns in the table and are not prefixed with colons. The SQL module languagecompiler should diagnose this error, but instead it fails to complete the compile.

On OpenVMS VAX systems, the SQL module language compile fails with errorsimilar to those in the following example:

$ sql$mod appl00000207’GF 14 28 06A7 797 MOVC3 #20,

G^MESSAGE$1_1+MESSAGE$1_1$VAR$3, G^MESSAGE$0_0+MESSAGE$0_0$VAR$0%MACRO-E-UNDEFSYM, Undefined symbol

06AE%MACRO-E-UNDEFSYM, Undefined symbol

00000223’GF 01 28 06CA 804 MOVC3 #1,G^MESSAGE$1_1+MESSAGE$1_1$VAR$6, G^MESSAGE$0_0+MESSAGE$0_0$VAR$0%MACRO-E-UNDEFSYM, Undefined symbol

06D1%MACRO-E-UNDEFSYM, Undefined symbol

There were 4 errors, 0 warnings and 0 information messages, on lines:797 (2) 804 (2)

MACRO/NOLIST MAR_SPEC

On OpenVMS Alpha systems the following is produced:

$ sql$mod appl%SQL-E-CHKINIT, 2 integrity check errors in initial IL & ST for moduleREAD_BD_FOR_BATCH%SQL-I-BUGCHKDMP, generating bugcheck dump file DISK1:[TEST]SQLBUGCHK.DMP;


This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. The SQL modulelanguage compiler has been enhanced to detect this situation and report a newerror message, as shown in the following example:

$ sql$mod applARCHIVED1

%SQL-F-INVINTOTAR, (1) target for an INTO clause must be a variable orparameter

2.2.13 ORDER BY Select Query from a View with ORDER BY on the SameCOMPUTED BY Column Returns Wrong Result

Bugs 880630 and 934057

The following ORDER BY select query from a view with ORDER BY on the sameCOMPUTED BY column returns wrong results:

select F_COMPUTE_BY from test_view order by F_COMPUTE_BY;F_COMPUTE_BY

5.505.50

2 rows selectedwhere the view test_view is defined as :create view test_view (LEV_ID ,F_COMPUTE_BY) as

selectT1.LEV_ID,T1.F_COMPUTE_BYfrom T1 T1order by T1.F_COMPUTE_BY asc ;

;

where the column F_COMPUTE_BY is defined as:

COMPUTED BY (select C2.F2 from T2 C2where (T1.F1 = C2.F1)));

The correct result should be the same as the following query:

SQL> sel * from test_view;LEV_ID F_COMPUTE_BY123456 5.50123456 10.102 rows selected

Here is the script to reproduce the problem:

create table T2 (F1 CHAR(26),F2 INTEGER);

INSERT INTO T2 VALUE (’F1_01’, 10);INSERT INTO T2 VALUE (’F1_02’, 5);

create table T1 (F1 CHAR(26),REV_ID INTEGER,PROJ_ID CHAR(6),LEV_ID CHAR(6),F_COMPUTE_BY

computed by (select T2.F2 from T2 T2where (T1.F1 = T2.F1)));


INSERT INTO T1 (F1, REV_ID, PROJ_ID, LEV_ID) VALUE(’F1_01’, 990413001, ’2800’, ’123456’);

INSERT INTO T1 (F1, REV_ID, PROJ_ID, LEV_ID) VALUE(’F1_02’, 990413002, ’2800’, ’123456’);

create index T1_NDXon T1 (PROJ_ID asc,REV_ID asc);

create index T2_NDXon T2 (F1);

This problem occurs when the ORDER BY clause of both the main select queryand view query is placed upon the same column where the column is COMPUTEDBY as a subquery select.

The current problem is caused by Oracle Rdb 7.0.1.6 where a fix was introducedfor bug 651184 to explicitly join the subselect query under the view query if theview query contains ORDER BY clause. This fix has a serious flaw when thesubselect query is defined under a COMPUTED BY definition for the column.

Workaround: None.


2.3 Oracle RMU Errors Fixed2.3.1 Lock ID Hidden by Stall Message in RMU/SHOW Statistics

Previously, RMU/SHOW Statistics could ‘‘hide’’ the Lock ID value when displayingstall messages if the stall message was long, even when the terminal width wasset wide enough to display everything correctly. For example:

Node: LLDV00 Oracle Rdb V7.0-01 Performance Monitor 11-AUG-1999 22:39:0Rate: 3.00 Seconds Stall Messages Elapsed: 6 04:26:42.2Page: 1 of 1 DEV_DISKE:[DEV.DATA]RGN_DB.RDB;2 Mode: Onlie

Process.ID Since...... T Stall.reason............................. Lock.ID.20202B96:1 10:37:11.23 W Waiting for client ’....Q...’ 000000051000000040000005

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. RMU/SHOWStatistics now displays the Lock ID value with an offset from the right margin ofthe display. Setting the display wider (to 132 columns, for example) allows boththe stall message text and the Lock ID to be displayed at one time.

2.3.2 Terminal Width Checked by RMU/SHOW StatisticsRMU/SHOW Statistics assumes a minimum terminal width of 80 columns. Whenrun on a terminal set to less than 80 columns, RMU/SHOW Statistics couldbugcheck or be unable to properly format the display.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. RMU/SHOWStatistics now enforces a minimum terminal width of 80 columns. It also enforcesa minimum row count of 24. If the terminal is set to less than the minimumnumber of rows or columns, an error message is displayed.


2.3.3 RMU/SHOW Statistic Physical-Area Event Creation BugchecksAttempting to create a user-defined event involving a physical or logical areawhen used in conjunction with the /NOINTERACTIVE qualifier causes theRMU/SHOW Statistic utility to bugcheck.

The following configuration file entry shows an example of a user-defined eventthat will cause the problem when the RMU/SHOW Statistic utility is invokedusing the NOINTERACTIVE qualifier:

EVENT_DESCRIPTION = "ENABLE ’ (Extends)’ \MAX_CUR_TOTAL \AREA DEPARTMENTS\INITIAL 0 EVERY 1 LIMIT 0 \NOTIFY OPER12";

The workaround is to use the /INTERACTIVE qualifier, or do not specify an eventusing a physical or logical area statistic name.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. User-definedevents using physical or logical areas in conjunction with the /NOINTERACTIVEqualifier now work as expected.

2.3.4 Ignore Row Caches when Writing RMU/SHOW Statistic ReportBug 944656

Customers frequently use the RMU/SHOW Statistic utility Write Report(Numbers) to generate screen snapshots which are then processed using variousanalysis tools. When the database has row caches enabled, the RMU/SHOWStatistic utility maps all available caches into memory. When the databasecontains a large number of row caches, or the row caches have a large number ofslots, or both, this can cause the process P0 space to be exhausted.

The best workaround is to put the row caches in system space (VLM).


When row caching is allowed on the database, the "Options" on-screen menu willdisplay the following new options:

• Include row cache information

This option allows you to include all row cache information in the report.This is the default setting.

• Exclude row cache information

This option allows you to exclude all row cache information in the report.

You can also use the new configuration variable REPORT_IGNORE_RCACHE tospecify the initial report option. The value TRUE indicates that the report shouldexclude all row cache information. The default value FALSE indicates that thereport should include row cache information. This variable can be changed at runtime using the Options on-screen menu options that was previously described.

2.3.5 RMU/LOAD from a Record-Oriented Device Caused RMS-F-IOP ErrorPreviously, attempting to use the RMU/LOAD utility using a record-orienteddevice (a terminal or mailbox, for example) for data input would fail with anRMS-F-IOP error.


For example:

$ RMU/LOAD DB.RDB /RECORD_DEFINITION=FILE=TBL.RRD TBL MBA500:%RMU-F-FILACCERR, error opening input file MBA500:[DB].UNL;-RMS-F-IOP, operation invalid for file organization or device%RMU-I-DATRECSTO, 0 data records stored.%RMU-F-FTL_LOAD, Fatal error for LOAD operation at 13-JUN-1999 15:13:33.41

This problem was caused by an attempt to search for the input file on thespecified device to return the full file specification.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. When the inputsource is a record-oriented device, no search for the input file is done.

2.3.6 RMU/EXTRACT Sometimes Bugchecks when Processing Many StorageAreas

Bug 633334

In previous versions of Oracle Rdb, the RMU/EXTRACT storage area outputcould be truncated or RMU might bugcheck at EXTRACT_DATABASE +789 if thedatabase had many storage areas. This affects the /ITEM options for DATABASE,IMPORT, and ALL.

RMU uses a special interface call (API) to retrieve all the names of the storageareas. This problem occured when the buffer was incorrectly truncated. Thistruncated buffer appeared corrupted and so RMU/EXTRACT would bugcheck.

This problem has been corrected in Oracle Rdb7 Release 7.0.3.1. The bufferreturned from the storage area query is no longer truncated.

2.3.7 Problem in Reporting Recovered AIJ Sequence NumberIn previous releases of Oracle Rdb, when multiple, after-image journals werecombined into one journal file, such as a backup of multiple journals, theRMU/RECOVER command’s AIJONEDONE trace message could display incorrectinformation. The RMU/RECOVER command might display the sequence numberof the next journal to be recovered instead of the journal just recovered. In thefollowing example, sequence 5 has just been recovered and sequence 6 will berecovered next, but the AIJONEDONE message indicates an incorrect sequencenumber of 6:

%RMU-I-AIJONEDONE, AIJ file sequence 6 roll-forward operations completed


2.3.8 Truncate Table Could Generate RMU/VERIFY ErrorsBug 919653

In rare cases, where the area bit map (ABM) pages are at the beginning of aspace management page (SPAM) interval, a truncate of that logical area couldcorrupt the linkages between the area inventory page (AIP), the area bit mappage, and the SPAM page. This corruption was reported by RMU/VERIFY.

The following example shows the output from the VERIFY. The reference tolarea_dbid : -1 indicates a deleted logical area on the SPAM page.


%RMU-W-AIPLAREID, area inventory page 7 entry #14 contains areference to logical area 95 that is nonexistent

%RMU-W-BADABMPTR, invalid larea for ABM page 192151 in storage area 1.The SPAM page entry for this page is for a different larea.SPAM larea_dbid : -1 page larea_dbid: 95.

%RMU-W-BADABMPTR, invalid larea for ABM page 192152 in storage area 1.The SPAM page entry for this page is for a different larea.SPAM larea_dbid : -1 page larea_dbid: 95.

Issuing an RMU/REPAIR/SPAM/ABM command will correct this error.


2.4 Row Cache Errors Fixed2.4.1 Row Cache of One Slot Causes Loop

When the Oracle Rdb7 row cache feature is enabled and if a cache is createdspecifying only one slot in the cache, a second insert into the cache may cause aprocess to enter a seemingly infinite loop.

As a possible workaround, always create row caches with at least 2 slots in thecache. Oracle recommends that you create all caches with at least 100 slots.

This problem as been corrected. Caches with only 1 slot no longer cause the toCPU loop.

2.5 Hot Standby Errors Fixed2.5.1 Stopping Hot Standby on Standby then Master Hangs Standby for 15

MinutesIf the Hot Standby product is properly shutdown on the standby database first,and then immediately thereafter also shutdown properly on the master database,it is possible for the standby database to wait 15 minutes before actually shuttingdown.

The workaround is to do any of the following:

• Stop Hot Standby on the standby database using the /ABORT qualifier.

• Restart the master database, and properly shutdown the master database.

This problem has been corrected in Oracle Rdb7 Version 7.0.3.1. Shutting downthe Hot Standby product from the standby database, master database, or bothnow works as expected.

2.5.2 Monitor ENQLM Minimum Increased to 32767All OpenVMS Systems

Bug 357439

In previous versions, the Oracle Rdb7 monitor process (RDMMON) was createdwith a minimum lock limit (ENQLM) of 8192 locks. This minimum has beenincreased to 32767 locks (the OpenVMS maximum value).

2.6 Oracle Trace Errors Fixed


2.6.1 Incorrect Completion Status Reported by Oracle TraceBug 949283

An incorrect value for the status of a request was being stored by Oracle Trace.The stored value was larger than the field definition and also corrupted the valuefor the Client_PC address. When the Oracle Trace information was formattedin a database, incorrect information was being returned in the queries againsttables holding this information.

There is no workaround for this problem.



3Documentation Corrections

This chapter provides information not currently available in the Oracle Rdb7documentation set.

3.1 Documentation Corrections3.1.1 Partition Clause is Optional on CREATE STORAGE MAP

Bug 642158

In the Oracle Rdb7 SQL Reference Manual, the syntax diagram for the CREATESTORAGE MAP statement incorrectly shows the partition clause as requiredsyntax. The partition clause is not a required clause.

This correction will appear in the next publication of the Oracle Rdb SQLReference Manual.

3.1.2 Oracle Rdb Logical NamesThe Oracle Rdb7 Guide to Database Performance and Tuning contains a tablein Chapter 2 summarizing the Oracle Rdb logical names and configurationparameters. The information in the following table supersedes the entries for theRDM$BIND_RUJ_ALLOC_BLKCNT and RDM$BIND_RUJ_EXTEND_BLKCNTlogical names.

Logical NameConfiguration Parameter Function

RDM$BIND_RUJ_ALLOC_BLKCNT Allows you to override the default value of the.ruj file. The block count value can be definedbetween 0 and 2 billion with a default of 127.

RDM$BIND_RUJ_EXTEND_BLKCNT Allows you to pre-extend the .ruj files for eachprocess using a database. The block count valuecan be defined between 0 and 65535 with adefault of 127.

3.1.3 Waiting for Client Lock MessageThe Oracle Rdb7 Guide to Database Performance and Tuning contains a sectionin Chapter 3 that describes the Performance Monitor Stall Messages screen. Thesection contains a list describing the ‘‘Waiting for’’ messages. The description ofthe ‘‘waiting for client lock’’ message was missing from the list.

A client lock indicates that an Oracle Rdb metadata lock is in use. The termclient indicates that Oracle Rdb is a client of the Oracle Rdb locking services.The metadata locks are used to guarantee memory copies of the metadata (table,index, and column definitions) are consistent with the on-disk versions.

Documentation Corrections 3–1

The ‘‘waiting for client lock’’ message means the database user is requesting anincompatible locking mode. For example, when trying to delete a table which isin use, the drop operation requests a PROTECTED WRITE lock on the metadataobject (such as a table) which is incompatible with the existing PROTECTEDREAD lock currently used by others of the table.

These metadata locks consist of three longwords. The lock is displayed in textformat first, followed by its hexadecimal representation. The text version masksout nonprintable characters with a period (.).

The leftmost value seen in the hexadecimal output contains the ID of the object.The following ID describes the tables, routines, modules and storage map areas.

• For tables and views, the ID represents the unique value found in theRDB$RELATION_ID column of the RDB$RELATIONS system table for thegiven table.

• For routines, the ID represents the unique value found in theRDB$ROUTINE_ID column of the RDB$ROUTINES system table for thegiven routine.

• For modules, the ID represents the unique value found in theRDB$MODULE_ID column of the RDB$MODULES system table for thegiven module.

• For storage map areas, the ID presents the physical area ID. The ‘‘waiting forclient lock’’ message on storage map areas is very rare. This may be raisedfor databases that have been converted from versions prior to Oracle Rdb 5.1.

The next value displayed signifies the object type. The following table describesobjects and their hexadecimal type values:

Table 3–1 Object Type Values

Object Hexadecimal Value

Tables or views 00000004

Routines 00000006

Modules 00000015

Storage map areas 0000000E

The last value in the hexadecimal output represents the lock type. The value 55indicates this is a client lock.

The following example shows a ‘‘waiting for client’’ lock message from the StallMessages screen:

Process.ID Since...... Stall.reason............................. Lock.ID.46001105:2 10:40:46.38 - waiting for client ’........’ 000000190000000400000055

1 2 3 4

The following list describes each part of the client lock:

1 ........ indicates nonprintable characters.

2 00000019 indicates unique identifier hex value 19 (RDB$RELATION_ID =25).

3 00000004 indicates object type 4 which is a table.

4 00000055 indicates this is a client lock.

3–2 Documentation Corrections

To determine the name of the referenced object given the Lock ID the followingqueries can be used based on the object type:

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE RDB$RELATION_ID = 25;SQL> SELECT RDB$MODULE_NAME FROM RDB$MODULES WHERE RDB$MODULE_ID = 12;SQL> SELECT RDB$ROUTINE_NAME FROM RDB$ROUTINES WHERE RDB$ROUTINE_ID = 7;

Note

Because the full client lock output is long, it may require more space thanis allotted for the Stall.reason column and therefore can be overwritten bythe Lock.ID. column output.

For more detailed lock information, perform the following steps:

1. Press the L option from the horizontal menu to display a menu ofLock IDs.

2. Select the desired Lock ID.

3.1.4 Documentation Error in Oracle Rdb7 Guide to Database Performanceand Tuning

The Oracle Rdb7 Guide to Database Performance and Tuning, Volume 2 containsan error in section C.7, ‘‘Displaying Sort Statistics with the R Flag’’.

When describing the output from this debugging flag, bullet 9 states:

Work File Alloc indicates how many work files were used in the sortoperation. A zero (0) value indicates that the sort was accomplishedcompletely in memory.

This is incorrect. This statistic should be described as shown:

Work File Alloc indicates how much space (in blocks) was allocated in thework files for this sort operation. A zero (0) value indicates that the sort wasaccomplished completely in memory.

This error will be corrected in a future release of Oracle Rdb Guide to DatabasePerformance and Tuning.

3.1.5 SET FLAGS Option IGNORE_OUTLINE Not AvailableBug 510968

The Oracle Rdb7 SQL Reference Manual described the option IGNORE_OUTLINE in Table 7-6 of the SET FLAGS section. However, this keywordwas not implemented in Oracle Rdb7.

This has been corrected in this release of Oracle Rdb7. This keyword is nowrecognized by the SET FLAGS statement. As a workaround the logical nameRDMS$BIND_OUTLINE_FLAGS "I" can be used to set this attribute.

3.1.6 SET FLAGS Option INTERNALS Not DescribedThe Oracle Rdb7 SQL Reference Manual does not describe the optionINTERNALS in Table 7-6 in the SET FLAGS section. This keyword was availablein first release of Oracle Rdb7 and is used to enable debug flags output forinternal queries such as constraints and triggers. It can be used in conjunctionwith other options such as STRATEGY, BLR, and EXECUTION. For example, thefollowing flag settings are equivalent to defining the RDMS$DEBUG_FLAGS as


ISn and shows the strategy used by the trigge’s actions on the AFTER DELETEtrigger on the EMPLOYEES table.

SQL> SET FLAGS ’STRATEGY, INTERNAL, REQUEST_NAME’;SQL> SHOW FLAGS

Alias RDB$DBHANDLE:Flags currently set for Oracle Rdb:

INTERNALS,STRATEGY,PREFIX,REQUEST_NAMESSQL> DELETE FROM EMPLOYEES WHERE EMPLOYEE_ID = ’00164’;~S: Trigger name EMPLOYEE_ID_CASCADE_DELETEGet Temporary relation Retrieval by index of relation DEGREESIndex name DEG_EMP_ID [1:1]

~S: Trigger name EMPLOYEE_ID_CASCADE_DELETEGet Temporary relation Retrieval by index of relation JOB_HISTORYIndex name JOB_HISTORY_HASH [1:1]

~S: Trigger name EMPLOYEE_ID_CASCADE_DELETEGet Temporary relation Retrieval by index of relation SALARY_HISTORYIndex name SH_EMPLOYEE_ID [1:1]

~S: Trigger name EMPLOYEE_ID_CASCADE_DELETEConjunct Get Retrieval by index of relation DEPARTMENTSIndex name DEPARTMENTS_INDEX [0:0]

Temporary relation Get Retrieval by index of relation EMPLOYEESIndex name EMPLOYEES_HASH [1:1] Direct lookup

1 row deleted

3.1.7 Documentation for VALIDATE_ROUTINE Keyword for SET FLAGSThe SET FLAGS section of the Oracle Rdb7 SQL Reference Manual omittedthe description of the VALIDATE_ROUTINE keyword (which can be negatedas NOVALIDATE_ROUTINE). This keyword enables the re-validation of aninvalidated stored procedure or function. This flag has the same action asthe logical RDMS$VALIDATE_ROUTINE or the UNIX environment variableSQL_VALIDATE_ROUTINE described in the Oracle Rdb7 Guide to DatabasePerformance and Tuning.

This example shows the re-validation of a stored procedure. When the storedroutine is successfully prepared (but not executed), the setting of VALIDATE_ROUTINE causes the entry for this routine in the RDB$ROUTINES system tableto be set as valid.

SQL> SET TRANSACTION READ WRITE;SQL> SET FLAGS ’VALIDATE_ROUTINE’;SQL> SET NOEXECUTE;SQL> CALL ADD_EMPLOYEE (’Smith’);SQL> SET EXECUTE;SQL> COMMIT;

In this example, the use of the SET NOEXECUTE statement in interactive SQLallows the stored routine to be successfully compiled, but it is not executed.

3.1.8 Documentation for Defining the RDBSERVER Logical NameBugs 460611 and 563649.

Sections 4.3.7.1 and 4.3.7.2 in the Oracle Rdb7 for OpenVMS Installation andConfiguration Guide provide the following examples for defining the RDBSERVERlogical name:

$ DEFINE RDBSERVER SYS$SYSTEM:RDBSERVER70.EXEand$ DEFINE RDBSERVER SYS$SYSTEM:RDBSERVER61.EXE


These definitions are inconsistent with other command procedures that attemptto reference the RDBSERVERxx.EXE image. The following is one example wherethe RDBSERVER.COM procedure references SYS$COMMON:<SYSEXE> andSYS$COMMON:[SYSEXE], rather than SYS$SYSTEM:

$ if .not. -((f$locate ("SYS$COMMON:<SYSEXE>",rdbserver_image) .ne. log_len) .or. -(f$locate ("SYS$COMMON:[SYSEXE]",rdbserver_image) .ne. log_len))

$ then$ say "’’rdbserver_image’ is not found in SYS$COMMON:<SYSEXE>"$ say "RDBSERVER logical is ’’rdbserver_image’"$ exit$ endif

In this case, if the logical name were defined as instructed in the Oracle Rdb7 forOpenVMS Installation and Configuration Guide, the image would not be found.

The Oracle Rdb7 for OpenVMS Installation and Configuration Guide shoulddefine the logical name as follows:

DEFINE RDBSERVER SYS$COMMON:<SYSEXE>RDBSERVER70.EXEand

DEFINE RDBSERVER SYS$COMMON:<SYSEXE>RDBSERVER61.EXE

3.1.9 Undocumented SET Commands and Language OptionsThe following SET statements were omitted from the Oracle Rdb7 documentation.

3.1.9.1 QUIET COMMIT OptionThe SET QUIET COMMIT statement (for interactive and dynamic SQL), themodule header option QUIET COMMIT, the /QUIET_COMMIT (and /NOQUIET_COMMIT) qualifier for SQL module language, or the /SQLOPTIONS=QUIET_COMMIT (and NOQUIET_COMMIT) option for the SQL language precompilerallows the programmer to control the behavior of the COMMIT and ROLLBACKstatements in cases where there is no active transaction.

By default, if there is no active transaction, SQL will raise an error whenCOMMIT or ROLLBACK is executed. This default is retained for backwardcompatibility for applications that may wish to detect the situation. If QUIETCOMMIT is set to ON, then a COMMIT or ROLLBACK executes successfullywhen there is no active transaction.

Note

Within a compound statement, the COMMIT and ROLLBACK statementsin this case are ignored.

ExamplesIn interactive or dynamic SQL, the following SET command can be used to disableor enable error reporting for COMMIT and ROLLBACK when no transaction isactive. The parameter to the SET command is a string literal or host variablecontaining the keyword ON or OFF. The keywords may be in any case (upper,lower, or mixed).


SQL> COMMIT;%SQL-F-NO_TXNOUT, No transaction outstandingSQL> ROLLBACK;%SQL-F-NO_TXNOUT, No transaction outstandingSQL> SET QUIET COMMIT ’on’;SQL> ROLLBACK;SQL> COMMIT;SQL> SET QUIET COMMIT ’off’;SQL> COMMIT;%SQL-F-NO_TXNOUT, No transaction outstanding

In the SQL module language or precompiler header, the clause QUIET COMMITcan be used to disable or enable error reporting for COMMIT and ROLLBACKwhen no transaction is active. The keyword ON or OFF must be used to enableor disable this feature. The following example enables QUIET COMMIT so thatno error is reported if a COMMIT is executed when no transaction is active. Forexample:

MODULE TXN_CONTROLLANGUAGE BASICPARAMETER COLONSQUIET COMMIT ON

PROCEDURE S_TXN (SQLCODE);SET TRANSACTION READ WRITE;

PROCEDURE C_TXN (SQLCODE);COMMIT;

3.1.9.2 COMPOUND TRANSACTIONS OptionThe SET COMPOUND TRANSACTIONS statement (for interactive and dynamicSQL) and the module header option COMPOUND TRANSACTIONS allows theprogrammer to control the SQL behavior for starting default transactions forcompound statements.

By default, if there is no current transaction, SQL will start a transaction beforeexecuting a compound statement or stored procedure. However, this may conflictwith the actions within the procedure, or may start a transaction for no reason ifthe procedure body does not perform any database access. This default is retainedfor backward compatibility for applications that may expect a transaction to bestarted for the procedure.

If COMPOUND TRANSACTIONS is set to EXTERNAL, then SQL starts atransaction before executing the procedure; otherwise, if it is set to INTERNAL,it allows the procedure to start a transaction as required by the procedureexecution.

ExamplesIn interactive or dynamic SQL, the following SET command can be used to disableor enable transactions started by the SQL interface. The parameter to the SETcommand is a string literal or host variable containing the keyword INTERNALor EXTERNAL. The keywords may be in any case (upper, lower, or mixed). Forexample:

SQL> SET COMPOUND TRANSACTIONS ’internal’;SQL> CALL START_TXN_AND_COMMIT ();SQL> SET COMPOUND TRANSACTIONS ’external’;SQL> CALL UPDATE_EMPLOYEES (...);


In the SQL module language or precompiler header, the clause COMPOUNDTRANSACTIONS can be used to disable or enable starting a transaction forprocedures. The keyword INTERNAL or EXTERNAL must be used to enable ordisable this feature.

MODULE TXN_CONTROLLANGUAGE BASICPARAMETER COLONSCOMPOUND TRANSACTIONS INTERNAL

PROCEDURE S_TXN (SQLCODE);BEGINSET TRANSACTION READ WRITE;END;

PROCEDURE C_TXN (SQLCODE);BEGINCOMMIT;END;

3.1.10 Undocumented Size Limit for Indexes with Keys Using CollatingSequences

Bug 586079

When a column is defined with a collating sequence, the index key is speciallyencoded to incorporate the correct ordering (collating) information. This specialencoding takes more space than keys encoded for ASCII (the default when nocollating sequence is used). Therefore, the encoded string uses more than thecustomary one byte per character of space within the index. This is true for allversions of Oracle Rdb that support collating sequences.

For all collating sequences, except Norwegian, the space required isapproximately 9 bytes for every 8 characters. So, a CHAR (24) column willrequire approximately 27 bytes. For Norwegian collating sequences, the spacerequired is approximately 10 bytes for every 8 characters.

The space required for encoding the string must be taken into account whencalculating the size of an index key against the limit of 255 bytes. Suppose acolumn defined with a collating sequence of GERMAN was used in an index. Thelength of that column is limited to a maximum of 225 characters because the keywill be encoded in 254 bytes.

The following example demonstrates how a 233 character column, defined with aGerman collating sequence and included in an index, exceeds the index size limitof 255 bytes, even though the column is defined as less than 255 characters inlength:

SQL> CREATE DATABASEcont> FILENAME ’TESTDB.RDB’cont> COLLATING SEQUENCE GERMAN GERMAN;SQL> CREATE TABLE EMPLOYEE_INFO (cont> EMP_NAME CHAR (233));SQL> CREATE INDEX EMP_NAME_IDXcont> ON EMPLOYEE_INFO (cont> EMP_NAME ASC)cont> TYPE IS SORTED;%RDB-E-NO_META_UPDATE, metadata update failed-RDMS-F-INDTOOBIG, requested index is too big


3.1.11 Changes to RMU/REPLICATE AFTER/BUFFERS CommandThe behavior of the RMU/REPLICATE AFTER/BUFFERS command has beenchanged. The /BUFFERS qualifier may be used with either the CONFIGUREoption or the START option.

When using local buffers, the AIJ log roll-forward server (LRS) will use aminimum of 4096 buffers. The value provided to the /BUFFERS qualifier willbe accepted, but it will be ignored if it is less than 4096. In addition, furtherparameters will be checked and the number of buffers may be increased if theresulting calculations are greater than the number of buffers specified by the/BUFFERS qualifier. If the database is configured to use more than 4096 AIJrequest blocks (ARBs), then the number of buffers may be increased to thenumber of ARBs configured for the database. The LRS ensures that there are atleast 10 buffers for every possible storage area in the database. Thus, if the totalnumber of storage areas (both used and reserved) multiplied by 10 results in agreater number of buffers, that number will be used.

When global buffers are used, the number of buffers used by the AIJ log roll-forward server is determined as follows:

• If the /BUFFERS qualifier is omitted and the /ONLINE qualifier is specified,the number of buffers will default to the previously configured value, if any,or 256, whichever is larger.

• If the /BUFFERS qualifier is omitted and the /ONLINE qualifier is notspecified or the /NOONLINE is specified, the number of buffers will default tothe maximum number of global buffers allowed per user (‘‘USER LIMIT’’), or256, whichever is larger.

• If the /BUFFERS qualifier is specified, that value must be at least 256, and itmay not be greater than the maximum number of global buffers allowed peruser (‘‘USER LIMIT’’).

The /BUFFER qualifier now enforces a minimum of 256 buffers for the AIJ logroll-forward server. The maximum number of buffers allowed is still 524288buffers.

3.1.12 Change in the Way RDMAIJ Server is Set Up in UCXStarting with Oracle Rdb V7.0.2.1, the RDMAIJ image has become a variantedimage. Therefore, the information in section 2.12, ‘‘Step 10: Specify the NetworkTransport Protocol,’’ of the Oracle Rdb7 and Oracle CODASYL DBMS Guideto Hot Standby Databases has become outdated in regards to setting up theRDMAIJSERVER object when using UCX as the network transport protocol. TheUCX SET SERVICE command should now look similar to the following:

$ UCX SET SERVICE RDMAIJ -/PORT=<port_number> -/USER_NAME=RDMAIJ -/PROCESS_NAME=RDMAIJ -/FILE=SYS$SYSTEM:RDMAIJSERVER.com -/LIMIT=<limit>

And for Oracle Rdb multiversion, it should look similar to the following:


$ UCX SET SERVICE RDMAIJ70 -/PORT=<port_number> -/USER_NAME=RDMAIJ70 -/PROCESS_NAME=RDMAIJ70 -/FILE=SYS$SYSTEM:RDMAIJSERVER70.com -/LIMIT=<limit>

The installation procedure for Oracle Rdb creates a user named RDMAIJ(nn)and places a file called RDMAIJSERVER(nn).com in SYS$SYSTEM and theRMONSTART(nn).COM command procedure will try to enable a service calledRDMAIJ(nn) if UCX is installed and running.

Changing the RDMAIJ server to a multivarianted image does not impactinstallations using DECNet since the correct DECNet object is created during theRdb installation.

3.1.13 CREATE INDEX Supported for Hot StandbyOn page 1-13 of the Guide to Hot Standby Databases, the add new index operationis incorrectly listed as an offline operation not supported by Hot Standby. TheCREATE INDEX operation is now fully supported by Hot Standby, as long as thetransaction does not span all available AIJ journals, including emergency AIJjournals.

3.1.14 Dynamic OR Optimization FormatsBug 711643

In Table C-2 on Page C-7 of the Oracle Rdb7 Guide to Database Performanceand Tuning, the dynamic OR optimization format is incorrectly documented as[l:h...]n. The correct formats for Oracle Rdb Release 7.0 and later are [(l:h)n] and[l:h,l2:h2].


4Known Problems and Restrictions

This chapter describes problems, restrictions, and workarounds known to exist inOracle Rdb7 Release 7.0.3.1.

4.0.1 AIJSERVER PrivilegesFor security reasons, the AIJSERVER account ("RDMAIJSERVER") is createdwith only NETMBX and TMPMBX privileges. These privileges are sufficient tostart Hot Standby, in most cases.

However, for production Hot Standby systems, these privileges are not adequateto ensure continued replication in all environments and workload situations.Therefore, Oracle recommends that the DBA provide the following additionalprivileges for the AIJSERVER account:

• ALTPRI

This privilege allows the AIJSERVER to adjust its own priority to ensureadequate quorum (CPU utilization) to prompt message processing.

• PSWAPM

This privilege allows the AIJSERVER to enable and disable process swapping,also necessary to ensure prompt message processing.

• SETPRV

This privilege allows the AIJSERVER to temporarily set any additionalprivileges it may need to access the standby database or its server processes.

• SYSPRV

This privilege allows the AIJSERVER to access the standby database rootfile,if necessary.

• WORLD

This privilege allows the AIJSERVER to more accurately detect standbydatabase server process failure and handle network failure more reliably.

4.0.2 Lock Remastering and Hot StandbyWhen using the Hot Standby feature, Oracle recommends that the VMSdistributed lock manager resource tree be mastered on the standby node whereHot Standby is started. This can be using any of the following methods:

• Disable dynamic lock remastering. This can be done dynamically by settingthe SYSGEN parameter PE1 to the value 1.

When using this option, be sure that Hot Standby is started on the nodewhere the standby database is first opened.

• Increasing the LOCKDIRWT value for the LRS node higher than any othernode in the same cluster. However, this is not a dynamic SYSGEN parameter,and a node re-boot is required.

Known Problems and Restrictions 4–1

Failure to prevent dynamic lock remastering may cause severe performancedegradation for the standby database, which ultimately may be reflected bydecreased master database transaction throughput.

4.0.3 RDB_SETUP Privilege ErrorRdb Web Agent V3.0 exposes a privilege problem with Rdb V7.0 and later. Thiswill be fixed in the next Rdb7 release.

The RDB_SETUP function fails with %RDB-E-NO_PRIV, privilege denied bydatabase facility.

It appears that the only workaround is to give users DBADM privilege. OracleCorporation does not recommend giving users the DBADM privilege.

4.0.4 Dynamic Optimizer Problem with Zigzag MatchIn some queries when utilizing zigzag match retrieval, a problem with theinteraction of the zigzag match and the dynamic optimizer may cause the queryto fail to deliver appropriate records.

The queries affected contain a join of two or more tables where the optimizerhas chosen to utilize a zigzag match retrieval strategy and dynamic optimization(LEAF) retrieval of data for the inner leg of the match.

The following is an example of the type of strategy associated with the affectedqueries:

MatchOuter loop (zig-zag)Conjunct Get Retrieval by index of relation TABLE1Index name TABLE1_INDEX_01 [1:1]

Inner loop (zig-zag)Leaf#02 Sorted TABLE2 Card=128800FgrNdx TABLE2_INDEX_01 [0:0] Fan=41BgrNdx1 TABLE2_INDEX_02 [0:0] Fan=27

A problem in the delivery of data by the inner leg of the match from the dynamicoptimizer data buffers prevented the appropriate match records in the outer fromleg being found.

A workaround for the problem is to use the RDMS$DISABLE_ZIGZAG_MATCHlogical name or the SQL SET FLAGS statement to disable the zigzag match:

VMS> define RDMS$DISABLE_ZIGZAG_MATCH 2

or

SQL> set flags ’nozigzag_match’;

Alternatively, dynamic optimization may be disabled by using the RDMS$MAX_STABILITY logical name or the SQL SET FLAGS statement:

VMS> define RDMS$MAX_STABILITY "TRUE"

or

SQL> set flags ’max_stability’;

4–2 Known Problems and Restrictions

4.0.5 Starting Hot Standby on Restored Standby Database May CorruptDatabase

If a standby database is modified outside of Hot Standby, then backed up andrestored, Hot Standby will appear to start up successfully but will corrupt thestandby database. A subsequent query of the database will return unpredictableresults, possibly in a bugcheck in DIOFETCH$FETCH_ONE_LINE. When thestandby database is restored from a backup of itself, the database is marked asunmodified. Therefore, Hot Standby cannot tell whether the database had beenmodified before the backup was taken.

WORKAROUND: None.

4.0.6 Restriction on Compound Statement Nesting LevelsThe use of multiple nesting levels of compound statements such as CASE or IF-THEN-ELSE within multistatement procedures can result in excessive memoryusage during the compile of the procedure. Virtual memory problems have beenreported with 10 or 11 levels of nesting. The following example shows an outlineof the type of nesting that can lead to this problem.

CREATE MODULE MY_MOD LANGUAGE SQLPROCEDURE MY PROCEDURE

( PARAMETERS .....);

BEGINDECLARE ....;

SET :VARS = 0;

SELECT .....;GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;CASE :FLAG ! Case #1

WHEN 100 THEN SET ...;WHEN -811 THEN SET ...;WHEN 0 THENSET ...; SELECT ...;GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;CASE :FLAG ! Case #2

WHEN 0 THEN SET ...;WHEN -811 THEN SET ...;WHEN 100 THEN

UPDATE...; SET ...;GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;IF :FLAG= 100 THEN SET ...; ! #1ELSEIF :FLAG < 0 THEN SET...; ! #2

ELSEDELETE ...GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;IF :FLAG= 100 THEN SET...; ! #3

SET ...;ELSEIF :FLAG < 0 THEN SET...; ! #4ELSEIF IN_CHAR_PARAM = ’S’ THEN ! #5UPDATE ...GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;IF :FLAG= 100 THEN SET ...; ! #6ELSEIF :FLAG < 0 THEN SET...; ! #7END IF; ! #7

END IF; ! #6END IF; ! #5


IF :FLAG = 0 THEN ! #5UPDATE ...GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;IF :FLAG= 100 THEN SET ...; ! #6ELSE

IF :FLAG < 0 THEN SET ...; ! #7ELSE

DELETE ...GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE:IF :FLAG= 100 THEN SET ...; ! #8ELSE

IF :FLAG < 0 THEN SET ...; ! #9ELSE

DELETE ...;GET DIAGNOSTICS EXCEPTION 1 :FLAG = RETURNED_SQLCODE;IF :FLAG= 100 THEN SET ...; ! #10

SET ...;ELSE

IF :FLAG < 0 THEN SET ...; ! #11END IF; (11 end if’s for #11 - #1)

ELSE SET ...;END CASE; ! Case #2

ELSE SET ...;END CASE; ! Case #1

END;END MODULE;

Workaround: Reduce the complexity of the multistatement procedure. Use fewerlevels of compound statement nesting by breaking the multistatement procedureinto smaller procedures or by using the CALL statement to execute nested storedprocedures.

4.0.7 Back Up All AIJ Journals Before Performing a Hot Standby SwitchoverOperation

Prior to performing a proper Hot Standby switchover operation from the oldmaster database to the new master database (old standby database), be sure toback up ALL AIJ journals.

If you do not back up the AIJ journals on the old master database prior toswitchover, they will be initialized by the Hot Standby startup operation, and youwill not have a backup of those AIJ journals.

Failure to back up these journals may place your new master database at risk ofnot being able to be recovered, requiring another fail-over in the event of systemfailure.

4.0.8 Concurrent DDL and Read-Only Transaction on the Same Table NotCompatible

It is possible that a read-only transaction could generate a bugcheck atDIOBND$FETCH_AIP_ENT + 1C4 if there is an active, uncommitted transactionthat is making metadata changes to the same table. Analysis shows that thesnapshot transaction is picking up stale metadata information. Dependingon what metatdata modifications are taking place, it is possible for metadatainformation to be removed from the system tables but still exist in the snapshotfile. When the read-only transaction tries to use that information, it no longerexists and causes a bugcheck.


The following example shows the actions of the two transactions:

A: B:attachset transaction read write

attachset transaction read only

drop index emp_last_nameselect * from employees...bugcheck...

The only workaround is to avoid running the two transactions together.

4.0.9 Oracle Rdb and the SRM_CHECK ToolThe Alpha Architecture Reference Manual, Third Edition (AARM) describesstrict rules for using interlocked memory instructions. The Compaq Alpha 21264(EV6) processor and all future Alpha processors are more stringent than theirpredecessors in their requirement that these rules be followed. As a result, codethat has worked in the past despite noncompliance may now fail when executedon systems featuring the new 21264 processor.

Oracle Rdb Release 7.0.3 supports the Compaq Alpha 21264 (EV6) processor.Oracle has performed extensive testing and analysis of the Rdb code to ensurethat it is compliant with the rules for using interlocked memory instructions.

However, customers using the Compaq supplied SRM_CHECK tool may findthat several of the Oracle Rdb images cause the tool to report potential alphaarchitecture violations. Although SRM_CHECK can normally identify a codesection in an image by the section’s attributes, it is possible for OpenVMS imagesto contain data sections with those same attributes. As a result, SRM_CHECKmay scan data as if it were code, and occasionally, a block of data may look likea noncompliant code sequence. This is the case with the Oracle Rdb suppliedimages. There is no actual instruction stream violation.

However, customers must use the SRM_CHECK tool on their own applicationexecutable image files. It is possible that applications linked with very old versionof Oracle Rdb (versions prior to Oracle Rdb Release 6.0-05) could have includedillegal interlocked memory instruction sequences produced by very old versions ofcompilers. This code was included in the Oracle Rdb object library files for somevery old versions of Oracle Rdb.

If errant instruction sequences are detected in the objects supplied by theOracle Rdb object libraries, the correct action is to relink the application with amore-current version of Oracle Rdb.

Additional information about the Compaq Alpha 21264 (EV6) processorinterlocked memory instructions issues is available at:

http://www.openvms.digital.com/openvms/21264_considerations.html

4.0.10 Oracle RMU Checksum_Verification QualifierThe Oracle Rdb RMU BACKUP database backup command includes a Checksum_Verification qualifier.

Specifying Checksum_Verification requests that the RMU Backup commandverify the checksum stored on each database page before it is backed up, therebyproviding end-to-end error detection on the database I/O.


The Checksum_Verification qualifier uses additional CPU resources but canprovide an extra measure of confidence in the quality of the data backed up. Useof the Checksum_Verification qualifier offers an additional level of data securityand use of the Checksum_Verification qualifier permits Oracle RMU to detect thepossibility that the data it is reading from these disks has only been partiallyupdated.

Note, however, that if you specify the Nochecksum_Verification qualifier, andundetected corruptions exist in your database, the corruptions are included inyour backup file and restored when you restore the backup file. Such a corruptionmight be difficult to recover from, especially if it is not detected until weeks ormonths after the restore operation is performed.

Oracle Corporation recommends that you use the Checksum_Verification qualifierwith all database backup operations because of the improved data integrity thisqualifier provides.

Unfortunately, due to an oversight, for versions of Oracle Rdb prior to Version8.0, the default for online backups is the Nochecksum_Verification qualifier.When you do not specify the Checksum_Verification qualifie on all of your RMUdatabase backup commands.

4.0.11 Do Not Use HYPERSORT with RMU/OPTIMIZE/AFTER_JOURNAL(Alpha)

OpenVMS Alpha V7.1 introduced the high-performance Sort/Merge utility (alsoknown as HYPERSORT). This utility takes advantage of the Alpha architectureto provide better performance for most sort and merge operations.

The high-performance Sort/Merge utility supports a subset of the SOR routines.Unfortunately, the high-performance Sort/Merge utility does not supportseveral of the interfaces used by the RMU/OPTIMIZE/AFTER_JOURNALcommand. In addition, the high-performance Sort/Merge utility reports noerror or warning when being called with the unsupported options used by theRMU/OPTIMIZE/AFTER_JOURNAL command.

For this reason, the use of the high-performance Sort/Merge utility is notsupported for the RMU/OPTIMIZE/AFTER_JOURNAL command. Do not definethe logical name SORTSHR to reference HYPERSORT.EXE.

4.0.12 Restriction on Using /NOONLINE with Hot StandbyWhen a user process is performing a read-only transaction on a standby database,an attempt to start replication on the standby database with the /NOONLINEqualifier will fail with the following error, and the database will be closedclusterwide:

%RDMS-F-OPERCLOSE, database operator requested database shutdown

In a previous release, the following error was returned and the process doing theread-only transaction was not affected:

%RDMS-F-STBYDBINUSE, standby database cannot be exclusively accessed forreplication

As a workaround, if exclusive access is necessary to the standby database,terminate any user processes before starting replication with the /NOONLINEqualifier.

This restriction is due to another bug fix and will be lifted in a future release ofOracle Rdb.


4.0.13 SELECT Query May Bugcheck withPSII2SCANGETNEXTBBCDUPLICATE Error

Bug 683916

A bugcheck could occur when a ranked B-tree index is used in a query aftera database has been upgraded to Release 7.0.1.3. This is a result of indexcorruption that was introduced in previous versions of Oracle Rdb7. Thiscorruption has been fixed and indexes created using Release 7.0.1.3 will not beimpacted.

As a workaround, delete the affected index and re-create it under Oracle Rdb7Release 7.0.1.3 or later.

4.0.14 DBAPack for Windows 3.1 is DeprecatedOracle Enterprise Manager DBAPack will no longer be supported for use onWindows 3.1.

4.0.15 Determining Mode for SQL Non-Stored ProceduresBug 506464.

Although stored procedures allow parameters to be defined with the modes IN,OUT, and INOUT, there is no similar mechanism provided for SQL modulelanguage or SQL precompiled procedures. However, SQL still associates a modewith a parameter using the following rules:

Any parameter which is the target of an assignment is considered an OUTparameter. Assignments consist of the following:

• The parameter is assigned a value with the SET or GET DIAGNOSTICSstatement. For example:

set :p1 = 0;get diagnostics :p2 = TRANSACTION_ACTIVE;

• The parameter is assigned a value with the INTO clause of an INSERT,UPDATE, or SELECT statement. For example:

insert into T (col1, col2)values (...)returning dbkey into :p1;

update accountsset account_balance = account_balance + :amountwhere account_number = :p1returning account_balanceinto :current_balance;

select last_nameinto :p1from employeeswhere employee_id = ’00164’;

• The parameter is passed on a CALL statement as an OUT or INOUTargument. For example:

begincall GET_CURRENT_BALANCE (:p1);end;


Any parameter that is the source for a query is considered an IN parameter.Query references include:

• The parameter appears in the SELECT list, WHERE or HAVING clauses of aSELECT, or DELETE statement. For example:

select :p1 || last_name, count(*)from Twhere last_name like ’Smith%’group by last_namehaving count(*) > :p2;

delete from Twhere posting_date < :p1;

• The parameter appears on the right side of the assignment in a SETstatement or SET clause of an UPDATE statement. For example:

set :p1 = (select avg(salary)from Twhere department = :p2);

update Tset col1 = :p1where ...;

• The parameter is used to provide a value to a column in an INSERTstatement. For example:

insert into T (col1, col2)values (:p1, :p2);

• The parameter is referenced by an expression in a TRACE, CASE, IF/ELSEIF,WHILE statement, or by the DEFAULT clause of a variable declaration. Forexample:

begindeclare :v integer default :p1;DO_LOOP:while :p2 > :p1loop

if :p1 is null thenleave DO_LOOP;

end if;set :p2 = :p2 + 1;...;trace ’Loop at ’, :p2;

end loop;end;

• The parameter is passed on a CALL statement as an INOUT or IN argument.For example:

begincall SET_LINE_SPEED (:p1);end;

SQL only copies values from the client (application parameters) to the procedurerunning in the database server if it is marked as either an IN or INOUTparameter. SQL only returns values from the server to the client applicationparameter variables if the parameter is an OUT or INOUT parameter.

If a parameter is considered an OUT only parameter, then it must be assigneda value within the procedure, otherwise the result returned to the applicationis considered undefined. This could occur if the parameter is used within aconditional statement such as CASE or IF/ELSEIF. In the following example, thevalue returned by :p2 would be undefined if :p1 were negative or zero:


beginif :p1 > 0 then

set :p2 = (select count(*)from Twhere col1 = :p1);

end if;end;

It is the responsibility of the application programmer to ensure that theparameter is correctly assigned values within the procedure. A workaround is toeither explicitly initialize the OUT parameter, or make it an INOUT parameter.For example:

beginif :p1 > 0 then

set :p2 = (select count(*)from Twhere col1 = :p1);

elseif :p2 is null thenbeginend;

end if;end;

The empty statement will include a reference to the parameter to make it an INparameter as well as an OUT parameter.

4.0.16 DROP TABLE CASCADE Results in %RDB-E-NO_META_UPDATE ErrorAn error could result when a DROP TABLE CASCADE statement is issued. Thisoccurs when the following conditions apply:

• A table is created with an index defined on the table.

• A storage map is created with a placement via index.

• The storage map is a vertical record partition storage map with two or moreSTORE COLUMNS clauses.

The error message given is %RDB-E-NO_META_UPDATE, metadata updatefailed.

The following example shows a table, index, and storage map definition followedby a DROP TABLE CASCADE statement and the resulting error message:

SQL> CREATE TABLE VRP_TABLE ( ID INT, ID2 INT);SQL> COMMIT;SQL> CREATE UNIQUE INDEX VRP_IDX ON VRP_TABLE (ID)SQL> STORE IN EMPIDS_LOW;SQL> COMMIT;SQL> CREATE STORAGE MAP VRP_MAPcont> FOR VRP_TABLEcont> PLACEMENT VIA INDEX VRP_IDXcont> ENABLE COMPRESSIONcont> STORE COLUMNS (ID)cont> IN EMPIDS_LOWcont> STORE COLUMNS (ID2)cont> IN EMPIDS_MID;SQL> COMMIT;SQL>SQL> DROP TABLE VRP_TABLE CASCADE;SQL> -- Index VRP_IDX is also being dropped.%RDB-E-NO_META_UPDATE, metadata update failed-RDMS-E-WISH_LIST, feature not implemented yet-RDMS-E-VRPINVALID, invalid operation for storage map "VRP_MAP"


The workaround to this problem is to first delete the storage map, and thendelete the table using the CASCADE option. The following example shows theworkaround. The SHOW statement indicates that the table, index, and storagemap were deleted:

SQL> DROP STORAGE MAP VRP_MAP;SQL> DROP TABLE VRP_TABLE CASCADE;SQL> -- Index VRP_IDX is also being dropped.SQL> COMMIT;SQL> SHOW TABLE VRP_TABLENo tables foundSQL> SHOW INDEX VRP_IDXNo indexes foundSQL> SHOW STORAGE MAP VRP_MAPNo Storage Maps Found

This problem will be corrected in a future version of Oracle Rdb.

4.0.17 Bugcheck Dump Files with Exceptions at COSI_CHF_SIGNALIn certain situations, Oracle Rdb bugcheck dump files will indicate an exceptionat COSI_CHF_SIGNAL. This location is, however, not the address of the actualexception. The actual exception occurred at the previous call frame on the stack(the one listed as the next "Saved PC" after the exception).

For example, consider the following bugcheck file stack information:

$ SEARCH RDSBUGCHK.DMP "EXCEPTION","SAVED PC","-F-","-E-"

***** Exception at 00EFA828 : COSI_CHF_SIGNAL + 00000140%COSI-F-BUGCHECK, internal consistency failureSaved PC = 00C386F0 : PSIINDEX2JOINSCR + 00000318Saved PC = 00C0BE6C : PSII2BALANCE + 0000105CSaved PC = 00C0F4D4 : PSII2INSERTT + 000005CCSaved PC = 00C10640 : PSII2INSERTTREE + 000001A0

.

.

.

In this example, the exception actually occurred at PSIINDEX2JOINSCR offset00000318. If you have a bugcheck dump with an exception at COSI_CHF_SIGNAL, it is important to note the next ‘‘Saved PC’’ because it will be neededwhen working with Oracle Rdb Support Services.

4.0.18 Interruptions Possible when Using Multistatement or Stored ProceduresLong running multistatement or stored procedures can cause other users in thedatabase to be interrupted by holding resources needed by those other users.Some resources obtained by the execution of a multistatement or stored procedurewill not be released until the multistatement or stored procedure finishes.This problem can be encountered even if the statement contains COMMIT orROLLBACK statements.

The following example demonstrates the problem. The first session enters anendless loop; the second session attempts to backup the database, but it ispermanently interrupted:

Session 1


SQL> ATTACH ’FILE MF_PERSONNEL’;SQL> CREATE FUNCTION LIB$WAIT (IN REAL BY REFERENCE)cont> RETURNS INT;cont> EXTERNAL NAME LIB$WAITcont> LOCATION ’SYS$SHARE:LIBRTL.EXE’cont> LANGUAGE GENERALcont> GENERAL PARAMETER STYLEcont> VARIANT;SQL> COMMIT;SQL> EXIT;

$ SQLSQL> ATTACH ’FILE MF_PERSONNEL’;SQL> BEGINcont> DECLARE :LAST_NAME LAST_NAME_DOM;cont> DECLARE :WAIT_STATUS INTEGER;cont> LOOPcont> SELECT LAST_NAME INTO :LAST_NAMEcont> FROM EMPLOYEES WHERE EMPLOYEE_ID = ’00164’;cont> ROLLBACK;cont> SET :WAIT_STATUS = LIB$WAIT (5.0);cont> SET TRANSACTION READ ONLY;cont> END LOOP;cont> END;

Session 2

$ RMU/BACKUP/LOG/ONLINE MF_PERSONNEL MF_PERSONNEL

From a third session we can see that the backup process is waiting for a lock heldin the first session:

$ RMU/SHOW LOCKS /MODE=BLOCKING MF_PERSONNEL================================================================================SHOW LOCKS/BLOCKING Information================================================================================

--------------------------------------------------------------------------------Resource: nowait signal

ProcessID Process Name Lock ID System ID Requested Granted--------- --------------- --------- --------- --------- -------

Waiting: 20204383 RMU BACKUP..... 5600A476 00010001 CW NLBlocker: 2020437B SQL............ 3B00A35C 00010001 PR PR$

There is no workaround for this restriction. When the multistatement or storedprocedure finishes execution, the resources needed by other processes will bereleased.

4.0.19 Row Cache Not Allowed on Standby Database While Hot StandbyReplication Is Active

The row cache feature may not be active on a Hot Standby database whilereplication is taking place. The Hot Standby feature will not start if row cache isactive on the standby database.

This restriction exists because rows in the row cache are accessed using logicaldbkeys. However, information transferred to the Hot Standby database from theafter-image journal facility only contains physical dbkeys. Because there is noway to maintain rows in the cache using the Hot Standby processing, the rowcache must be disabled on the standby database when the standby database isopen and replication is active. The master database is not affected; the row cachefeature and the Hot Standby feature may be used together on a master database.


The row cache feature should be identically configured on the master and standbydatabases in the event failover occurs, but the row cache feature must not beactivated on the standby database until it becomes the master.

A new command qualifier, ROW_CACHE=DISABLED, has been added to theRMU/OPEN command to disable the row cache feature on the standby database.To open the Hot Standby database prior to starting replication, use the ROW_CACHE=DISABLED qualifier on the RMU/OPEN command.

4.0.20 Hot Standby Replication Waits when Starting if Read-Only TransactionsRunning

Hot Standby replication will wait to start if there are read-only (snapshot)transactions running on the standby database. The log roll-forward server (LRS)will wait until the read-only transactions commit, and then replication willcontinue.

This is an existing restriction of the Hot Standby software. This release note isintended to complement the Hot Standby documentation.

4.0.21 Error when Using the SYS$LIBRARY:SQL_FUNCTIONS70.SQL OracleFunctions Script

If your programming environment is not set up correctly, you may encounterproblems running the SYS$LIBRARY:SQL_FUNCTIONS70.SQL script used toset up the Oracle7 functions being supplied with Oracle Rdb.

The following example shows the error:

%RDB-E-EXTFUN_FAIL, external routine failed to compile or execute successfully-RDMS-E-INVRTNUSE, routine RDB$ORACLE_SQLFUNC_INTRO can not be used, image"SQL$FUNCTIONS" not activated-RDMS-I-TEXT, Error activating imageDISK:[DIR]SQL$FUNCTIONS.;, File not found

To resolve this problem, use the @SYS$LIBRARY:RDB$SETVER to set up theappropriate logical names. This will be necessary for programs that use thefunctions as well.

In a standard environment, use the command shown in the following example:

$ @SYS$LIBRARY:RDB$SETVER S

In a multiversion environment, use the command shown in the following example:

$ @SYS$LIBRARY:RDB$SETVER 70

4.0.22 DEC C and Use of the /STANDARD SwitchBug 394451

The SQL$PRE compiler examines the system to know which dialect of C togenerate. That default can be overwritten by using the /CC=[DECC/VAXC]switch. The /STANDARD switch should not be used to choose the dialect of C.

Support for DEC C was added to the product with V6.0 and this note ismeant to clarify that support, not to indicate a change. It is possible to use/STANDARD=RELAXED_ANSI89 or /STANDARD=VAXC correctly, but this is notrecommended.


The following example shows both the right and wrong way to compile an OracleRdb SQL program. Assume a symbol SQL$PRE has been defined, and DEC C isthe default C compiler on the system:

$ SQL$PRE/CC ! This is correct.$ SQL$PRE/CC=DECC ! This is correct.$ SQL$PRE/CC=VAXC ! This is correct.

$ SQL$PRE/CC/STANDARD=VAXC ! This is incorrect.

Notice that the /STANDARD switch has other options in addition toRELAXED_ANSI89 and VAX C. Those are also not supported.

4.0.23 Excessive Process Page Faults and Other Performance ConsiderationsDuring Oracle Rdb Sorts

Excessive hard or soft page faulting can be a limiting factor of processperformance. Sometimes this page faulting occurs during Oracle Rdb sortoperations. This note describes how page faulting can occur and some ways tohelp control, or at least understand, it.

One factor contributing to Oracle Rdb process page faulting is sorting operations.Common causes of sorts include the SQL GROUP BY, ORDER BY, UNION, andDISTINCT clauses specified for query and index creation operations. Defining thelogical name RDMS$DEBUG_FLAGS to "RS" can help determine when OracleRdb sort operations are occurring and to display the sort keys and statistics.

Oracle Rdb includes its own copy of the OpenVMS SORT32 code within theOracle Rdb images and does not generally call the routines in the OpenVMSrun-time library. A copy of the SORT32 code is used to provide stability betweenversions of Oracle Rdb and OpenVMS and because Oracle Rdb calls the sortroutines from executive processor mode which is difficult to do using the SORT32sharable image. Database import and RMU load operations call the OpenVMSsort run-time library.

At the beginning of a sort operation, the sort code allocates some memory forworking space. The sort code uses this space for buffers, in-memory copies of thedata, and sorting trees.

Sort code does not directly consider the process quotas or parameters whenallocating memory. The effects of WSQUOTA and WSEXTENT are indirect. Atthe beginning of each sort operation, the sort code attempts to adjust the process’working set to the maximum possible size using the $ADJWSL system servicespecifying a requested working set limit of %X7FFFFFFF pages (the maximumpossible). Sort code then uses a value of 75% of the returned working set forvirtual memory scratch space. The scratch space is then initialized and the sortbegins.

The initialization of the scratch space generally causes page faults to accessthe pages newly added to the working set. Pages that were in the working setalready may be faulted out as new pages are faulted in. Once the sort operationcompletes, the pages that may have been faulted out of the working set are likelyto be faulted back into the working set.

When a process’ working set is limited by the working set quota (WSQUOTA)parameter and the working set extent (WSEXTENT) parameter is a much largervalue, the first call to the sort routines can cause many page faults as the workingset grows. Using a value of WSEXTENT that is closer to WSQUOTA can helpreduce the impact of this case.


With some OpenVMS versions, AUTOGEN sets the SYSGEN parameter PQL_MWSEXTENT equal to the WSMAX parameter. This means that all processeson the system end up with WSEXTENT the same as WSMAX. Because WSMAXmight be quite high, sorting might result in excessive page faulting. You maywant to explicitly set PQL_MWSEXTENT to a lower value if this is the case onyour system.

Sort work files are another factor to consider when tuning Oracle Rdb sortoperations. When the operation cannot be done in available memory, sort codewill use temporary disk files to hold the data as it is being sorted. The OracleRdb Guide to Performance and Tuning contains more detailed information aboutsort work files.

The logical name RDMS$BIND_SORT_WORKFILES specifies how many workfiles sort code is to use if work files are required. The default is 2, and themaximum number is 10. The work files can be individually controlled by theSORTWORKn logical names (where n is from 0 through 9). You can increase theefficiency of sort operations by assigning the location of the temporary sort workfiles to different disks. These assignments are made by using up to 10 logicalnames, SORTWORK0 through SORTWORK9.

Normally, sort code places work files in the user’s SYS$SCRATCH directory. Bydefault, SYS$SCRATCH is the same device and directory as the SYS$LOGINlocation. Spreading the I/O load over many disks improves efficiency as well asperformance by taking advantage of the system resources and helps prevent diskI/O bottlenecks. Specifying that a user’s work files will reside on separate diskspermits overlap of the sort read/write cycle. You may also encounter cases whereinsufficient space exists on the SYS$SCRATCH disk device, such as when OracleRdb builds indexes for a very large table. Using the SORTWORK0 throughSORTWORK9 logical names can help you avoid this problem.

Note that sort code uses the work files for different sorted runs, and then mergesthe sorted runs into larger groups. If the source data is mostly sorted, thennot every sort work file may need to be accessed. This is a possible sourceof confusion because even with 10 sort work files, it is possible to exceed thecapacity of the first sort file, and the sort operation will fail never having accessedthe remaining 9 sort work files.

Note that the logical names RDMS$BIND_WORK_VM and RDMS$BIND_WORK_FILE do not affect or control the operation of sort. These logical namesare used to control other temporary space allocations within Oracle Rdb.

4.0.24 Performance Monitor Column MislabeledThe File IO Overview statistics screen, in the Rdb Performance Monitor, containsa column labeled Pages Checked. The column should be labeled Pages Discardedto correctly reflect the statistic displayed.

4.0.25 Restriction Using Backup Files Created Later than Oracle Rdb7Release 7.0.1

Bug 521583

Backup files created using Oracle Rdb7 releases later than 7.0.1 cannot berestored using Oracle Rdb7 Release 7.0.1. To fix a problem in a previous release,some internal backup file data structures were changed. These changes are notbackward compatible with Oracle Rdb7 Release 7.0.1.


If you restore the database using such a backup file, then any attempt to accessthe restored database may result in unpredictable behavior, even though a verifyoperation may indicate no problems.

There is no workaround to this problem. For this reason, Oracle Corporationstrongly recommends performing a full and complete backup both before andafter the upgrade from Release 7.0.1 to later releases of Oracle Rdb7.

4.0.26 RMU Backup Operations and Tape Drive TypesWhen using more than one tape drive for an RMU backup operation, all the tapedrives must be of the same type. For example, all the tape drives must be eitherTA90s or TZ87s or TK50s. Using different tape drive types (one TK50 and oneTA90) for a single database backup operation may make database restorationdifficult or impossible.

Oracle RMU attempts to prevent using different tape drive densities during abackup operation, but is not able to detect all invalid cases and expects that alltape drives for a backup are of the same type.

As long as all the tapes used during a backup operation can be read by the sametype of tape drive during a restore operation, the backup is likely to be valid.This may be the case, for example, when using a TA90 and a TA90E.

Oracle recommends that, on a regular basis, you test your backup and recoveryprocedures and environment using a test system. You should restore thedatabases and then recover them using AIJs to simulate failure recovery ofthe production system.

Consult the Oracle Rdb Guide to Database Maintenance, the Oracle Rdb Guideto Database Design and Definition, and the Oracle RMU Reference Manual foradditional information about Oracle Rdb backup and restore operations.

4.0.27 Use of Oracle Rdb from Shared ImagesBug 470946

If code in the image initialization routine of a shared image makes any callsinto Oracle Rdb, through SQL or any other means, access violations or otherunexpected behavior may occur if Oracle Rdb’s images have not had a chance todo their own initialization.

To avoid this problem, applications must do one of the following:

• Do not make Oracle Rdb calls from the initialization routines of sharedimages.

• Link in such a way that the RDBSHR.EXE image initializes first. This canbe done by placing the reference to RDBSHR.EXE and any other Oracle Rdbshared images last in the linker options file.

4.0.28 Interactive SQL Command Line Editor Rejects Eight-Bit CharactersDigital UNIX Systems

The interactive SQL command line editor on Digital UNIX can interfere withentering eight-bit characters from the command line. The command line editorassumes that a character with the eighth bit set will invoke an editing function.If the command line editor is enabled and a character with the eighth bit setis entered from the command line, the character will not be inserted on thecommand line. If the character has a corresponding editor function, the functionwill be invoked; otherwise, the character is considered invalid and rejected.


There are two ways to enter eight-bit characters from the SQL command line:either disable the command line editor or use the command line editor characterquoting function to enter each eight-bit character. To disable the command lineeditor, set the configuration parameter RDB_NOLINEDIT in the configurationfile. For example:

! Disable the interactive SQL command line editor.RDB_NOLINEDIT ON

To place quotation marks around a character using the command line editor, typeCtrl/V before each character to be place in quotation marks.

4.0.29 Restriction Added for CREATE STORAGE MAP on Table with DataOracle Rdb7 added support that allows a storage map to be added to an existingtable which contains data. The restrictions listed for Oracle Rdb7 were:

• The storage map must be a simple map that references only the defaultstorage area and represents the current (default) mapping for the table. Thedefault storage area is either RDB$SYSTEM or the area name provided bythe CREATE DATABASE...DEFAULT STORAGE AREA clause.

• The new map cannot change THRESHOLDS or COMPRESSION for the table,nor can it use the PLACEMENT VIA INDEX clause. It can only contain onearea and cannot be vertically partitioned. This new map simply describes themapping as it exists by default for the table.

This release of Rdb7 adds the additional restriction that the storage map may notinclude a WITH LIMIT clause for the storage area. The following example showsthe reported error:

SQL> CREATE TABLE MAP_TEST1 (A INTEGER, B CHAR(10));SQL> CREATE INDEX MAP_TEST1_INDEX ON MAP_TEST1 (A);SQL> INSERT INTO MAP_TEST1 (A, B) VALUES (3, ’Third’);1 row insertedSQL> CREATE STORAGE MAP MAP_TEST1_MAP FOR MAP_TEST1cont> STORE USING (A) IN RDB$SYSTEMcont> WITH LIMIT OF (10); -- can’t use WITH LIMIT clause%RDB-E-NO_META_UPDATE, metadata update failed-RDMS-F-RELNOTEMPTY, table "MAP_TEST1" has data in it-RDMS-E-NOCMPLXMAP, can not use complex map for non-empty table

4.0.30 ALTER DOMAIN...DROP DEFAULT Reports DEFVALUNS ErrorBug 456867

If a domain has a DEFAULT of CURRENT_USER, SESSION_USER, orSYSTEM_USER and attempts to delete that default, it may fail unexpectedly.The following example shows the error:

SQL> ATTACH ’FILENAME PERSONNEL’;SQL> CREATE DOMAIN ADDRESS_DATA2_DOM CHAR(31)cont> DEFAULT CURRENT_USER;SQL> COMMIT;SQL> ALTER DOMAIN ADDRESS_DATA2_DOMcont> DROP DEFAULT;%SQL-F-DEFVALUNS, Default values are not supported for the data type ofADDRESS_DATA2_DOM


To work around this problem you must first alter the domain to have a default ofNULL, as shown, and then use DROP DEFAULT:

SQL> ALTER DOMAIN ADDRESS_DATA2_DOMcont> SET DEFAULT NULL;SQL> ALTER DOMAIN ADDRESS_DATA2_DOMcont> DROP DEFAULT;SQL> COMMIT;

This problem will be corrected in a future release of Oracle Rdb.

4.0.31 Oracle Rdb7 Workload Collection Can Stop Hot Standby ReplicationIf you are replicating your Oracle Rdb7 database using the Oracle Hot Standbyoption, you must not use the workload collection option. By default, workloadcollection is disabled. However, if you enabled workload collection, you mustdisable it on the master database prior to performing a backup operation on thatmaster database if it will be used to create the standby database for replicationpurposes. If you do not disable workload collection, it could write workloadinformation to the standby database and prevent replication operations fromoccurring.

The workaround included at the end of this section describes how to disableworkload collection on the master database and allow the Hot Standby softwareto propagate the change to the standby database automatically during replicationoperations.

Background InformationBy default, workload collection and cardinality collection are automaticallydisabled when Hot Standby replication operations are occurring on the standbydatabase. However, if replication stops (even for a brief network failure), OracleRdb7 potentially can start a read/write transaction on the standby database towrite workload collection information. Then, because the standby database isno longer synchronized transactionally with the master database, replicationoperations cannot restart.

Note

The Oracle Rdb7 optimizer can update workload collection information inthe RDB$WORKLOAD system table even though the standby databaseis opened exclusively for read-only queries. A read/write transaction isstarted during the disconnection from the standby database to flush theworkload and cardinality statistics to the system tables.

If the standby database is modified, you receive the following messages when youtry to restart Hot Standby replication operations:%RDMS-F-DBMODIFIED, database has been modified; AIJ roll-forward not possible%RMU-F-FATALRDB, Fatal error while accessing Oracle Rdb.

WorkaroundTo work around this problem, perform the following:

• On the master database, disable workload collection using the SQL clauseWORKLOAD COLLECTION IS DISABLED on the ALTER DATABASEstatement. For example:

SQL> ALTER DATABASE FILE mf_personnelcont> WORKLOAD COLLECTION IS DISABLED;


This change is propagated to the standby database automatically when yourestore the standby database and restart replication operations. Note that,by default, the workload collection feature is disabled. You need to disableworkload collection only if you previously enabled workload collection withthe WORKLOAD COLLECTION IS ENABLED clause.

• On the standby database, include the Transaction_Mode qualifier on theRMU/Restore command when you restore the standby database. You shouldset this qualifier to read-only to prevent modifications to the standby databasewhen replication operations are not active. The following example shows theTransaction_Mode qualifier used in a typical RMU/Restore command:

$ RMU/RESTORE /TRANSACTION_MODE=READ_ONLY/NOCDD/NOLOG/ROOT=DISK1:[DIR]standby_personnel.rdb/AIJ_OPT=aij_opt.datDISK1:[DIR]standby_personnel.rbf

If, in the future, you fail over processing to the standby database (so that thestandby database becomes the master database), you can re-enable updates tothe ‘‘new’’ master database. For example, to re-enable updates, use the SQLstatement ALTER DATABASE and include the SET TRANSACTION MODES(ALL) clause. The following example shows this statement used on the newmaster database:

SQL> ALTER DATABASE FILE mf_personnelcont> SET TRANSACTION MODES (ALL);

4.0.32 RMU Convert Command and System TablesWhen the RMU Convert command converts a database from a previous versionto Oracle Rdb V7.0 or higher, it sets the RDB$CREATED and RDB$LAST_ALTERED columns to the timestamp of the convert operation.

The RDB$xxx_CREATOR columns are set to the current user name (which isspace filled) of the converter. Here xxx represents the object name, such as inRDB$TRIGGER_CREATOR.

The RMU Convert command also creates the new index on RDB$TRANSFER_RELATIONS if the database is transfer enabled.

4.0.33 Converting Single-File DatabasesBecause of a substantial increase in the database root file information for Release7.0, you should ensure that you have adequate disk space before you use theRMU Convert command with single-file databases and Release 7.0 or higher.

The size of the database root file of any given database will increase a minimumof 13 blocks and a maximum of 597 blocks. The actual increase depends mostlyon the maximum number of users specified for the database.

4.0.34 Restriction when Adding Storage Areas with Users Attached toDatabase

If you try to interactively add a new storage area where the page size is less thanthe existing page size and the database has been manually opened or users areactive, the add operation fails with the following error:

%RDB-F-SYS_REQUEST, error from system services request-RDMS-F-FILACCERR, error opening database root DKA0:[RDB]TEST.RDB;1-SYSTEM-W-ACCONFLICT, file access conflict


You can make this change only when no users are attached to the database and,if the database is set to OPEN IS MANUAL, the database is closed. Severalinternal Oracle Rdb data structures are based on the minimum page size, andthese structures cannot be resized if users are attached to the database.

Furthermore, because this particular change is not recorded in the AIJ file, anyrecovery scenario will fail. Note also that if you use .aij files, you must backupthe database and restart after-image journaling because this change invalidatesthe current AIJ recovery.

4.0.35 Restriction on Tape Usage for Digital UNIX V3.2Digital UNIX Systems

You can experience a problem where you are unable to use multiple tapes withthe Oracle RMU Backup command with Digital UNIX V3.2. Every attempt torecover fails. If this happens and device errors are logged in the system error log,it is possible that the operation succeeded, but the device open reference count iszeroed out. This means that any attempt to use the drive by the process holdingthe open file descriptor will fail with EINVAL status but another process will beable to open and use the drive even while the first process has it opened.

There is no workaround for this problem. This problem with the magtape driverwill be corrected in a future release of Digital UNIX.

4.0.36 Support for Single-File Databases to be Dropped in a Future ReleaseOracle Rdb currently supports both single-file and multifile databases on bothOpenVMS and Digital UNIX. However, single-file databases will not be supportedin a future release of Oracle Rdb. At that time, Oracle Rdb will provide themeans to easily convert single-file databases to multifile databases.

Oracle recommends that users with single-file databases perform the followingactions:

• Use the Oracle RMU commands, such as Backup and Restore, to makecopies, back up, or move single-file databases. Do not use operating systemcommands to copy, back up, or move databases.

• Create new databases as multifile databases even though single-file databasesare supported in Oracle Rdb release 6.1 and release 7.0.

4.0.37 DECdtm Log StallsResource managers using the DECdtm services can sometimes suddenly stopbeing able to commit transactions. If Oracle Rdb7 is installed and transactionsare being run, an RMU Show command on the affected database will showtransactions as being "stalled, waiting to commit".

Refer to the DECdtm documentation and release notes for information onsymptoms, fixes, and workarounds for this problem. One workaround, forOpenVMS V5.5-x, is provided here.

On the affected node while the log stall is in progress, type the followingcommand from a privileged account:

$ MCR LMCP SET NOTIMEZONE

This should force the log to restart.


This stall occurs only when a particular bit in a pointer field becomes set. Tosee the value of the pointer field, enter the following command from a privilegedaccount (where <nodename> is the SCS node name of the node in question).

$ MCR LMCP DUMP/ACTIVE/NOFORM SYSTEM$<nodename>

This command displays output similar to the following:

Dump of transaction log SYS$COMMON:[SYSEXE]SYSTEM$<nodename>.LM$JOURNAL;1End of file block 4002 / Allocated 4002Log Version 1.0Transaction log UID: 29551FC0-CBB7-11CC-8001-AA000400B7A5Penultimate Checkpoint: 000013FD4479 0079Last Checkpoint: 000013FDFC84 0084

Total of 2 transactions active, 0 prepared and 2 committed.

The stall will occur when bit 31 of the checkpoint address becomes set, as thisexcerpt from the previous example shows:

Last Checkpoint: 000013FDFC84 0084^|

When the number indicated in the example becomes 8, the log will stall. Checkthis number and observe how quickly it grows. When it is at 7FFF, frequentlyuse the following command:

$ MCR LMCP SHOW LOG /CURRENT

If this command shows a stall in progress, use the workaround to restart the log.

See your Compaq Computer Corporation representative for information aboutpatches to DECdtm.

4.0.38 Cannot Run Distributed Transactions on Systems with DECnet/OSI andOpenVMS Alpha Version 6.1 or OpenVMS VAX Version 6.0

If you have DECnet/OSI installed on a system with OpenVMS Alpha Version6.1 or OpenVMS VAX Version 6.0, you cannot run Oracle Rdb7 operationsthat require the two-phase commit protocol. The two-phase commit protocolguarantees that if one operation in a distributed transaction cannot be completed,none of the operations is completed.

If you have DECnet/OSI installed on a system running OpenVMS VAX Version6.1 or higher or OpenVMS Alpha Version 6.2 or higher, you can run Oracle Rdboperations that require the two-phase commit protocol.

For more information about the two-phase commit protocol, see the Oracle RdbGuide to Distributed Transactions.

4.0.39 Multiblock Page Writes May Require Restore OperationIf a node fails while a multiblock page is being written to disk, the page inthe disk becomes inconsistent and is detected immediately during failover.(Failover is the recovery of an application by restarting it on another computer.)The problem is rare and occurs because only single-block I/O operations areguaranteed by OpenVMS to be written atomically. This problem has never beenreported by any customer and was detected only during stress tests in our labs.

Correct the page by an area-level restore operation. Database integrity isnot compromised, but the affected area will not be available until the restoreoperation completes.


A future release of Oracle Rdb will provide a solution that guarantees multiblockatomic write operations. Cluster failovers will automatically cause the recovery ofmultiblock pages, and no manual intervention will be required.

4.0.40 Oracle Rdb7 Network Link Failure Does Not Allow DISCONNECT toClean Up Transactions

If a program attaches to a database on a remote node and it loses the connectionbefore the COMMIT statement is issued, there is nothing you can do except exitthe program and start again.

The problem occurs when a program is connected to a remote database andupdates the database, but then just before it commits, the network fails. Whenthe commit executes, SQL shows, as it normally should, that the program haslost the link. Assume that the user waits for a minute or two, then tries thetransaction again. The problem is that when the start transaction is issued forthe second time, it fails because old information still exists about the previousfailed transaction. This occurs even if the user issues a DISCONNECT statement(in Release 4.1 and earlier, a FINISH statement), which also fails with anRDB-E-IO_ERROR error message.

4.0.41 Replication Option Copy Processes Do Not Process Database PagesAhead of an Application

When a group of copy processes initiated by the Replication Option (formerlyData Distributor) begins running after an application has begun modifying thedatabase, the copy processes will catch up to the application and will not beable to process database pages that are logically ahead of the application inthe RDB$CHANGES system table. The copy processes all align waiting for thesame database page and do not move on until the application has released it.The performance of each copy process degrades because it is being paced by theapplication.

When a copy process completes updates to its respective remote database,it updates the RDB$TRANSFERS system table and then tries to delete anyRDB$CHANGES rows not needed by any transfers. During this process, theRDB$CHANGES table cannot be updated by any application process, holdingup any database updates until the deletion process is complete. The applicationstalls while waiting for the RDB$CHANGES table. The resulting contentionfor RDB$CHANGES SPAM pages and data pages severely impacts performancethroughput, requiring user intervention with normal processing.

This is a known restriction in Release 4.0 and higher. Oracle Rdb uses pagelocks as latches. These latches are held only for the duration of an action onthe page and not to the end of transaction. The page locks also have blockingasynchronous system traps (ASTs) associated with them. Therefore, whenevera process requests a page lock, the process holding that page lock is sent ablocking AST (BLAST) by OpenVMS. The process that receives such a blockingAST queues the fact that the page lock should be released as soon as possible.However, the page lock cannot be released immediately.

Such work requests to release page locks are handled at verb commit time.An Oracle Rdb verb is an Oracle Rdb query that executes atomically, within atransaction. Therefore, verbs that require the scan of a large table, for example,can be quite long. An updating application does not release page locks until itsverb has completed.


The reasons for holding on to the page locks until the end of the verb arefundamental to the database management system.

4.0.42 SQL Does Not Display Storage Map Definition After Cascading Deleteof Storage Area

When you delete a storage area using the CASCADE keyword and that storagearea is not the only area to which the storage map refers, the SHOW STORAGEMAP statement no longer shows the placement definition for that storage map.

The following example demonstrates this restriction:

SQL> SHOW STORAGE MAP DEGREES_MAP1DEGREES_MAP1

For Table: DEGREES1Compression is: ENABLEDPartitioning is: NOT UPDATABLEStore clause: STORE USING (EMPLOYEE_ID)

IN DEG_AREA WITH LIMIT OF (’00250’)OTHERWISE IN DEG_AREA2

SQL> DISCONNECT DEFAULT;SQL> -- Drop the storage area, using the CASCADE keyword.SQL> ALTER DATABASE FILENAME MF_PERSONNELcont> DROP STORAGE AREA DEG_AREA CASCADE;SQL> --SQL> -- Display the storage map definition.SQL> ATTACH ’FILENAME MF_PERSONNEL’;SQL> SHOW STORAGE MAP DEGREES_MAP1

DEGREES_MAP1For Table: DEGREES1Compression is: ENABLEDPartitioning is: NOT UPDATABLE

SQL>

The other storage area, DEG_AREA2, still exists, even though the SHOWSTORAGE MAP statement does not display it.

A workaround is to use the RMU Extract command with the Items=Storage_Mapqualifier to see the mapping.

4.0.43 ARITH_EXCEPT or Incorrect Results Using LIKE IGNORE CASEWhen you use LIKE . . . IGNORE CASE, programs linked under Oracle RdbRelease 4.2 and Release 5.1, but run under higher versions of Oracle Rdb, mayresult in incorrect results or %RDB-E-ARITH_EXCEPT exceptions.

To work around the problem, avoid using IGNORE CASE with LIKE, or recompileand relink under a higher version (Release 6.0 or higher.)

4.0.44 Different Methods of Limiting Returned Rows from QueriesYou can establish the query governor for rows returned from a query by using theSQL SET QUERY LIMIT statement, a logical name, or a configuration parameter.This note describes the differences between the mechanisms.

• If you define the RDMS$BIND_QG_REC_LIMIT logical name or RDB_BIND_QG_REC_LIMIT configuration parameter to a small value, the query willoften fail with no rows returned. The following example demonstrates settingthe limit to 10 rows and the resulting failure:


$ DEFINE RDMS$BIND_QG_REC_LIMIT 10$ SQL$SQL> ATTACH ’FILENAME MF_PERSONNEL’;SQL> SELECT EMPLOYEE_ID FROM EMPLOYEES;%RDB-F-EXQUOTA, Oracle Rdb runtime quota exceeded-RDMS-E-MAXRECLIM, query governor maximum limit of rows has been reached

Interactive SQL must load its metadata cache for the table before it canprocess the SELECT statement. In this example, interactive SQL loadsits metadata cache to allow it to check that the column EMPLOYEE_IDreally exists for the table. The queries on the Oracle Rdb system tablesRDB$RELATIONS and RDB$RELATION_FIELDS exceed the limit of rows.

Oracle Rdb does not prepare the SELECT statement, let alone execute it.Raising the limit to a number less than 100 (the cardinality of EMPLOYEES)but more than the number of columns in EMPLOYEES (that is, the numberof rows to read from the RDB$RELATION_FIELDS system table) is sufficientto read each column definition.

To see an indication of the queries executed against the system tables, definethe RDMS$DEBUG_FLAGS logical name or the RDB_DEBUG_FLAGSconfiguration parameter as S or B.

• If you set the row limit using the SQL SET QUERY statement and run thesame query, it returns the number of rows specified by the SQL SET QUERYstatement before failing:

SQL> ATTACH ’FILENAME MF_PERSONNEL’;SQL> SET QUERY LIMIT ROWS 10;SQL> SELECT EMPLOYEE_ID FROM EMPLOYEES;EMPLOYEE_ID0016400165

.

.

.00173%RDB-E-EXQUOTA, Oracle Rdb runtime quota exceeded-RDMS-E-MAXRECLIM, query governor maximum limit of rows has been reached

The SET QUERY LIMIT specifies that only user queries be limited to 10 rows.Therefore, the queries used to load the metadata cache are not restricted inany way.

Like the SET QUERY LIMIT statement, the SQL precompiler andmodule processor command line qualifiers (QUERY_MAX_ROWS andSQLOPTIONS=QUERY_MAX_ROWS) only limit user queries.

Keep the differences in mind when limiting returned rows using the logical nameRDMS$BIND_QG_REC_LIMIT or the configuration parameter RDB_BIND_QG_REC_LIMIT. They may limit more queries than are obvious. This is importantwhen using 4GL tools, the SQL precompiler, the SQL module processor, and otherinterfaces that read the Oracle Rdb system tables as part of query processing.

4.0.45 Suggestions for Optimal Usage of the SHARED DATA DEFINITIONClause for Parallel Index Creation

The CREATE INDEX process involves the following steps:

1. Process the metadata.

2. Lock the index name.


Because new metadata (which includes the index name) is not written todisk until the end of the index process, Oracle Rdb must ensure index nameuniqueness across the database during this time by taking a special lock onthe provided index name.

3. Read the table for sorting by selected index columns and ordering.

4. Sort the key data.

5. Build the index (includes partitioning across storage areas).

6. Write new metadata to disk.

Step 6 is the point of conflict with other index definers because the system tableand indexes are locked like any other updated table.

Multiple users can create indexes on the same table by using the RESERVINGtable_name FOR SHARED DATA DEFINITION clause of the SETTRANSACTION statement. For optimal usage of this capability, Oracle Rdbsuggests the following guidelines:

• You should commit the transaction immediately after the CREATE INDEXstatement so that locks on the table are released. This avoids lock conflictswith other index definers and improves overall concurrency.

• By assigning the location of the temporary sort work files SORTWORK0,SORTWORK1, . . . , SORTWORK9 to different disks for each parallel processthat issues the SHARED DATA DEFINITION statement, you can increase theefficiency of sort operations. This minimizes any possible disk I/O bottlenecksand allows overlap of the SORT read/write cycle.

• If possible, enable global buffers and specify a buffer number large enough tohold a sufficient amount of table data. However, do not define global bufferslarger than the available system physical memory. Global buffers allowsharing of database pages and thus result in disk I/O savings. That is, pagesare read from disk by one of the processes and then shared by the other indexdefiners for the same table, reducing the I/O load on the table.

• If global buffers are not used, ensure that enough local buffers exist to keepmuch of the index cached (use the RDM$BIND_BUFFERS logical nameor RDB_BIND_BUFFERS configuration parameter or the NUMBER OFBUFFERS IS clause in SQL to change the number of buffers).

• To distribute the disk I/O load, place the storage areas for the indexes onseparate disk drives. Note that using the same storage area for multipleindexes will result in contention during the index creation (Step 5) for SPAMpages.

• Consider placing the .ruj file for each parallel definer on its own disk or aninfrequently used disk.

• Even though snapshot I/O should be minimal, consider disabling snapshotsduring parallel index creation.

• Refer to the Oracle Rdb Guide to Performance and Tuning to determinethe appropriate working set values for each process to minimize excessivepaging activity. In particular, avoid using working set parameters wherethe difference between WSQUOTA and WSEXTENT is large. The SORTutility uses the difference between these two values to allocate scratch virtualmemory. A large difference (that is, the requested virtual memory grosslyexceeds the available physical memory) may lead to excessive page faulting.


• The performance benefits of using SHARED DATA DEFINITION can bestbe observed when creating many indexes in parallel. The benefit is in theaverage elapsed time, not in CPU or I/O usage. For example, when twoindexes are created in parallel using the SHARED DATA DEFINITIONclause, the database must be attached twice, and the two attaches each useseparate system resources.

• Using the SHARED DATA DEFINITION clause on a single-file database orfor indexes defined in the RDB$SYSTEM storage area is not recommended.

The following table displays the elapsed time benefit when creating multipleindexes in parallel with the SHARED DATA DEFINITION clause. Thetable shows the elapsed time for 10 parallel process index creations (Index1,Index2, . . . Index10) and one process with 10 sequential index creations (All10).In this example, global buffers are enabled and the number of buffers is 500.The longest time for a parallel index creation is Index7 with an elapsed time of00:02:34.64, compared to creating 10 indexes sequentially with an elapsed time of00:03:26.66. The longest single parallel create index elapsed time is shorter thanthe elapsed time of creating all 10 of the indexes serially.

Index Create Job Elapsed Time

Index1 00:02:22.50

Index2 00:01:57.94

Index3 00:02:06.27

Index4 00:01:34.53

Index5 00:01:51.96

Index6 00:01:27.57

Index7 00:02:34.64

Index8 00:01:40.56

Index9 00:01:34.43

Index10 00:01:47.44

All 10 00:03:26.66

4.0.46 Side Effect when Calling Stored RoutinesWhen calling a stored routine, you must not use the same routine to calculateargument values by a stored function. For example, if the routine being calledis also called by a stored function during the calculation of an argument value,passed arguments to the routine may be incorrect.

The following example shows a stored procedure P being called during thecalculation of the arguments for another invocation of the stored procedure P:


SQL> CREATE MODULE Mcont> LANG SQLcont>cont> PROCEDURE P (IN :A INTEGER, IN :B INTEGER, OUT :C INTEGER);cont> BEGINcont> SET :C = :A + :B;cont> END;cont>cont> FUNCTION F () RETURNS INTEGERcont> COMMENT IS ’expect F to always return 2’;cont> BEGINcont> DECLARE :B INTEGER;cont> CALL P (1, 1, :B);cont> TRACE ’RETURNING ’, :B;cont> RETURN :B;cont> END;cont> END MODULE;SQL>SQL> SET FLAGS ’TRACE’;SQL> BEGINcont> DECLARE :CC INTEGER;cont> CALL P (2, F(), :CC);cont> TRACE ’Expected 4, got ’, :CC;cont> END;~Xt: returning 2~Xt: Expected 4, got 3

The result as shown above is incorrect. The routine argument values are writtento the called routine’s parameter area before complex expression values arecalculated. These calculations may (as in the example) overwrite previouslycopied data.

The workaround is to assign the argument expression (in this example calling thestored function F) to a temporary variable and pass this variable as the input forthe routine. The following example shows the workaround:

SQL> BEGINcont> DECLARE :BB, :CC INTEGER;cont> SET :BB = F();cont> CALL P (2, :BB, :CC);cont> TRACE ’Expected 4, got ’, :CC;cont> END;~Xt: returning 2~Xt: Expected 4, got 4

This problem will be corrected in a future version of Oracle Rdb7.

4.0.47 Nested Correlated Subquery Outer References IncorrectOuter references from aggregation subqueries contained within nested queriescould receive incorrect values, causing the overall query to return incorrectresults. The general symptom for an outer query that returned rows 1 to n wasthat the inner aggregation query would operate with the nth - 1 row data (usuallyNULL for row 1) when it should have been using the nth row data.

This problem has existed in various forms for all previous versions of OracleRdb7, but only appears in Release 6.1 and later when the inner of the nestedqueries contains an UPDATE statement.


The following example demonstrates the problem:

SQL> ATTACH ’FILENAME SHIPPING’;SQL> SELECT * FROM MANIFEST WHERE VOYAGE_NUM = 4904 ORcont> VOYAGE_NUM = 4909;VOYAGE_NUM EXP_NUM MATERIAL TONNAGE

4904 311 CEDAR 12004904 311 FIR 6904909 291 IRON ORE 30004909 350 BAUXITE 11004909 350 COPPER 12004909 355 MANGANESE 5504909 355 TIN 500

7 rows selected

SQL> BEGINcont> FOR :A AS EACH ROW OFcont> SELECT * FROM VOYAGE V WHERE V.SHIP_NAME = ’SANDRA C.’ ORcont> V.SHIP_NAME = ’DAFFODIL’ DOcont> FOR :B AS EACH ROW OF TABLE CURSOR MODCUR1 FORcont> SELECT * FROM MANIFEST M WHERE M.VOYAGE_NUM = :A.VOYAGE_NUM DOcont> UPDATE MANIFESTcont> SET TONNAGE = (SELECT (AVG (M1.EXP_NUM) *3) FROM MANIFEST M1cont> WHERE M1.VOYAGE_NUM = :A.VOYAGE_NUM)cont> WHERE CURRENT OF MODCUR1;cont> END FOR;cont> END FOR;cont> END;SQL> SELECT * FROM MANIFEST WHERE VOYAGE_NUM = 4904 ORcont> VOYAGE_NUM = 4909;VOYAGE_NUM EXP_NUM MATERIAL TONNAGE

4904 311 CEDAR NULL4904 311 FIR NULL4909 291 IRON ORE 9334909 350 BAUXITE 9334909 350 COPPER 9334909 355 MANGANESE 9334909 355 TIN 933

7 rows selected

The correct value for TONNAGE on both rows for VOYAGE_NUM 4904 (outerquery row 1) is AVG (311+311)*3=933. However, Oracle Rdb7 calculates it as AVG(NULL+NULL)*3=NULL. In addition, the TONNAGE value for VOYAGE_NUM4909 (outer query row 2) is actually the TONNAGE value for outer query row 1.

A workaround is to declare a variable of the same type as the outer referencedata item, assign the outer reference data into the variable before the inner querythat contains the correlated aggregation subquery, and reference the variablein the aggregation subquery. Keep in mind the restriction on the use of localvariables in FOR cursor loops.

For example:


SQL> DECLARE :VN INTEGER;SQL> BEGINcont> FOR :A AS EACH ROW OFcont> SELECT * FROM VOYAGE V WHERE V.SHIP_NAME = ’SANDRA C.’ DOcont> SET :VN = :A.VOYAGE_NUM;cont> FOR :B AS EACH ROW OF TABLE CURSOR MODCUR1 FORcont> SELECT * FROM MANIFEST M WHERE M.VOYAGE_NUM = :A.VOYAGE_NUM DOcont> UPDATE MANIFESTcont> SET TONNAGE = (SELECT (AVG (M1.EXP_NUM) *3) FROM MANIFEST M1cont> WHERE M1.VOYAGE_NUM = :VN)cont> WHERE CURRENT OF MODCUR1;cont> END FOR;cont> END FOR;cont> END;SQL> SELECT * FROM MANIFEST WHERE VOYAGE_NUM = 4904;VOYAGE_NUM EXP_NUM MATERIAL TONNAGE

4904 311 CEDAR 9334904 311 FIR 933

This problem will be corrected in a future release of Oracle Rdb.

4.0.48 Considerations when Using Holdable CursorsIf your applications use holdable cursors, be aware that after a COMMIT orROLLBACK statement is executed, the result set selected by the cursor maynot remain stable. That is, rows may be inserted, updated, and deleted by otherusers because no locks are held on the rows selected by the holdable cursor aftera commit or rollback occurs. Moreover, depending on the access strategy, rows notyet fetched may change before Oracle Rdb actually fetches them.

As a result, you may see the following anomalies when using holdable cursors ina concurrent user environment:

• If the access strategy forces Oracle Rdb to take a data snapshot, the dataread and cached may be inaccurate by the time the cursor fetches the data.

For example, user 1 opens a cursor and commits the transaction. User2 deletes rows read by user 1 (this is possible because the read locks arereleased). It is possible for user 1 to report data now deleted and committed.

• If the access strategy uses indexes that allow duplicates, updates to theduplicates chain may cause rows to be skipped, or even revisited.

Oracle Rdb keeps track of the dbkey in the duplicate chain pointing to thedata that was fetched. However, the duplicates chain could be revised by thetime Oracle Rdb returns to using it.

Holdable cursors are a very powerful feature for read-only or predominantly read-only environments. However, in concurrent update environments, the instabilityof the cursor may not be acceptable. The stability of holdable cursors for updateenvironments will be addressed in future versions of Oracle Rdb.

You can define the logical name RDMS$BIND_HOLD_CURSOR_SNAP orconfiguration parameter RDB_BIND_HOLD_CURSOR_SNAP to the value 1 toforce all hold cursors to fetch the result set into a cached data area. (The cacheddata area appears as a ‘‘Temporary Relation’’ in the optimizer strategy displayedby the SET FLAGS STRATEGY statement or the RDMS$DEBUG_FLAGS S flag.)This logical name or configuration parameter helps to stabilize the cursor to somedegree.


4.0.49 INCLUDE SQLDA2 Statement Is Not Supported for SQL Precompiler forPL/I in Oracle Rdb Release 5.0 or Higher

The SQL statement INCLUDE SQLDA2 is not supported for use with the PL/Iprecompiler in Oracle Rdb Release 5.0 or higher.

There is no workaround. This problem will be fixed in a future version of OracleRdb.

4.0.50 SQL Pascal Precompiler Processes ARRAY OF RECORD DeclarationsIncorrectly

The Pascal precompiler for SQL gives an incorrect %SQL-I-UNMATEND errorwhen it parses a declaration of an array of records. The precompiler does notassociate the END statement with the record definition, and the resultingconfusion in host variable scoping causes a fatal error.

A workaround for the problem is to declare the record as a type and then defineyour array of that type. For example:

main.spa:

program main (input,output);

typeexec sql include ’bad_def.pin’; !gives errorexec sql include ’good_def.pin’; !okvar

a : char;

beginend.

---------------------------------------------------------------bad_def.pin

x_record = recordy : char;variable_a: array [1..50] of record

a_fld1 : char;b_fld2 : record;

t : recordv : integer;

end;end;

end;end;

---------------------------------------------------------------

good_def.pin

good_rec = recorda_fld1 : char;b_fld2 : record

t : recordv: integer;

end;end;

end;

x_record = recordy : charvariable_a : array [1..50] of good_rec;

end;


4.0.51 RMU Parallel Backup Command Not Supported for Use with SLSThe RMU Parallel Backup command is not supported for use with the StorageLibrary System (SLS) for OpenVMS.

4.0.52 Oracle RMU Commands Pause During Tape RewindDigital UNIX Systems

For Oracle Rdb Release 6.1 or higher on Digital UNIX, the Oracle RMU Backupand Restore commands pause under certain conditions.

If multiple tape drives are used for RMU Backup or RMU Restore commandsand a tape needs to rewind, the Oracle RMU command pauses until the rewindis complete. This is different from behavior on OpenVMS systems where thecommand continues to write to tape drives that are not rewinding.

There is no workaround for this problem.

4.0.53 TA90 and TA92 Tape Drives Are Not Supported on Digital UNIXDigital UNIX Systems

When rewinding or unloading tapes using either TA90 and TA92 drives, DigitalUNIX intermittently returns an EIO error causing the Oracle RMU operationto abort. This problem occurs most often when Oracle RMU accesses multipletape drives in parallel. However, the problem occurs even with single-tape driveaccess.

As a result of this problem, Oracle Rdb on Digital UNIX supports neither TA90nor TA92 tape drives.

4.1 Oracle CDD/Repository RestrictionsThis section describes known problems and restrictions in Oracle CDD/RepositoryRelease 7.0 and earlier.

4.1.1 Oracle CDD/Repository Compatibility with Oracle Rdb FeaturesSome Oracle Rdb features are not fully supported by all versions of OracleCDD/Repository. Table 4–1 shows which versions of Oracle CDD/Repositorysupport Oracle Rdb features and the extent of support.

In Table 4–1, repository support for Oracle Rdb7 features can vary as follows:

• Explicit support—The repository recognizes and integrates the feature, andyou can use the repository to manipulate the item.

• Implicit support—The repository recognizes and integrates the feature, butyou cannot use any repository interface to manipulate the item.

• Pass-through support—The repository does not recognize or integrate thefeature, but allows the Oracle Rdb7 operation to complete without aborting oroverwriting metadata. With pass-through support, a CDD-I-MBLRSYNINFOinformational message may be returned.


Table 4–1 Oracle CDD/Repository Compatibility for Oracle Rdb Features

Oracle Rdb FeatureMinimum Releaseof Oracle Rdb

Minimum Release ofOracle CDD/Repository Support

CASE, NULLIF, andCOALESCE expressions

6.0 6.1 Implicit

CAST function 4.1 7.0 Explicit

Character data types to supportcharacter sets

4.2 6.1 Implicit

Collating sequences 3.1 6.1 Explicit

Constraints (PRIMARY KEY,UNIQUE, NOT NULL, CHECK,FOREIGN KEY)

3.1 5.2 Explicit

CURRENT_DATE, CURRENT_TIME, and CURRENT_TIMESTAMP functions

4.1 7.0 Explicit

CURRENT_USER, SESSION_USER, SYSTEM_USERfunctions

6.0 7.0 Explict

Date arithmetic 4.1 6.1 Pass-through

DATE ANSI, TIME,TIMESTAMP, and INTERVALdata types

4.1 6.1 Explicit

Delimited identifiers 4.2 6.11 Explicit

External functions 6.0 6.1 Pass-through

External procedures 7.0 6.1 Pass-through

EXTRACT, CHAR_LENGTH,and OCTET_LENGTH functions

4.1 6.1 Explicit

GRANT/REVOKE privileges 4.0 5.0 accepts but does notstore information

Pass-through

Indexes 1.0 5.2 Explicit

INTEGRATE DOMAIN 6.1 6.1 Explicit

INTEGRATE TABLE 6.1 6.1 Explicit

Logical area thresholds forstorage maps and indexes

4.1 5.2 Pass-through

Multinational character set 3.1 4.0 Explicit

Multiversion environment(multiple Rdb versions)

4.1 5.1 Explicit

NULL keyword 2.2 7.0 Explicit

Oracle7 compatibility functions,such as CONCAT, CONVERT,DECODE, and SYSDATE

7.0 7.0 Explicit

Outer joins, derived tables 6.0 7.0 Pass-through

Query outlines 6.0 6.1 Pass-through

1The repository does not preserve the distinction between uppercase and lowercase identifiers. If youuse delimited identifiers with Oracle Rdb, the repository ensures that the record definition does notinclude objects with names that are duplicates except for case.

(continued on next page)


Table 4–1 (Cont.) Oracle CDD/Repository Compatibility for Oracle Rdb Features

Oracle Rdb FeatureMinimum Releaseof Oracle Rdb

Minimum Release ofOracle CDD/Repository Support

Storage map definitions correctlyrestored

3.0 5.1 Explicit

Stored functions 7.0 6.1 Pass-through

Stored procedures 6.0 6.1 Pass-through

SUBSTRING function 4.0 7.0 supports all features5.0 supports all but 4.2MIA features 2

Explicit

Temporary tables 7.0 6.1 Pass-through

Triggers 3.1 5.2 Pass-through

TRUNCATE TABLE 7.0 6.1 Pass-through

TRIM and POSITION functions 6.1 7.0 Explicit

UPPER, LOWER, TRANSLATEfunctions

4.2 7.0 Explicit

USER function 2.2 7.0 Explict

2Multivendor Integration Architecture (MIA) features include the CHAR_LENGTH clause and theTRANSLATE function.

4.1.2 Multischema Databases and CDD/RepositoryYou cannot use multischema databases with CDD/Repository and Oracle Rdbrelease 7.0 and earlier. This problem will be corrected in a future release ofOracle Rdb.

4.1.3 Interaction of Oracle CDD/Repository Release 5.1 and Oracle RMUPrivileges Access Control Lists

Oracle Rdb provides special Oracle RMU privileges that use the unused portionof the OpenVMS access control list (ACL) to manage access to Oracle RMUoperations.

You can use the RMU Set Privilege and RMU Show Privilege commandsto set and show the Oracle RMU privileges. The DCL SHOW ACL andDIRECTORY/ACL commands also show the added access control information;however, these tools cannot translate the names defined by Oracle Rdb.

Note

The RMU Convert command propagates the database internal ACL to theroot file for access control entries (ACEs) that possess the SECURITY andDBADM (ADMINISTRATOR) privileges.

Oracle CDD/Repository protects its repository (dictionary) by placing theCDD$SYSTEM rights identifier on each file created within the anchor directory.CDD$SYSTEM is a special, reserved rights identifier created by OracleCDD/Repository.


When Oracle CDD/Repository executes the DEFINE REPOSITORY command, itadds (or augments) an OpenVMS default ACL to the anchor directory. Typically,this ACL allows access to the repository files for CDD$SYSTEM and denies accessto everyone else. All files created in the anchor directory inherit this default ACL,including the repository database.

Unfortunately, there is an interaction between the default ACL placed on therepository database by Oracle CDD/Repository and the Oracle RMU privilegesACL processing.

Within the ACL on the repository database, the default access control entries(ACEs) that were inherited from the anchor directory will precede the ACEsadded by RMU Restore. As a result, the CDD$SYSTEM identifier will not haveany Oracle RMU privileges granted to it. Without these privileges, if the userdoes not have the OpenVMS SYSPRV privilege enabled, Oracle RMU operations,such as Convert and Restore, will not be allowed on the repository database.

The following problems may be observed by users who do not have the SYSPRVprivilege enabled:

• While executing a CDO DEFINE REPOSITORY or DEFINE DICTIONARYcommand:

If the CDD$TEMPLATEDB backup (.rbf) file was created by a previousversion of Oracle Rdb7, the automatic RMU Convert operation that will becarried out on the .rbf file will fail because SYSPRV privilege is required.

If the CDD$TEMPLATEDB backup (.rbf) file was created by the currentversion of Oracle Rdb7, the restore of the repository database will failbecause the default ACEs that already existed on the repository file thatwas backed up will take precedence, preventing RMU$CONVERT andRMU$RESTORE privileges from being granted to CDD$SYSTEM or theuser.

If no CDD$TEMPLATEDB is available, the repository database will becreated without a template, inheriting the default ACL from the parentdirectory. The ACE containing all the required Oracle RMU privilegeswill be added to the end of the ACL; however, the preexisting defaultACEs will prevent any Oracle RMU privilege from being granted.

• You must use the RMU Convert command to upgrade the database diskformat to Oracle Rdb7 after installing Release 7.0. This operation requiresthe SYSPRV privilege.

During the conversion, RMU Convert adds the ACE containing the OracleRMU privileges at the end of the ACL. Because the repository databasealready has the default Oracle CDD/Repository ACL associated with it, theOracle CDD/Repository ACL will take precedence, preventing the granting ofthe Oracle RMU privileges.

• During a CDO MOVE REPOSITORY command, the Oracle RMU privilegechecking may prevent the move, as the RMU$COPY privilege has not beengranted on the repository database.

• When you execute the CDD template builder CDD_BUILD_TEMPLATE, thestep involving RMU Backup privilege has not been granted.

Oracle CDD/Repository Releases 5.2 and higher correct this problem. A versionof the Oracle CDD/Repository software that corrects this problem and allows newrepositories to be created using Oracle Rdb7 is provided on the Oracle Rdb7 kitfor use on OpenVMS VAX systems. See Section 4.1.3.1 for details.


4.1.3.1 Installing the Corrected CDDSHR ImagesOpenVMS VAX Systems

Note

The following procedure must be carried out if you have installed or planto install Oracle Rdb7 and have already installed CDD/Repository Release5.1 software on your system.

Due to the enhanced security checking associated with Oracle RMU commandsin Oracle Rdb on OpenVMS VAX, existing CDDSHR images for CDD/RepositoryRelease 5.1 must be upgraded to ensure that the correct Oracle RMU privilegesare applied to newly created or copied repository databases.

Included in the Oracle Rdb7 for OpenVMS VAX distribution kit is a CDDupgraded image kit, called CDDRDB042, that must be installed after you haveinstalled the Oracle Rdb7 for OpenVMS VAX kit.

This upgrade kit should be installed by using VMSINSTAL. It automaticallychecks which version of CDDSHR you have installed and replaces the existingCDDSHR.EXE with the corrected image file. The existing CDDSHR.EXE will berenamed SYS$LIBRARY:OLD_CDDSHR.EXE.

The upgrade installation will also place a new CDD_BUILD_TEMPLATE.COMprocedure in SYS$LIBRARY for use with CDD/Repository V5.1.

Note

If you upgrade your repository to CDD/Repository V5.1 after you installOracle Rdb7 V7.0, you must install the corrected CDDSHR image againto ensure that the correct CDDSHR images have been made available.

The CDD/Repository upgrade kit determines which version ofCDD/Repository is installed and replaces the existing CDDSHR.EXEwith the appropriate version of the corrected image.

4.1.3.2 CDD Conversion ProcedureOpenVMS VAX Systems

Oracle Rdb7 provides RDB$CONVERT_CDD$DATABASE.COM, a commandprocedure that both corrects the anchor directory ACL and performs the RMUConvert operation. The command procedure is located in SYS$LIBRARY.

Note

You must have SYSPRV enabled before you execute the procedureRDB$CONVERT_CDD$DATABASE.COM because the procedure performsan RMU Convert operation.

Use the procedure RDB$CONVERT_CDD$DATABASE.COM to process theanchor directory and update the ACLs for both the directory and, if available, therepository database.


This procedure accepts one parameter: the name of the anchor directory thatcontains, or will contain, the repository files. For example:

$ @SYS$LIBRARY:DECRDB$CONVERT_CDD$DATABASE [PROJECT.CDD_REP]

If many repositories exist on a system, you may want to create a DCL commandprocedure to locate them, set the Oracle RMU privileges ACL, and convert thedatabases. Use DCL commands similar to the following:

$ LOOP:$ REP_SPEC = F$SEARCH("[000000...]CDD$DATABASE.RDB")$ IF REP_SPEC .NES. ""$ THEN$ @SYS$LIBRARY:DECRDB$CONVERT_CDD$DATABASE -

’F$PARSE(REP_SPEC,,,"DIRECTORY")’$ GOTO LOOP$ ENDIF


5Enhancements

This chapter describes the enhancements that are introduced in Oracle Rdb7Release 7.0.3.1.

5.1 Enhancements Provided in Oracle Rdb7 Release 7.0.3.15.1.1 Per-Process Monitoring for SHOW STATS

The purpose of the Per-Process Monitoring facility is to provide a powerful drill-down capability to allow the DBA to analyze process-specific information for asingle process, class of processes, or all attached database processes. The facilityalso provides several screens that display a side-by-side comparison of individualprocess statistic information, such as I/O, transaction, and record statistics. ThePer-Process Monitoring facility presents real-time information and, consequently,does not write its information to the binary output file. Therefore, the Per-ProcessMonitoring facility is not available during the replay of a binary input file.

The Per-Process Monitoring facility is not available if clusterwide statisticcollection is active. Conversely, the clusterwide statistic collection facility is notavailable when the Per-Process Monitoring facility is active.

For a complete description of the various methods by which the Per-ProcessMonitoring facility can be activated, see the white paper, RMU SHOWSTATISTIC Utility Per-Process Monitoring Facility on MetaLink.

5.1.2 New DOMAINS Option for RMU/EXTRACTIn Oracle Rdb7 Release 7.0.3.1, RMU Extract adds more control over the waydomain definitions are handled. A new /OPTION=NODOMAINS can be used toeliminate the domain name from within metadata objects. When used the domainname is replaced by the underlying data type. This option is designed for usewith tools that do not understand the SQL92 SQL language domain feature.

• Affect on /LANGUAGE=SQL output.

The default is /OPTION=DOMAINS.

A SQL script generated when using /OPTION=NODOMAINS no longerincludes the domain name in the CREATE TABLE column definition,CREATE FUNCTION or CREATE PROCEDURE parameter definitions,and any other value expression which uses the CAST function to convertexpression to a domain data type (such as a CREATE VIEW or CREATETRIGGER).

The output for CREATE MODULE is not affected by /OPTION=NODOMAINSbecause it is based on the original source SQL which is not edited by RMUExtract.

• Affect on the /LANGUAGE=ANSI_SQL output.

Enhancements 5–1

The default is /OPTION=NODOMAINS when /OPTION=NORMAL is specifiedor is the default.

In prior versions, ANSI_SQL would attempt to extract the definition usingsyntax from ANSI SQL89 if /OPTION=NORMAL was specified or was thedefault. This SQL language standard does not support domain definitions butRMU Extract would still output the definitions if /ITEM=ALL was specified.In this release of Oracle Rdb RMU Extract no longer generates a list ofCREATE DOMAIN statements if /ITEM=DOMAINS or /ITEM=ALL is used.

To get the behavior of previous versions use the /OPTION=DOMAINSqualifier to have domains generated. For example:

$ RMU/EXTRACT/LANGUAGE=ANSI_SQL/OPTION=DOMAINS databasename

Use the /OPTION=FULL qualifier to have syntax generated for SQL92 toinclude the use of domains.

5.1.3 New NO REORGANIZE clause for ALTER STORAGE MAPIn Oracle Rdb V7.0.2, support was added to allow an existing storage map tobe converted to a strictly partitioned storage map using the ALTER STORAGEMAP...PARTITIONING IS NOT UPDATABLE clause of the ALTER STORAGEMAP statement.

This statement implicitly performs a REORGANIZE on the base table, movingrows within the map if necessary, scanning the storage areas to make sure all thestored data conforms to the storage map definition. This allows the the OracleRdb optimizer to use this type of table efficiently when a sequential scan uses asubset of the storage areas.

In many cases the database administrator knows that a large table is alreadystrictly partitioned but it is prohibitive to reorganize the table (the amountof I/O alone might last several hours). Therefore, in this release of OracleRdb, we have allowed the database administrator to bypass the automaticREORGANIZE performed by the ALTER STORAGE MAP ... PARTITIONING ISNOT UPDATABLE statement using a new NO REORGANIZE clause.

There is an associated risk because Oracle Rdb has not validated the tablepartitioning. It is possible that rows will be missed by sequential scans.The database administrator must take this risk into account when usingthis new clause. Oracle Corporation suggests that an ALTER STORAGEMAP...REORGANIZE be carried out as soon as practical.

When the NO REORGANIZE clause is used, Oracle Rdb records this informationin the Oracle Rdb system tables. The SHOW STORAGE MAP statement willdisplay informational text.

The following example shows an ALTER STORAGE MAP statement whichdisabled the area scan for PARTITIONING IS NOT UPDATABLE and theinformational text from the SHOW STORAGE MAP statement:

5–2 Enhancements

SQL> set flags ’stomap_stats’;SQL> alter storage map EMPLOYEES_MAPcont> partitioning is not updatablecont> no reorganizecont> storecont> using (EMPLOYEE_ID)cont> in EMPIDS_LOWcont> with limit of (’00200’)cont> in EMPIDS_MIDcont> with limit of (’00400’)cont> otherwise in EMPIDS_OVER;~As: starting map restructure...~As: REORGANIZE needed to preserve strict partitioning~As: NO REORGANIZE was used to override scan~As: reads: async 0 synch 21, writes: async 7 synch 3SQL>SQL> show storage map EMPLOYEES_MAP

EMPLOYEES_MAPFor Table: EMPLOYEESPlacement Via Index: EMPLOYEES_HASHPartitioning is: NOT UPDATABLEStrict partitioning was not validated for this tableComment: employees partitioned by "00200" "00400"Store clause: STORE

using (EMPLOYEE_ID)in EMPIDS_LOW

with limit of (’00200’)in EMPIDS_MID

with limit of (’00400’)otherwise in EMPIDS_OVER

Compression is: ENABLEDSQL>

Entering a subsequent ALTER STORAGE MAP...REORGANIZE will validate thepartitioning:

SQL> alter storage map EMPLOYEES_MAPcont> partitioning is not updatablecont> reorganize;~As: starting map restructure...~As: starting REORGANIZE...~As: reorganize AREAS...~As: processing rows from area 69~As: processing rows from area 70~As: processing rows from area 71~As: reads: async 408 synch 22, writes: async 3 synch 0SQL>

Usage Notes

• The NO REORGANIZE clause is ignored unless used with PARTITIONINGIS NOT UPDATABLE. This is because either no automatic reorganize isrequired, or a full rebuild of the table is needed to implement the new mapstructure.

• REORGANIZE and NO REORGANIZE may not appear in the same ALTERSTORAGE MAP command.

Enhancements 5–3

SQL> alter storage map EMPLOYEES_MAPcont> partitioning is not updatablecont> no reorganizecont> reorganize areascont> storecont> using (EMPLOYEE_ID)cont> in EMPIDS_LOWcont> with limit of (’00200’)cont> in EMPIDS_MIDcont> with limit of (’00400’)cont> otherwise in EMPIDS_OVER;%SQL-F-MULTSPECATR, Multiple specified attribute. "REORGANIZE" was specifiedmore than once

• The SET FLAGS option STOMAP_STATS will output an indication that NOREORGANIZE was used.

• The SHOW STORAGE MAP command will output an indication that NOREORGANIZE was used. For example:

SQL> show storage map EMPLOYEES_MAPEMPLOYEES_MAP

For Table: EMPLOYEESPlacement Via Index: EMPLOYEES_HASHPartitioning is: NOT UPDATABLEStrict partitioning was not validated for this table ...

5.1.4 New Options for the GET DIAGNOSTICS StatementFor Oracle Rdb7 Release 7.0.3.1, two new options have been added to the GETDIAGNOSTICS statement:

• TRANSACTION_TIMESTAMP

This option returns the date and time that the last transaction was started.If a transaction is not active, then this may be a prior transaction. Thedatabase server will start transactions when performing database operationsand, therefore, this timestamp may reflect the time of an internal transaction.

If the default date format is SQL92, this option returns a value with thedata type TIMESTAMP(2); otherwise, it returns a DATE (VMS) data type.The default date format can be changed using either the SET DIALECT orSET DEFAULT DATE FORMAT statements, or one of the associated moduleattributes.

• TRANSACTION_SEQUENCE

This is the transaction sequence number (TSN) assigned to the most recentlystarted transaction. The TSN is a unique indicator of database transactionactivity; however, note that the TSN may be reused in some cases. The TSNfor a read-only transaction reflects the transaction state which is visible tothe transaction, and therefore it could have been previously assigned to aread/write transaction. If a read/write transaction performs no database I/O,or was rolled back, then that TSN may be reused by a subsequent read/writetransaction.

This option returns a BIGINT data type.

5–4 Enhancements

The following example uses both these new options:

SQL> set transaction read write;SQL> show transactionTransaction information:

Statement constraint evaluation is offOn the default aliasTransaction characteristics:

Read WriteTransaction information returned by base system:a read-write transaction is in progress- updates have not been performed- transaction sequence number (TSN) is 0:256- snapshot space for TSNs less than 0:256 can be reclaimed- recovery unit journal filename is USER2:[RDM$RUJ]SCRATCH$00018679B3AD.RUJ;1- session ID number is 8

SQL>SQL> declare :x date vms;SQL>SQL> begin get diagnostics :x = transaction_timestamp; end;SQL> print :x;X27-MAY-1999 22:39:17.02

SQL>SQL> declare :y bigint;SQL>SQL> begin get diagnostics :y = transaction_sequence; end;SQL> print :y;

Y256

SQL>SQL> select current_timestamp from rdb$database;

27-MAY-1999 22:39:18.201 row selectedSQL>SQL> commit;

5.1.5 RMU/SHOW Statistic OPCOM Message TrackingThe RMU/SHOW Statistic utility has been enhanced to provide tracking ofdatabase-related OPCOM messages. OPCOM messages are tracked using twoindependent methods:

1. New ‘‘OPCOM Messages’’ Screen. Located in the ‘‘Process Information’’submenu, the ‘‘OPCOM Messages’’ screen identifies the last broadcastOPCOM message for each active process. If a single process is attached to thedatabase multiple times, the OPCOM messages are displayed for the attachthat issued the broadcast.

2. New /OPCOM_LOG qualifier. This qualifier specifies the file specificationof the log file to record various OPCOM messages broadcast by attacheddatabase processes.

The following is an example of the ‘‘OPCOM Messages’’ screen:

Enhancements 5–5

Oracle Rdb X7.1-00 Performance Monitor OPCOM LogDatabase KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS.RDB;2OPCOM Log created 7-JUN-1999 06:25:10.6106:25:12.13 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS2.AIJ;1"(missed 4)06:25:12.13 2A526A05:1 AIJ Log Catch-Up Server activated (missed 4)06:25:21.07 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS3.AIJ;1"06:27:50.11 2A53D804:1 After-image journal 14 switch-over in progress (to 15)06:27:51.26 2A53D804:1 After-image journal switch-over complete06:28:53.44 2A47061D:1 AIJ backup operation started06:28:59.00 2A53D804:1 Automatic backup utility cannot be invoked for TCS3ABS AIJ backup06:30:29.27 2A53D804:1 After-image journal 15 switch-over in progress (to 16)06:30:30.41 2A53D804:1 After-image journal switch-over complete (missed 2)06:31:40.23 2A53DE21:1 AIJ backup operation started06:31:54.56 2A53D804:1 Automatic backup utility cannot be invoked for TCS4ABS AIJ backup06:32:20.88 2A53DE21:1 AIJ backup operation completed06:34:17.52 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS1.AIJ;1"06:36:56.55 2A51E222:1 AIJ backup operation started06:37:30.46 2A51E222:1 AIJ backup operation completed06:37:44.74 2A53D804:1 Replication server stalled waiting for MSN 5700 (AIJ17:12526)06:37:44.74 2A526A05:1 Replication server stalled waiting for MSN 5700 (AIJ17:12526)06:41:38.39 2A53D34B:1 After-image journal 17 switch-over in progress (to 18)06:42:13.87 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS2.AIJ;1"06:42:15.49 2A53D34B:1 After-image journal switch-over complete (missed 2)06:42:19.96 2A53D34B:1 After-image journal 18 switch-over in progress (to 19)06:42:23.31 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS3.AIJ;1"06:42:23.31 2A53D34B:1 After-image journal switch-over complete06:42:46.27 2A4D3423:1 AIJ backup operation started06:44:26.61 2A53D804:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:32.13 2A53D804:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:33.27 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS4.AIJ;1"(missed 2)06:44:34.45 2A53D804:1 After-image journal switch-over complete06:44:34.45 2A532216:31 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:35.66 2A4F9A1A:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:35.66 2A461220:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:36.88 2A505617:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:36.88 2A517218:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:36.88 2A462C1F:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:40.29 2A46EC1C:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:41.45 2A4EBA19:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:44:43.71 2A4F361E:1 Automatic backup utility cannot be invoked for TCS2ABS AIJ backup06:46:10.60 2A53E224:1 AIJ backup operation started06:46:20.53 2A53D804:1 Automatic backup utility cannot be invoked for TCS3ABS AIJ backup06:46:42.36 2A53E224:1 AIJ backup operation completed06:47:11.60 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS5.AIJ;1"06:48:16.92 2A4D7825:1 AIJ backup operation started06:48:47.36 2A4D7825:1 AIJ backup operation completed06:49:40.60 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS1.AIJ;1"

5–6 Enhancements

(missed 2)06:49:41.76 2A53D804:1 After-image journal switch-over complete06:52:45.64 2A53D34B:1 After-image journal 22 switch-over in progress (to 23)06:52:50.04 2A53D804:1 Opening "KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS2.AIJ;1"06:52:50.04 2A53D34B:1 After-image journal switch-over complete06:53:49.82 2A474E26:1 AIJ backup operation started06:54:29.37 2A53D804:1 Automatic backup utility cannot be invoked for TCS1ABS AIJ backup06:55:14.93 2A53D804:1 Automatic backup utility cannot be invoked for TCS1ABS AIJ backup06:55:29.91 2A53D804:1 Automatic backup utility cannot be invoked for TCS1ABS AIJ backup

The following is an example of the /OPCOM_LOG qualifier log file contents:

Oracle Rdb X7.1-00 Performance Monitor OPCOM LogDatabase KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS.RDB;2OPCOM Log created 4-JUN-1999 14:52:16.8114:52:26.87 2A506125:1 After-image journal 33 switch-over in progress (to 34)14:52:28.44 2A506125:1 After-image journal switch-over complete14:53:40.79 2A506125:1 After-image journal 34 switch-over in progress (to 35)14:53:42.22 2A506125:1 After-image journal switch-over complete15:03:21.67 2A506125:1 After-image journal 36 switch-over in progress (to 37)15:03:23.16 2A506125:1 After-image journal switch-over complete15:03:24.82 2A459220:1 AIJ backup operation started15:03:27.82 2A459220:1 AIJ backup operation completed

When recording OPCOM messages, it is possible to occassionally miss a fewmessages for a specific process. When this occurs, the message ‘‘n missed’’ will bedisplayed in the log file.

It is possible to record specific operator classes of OPCOM messages if you specifythe /OPTION=VERBOSE qualifier. This qualifier records only those messagesthat can be received by the process executing the RMU/SHOW Statistic utility.For example, if the process is enabled to receive operator class CENTRAL,then specifying /OPCOM_LOG=opcom.log/OPTION=VERBOSE will recordall CENTRAL operator messages. Conversely, specifying only the /OPCOM_LOG=opcom.log qualifier will record all database-specific OPCOM messagesgenerated from this node.

The operator-specific log file output format is different from the database-specificcontents, because the output is being captured directly from OpenVMS. Thefollowing is an example of the operator-specific log file contents for the CLUSTERand CENTRAL operator classes:

Enhancements 5–7

Oracle Rdb X7.1-00 Performance Monitor OPCOM LogDatabase KODA_TEST:[R_ANDERSON.TCS_MASTER]TCS.RDB;2OPCOM Log created 11-JUN-1999 10:52:07.5311-JUN-1999 10:52:23.85) Message from user RDBVMS on ALPHA4 Oracle RdbX8.0-00 Event Notification for Database _$111$DUA368:[BBENTON.TEST]MF_PERSONNEL.RDB;1 AIJ Log Server terminated11-JUN-1999 10:52:25.49) Message from user RDBVMS on ALPHA4 Oracle RdbX8.0-00 Event Notification for Database _$111$DUA368:[BBENTON.TEST]MF_PERSONNEL.RDB;1 AIJ Log Roll-Forward Server started11-JUN-1999 10:52:26.06) Message from user RDBVMS on ALPHA4 Oracle RdbX8.0-00 Event Notification for Database _$111$DUA368:[BBENTON.TEST]MF_PERSONNEL.RDB;1 AIJ Log Roll-Forward Server failed...11-JUN-1999 10:54:16.05) Message from user INTERnet on ALPHA4 TELNET LoginRequest from Remote Host: 138.2.136.180 Port: 125211-JUN-1999 10:54:16.36) Message from user RDBVMS on ALPHA4 Oracle RdbX8.0-00 Event Notification for Database _$111$DUA368:[BBENTON.TEST]MF_PERSONNEL.RDB;1 AIJ Log Catch-Up Server terminated

5.1.6 New Restricted_Access Qualifier for RMU/LOADRMU Load now supports the Restricted_Access qualifier when attaching to anOracle Rdb database. This option allows a single process to load data and enablessome optimizations available only when Restricted Access is in use.

If you are loading a table from an RMU Unload file which contains LIST OFBYTE VARYING data then the Restricted_Access qualifier will reserve theLIST areas for exclusive access. This reduces the virtual memory used by longtransactions in RMU Load and also eliminates I/O to the snapshot files for theLIST storage areas.

The Restricted_Access and Parallel qualifiers are mutually exclusive and may notboth be specified on the RMU Load command line, or within a plan file. WhileRMU Load is running with this option enabled, no other user may attach to thedatabase. The default is Norestricted_Access.

5.1.7 RDO EDT Editor on OpenVMS Alpha Now AvailablePreviously, on OpenVMS Alpha, the RDO editor was restricted to the TPU editor.The EDT editor was not available via the RDO$EDIT logical name.

This problem has been corrected. The RDO$EDIT logical name controls the editorselection between EDT and TPU as it does on OpenVMS VAX.

5.1.8 New Options Added to SQL EXTRACT FunctionIn Oracle Rdb7 Release 7.0.3.1, the SQL EXTRACT function is being enhancedwith two new options: WEEK_NUMBER and YEAR_WEEK. These options returnthe week number as defined by the International Standard ISO 8601:1988 "Dataelements and interchange formats - Information interchange - Representation ofdates and times".

Section 3.17 of this standard defines a week as "week, calendar: A seven dayperiod within a calendar year, starting on a Monday and identified by its ordinalnumber within a year; the first calendar week of the year is the one that includesthe first Thursday of that year. In the Gregorian calendar, this is equivalent tothe week which includes 4 January."

WEEK_NUMBER is a number between 1 and 53 representing the week of theyear (most years only have 52 weeks). A week starts on Monday and has most ofits days falling in a specific year.

5–8 Enhancements

YEAR_WEEK is a variation of the WEEK_NUMBER that includes the year(including the century) in which the week logically falls. The values range from185901 through 999952 (higher values are possible if dates are constructed witha year beyond 9999). The last two digits of the value are identical to the valuereturned by the WEEK_NUMBER option.

The following example shows the new function results:

SQL> select dt,cont> extract (week_number from dt),cont> extract (year_week from dt)cont> from week_samplecont> order by dt;DT1859-01-07 1 1859011999-01-01 53 1998531999-01-04 1 1999011999-01-10 1 1999011999-12-31 52 1999522000-01-01 52 1999522000-01-03 1 2000012000-02-28 9 2000092000-02-29 9 2000092000-03-01 9 2000099999-12-31 52 99995211 rows selected

Usage Notes

• The source date/time expression must include a date component; DATE(ANSI), TIMESTAMP, or DATE (VMS). Attempts to use other data types willresult in an error. For example:

SQL> select extract (week_number from current_time) from ...;%RDB-E-CONVERT_ERROR, invalid or unsupported data conversion-RDMS-E-EXT_WEEKDAY_TS, invalid type for EXTRACT - must be DATE or TIMESTAMP

• Note that neither WEEK_NUMBER nor YEAR_WEEK can be calculated forthe year 1858, or the first few days of 1859 because the Oracle Rdb date onlysupports part of the year 1858, and therefore the calculation cannot be made.For example:

SQL> select extract (week_number from date’1859-1-1’) from ...;%RDB-E-ARITH_EXCEPT, truncation of a numeric value at runtime-COSI-F-IVTIME, invalid date or time

• Note that the year in which the week falls may not be the same as theextracted year from the date/time value because days at the start of acalendar year may logically fall in the last week of the previous year, anddays at the end of a calendar year may logically fall in the first week of thefollowing year.

Enhancements 5–9

oracle®rdb7foropenvms releasenotesdownload.oracle.com/otn_hosted_doc/rdb/pdf/rdbrn_7031.pdf ·...

Documents