Oracle Rdb Update 04 for Rdb Release 7.2.4.1.0/7.2.4.1.1 An Oracle Rdb update (dated 4-OCT-2010) is available for Rdb Release 7.2.4.1.0/7.2.4.1.1. The following changes, listed in no particular order, are included in this update kit. Rdb Monitor Bugcheck at MON$LOCK_MPLL Bug 10142076 A problem was introduced in Oracle Rdb Release 7.2.4.0 that could corrupt one of the Rdb monitor's in-memory data structures causing the monitor to terminate with a bugcheck at MON$LOCK_MPLL + 00000264. The problem does not lead to any data corruption and the monitor can be restarted normally. This problem has been corrected in Oracle Rdb Release 7.2.5. Query Slows Down Using Aggregate Outer Join at Outer Loop Bug 10077574 In prior releases of Oracle Rdb, the following update query would run much slower when applying Aggregate Outer Join at the outer match loop than it did when using zig-zag at the outer match loop. See the following example. update T1 C1 set A_SALE = (C1.A_SALE + ((select sum(C2.A_SUMM) from T2 C2 where ((C2.SYSID = 6840) and (C2.A_ANAL = C1.A_ANAL))))) where (exists (select * from T2 C3 where ((C3.SYSID = 6840) and (C3.A_ANAL = C1.A_ANAL))) and (C1.A_STAT = 0); Tables: 0 = T1 1 = T2 2 = T2 Cross block of 2 entries Q0 Cross block entry 1 Conjunct: <> 0 Match (Agg Outer Join) Q1 Outer loop Match_Key:0.A_ANAL Conjunct: 0.A_STAT = 0 Get Retrieval by index of relation 0:T1 Index name T1_NDX1 [0:0] Bool: 0.A_STAT = 0 Inner loop (zig-zag) Match_Key:1.A_ANAL Index_Key:SYSID, A_ANAL, A_SYMBOL Aggregate-F1: 0:COUNT-ANY () Q2 Index only retrieval of relation 1:T2 Index name T1_NDX2 [1:1] Keys: 1.SYSID = 6840 Cross block entry 2 Aggregate: 1:SUM (2.A_SUMM) Q3 Leaf#01 BgrOnly 2:T2 Bool: (2.SYSID = 6840) AND (2.A_ANAL = 0.A_ANAL) BgrNdx1 T2_NDX1 [2:2] Fan=29 Keys: (2.SYSID = 6840) AND (2.A_ANAL = 0.A_ANAL) BgrNdx2 T2_NDX2 [2:2] Fan=26 Keys: (2.A_ANAL = 0.A_ANAL) AND (2.SYSID = 6840) 2 rows updated ii rollback; show statistics; process statistics at 3-SEP-2010 17:19:32.99 elapsed time = 0 00:00:09.32 CPU time = 0 00:00:02.85 page fault count = 34 pages in working set = 86240 buffered I/O count = 53 direct I/O count = 15039 open file count = 24 file quota remaining = 1976 locks held = 3207 locks remaining = 28793 CPU utilization = 30.5% AST quota remaining = 995 In a previous version of Oracle Rdb, Release 7.2.3.5, the same query runs fast (less than a second) using zig-zag at the outer match loop. update T1 C1 set A_SALE = (C1.A_SALE + ((select sum(C2.A_SUMM) from T2 C2 where ((C2.SYSID = 6840) and (C2.A_ANAL = C1.A_ANAL))))) where (exists (select * from T2 C3 where ((C3.SYSID = 6840) and (C3.A_ANAL = C1.A_ANAL))) and (C1.A_STAT = 0); Tables: 0 = T1 1 = T2 2 = T2 Cross block of 2 entries Q0 Cross block entry 1 Conjunct: <> 0 Match Q1 Outer loop (zig-zag) Match_Key:0.A_ANAL Conjunct: 0.A_STAT = 0 Get Retrieval by index of relation 0:T1 Index name T1_NDX1 [0:0] Bool: 0.A_STAT = 0 Inner loop (zig-zag) Match_Key:1.A_ANAL Index_Key:SYSID, A_ANAL, A_SYMBOL iii Aggregate-F1: 0:COUNT-ANY () Q2 Index only retrieval of relation 1:T2 Index name T1_NDX2 [1:1] Keys: 1.SYSID = 6840 Cross block entry 2 Aggregate: 1:SUM (2.A_SUMM) Q3 Leaf#01 BgrOnly 2:T2 Bool: (2.SYSID = 6840) AND (2.A_ANAL = 0.A_ANAL) BgrNdx1 T2_NDX1 [2:2] Fan=29 Keys: (2.SYSID = 6840) AND (2.A_ANAL = 0.A_ANAL) BgrNdx2 T2_NDX2 [2:2] Fan=26 Keys: (2.A_ANAL = 0.A_ANAL) AND (2.SYSID = 6840) 2 rows updated rollback; show statistics; process statistics at 23-SEP-2010 12:31:22.50 elapsed time = 0 00:00:08.27 CPU time = 0 00:00:00.01 page fault count = 31 pages in working set = 26592 buffered I/O count = 54 direct I/O count = 12 open file count = 24 file quota remaining = 1976 locks held = 562 locks remaining = 31438 CPU utilization = 0.1% AST quota remaining = 995 This problem has been corrected in Oracle Rdb Release 7.2.5. Bugcheck At RUJUTL$ROLLBACK_LOOP Bug 9856675 In very rare cases, it is possible for a rollback operation (either explicit or implicit) to fail with a bugcheck due to entries being unable to be "undone" on a database page due to an unexpected lack of "locked" space. The sequence of events is complex and requires a specific ordering of operations and accumulation of locked and free space on a database page among several processes. iv The bugcheck "footprint" will be similar to the following: Exception occurred at RDMSHRP72\RUJUTL$ROLLBACK_LOOP + 000010A1 Called from RDMSHRP72\RUJ$ROLLBACK + 000000F0 Called from RDMSHRP72\KOD$ROLLBACK + 000007A0 Called from RDMSHRP72\RDMS$$INT_ROLLBACK_TRANSACTION + 00001140 Called from RDMSHRP72\RDMS$TOP_ROLLBACK_TRANSACTION + 00000A90 Analysis of the bugcheck dump will indicate one or more entries on the "FBIJBL" queue similar to the following: FBIJBL @1C3109C0: QUE = 16E5B0F8:16E5B0F8 +-----------------------------------------------------------+ | This JFA 0 Record sequence number 640 | | Prior JFA 94096 Previous TSN was 0:3390022611 | | Modified segment 911:11828:16 with length of 64 bytes | +-----------------------------------------------------------+ The cause of the problem was related to an incorrect synchronization between processes manipulating the locked and free space while adding lines to the page. This problem has been corrected in a workaround fashion. This update kit implements logic for free space and free line indexes on a database page similar to that of early Rdb 7.0 releases. A temporary (for this release only) logical name RDM$BIND_CHECK_PAGE_ALGORITHM can be used to select one of two algorithms. The value of the logical can be: o 1 - Use the logic for free space and free line indexes on a database page similar to that of early Rdb 7.0 releases. This is the default behavior for this update kit if the logical name is not defined. o 2 - Use the logic for free space and free line indexes on a database page from Rdb Release 7.2.4.1. v DBR Bugchecks Within RUJUTL$BIJBL_GET_FORWARD In prior versions of Oracle Rdb, in rare cases (likely involving a "verb" rollback), it was possible for a later process failure to result in a database recovery process (DBR) failure with a "footprint" similar to the following: ***** Exception at 000000000018E658 : RDMDBR72\RUJUTL$BIJBL_GET_FORWARD + 000000F8 %COSI-F-BUGCHECK, internal consistency failure Saved PC = 0000000000194FA4 : RDMDBR72\RUJUTL$RECOVER_RUJ + 00000964 Saved PC = 0000000000078F08 : RDMDBR72\DBR$RECOVER_USER + 00000A78 Saved PC = 0000000000078164 : RDMDBR72\DBR$RECOVER + 000004C4 Saved PC = 000000000006E9B4 : RDMDBR72\DBR$MAIN + 00001514 This particular case was caused by an incorrect pointer within the RUJ file being used by the recovery process. Upon database re-open, the DBR would succeed. This problem has been corrected in Oracle Rdb Release 7.2.5. Continuous LogMiner Fails With RMU-E-AIJCORRUPT Bug 9594344 In very rare cases, the "RMU /UNLOAD /AFTER_JOURNAL /CONTINUOUS" command can fail with an internal consistency failure "footprint" similar to: %RMU-W-FILACCERR, error reading journal file DKA0:[DB]A1.AIJ;1 %RMU-W-AIJCORRUPT, journal entry 174839/1 contains a new AIJBL that doesn't have the start flag set %RMU-F-FILACCERR, error reading journal file DKA0:[DB]A1.AIJ;1 -RMU-E-AIJCORRUPT, journal entry 174839/1 contains ^%$#W^% %RMU-F-FTL_RMU, Fatal error for RMU operation at 29-MAR-2010 03:50:58 This problem can be caused by multiple processes or multiple systems writing to the AIJ file in an "out- of-order" fashion. The Continuous LogMiner feature requires that blocks in the AIJ file be accessed sequentially. vi This problem has been corrected in the next release of Oracle Rdb. Writers to the AIJ file now serialize AIJ writes to avoid cases where writes are completed "out-of-order". DROP INDEX or TRUNCATE TABLE Do Not Delete Hash Index Nodes With Oracle Rdb Release 7.2.4.1 Bug 9906665 In Oracle Rdb Release 7.2.4.1, a flaw was introduced where dropping a hashed index or truncating a table with a hashed index would likely not correctly erase hashed index nodes. This problem is specific to Oracle Rdb Release 7.2.4.1 on both Alpha and I64 systems. The following sequence demonstrates one possible example of this problem where there is still an index node with an entry for *XYZZY* even after the index was dropped: $ SQL$ CREATE DATABASE FILENAME 'FOO' CREATE STORAGE AREA RDB$SYSTEM FILENAME 'RDB$SYSTEM' CREATE STORAGE AREA A1 FILENAME 'A1' PAGE FORMAT IS MIXED ALLOCATION IS 3; CREATE TABLE T1 (C1 VARCHAR(10)); CREATE INDEX I1 ON T1 (C1) TYPE HASH STORE IN A1; INSERT INTO T1 VALUES ('*XYZZY*'); COMMIT; DROP INDEX I1; COMMIT; EXIT; $ RMU /DUMP /AREA=A1 FOO /OUTPUT=X.X $ SEARCH X.X XYZZY In order to reclaim the space used by the index nodes, it would be required to drop the storage area and recreate it. This problem has been corrected in the next release of Oracle Rdb. vii Query With OR Predicates Bugchecks Bug 9758402 In prior releases of Oracle Rdb, the following query with OR predicates would generate a bugcheck. SQL> select PRO_NUM cont> from PRO_D cont> where cont> (C_NUMBER = '0098816' OR CC_NUMB = '0098816' OR TPC_NUMB = '0098816') cont> AND (MB_NUMBER = ' ' OR MB_NUMBER is null); %RDMS-I-BUGCHKDMP, generating bugcheck dump file DISK:[DIRECTORY]RDSBUGCHK.DMP; %RDMS-I-BUGCHKDMP, generating bugcheck dump file DISK:[DIRECTORY]RDSBUGCHK.DMP; %RDB-F-BUG_CHECK, internal consistency check failed This problem has been corrected in the next release of Oracle Rdb. Query on Table With 12 Million Rows Slows Down Bug 9587738 In prior releases of Oracle Rdb, the following query was significantly slower, with the dynamic optimizer switching prematurely to "ThreLim". SELECT DC.* FROM TAB_DOB DC WHERE DC.STAT<>2 AND DC.STAT<>6 AND DC.STAT BETWEEN 0 AND 1000 AND DC.A_DATE BETWEEN 20090904 AND 20090904 AND DC.A_ACC=173761 ORDER BY DC.A_DATE,DC.A_TIME,DC.A_SYSID,DC.A_SUMM; ~Estim RLEAF Cardinality= 1.2944968E+10 ~E#0003.01(1) Estim Index/Estimate 1/1 ~E#0003.01(1) BgrNdx1 ThreLim DBKeys=0 Fetches=0+0 RecsOut=0 ~E#0003.01(1) Fin Seq DBKeys=61483521 Fetches=0+4596231 RecsOut=1 This problem has been corrected in the next release of Oracle Rdb. viii __________________________________________________________________ How To Install A ZIP file of the VMSINSTAL saveset of this update kit is available. In order to correctly preserve the OpenVMS file attributes, you should UNZIP this file on the OpenVMS system. Once UNZIPed, the update kit is installed with the OpenVMS VMSINSTAL utility (where "dev:[dir]" is the device and directory specification of where the kit is located): $ @SYS$UPDATE:VMSINSTAL RDB_UPD04_7241_072 dev:[dir] Once the installation completes, you should stop and restart Oracle Rdb on all nodes of the cluster that share the system disk where this kit was installed. Oracle recommends that you ensure that a valid system disk backup has been taken before installing any software on your system. The UNZIP utility is available on the OpenVMS Freeware CD or on the world-wide-web at the OpenVMS site "http://h71000.www7.hp.com/openvms/freeware/". ix