| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 5076.1 |  | NOVA::SMITHI | Don't understate or underestimate Rdb! | Wed Feb 26 1997 12:24 | 9 | 
|  | RDB$SEGMENTED_STRINGS is the name for the logical area(s) used to hold
segmented strings.
Although the user may not use segmented strings, Rdb does.  They are used for
security ACL's, constraint definitions, etc.
What were they doing when the error occurred?
Ian
 | 
| 5076.2 |  | m5.us.oracle.com::LWILCOX | Chocolate in January!! | Wed Feb 26 1997 12:52 | 16 | 
|  |   <<< Note 5076.1 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>
>>RDB$SEGMENTED_STRINGS is the name for the logical area(s) used to hold
>>segmented strings.
>>Although the user may not use segmented strings, Rdb does.  They are used for
>>security ACL's, constraint definitions, etc.
Thanks!  And of course, now the story is that they DO use seg strings.
>>What were they doing when the error occurred?
They aren't sure but think they might have been retrieving data.  I've sent
them off to do more work.
Liz
 | 
| 5076.3 | yuck | m5.us.oracle.com::LWILCOX | Chocolate in January!! | Wed Feb 26 1997 14:07 | 92 | 
|  | OK, here's the scoop.  The primary segment is located at line 1:219368:44
and points to a secondary segment at 1:219368:43, which doesn't appear to
exist.  Here is a dump of the interesting pieces of the page.  I have the
whole page if needed.  I have suggested a possible restore/recover of the
page, and the consultant onsite (not from Oracle) mentioned something about
RMU/ALTER.  Other ideas/thoughts/suggestions?
*------------------------------------------------------------------------------
* DEC Rdb V6.1-04                                       26-FEB-1997 12:42:49.21
*
* Dump of Live area SEGMENTED_STRING_AREA
*     Filename: NTL01_RDA_901:[NTL01]SEGMENTED_STRING__DATA.RDA;1
*     Database: NTL01_DATA_ROOT:[NTL01]NTL01_DATA.RDB;2
*
*------------------------------------------------------------------------------
                   0030 000358E8  0000  page 219368, physical area 48
                        89D8F904  0006  checksum = 89D8F904
               009B06A8 CAA08006  000A  time stamp = 25-FEB-1997 13:32:21.39
                       00A2 0020  0012  32 free bytes, 162 locked
                            002D  0016  45 lines
                       0005 0FE4  0018  line 0: offset 0FE4, 5 bytes
                       0057 0EEA  001C  line 1: offset 0EEA, 87 bytes
                       0057 0E92  0020  line 2: offset 0E92, 87 bytes
                       0057 0E3A  0024  line 3: offset 0E3A, 87 bytes
                       0049 0DF0  0028  line 4: offset 0DF0, 73 bytes
.
.
.
                       0049 02F2  00BC  line 41: offset 02F2, 73 bytes
                       0057 029A  00C0  line 42: offset 029A, 87 bytes
                       0194 0000  00C4  line 43: locked by 404
                       0057 0242  00C8  line 44: offset 0242, 87 bytes
                        00000000  00CC  line 0: TSN 0
                        09DE33BD  00D0  line 1: TSN 165557181
                        09DE33CE  00D4  line 2: TSN 165557198
                        09DE33DB  00D8  line 3: TSN 165557211
.
.
.
                        09DE3593  0170  line 41: TSN 165557651
                        09DE3593  0174  line 42: TSN 165557651
                        00000000  0178  line 43: TSN 0
                        09DE35E3  017C  line 44: TSN 165557731
01940194019401940194019401940194  0180  locked space '................'
                                  ::::  (9 duplicate lines)
                            0194  0220  locked space '..'
