Hi Knut,
I think the change made by Øystein to fix DERBY-298 makes it hard to
reproduce in 10.2, the problem you are seeing in 10.1 is still there.
DERBY-298 fix added a code to check for last good instant of the
last log file before switching to a new log file to handle crashes
during the log file creation. For problem to appear the last log
instant wrtten in the second database has to exactlty match with what
was there when switch to the second log file happend on the first
databse.
Could you please file JIRA report for this issue , I think database
creation should FAIL if there is a LOG directory at the specified log
device path already; This is similar what is done if there is a
database with same name aready in the derby home.
After a bit of struggle to get the log instant end at the right place,
I manage to reproduce on a 10.2 client with the attached scripts.
Repro is flakey, it will not work if some new log record is generated
on a database creation or by some other operation.
Repro:
1) run logd.sql , then kill IJ
2) change the log swith interval to
derby.storage.logSwitchInterval=3145727
3) run logd1.sql , then kill IJ
4) reconnect to wombat1 , it will fail with following error.
ij> connect 'wombat1';
ERROR XJ040: Failed to start database 'wombat1', see the next
exception for deta
ils.
ERROR XSDB4: Page Page(1,Container(0, 896)) is at version 2, the log
file contains change version 3, either there are log records of this
page missing, or this page did not get written out to disk properly.
Thanks
-suresh
Knut Anders Hatlen wrote:
Maciek <[EMAIL PROTECTED]> writes:
Knut Anders Hatlen <[EMAIL PROTECTED]> writes:
I have seen this error when I have deleted the database directory and
recreated the database, but not deleted the log directory. Could that
be your problem too?
Well, deleting log files helped. DB is working and the user claims no data is
lost. Maybe adding a "repair tool" to my app that deletes log files could solve
future problems of this.
I have been trying to reproduce this problem with no luck. Then I
moved from the development trunk to the 10.1.1.0 release, and I was
immediately able to reproduce the error by doing this:
1) Create a database with logDevice set to /tmp/log
2) Run some transactions so that a couple of log files are generated
3) Kill Derby
4) Delete database directory
5) Re-create database with logDevice set to /tmp/log
6) Run some transactions so that some, but not all of the log files
are overwritten.
7) Kill Derby
8) Restart Derby
During the recovery in 8) I got this error message:
ERROR XSDB4: Page Page(0,Container(0, 768)) is at version 2,657, the
log file contains change version 2,715, either there are log records
of this page missing, or this page did not get written out to disk
properly.
Since I don't get this error with the development trunk (and I have
really tried hard!), it seems like the problem has been fixed. I was
also able to reproduce the error using the 10.1.2.1 release.
Maybe someone knows when this was fixed and can advise how to port the
fix to the release you are running?
connect 'jdbc:derby:wombat;create=true;logDevice=extinout/log' as c1;
autocommit off;
create table t2(a int) ;
insert into t2 values(9999);
commit;
create table t3(a int );
connect 'jdbc:derby:wombat' as c2;
create table t1(a int ) ;
insert into t1 values(1);
insert into t1 values(1);
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
-- this insesr should have switched the log at commit
insert into t1 select * from t1 ;
--- this insert will go into the second log
insert into t1 values(1);
--now do bunch of more inserts , these should cause a
-- recovery error if another databases uses the same log dir
insert into t2 select * from t1 ;
-- kill the ij create the second database with same log path
-- run script logd1.sql after setting derby.storage.logSwitchInterval=3145727
-- change the log switch interval to
-- derby.storage.logSwitchInterval=3145727
-- to avoid the log switch cleaning up the second log file
connect 'jdbc:derby:wombat1;create=true;logDevice=extinout/log' as c1;
autocommit off;
create table t2(a int) ;
commit;
create table t3(a int );
insert into t3 values(9999);
connect 'jdbc:derby:wombat1' as c2;
create table t1(a int ) ;
insert into t1 values(1);
insert into t1 values(1);
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
insert into t1 select * from t1 ;
-- this insesr should leave the first log at the same instant
-- first db ended it.
insert into t1 select * from t1 ;
-- crash and reboot the second database , recovery should fail.
-- or you shoud see more rows than what were supposed to be there.
