| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4956.1 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Fri Jan 24 1997 08:15 | 7 |
| Given the limited information, this AIJ dump looks fine.
Not sure what the problem is...
File a bug & provide the files.
Rick
|
| 4956.2 | timestamp | NLVMS3::ADRIEL | | Fri Jan 24 1997 10:07 | 9 |
| Rick,
I just wanted to enter the following reply.
I don't think the AIJ dump looks OK.
AIJ has been backup(hence initialised) at 20:00.
The first 2 records belong to activities which took place at 15:58.
Adri
|
| 4956.3 | locking ?? | NLVMS3::ADRIEL | | Fri Jan 24 1997 10:10 | 26 |
|
Hi,
some ideas about this situation.
Given the fact that these 'old' AIJ records were put on correct
place, after the open record (3/2 and 3/3), I think these records
were inserted by an Rdb process.
This looks valid for the 'old' database data as well.
Remember that pages were correctly formatted.
AIJ backup took place at 20:00 (see open record). Until 23:27
there was no activity on the database.
Database open is AUTOMATIC, so database has been closed.
Something else I noticed is that although the database insert job
run at 23:30-07:30-15:30 (8 hour shifts) only the one at 23:30
introduces the problem.
I am not that familiar with UNIX but it looks like I/O to
the AIJ and database file isn't correctly synchronized between
several writers.
Could there be a locking issue ?
I will suggest to change database open to MANUAL.
Adri
|
| 4956.4 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Fri Jan 24 1997 16:45 | 18 |
| No, this journal *is* fine.
The first 2 records happen the be the last 2 records of the previous AIJ
journal, which had to be "carried over" into the next AIJ journal because of
either of the following reasons:
1. Fast-commit is enabled and this transaction is past the oldest active
checkpoint (I don't think this is the case)
2. The transaction was active at the time of the backup & had to be
carried-forward.
Note that the "last commit TSN" of the open record matches the commit TSN of the
first 2 transactions.
However, the "synchronization TSN" should have been set in the open record, but
because AIJ journals are idempotent, this is ok.
Rick
|
| 4956.5 | FC disabled, /QUIET_POINT | NLVMS3::ADRIEL | | Mon Jan 27 1997 08:14 | 12 |
| Rick,
I see what you mean.
But neither fast commit is enabled nor /NOQUIET_POINT AIJ backup is
made.
The AIJ backup command is: RMU -BACKUP -AFTER -LOG
I assume the default is /QUIET_POINT like in OpenVMS.
???
Adri
|
| 4956.6 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Mon Jan 27 1997 11:30 | 5 |
| It doesn't matter, even with a quiet-point AIJ backup. If the backup encounters
an "in-progress" AIJ commit, it MUST replicate the remaining portion of the AIJ
journal to the "next" AIJ journal in order to ensure proper recovery.
Rick
|
| 4956.7 | previous AIJ file required ? | NLVMS3::ADRIEL | | Thu Jan 30 1997 04:36 | 8 |
| .1
Does this mean that in order to complete the recovery the customer
should start with the previous AIJ file ?
As mentioned in .0 every time the customer has this 'partial' AIJ record
following the open record the recovery bugchecks immediately.
Adri
|
| 4956.8 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Jan 30 1997 07:15 | 14 |
| > Does this mean that in order to complete the recovery the customer
> should start with the previous AIJ file ?
No, this is not necessary.
The repeated data exists in both the previous journal as well as this one...
This was a quiet-point AIJ backup, so the previous journal is not needed (that's
1 reason why the data is repeated in the new journal). Also, the replicated
data is idempotent, so re-applying the changes are ok.
Kind of complicated, isn't it :-)
Rick
|
| 4956.9 | Clear. But bugcheck ? | NLVMS3::ADRIEL | | Thu Jan 30 1997 11:11 | 56 |
| Complicated ?
It's clear now, I was afraid that you meant to say that even
with /quiet_point AIJ backup tx's could span AIJ files.
But there is still the problem not being able to apply this (and other)
AIJ file.
I do have a copy of the database and the AIJ file and I am able to
reproduce the bugcheck.
Below some bugcheck info.
Do you want me to enter a bugreport?
regards, Adri
================================================================================
Bugcheck dump /u01/dbsmgr/rmubugchk.dmp.1
================================================================================
This file was generated by DEC Rdb V6.1-0 upon detection of a
fatal, unexpected, error. Please return this file, the query or
program that produced the bugcheck, the database, monitor log,
and any other pertinent information with an SPR.
This is a DEC 3000 Model 300 series running OSF1 V3.2
Current time is 23-JAN-1997 12:17:59.91
================================================================================
Stack Dump
================================================================================
Saved PC = 000003FF811AA63C : cosi_std_dump_aosf_stack + 0000006C at line 175
Saved PC = 00000001202A9124 : kod$bugcheck_dump + 000009FC at line 784
Saved PC = 000003FF811A9DB0 : cosi_sigsegv_handler + 00000018 at line 361
Saved PC = 000003FF811A9C5C : cosi_default_sighandler + 0000079C at line 315
Saved PC = 000003FF805087F4 : __sigtramp + 00000074 at line 239
Saved PC = 000000012039C218 : diore$allocate_clump + 00000040 at line 469
Saved PC = 000000012039BDF0 : dio$re_do + 000000B0 at line 311
Saved PC = 000000012033E290 : kutrec$apply_aijbl + 000002C8 at line 4784
Saved PC = 0000000120339B08 : kutrec$do_c_aijbuf + 000005D8 at line 2780
Saved PC = 000000012033E9E8 : kutrec$normal_rollforward + 00000428 at line 5068
Saved PC = 0000000120336EC8 : kutrec$recover_journal + 00001308 at line 1569
Saved PC = 0000000120335588 : kutrec$recover + 000002A0 at line 940
Saved PC = 00000001200E0708 : rmurec$recover_action + 00000DAC at line 515
Saved PC = 00000001200DF828 : rmucli$recover + 00000848 at line 277
Saved PC = 0000000120082D98 : __start + 000000E8 at line 371
================================================================================
Contents of TROOT
================================================================================
......
....
...
|
| 4956.10 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Jan 30 1997 12:45 | 3 |
| > Do you want me to enter a bugreport?
Yes, please...
|
| 4956.11 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Jan 30 1997 12:46 | 1 |
| Could you post the stack trace here first?
|
| 4956.12 | stack dump | NLVMS3::ADRIEL | | Fri Jan 31 1997 08:33 | 267 |
| Rick,
below stack dump.
I was using Oracle Rdb UNIX V6.1-0. Customer is running V6.1-03
Adri
================================================================================
Stack Dump
================================================================================
Image /usr/bin/rmu
.text linked at 0000000120000000 mapped at 0000000120000000 size 0x003C2000
.data linked at 0000000140000000 mapped at 0000000140000000 size 0x00090000
.bss linked at 0000000140090000 mapped at 0000000140090000 size 0x00002430
Image /usr/lib/dbs/shlib/libcosi.so
.text linked at 000003FF81160000 mapped at 000003FF81160000 size 0x000A6000
.data linked at 000003FFC0680000 mapped at 000003FFC0680000 size 0x0001C000
.bss linked at 000003FFC069C000 mapped at 000003FFC069C000 size 0x00005E40
Image /usr/lib/cmplrs/cxx/libcxx.so
.text linked at 000003FF81D20000 mapped at 000003FF81D20000 size 0x0002E000
.data linked at 000003FFC1520000 mapped at 000003FFC1520000 size 0x00006000
Image /usr/shlib/libots.so
.text linked at 000003FF81800000 mapped at 000003FF81800000 size 0x0000E000
.data linked at 000003FFC1000000 mapped at 000003FFC1000000 size 0x00004000
Image /usr/shlib/libsort.so
.text linked at 000003FF81C00000 mapped at 000003FF81C00000 size 0x00010000
.data linked at 000003FFC1400000 mapped at 000003FFC1400000 size 0x00002000
Image /usr/shlib/libm.so
.text linked at 000003FF80170000 mapped at 000003FF80170000 size 0x000EE000
.data linked at 000003FFC00C0000 mapped at 000003FFC00C0000 size 0x00004000
Image /usr/shlib/libpthreads.so
.text linked at 000003FF80530000 mapped at 000003FF80530000 size 0x00048000
.data linked at 000003FFC01D0000 mapped at 000003FFC01D0000 size 0x0000E000
.bss linked at 000003FFC01DE000 mapped at 000003FFC01DE000 size 0x00000D00
Image /usr/shlib/libmach.so
.text linked at 000003FF80510000 mapped at 000003FF80510000 size 0x00010000
.data linked at 000003FFC01C0000 mapped at 000003FFC01C0000 size 0x00004000
Image /usr/shlib/libc_r.so
.text linked at 000003FF80480000 mapped at 000003FF80480000 size 0x0008C000
.data linked at 000003FFC01A0000 mapped at 000003FFC01A0000 size 0x00008000
.bss linked at 000003FFC01A8000 mapped at 000003FFC01A8000 size 0x00003050
Image /usr/shlib/libc.so
.text linked at 000003FF80080000 mapped at 000003FF80080000 size 0x000DC000
.data linked at 000003FFC0080000 mapped at 000003FFC0080000 size 0x0000E000
.bss linked at 000003FFC008E000 mapped at 000003FFC008E000 size 0x0000E050
Image /usr/shlib/librt.so
.text linked at 000003FF80CE0000 mapped at 000003FF80CE0000 size 0x0000A000
.data linked at 000003FFC0540000 mapped at 000003FFC0540000 size 0x00006000
Image /usr/shlib/libFutil.so
.text linked at 000003FF81A00000 mapped at 000003FF81A00000 size 0x00024000
.data linked at 000003FFC1200000 mapped at 000003FFC1200000 size 0x00004000
Image /usr/shlib/libsecurity.so
.text linked at 000003FF807C0000 mapped at 000003FF807C0000 size 0x00032000
.data linked at 000003FFC0270000 mapped at 000003FFC0270000 size 0x0000E000
.bss linked at 000003FFC027E000 mapped at 000003FFC027E000 size 0x000BA5F0
Image /usr/shlib/libaud.so
.text linked at 000003FF807A0000 mapped at 000003FF807A0000 size 0x00006000
.data linked at 000003FFC0250000 mapped at 000003FFC0250000 size 0x00002000
================================================================================
Loading symbols for /usr/bin/rmu
Loading symbols for /usr/lib/dbs/shlib/libcosi.so
Loading symbols for /usr/lib/cmplrs/cxx/libcxx.so
Loading symbols for /usr/shlib/libots.so
Loading symbols for /usr/shlib/libsort.so
Loading symbols for /usr/shlib/libm.so
Loading symbols for /usr/shlib/libpthreads.so
Loading symbols for /usr/shlib/libmach.so
Loading symbols for /usr/shlib/libc_r.so
Loading symbols for /usr/shlib/libc.so
Loading symbols for /usr/shlib/librt.so
Loading symbols for /usr/shlib/libFutil.so
Loading symbols for /usr/shlib/libsecurity.so
Loading symbols for /usr/shlib/libaud.so
================================================================================
Saved PC = 000003FF811AA63C : cosi_std_dump_aosf_stack + 0000006C at line 175
R0 (v0 ) = 000003FFC06843C8: 0000000000000000 FFFFFC017FA7F4A8 FFFFFC017FA7FC68
R1 (t0 ) = 000003FF804B8DD8: 4400040A40001000 A6FE0098F500000D 23BD3A5827B73FCF
R2 (t1 ) = 0000000000000000
R3 (t2 ) = 0000000000000000
R4 (t3 ) = 0000000000000000
R5 (t4 ) = 0000000000000000
R6 (t5 ) = 000000000000000C
R7 (t6 ) = 000003FF804B8FE4: 44210411227E01F8 2FFE000047FF041F 27BA3FCFA43E0020
R8 (t7 ) = 000003FFC0080628: 0000000000000000 0000000000000000 0000000000000000
R9 (s0 ) = 00000001202A8728: 6B5B473AB41E00C0 201E00B8B7FE00B8 23BD53E827BB1FDE
R10 (s1 ) = 000003FFC069BE50: 0311111111111111 000003FFC0080628 000003FFC06843C8
R11 (s2 ) = 0000000000000000
R12 (s3 ) = 0000000140063E38: 0000000000000000 72727563206E6916 54535953244D4E4C
R13 (s4 ) = 0000000140048878: 00000001400F6598 00000001400488B0 0080000003000282
R14 (s5 ) = 0000000140063E38: 0000000000000000 72727563206E6916 54535953244D4E4C
R15 (FP ) = 0000000140063E38: 0000000000000000 72727563206E6916 54535953244D4E4C
R16 (a0 ) = 0000000000000001
R17 (a1 ) = 000003FF804A59CC: 27BB3FD02FFE0000 27BB3FD06BFA8001 A75E000027BA3FD0
R18 (a2 ) = 0000000000000000
R19 (a3 ) = 000003FF804A59CC: 27BB3FD02FFE0000 27BB3FD06BFA8001 A75E000027BA3FD0
R20 (a4 ) = 0000000000000001
R21 (a5 ) = 000003FF804A3EC0: A43E001027BA3FD1 6B5B4656B3F10008 23BD897027BA3FD1
R22 (t8 ) = 0000000000000000
R23 (t9 ) = 000003FF804B9008: E4400009227E0050 42201001A77D8CC0 A63E002827BA3FCF
R24 (t10) = 000003FFC01DE9F8: 0000000000000000 0400000000000001 0000000000000000
R25 (t11) = 0000000000043E88: 0000000000000000 0000000000000000 0000000000000000
R26 (ra ) = 000003FF811AA63C: 23BD60EC4160340B F01FFFF144090100 23BD616427BA3F4F
R27 (pv ) = 0000000000000001
R28 (at ) = 000003FFC01DE9F8: 0000000000000000 0400000000000001 0000000000000000
R29 (GP ) = 000003FFC06A07A0: 0000000000000000 0000000000000000 0000000000000000
R30 (SP ) = 000000011FFFD480: 000003FF804B8FE4 000003FF81191AF4 00000001202A9124
Saved PC = 00000001202A9124 : kod$bugcheck_dump + 000009FC at line 784
R10 (s1 ) = 0000000140063E38: 0000000000000000 72727563206E6916 54535953244D4E4C
R11 (s2 ) = 0000000140063E38: 0000000000000000 72727563206E6916 54535953244D4E4C
R26 (ra ) = 00000001202A9124: 23BD496C27BA1FDE 23BD49AC27BA1FDE 23BD49EC27BA1FDE
R30 (SP ) = 000000011FFFD730: 000000000000000A 0000000000000000 0000000000000000
Saved PC = 000003FF811A9DB0 : cosi_sigsegv_handler + 00000018 at line 361
R9 (s0 ) = 000000000000000A
R10 (s1 ) = 000000011FFFDBD0: 0000000000000000 646E6120706D7564 0000000000000000
R11 (s2 ) = 0000000000000001
R12 (s3 ) = 00000001202A8728: 6B5B473AB41E00C0 201E00B8B7FE00B8 23BD53E827BB1FDE
R13 (s4 ) = 72452049534F433F
R14 (s5 ) = 000003FF811A94C0: 47E1741023BD7264 B7FE003823BD72A4 23BD72E027BB3F4F
R15 (FP ) = 000000011FFFF950: 000000011FFFF950 0000000140099D90 0000000120177E78
R26 (ra ) = 000003FF811A9DB0: 23BD697027BA3F4F 23BD69B027BA3F4F 23BD69F027BA3F4F
R30 (SP ) = 000000011FFFDB80: 6220746E65696C63 0000000000000000 000003FF811A9C5C
Saved PC = 000003FF811A9C5C : cosi_default_sighandler + 0000079C at line 315
R26 (ra ) = 000003FF811A9C5C: A77D8EB8C3E00015 6B5B406D47EC0410 23BD6B4427BA3F4F
R30 (SP ) = 000000011FFFDB90: 646E6120706D7564 0000000000000000 000003FF805087F4
Saved PC = 000003FF805087F4 : __sigtramp + 00000074 at line 239
R9 (s0 ) = 000000014010EC58: 0000000000000000 833A33323A37323A 000001001A000000
R10 (s1 ) = 000000014010EC50: 0000000000000000 353120373939312D 8100960034000000
R11 (s2 ) = 0000000000000000
R12 (s3 ) = 000000011FFFE208: 0000000000000001 00000001401038D0 000000014010EC50
R13 (s4 ) = 0000000000000019
R14 (s5 ) = 0000000000000000
R26 (ra ) = 000003FF805087F4: 4A0070C14A007162 B7BE0008B75E0000 43ECF400A61E0000
R30 (SP ) = 000000011FFFDCF0: FFFFFFFFFFFFFFFF 000003FF811B92C4 000000011FFFDD38
Saved PC = 000000012039C218 : diore$allocate_clump + 00000040 at line 469
R0 (v0 ) = 0000000000000016
R1 (t0 ) = 00000001400F6830: 00000001400F9C78 00000001400F80F8 0000000000000016
R3 (t2 ) = FFFFFFFFFFFFFFFF
R5 (t4 ) = 0000000000000001
R6 (t5 ) = 0000000000000000
R7 (t6 ) = 0000000000000000
R8 (t7 ) = 0000000000000000
R16 (a0 ) = 0000000000000000
R17 (a1 ) = 0000000000000001
R18 (a2 ) = 0000000000000001
R19 (a3 ) = 0000000000000043
R20 (a4 ) = 0000000000000000
R21 (a5 ) = 0000000000000007
R22 (t8 ) = 0000000000043ED0: 0000000000000000 0000000000000000 0000000000000034
R23 (t9 ) = 0000000000043ED1: 1800000000000000 1800000000000000 0000000000000000
R24 (t10) = 0000000000043ED1: 1800000000000000 1800000000000000 0000000000000000
R25 (t11) = 0000000000000001
R26 (ra ) = 000000012039BDF0: 47FF041FC3E000C8 C3E000D7B01E0030 47FF041FC3E000E8
R27 (pv ) = 000003FF811BB310: B5BE0028B59E0020 23DE001043E103A0 23BD549027BB3F4E
R28 (at ) = 000000012039BDD8: 47EA04102FFE0000 47EA04102FFE0000 47EA04102FFE0000
R29 (GP ) = 000000014008DB10: 000003FF811B86C0 000003FF80505990 000003FF801257A0
R30 (SP ) = 000000011FFFDFC0: 000000000007D3D8 000003FF811C5BD0 000000012039BDF0
Saved PC = 000000012039BDF0 : dio$re_do + 000000B0 at line 311
R9 (s0 ) = 0000000000000000
R30 (SP ) = 000000011FFFDFE0: 00000001203A1FB0 00000001203B1D88 000000012033E290
Saved PC = 000000012033E290 : kutrec$apply_aijbl + 000002C8 at line 4784
R9 (s0 ) = 000000014010EC50: 0000000000000000 353120373939312D 8100960034000000
R10 (s1 ) = FFFFFFFFFFFFFFFF
R11 (s2 ) = 00000001401039D0: 0000000000000000 0000000000000000 000000014004A410
R26 (ra ) = 000000012033E290: A2410000B2070040 23BDF84027BA1FD5 A0290000F000003B
R30 (SP ) = 000000011FFFE160: 000003FF811DE43C 000003FFFFFFFFFF 0000000120339B08
Saved PC = 0000000120339B08 : kutrec$do_c_aijbuf + 000005D8 at line 2780
R9 (s0 ) = 00000001401039D0: 0000000000000000 0000000000000000 000000014004A410
R10 (s1 ) = 000000014004A3E0: 00000000FFFFFFFF 000000014004A420 0000000000000000
R26 (ra ) = 0000000120339B08: 221E0190B57E0080 47FF041FA14A00B8 47FF041FC3FFFFF1
R30 (SP ) = 000000011FFFE1B0: 0000000000000042 000003FFC069D7F8 000000012033E9E8
Saved PC = 000000012033E9E8 : kutrec$normal_rollforward + 00000428 at line 5068
R9 (s0 ) = 000000014004A6A8: 000000FE560220B1 3A30303A30333A37 2F4D078000430012
R10 (s1 ) = 00000001401039D0: 0000000000000000 0000000000000000 000000014004A410
R12 (s3 ) = 00000001400AF630: 0000000000000000 0000000000000000 000000000000001F
R26 (ra ) = 000000012033E9E8: B59E0030B57E0028 A75E000047FF041F A54A001047FF041F
R30 (SP ) = 000000011FFFE640: 000003FF805644FC 0000002801000018 0000000120336EC8
Saved PC = 0000000120336EC8 : kutrec$recover_journal + 00001308 at line 1569
R9 (s0 ) = 000000014004AAD0: 0000000000000000 0000000000000000 0000000000000001
R10 (s1 ) = 0000000140048878: 00000001400F6598 00000001400488B0 0080000003000282
R11 (s2 ) = 0000000000000000
R26 (ra ) = 0000000120336EC8: D340046247FF041F 47FF041FE4600003 47FF041FA009F9C8
R30 (SP ) = 000000011FFFE800: 00000E1032E748E8 0000000000000000 0000000120335588
Saved PC = 0000000120335588 : kutrec$recover + 000002A0 at line 940
R9 (s0 ) = 0000000000000019
R10 (s1 ) = 000000014004AAD0: 0000000000000000 0000000000000000 0000000000000001
R26 (ra ) = 0000000120335588: 47F00413A6B00008 E440014444430802 43E00000B01E00D0
R30 (SP ) = 000000011FFFEC50: 000000011FFFECD0 0000000140099D18 000000011FFFED10
Saved PC = 00000001200E0708 : rmurec$recover_action + 00000DAC at line 515
R9 (s0 ) = 0000000000000029
R10 (s1 ) = 0000000140099D18: 0000000000000000 0000002900000000 00000000020E0012
R26 (ra ) = 00000001200E0708: AE9300004640F113 205E00A0A43E0098 B01E00D847FF041F
R30 (SP ) = 000000011FFFF090: 0000000000000001 0000000000000000 0000000000000001
Saved PC = 00000001200DF828 : rmucli$recover + 00000848 at line 277
R9 (s0 ) = 0000000140099D90: 0000000000000000 0000000000000000 0000000000000000
R10 (s1 ) = 0000000000000005
R11 (s2 ) = 000003FFC008C8B0: 0000000000000000 0000000000000000 000000000000000D
R12 (s3 ) = 0000000000000000
R13 (s4 ) = 0000000140021D08: 0000000000000000 0000000000000000 0000000000000000
R14 (s5 ) = 000000014000ADD0: 0048544150040000 000064A400030301 0405444E414D4D4F
R26 (ra ) = 00000001200DF828: 247DFFFCB0200044 A77D033847E07419 2FFE000047FF0419
R30 (SP ) = 000000011FFFF8D0: 0000000120177E78 000003FF811C4A54 000003FF81199F48
Saved PC = 0000000120084110 : rmu$main + 00001298 at line 524
R9 (s0 ) = 0000000140092450: 0000000000000000 0000000000000000 00000000020E0007
R10 (s1 ) = 0000000000000004
R15 (FP ) = 0000000000000014
R26 (ra ) = 0000000120084110: 4940762AA5490000 47E3041344C404C3 C3E001E947FF041F
R30 (SP ) = 000000011FFFFC10: 0000000000000005 000003FF804A587C 0000000120082D98
Saved PC = 0000000120082D98 : __start + 000000E8 at line 371
R9 (s0 ) = 0000000140022158: 0000000000000000 0000000000000000 0000000000000000
R10 (s1 ) = 0000000140021E80: 0000000000000000 0000000000000000 0000000000000000
R26 (ra ) = 0000000120082D98: 4A007630A61E0000 47FF041F6BE00000 A43DFDF847FF041F
R30 (SP ) = 000000011FFFFDF0: 000000011FFFFF90 0000000000000000 0000000000000000
================================================================================
Contents of TROOT
================================================================================
|
| 4956.13 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Fri Jan 31 1997 14:25 | 7 |
| The recovery bugcheck problem is fixed in the latest set of ECOs for Rdb v6.0,
v6.1 and v7.0.
The problem is caused by a mis-interpretation of the initial carried-over data
record.
Rick
|
| 4956.14 | V6.1A ECO1 ? | NLVMS3::ADRIEL | | Mon Feb 03 1997 11:25 | 10 |
| Sorry Rick,
last question, do you mean Rdb V6.1A or ECO 1 following V6.1A ?
What about Oracle Rdb UNIX version ? I have not seen V6.1A for UNIX
platform.
Given these uncertainties, is there a workaround in case AIJ recovery
is really required ? Until now the customer tried to recover for test
purposes.
Adri
|
| 4956.15 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Mon Feb 03 1997 12:43 | 19 |
| > last question, do you mean Rdb V6.1A or ECO 1 following V6.1A ?
> What about Oracle Rdb UNIX version ?
Sorry, I can never keep up with which release is the latest...
I mean Rdb v6.1A if that's the latest version currently available.
>I have not seen V6.1A for UNIX
> platform.
Don't know anything about this - sorry...
> Given these uncertainties, is there a workaround in case AIJ recovery
> is really required ? Until now the customer tried to recover for test
> purposes.
Start with the previous AIJ journal.
Rick
|