Filed	24-JAN-2001
Product	Oracle Server - Enterprise Edition V7	Product Version 	8.1.6
Platform	Sun Solaris V2 Sparc	Platform Version	2.6
Database Version	8.1.6	Affects Platforms 	Generic
Priority	Severe Loss of Service	Status	Q/A To Development
Base Bug	N/A	Fixed in Product Version	9.0.0

Problem statement:

ANALYZE TABLE LIST CHAINED ROWS REPORTS CHAINS WITHIN A BLOCK 
 
*** HBERGH 01/24/01 06:40 pm *** (CHG: Sta->11 Asg->HBERGH) 
*** HBERGH 01/24/01 06:40 pm *** 
 When processing a row that is chained within a block, kdglcr() checks each row  
 piece from H to L to see if all pieces are contained in the same block. When  
 it gets to the last piece, the loop ends, but the function doesn't explicitly  
 return any value. It should return 0 at this point. The return value is  
 undefined, and appears to be non-zero for an optimized module, and 0 for a  
 non-optimized module. 
 The fix is to remove the "else" before the last "return 0". 
*** HBERGH 01/25/01 02:15 pm *** 
 In the RDBMS_MAIN_SOLARIS_010124 label, lint reports: 
 ./kdg.c: 814: Warning:381 Return without value is possible for: kdglcr 
 This is exactly the cause of the bug. It reports other problems as well. 
 In 8.1.6 lint didn't report any problems in kdg.c 
*** HBERGH 01/26/01 04:03 pm *** 
 Sent review request. 
*** LCPRICE 02/12/01 02:20 pm *** (CHG: DevPri->2) 
*** HBERGH 02/13/01 06:40 pm *** 
. 
*** HBERGH 02/14/01 03:58 pm *** 
 Sent merge request. 
*** HBERGH 02/14/01 04:33 pm *** (CHG: Sta->80) 
*** HBERGH 02/14/01 04:33 pm *** (CHG: Fixed->9.0.0) 
*** HBERGH 02/14/01 04:33 pm *** 
 ADE transaction: hbergh_bug-1611490 
 File:  
 /vobs/rdbms/src/server/ram/analyze/kdg.c/main/st_rdbms_hbergh_bug-1611490/1 
 Internal Description:  
         When processing a row that is chained within a block, kdglcr() 
         checks each row piece from H to L to see if all pieces are 
         contained in the same block. When it gets to the last piece, 
         the loop ends, but the function doesn't explicitly return any 
         value. It should return 0 at this point. The return value is 
         undefined, and appears to be non-zero for an optimized module, 
         and 0 for a non-optimized module, on Solaris and Tru64. 
*** HBERGH 02/14/01 04:34 pm *** 
How to determine rediscovery: 
        Execute the command ANALYZE TABLE LIST CHAINED ROWS and count the 
        rows it has added to the table CHAINED_ROWS. If this number is 
        greater than the value of USER_TABLES.CHAIN_CNT after running 
        ANALYZE TABLE COMPUTE STATISTICS, then you've rediscovered this bug. 
. 
*** HNAPEL 10/02/02 05:43 am *** 
 Seems the TRUE chained rows have their HEAD_ROWID pointing to row# 0 only, 
 the result of this query should equal the CHAIN_CNT from USER_TABLES: 
 select count(*) from chained_rows 
 where dbms_rowid.rowid_row_number(head_rowid)=0;