| Title: | Oracle Rdb - Still a strategic database for DEC on Alpha AXP! |
| Notice: | RDB_60 is archived, please use RDB_70 .. |
| Moderator: | NOVA::SMITHI SON |
| 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 |
I hoping for an understanding of why the following behavior
was seen with the RDB/MOVE_AREA command in 6.1-1. The behavior
is reproducible at will.
The sceanrio consists of 2 users, one attached to the db
and one doing an RMU/MOVE/ONLINE of EMPIDS_MID.
User 1 is attached and accessing other tables in other areas,
when user 2 starts an RMU/MOVE/ONLINE. Before the move completes
though, user 1 accesses data in the storage area being moved,
which results in the rmu/move finishing as follows --
TEST>rmu/move/online/log mf_personnel empids_mid
%RMU-I-QUIETPT, waiting for database quiet point
%RMU-I-RELQUIETPT, Database quiet point lock has been released.
%RMU-I-MOVTXT_01, Moved storage areaDISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;2
%RMU-I-MOVTXT_01, Moved storage areaDISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;2
%RMU-I-RESTXT_05, rebuilt 1 space management page
%RMU-I-MOVTXT_02, moved 0 inventory pages
%RMU-I-RESTXT_07, rebuilt 0 logical area bitmap pages
%RMU-I-MOVTXT_03, moved 51 data pages
%RMU-I-RESTXT_01, Initialized snapshot fileDISK$USR2:[DDAYBERR]EMPIDS_MID.SNP;2
%RMU-I-LOGINIFIL, contains 10 pages, each page is 2 blocks long
%RMU-F-CANTDELETE, error deleting"DISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;1"
%COSI-E-FLK, file currently locked by another user
-RMS-E-FLK, file currently locked by another user
%RMU-F-CANTDELETE, error deleting"DISK$USR2:[DDAYBERR]EMPIDS_MID.SNP;1"
%COSI-E-FLK, file currently locked by another user
-RMS-E-FLK, file currently locked by another user
This seems pretty reasonable, but the behavior that follows
is what seems questionable. If user 1 inserts and commits a record,
only user 1 can see the record if indexed accessed is used. If
user2 inserts and commits a record, only user 2 can see the record
if an index retrieval is used. So, it appears the rmu/move being
interupted, results in newly added index records getting corrupt.
It would seem the rmu/move doesn't complete and results in
corruption when a user accesses the database during the move.
Should RDB handle this a little better, or is this 'buyer beware'
when users are in the database.
Debbie
A verify log follows from when I reproduced this.
%RMU-I-BGNROOVER, beginning root verification
%RMU-I-ENDROOVER, completed root verification
%RMU-I-BGNVCONST, beginning verification of constraints for databaseDISK$USR2:`
%RMU-I-ENDVCONST, completed verification of constraints for databaseDISK$USR2:`
%RMU-I-DBBOUND, bound to database"DISK$USR2:[DDAYBERR]MF_PERSONNEL.RDB;1"
%RMU-W-AREABUSY, usage of storage areaDISK$USR2:[DDAYBERR]MF_PERS_DEFAULT.RDA;`
%RMU-E-BADREADY, error readying storage area RDB$SYSTEM
%RMU-I-NOTREQVFY, not all requested verifications have been performed
%RMU-F-ABORTVER, fatal error encountered; aborting verification
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5014.1 | M5::LWILCOX | Chocolate in January!! | Tue Feb 11 1997 08:39 | 30 | |
<<< Note 5014.0 by M5::DDAYBERR >>>
-< RMU/MOVE results in corruption in 6.1-1 >-
>> This seems pretty reasonable, but the behavior that follows
>> is what seems questionable. If user 1 inserts and commits a record,
>> only user 1 can see the record if indexed accessed is used. If
>> user2 inserts and commits a record, only user 2 can see the record
>> if an index retrieval is used. So, it appears the rmu/move being
>> interupted, results in newly added index records getting corrupt.
Debbie, are you saying that if in each case sequential access is used that
each user CAN see the row the other user added but if using indexed
retrieval they can't?
>> %RMU-I-DBBOUND, bound to database"DISK$USR2:[DDAYBERR]MF_PERSONNEL.RDB;1"
>> %RMU-W-AREABUSY, usage of storage areaDISK$USR2:[DDAYBERR]MF_PERS_DEFAULT.RDA;`
>> %RMU-E-BADREADY, error readying storage area RDB$SYSTEM
>> %RMU-I-NOTREQVFY, not all requested verifications have been performed
>> %RMU-F-ABORTVER, fatal error encountered; aborting verification
This could be a series of "normal" messages since verify uses a protected
transaction by default.
Could you post a script of what you did? Maybe a visual will help.
Thanks.
Liz
| |||||
| 5014.2 | Here's the log | M5::DDAYBERR | Tue Feb 11 1997 10:45 | 259 | |
Yes Liz, that's what I'm saying -- that each user, when using
an indexed retrieval, can only see the record that he/she added,
whereas when a sequential retrieval is done, all records are seen.
Here's a log of the process that did the move/area, then added
an employee_id of 00251.
TEST>rmu/dump/users mf_personnel
Active user with process ID 2AA03129 *Other Interactive user
Stream ID is 1
Monitor ID is 1
Transaction ID is 11
No transaction in progress
TEST>show process
10-FEB-1997 13:48:23.97 User: DDAYBERR Process ID: 2AA00925
Node: BLANCA Process name: "_RTA1:"
Terminal: RTA1: (BLANCA::DDAYBERR)
User Identifier: [WWS,DDAYBERR]
Base priority: 4
Default file spec: DISK$USR2:[DDAYBERR]
Devices allocated: BLANCA$RTA1:
TEST>rmu/move/online/log mf_personnel empids_mid
%RMU-I-QUIETPT, waiting for database quiet point !User starts transaction
%RMU-I-RELQUIETPT, Database quiet point lock has been released. now.
%RMU-I-MOVTXT_01, Moved storage area DISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;2
%RMU-I-MOVTXT_01, Moved storage area DISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;2
%RMU-I-RESTXT_05, rebuilt 1 space management page
%RMU-I-MOVTXT_02, moved 0 inventory pages
%RMU-I-RESTXT_07, rebuilt 0 logical area bitmap pages
%RMU-I-MOVTXT_03, moved 51 data pages
%RMU-I-RESTXT_01, Initialized snapshot file DISK$USR2:[DDAYBERR]EMPIDS_MID.SNP;2
%RMU-I-LOGINIFIL, contains 10 pages, each page is 2 blocks long
%RMU-F-CANTDELETE, error deleting "DISK$USR2:[DDAYBERR]EMPIDS_MID.RDA;1"
%COSI-E-FLK, file currently locked by another user
-RMS-E-FLK, file currently locked by another user
%RMU-F-CANTDELETE, error deleting "DISK$USR2:[DDAYBERR]EMPIDS_MID.SNP;1"
%COSI-E-FLK, file currently locked by another user
-RMS-E-FLK, file currently locked by another user
TEST>mcr sql$
SQL> attach 'file mf_personnel';
SQL> select employee_id from employees where employee_id > '00200' and
cont> employee_id < '00400';
EMPLOYEE_ID
00201
00202
00203
00204
00205
00206
00207
00208
00209
00210
00211
00212
00213
00214
00217
00218
00219
00220
00221
00222
00223
00224
00225
00226
00227
00228
00229
00230
00231
00232
00233
00234
00235
00236
00237
00238
00239
00240
00241
00242
00243
00244
00245
00246
00247
00248
00249 No 250 or 251
00267
00276
00287
00319
00345
00354
00358
00359
00369
00374
57 rows selected
SQL> insert into employees (employee_id, last_name) values ('00251', 'Dayberry');
1 row inserted
SQL> commit;
SQL> select * from employees where employee_id > '00249' and employee_id
cont> < '00252';
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer associated with a record
-RDMS-F-NODBK, 70:6:10 does not point to a data record
SQL> commit;
SQL> exit;
TEST>rmu/dump/users mf_personnel
No active users
TEST>rmu/close mf_personnel
%RDMS-F-CANTCLOSEDB, database could not be closed as requested
-RDMS-F-DBNOTACTIVE, database is not being used
%RMU-W-FATALERR, fatal error on DISK$USR2:[DDAYBERR]MF_PERSONNEL.RDB;1
--- Other user adds employee_id 250 ---
TEST>mcr sql$
SQL> attach 'file mf_personnel';
SQL> select * from employees where employee_id = '00250';
0 rows selected
This process can see the record that it added, but not the record the
other user added.
SQL> select * from employees where employee_id = '00251';
EMPLOYEE_ID LAST_NAME FIRST_NAME MIDDLE_INITIAL
ADDRESS_DATA_1 ADDRESS_DATA_2 CITY
STATE POSTAL_CODE SEX BIRTHDAY STATUS_CODE
00251 Dayberry NULL
? NULL N
1 row selected
SQL> select employee_id, last_name from employees where employee_id = '00250';
0 rows selected
SQL> select employee_id, last_name from employees where employee_id = '00251';
EMPLOYEE_ID LAST_NAME
00251 Dayberry
1 row selected
SQL> select employee_id, last_name from employees where last_name ='Dayberry';
%RDB-E-NO_RECORD, access by dbkey failed because dbkey is no longer associated with a record
-RDMS-F-NODBK, 70:6:10 does not point to a data record
SQL> select employee_id from employees;
EMPLOYEE_ID
00164
00165
00166
00167
00168
00169
00170
00171
00172
00173
00174
00175
00176
00177
00178
00179
00180
00181
00182
00183
00184
00185
00186
00187
00188
00189
00190
00191
00192
00193
00194
00195
00196
00197
00198
00199
00200
00201
00202
00203
00204
00205
00206
00207
00208
00209
00210
00211
00212
00213
00214
00217
00218
00219
00220
00221
00222
00223
00224
00225
00226
00227
00228
00229
00230
00231
00232
00233
00234
00235
00236
00237
00238
00239
00240
00241
00242
00243
00244
00245
00246
00247
00248
00249
00250 The record the other user process added
00251 The record that this process added
00267
00276
00287
00319
00345
00354
00358
00359
00369
00374
00405
00415
00416
00418
00435
00471
102 rows selected
SQL> exit
TEST>lo
DDAYBERR logged out at 10-FEB-1997 14:04:02.50
| |||||
| 5014.3 | maybe optimizer/locking issue???? | M5::JAKUHN | rdb exists *ONLY* for CDD | Wed Feb 12 1997 14:02 | 5 |
a wild guess: Maybe the move/area locks the index and somehow the
optimzer, seeing the index is locked ??) ignores it and forces
sequential. just a thought.
jk
| |||||
| 5014.4 | Should I follow-up with a BUG | M5::DDAYBERR | Thu Feb 13 1997 11:19 | 15 | |
Thanks for the WAG Jay, but it's not that we are doing a
sequential access unexpectedly, but rather the current user seems
to result in the index getting corrupt when doing the MOVE_AREA;
therefore, the index retrievals result in 0 records found or in
an error, and the sequential retrieval works.
Since we support an ONLINE qualifier for the RMU/MOVE_AREA,
it seems perhaps the MOVE should handle the concurrent users a
little more gracefully. I can reproduce this with RDB 6.6-1,
so I was hoping to determine if I should BUG this or not.
Thanks.
Debbie
| |||||
| 5014.5 | NOVA::SMITHI | Don't understate or underestimate Rdb! | Thu Feb 13 1997 11:42 | 3 | |
if you have a reproducer then please BUG it... Ian | |||||
| 5014.6 | It will not do that | svrav1.au.oracle.com::MBRADLEY | I was dropped on my head as a baby. What's your excuse? | Sun Feb 16 1997 19:10 | 15 |
Jay, > <<< Note 5014.3 by M5::JAKUHN "rdb exists *ONLY* for CDD" >>> > -< maybe optimizer/locking issue???? >- > > a wild guess: Maybe the move/area locks the index and somehow the > optimzer, seeing the index is locked ??) ignores it and forces > sequential. just a thought. The optimizer will not switch to sequential because of any locking consideration. G'day, Mark. | |||||
| 5014.7 | Bug 454570 for 6.1.1, but fixed in 7.0 | M5::DDAYBERR | Tue Feb 18 1997 10:21 | 8 | |
Well, I did enter a bug on this (454570) but all
to quickly I'm afraid, because testing this under RDB
7.0 gives expected results. In 7.0 the 'old' area can't be
deleted due to the interactive user, but the indexes
aren't left corrupt. I went ahead and closed the bug
report as fixed in RDB 7.0.
Debbie
| |||||
| 5014.8 | Will this fix be backported? | 141.148.22.23::ROHR | The Packers did it! | Tue Mar 04 1997 09:37 | 8 |
I have a customer with this behaviour under 6.1-04, and they are not
going to upgrade to V7 in the foreseeable future.
Can someone in engineering comment if the fix can/will be backported to
the 6.1 string or should I make a backport request?
Thanks,
Regina
| |||||
| 5014.9 | New bug or reopen old bug? | CHSR38::ROHR | The Packers did it! | Fri Mar 07 1997 10:20 | 8 |
Re . .8:
So should I open another bug in order to know if this will be
backported? Or should I reopen the old bug?
thanks,
Regina
| |||||