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
|