[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5076.0. "NODBKEY on RDB$SEGMENTED_STRINGS" by m5.us.oracle.com::LWILCOX (Chocolate in January!!) Wed Feb 26 1997 10:17

Rdb 6.1.  Customer reported a NODBKEY error, and the dbkey is 1:219368:43.
The larea is RDB$SEGMENTED_STRINGS.  He states that the table being accessed
doesn't have any segmented strings in it, and I'm having a difficult time
finding reference to RDB$SEGMENTED_STRINGS in the system relations.
I've checked in the TSH and a few other places.  I have dumped it.

This looks somewhat similar to note 2263.

I've asked him to try to have his user define debug flags so we can get
a better idea of what Rdb is going after, and maybe a verify.

Other ideas?

Thanks.

Liz

T.RTitleUserPersonal
Name
DateLines
5076.1NOVA::SMITHIDon't understate or underestimate Rdb!Wed Feb 26 1997 12:249
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.2m5.us.oracle.com::LWILCOXChocolate in January!!Wed Feb 26 1997 12:5216
  <<< 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.3yuckm5.us.oracle.com::LWILCOXChocolate in January!!Wed Feb 26 1997 14:0792
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.4Restore/recover would be a good place to startbouvs.us.oracle.com::OAKEYI&#039;ll take Clueless for $500, AlexWed Feb 26 1997 14:2816
>    <<< 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.5hotrdb.us.oracle.com::PMEADPaul, [email protected], 719-577-8032Wed Feb 26 1997 15:143
    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.6NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Wed Feb 26 1997 16:023
I'd like to see a dump of the entire page...

Ian
5076.7m5.us.oracle.com::LWILCOXChocolate in January!!Thu Feb 27 1997 11:206
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.8NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Thu Feb 27 1997 11:385
fine, I'll dispose of it appropriately.

thanks,

ian
5076.9m5.us.oracle.com::LWILCOXChocolate in January!!Thu Feb 27 1997 14:069
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