454D45474E4152524120544D59502053  0222  free space 'S PYMT ARRANGEME'
52454D55534E4F43204854495720544E  0232  free space 'NT WITH CONSUMER'
                            2008  0242  line 44: blob primary chained segment
                         00 0001  0244  Control information
                                  ....  total blob segment size: 82
              0001 000358E8 002B  0247  next chained segment 1:219368:43
               00000000 00000078  024F  total length of segments 0;120
                        00000002  0257  number of segments 2
                            003C  025B  length of longest segment 60
53414820454853205941532054535543  025D   data 'CUST SAY SHE HAS'
4E454D45474E4152524120544D595020  026D   data ' PYMT ARRANGEMEN'
2052454D55534E4F4320485449572054  027D   data 'T WITH CONSUMER '
        2020444E4120544944455243  028D   data 'CREDIT AND  '
                              00  0299  padding '.'
                            2008  029A  line 42: blob primary chained segment
                         00 0001  029C  Control information
                                  ....  total blob segment size: 82
              0001 000358E8 0029  029F  next chained segment 1:219368:41
               00000000 000000B4  02A7  total length of segments 0;180
                        00000003  02AF  number of segments 3
               00000000 000000B4  02A7  total length of segments 0;180
                        00000003  02AF  number of segments 3
                            003C  02B3  length of longest segment 60
7472202E2E2373732066727620696363  02B5   data 'cci vrf ss#.. rt'
61202E2E6C6C632072756F20676E6E72  02C5   data 'rnng our cll.. a'
206E6F206474737020746D6D70207664  02D5   data 'dv pmmt pstd on '
        20202020202E2E2E34322F32  02E5   data '2/24...     '
                              01  02F1  padding '.'
                            2009  02F2  line 41: blob secondary chained segment
 | 
| 5076.4 | Restore/recover would be a good place to start | bouvs.us.oracle.com::OAKEY | I'll take Clueless for $500, Alex | Wed Feb 26 1997 14:28 | 16 | 
|  | >    <<< Note 5076.3 by m5.us.oracle.com::LWILCOX "Chocolate in January!!" >>>
>>                                   -< yuck >-
>>RMU/ALTER.  Other ideas/thoughts/suggestions?
What category are you looking for ideas/thoughts/suggestions on?
It does look broke, a restore/recover would be the recommended/preferred 
method of fixing the problem.
They might want to consider upgrading to 6.1-10.  
Are they using global buffers?  Memory page transfer?  After-image 
journaling?  (AIJ *might* provide a footprint of what happened.)  Has this 
ever happened before?  
 | 
| 5076.5 |  | hotrdb.us.oracle.com::PMEAD | Paul, [email protected], 719-577-8032 | Wed Feb 26 1997 15:14 | 3 | 
|  |     This has the looks of a problem I fixed recently.  No way we can say
    for sure, however.  The fix will be in the next ECO *after* V6.1A ECO
    1.
 | 
| 5076.6 |  | NOVA::SMITHI | Don't understate or underestimate Rdb! | Wed Feb 26 1997 16:02 | 3 | 
|  | I'd like to see a dump of the entire page...
Ian
 | 
| 5076.7 |  | m5.us.oracle.com::LWILCOX | Chocolate in January!! | Thu Feb 27 1997 11:20 | 6 | 
|  | Ian, I'll mail it to you.  It was suggested (thanks paul!) that since it
contained what could be confidential credit info and phone #s, etc. that
posting it might not be a good idea.
LIz
 | 
| 5076.8 |  | NOVA::SMITHI | Don't understate or underestimate Rdb! | Thu Feb 27 1997 11:38 | 5 | 
|  | fine, I'll dispose of it appropriately.
thanks,
ian
 | 
| 5076.9 |  | m5.us.oracle.com::LWILCOX | Chocolate in January!! | Thu Feb 27 1997 14:06 | 9 | 
|  | FWIW, since the customer couldn't delete this row ('cause it couldn't find
the second segment), he just modified the key field value to be a value
that would not be "reasonable".  i.e., the application will never look for
a row with that key value.
So, Ian, if you have a moment to write another external function to perhaps
call RMU/ALTER to fix this...  :-).
Liz
 |