Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: 32.97.182.141 is neither permitted nor
 denied by domain of Stan.Bradbury@gmail.com)
Message-ID: <43F4B4E1.8050305@gmail.com>
Date: Thu, 16 Feb 2006 09:22:41 -0800
From: Stanley Bradbury <Stan.Bradbury@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Derby db files get corrupted
References: <20060216074417.714D3D54E4@poczta.interia.pl>
In-Reply-To: <20060216074417.714D3D54E4@poczta.interia.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

wegorkie@interia.pl wrote:

>Hi,
>
>I use Derby in my product which is personal finance manager written in Java. The app is standalone and has derby as embedded 
>
>database which of course starts together with an app.
>
>The version of derby.jar (from manifest) is:
>Bundle-Name: Apache Derby 10.1
>Bundle-Version: 10.1.1000000.208786
>
>and I use embedded driver from the same jar:
>org.apache.derby.jdbc.EmbeddedDriver
>
>Now. I have a serious problem. The application is used by many users, and from time to time the database gets corrupted. I do 
>
>not know what way. I have never such a corrupt on my desktop (I use my app as a user as well). I can maybe suppose that users 
>
>are doing something wrong, or the other way that I do.
>Anyway, after db files are corrupted, the data is lost. I don't know how to get them back. Are there any diagnostic tools for 
>
>Derby? I don't see any.
>Well this is sample fragment from stacktrace from JDBC trying to open corrupted db:
>
>(...)
>Page Page(3,Container(0, 976)) is at version 755, the log file contains change version 5 564, either there are log records of 
>
>this page missing, or this page did not get written out to disk properly.
>ERROR XSDB4: Page Page(3,Container(0, 976)) is at 
>
>version 755, the log file contains change version 5 564, either there are log records of this page missing, or this page did 
>
>not get written out to disk properly.
>	at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
>	at org.apache.derby.impl.store.raw.data.PageBasicOperation.needsRedo(Unknown Source)
>	at org.apache.derby.impl.store.raw.log.FileLogger.redo(Unknown Source)
>	at org.apache.derby.impl.store.raw.log.LogToFile.recover(Unknown Source)
>	at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
>	at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
>	at org.apache.derby.impl.store.access.RAMAccessManager.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
>	at org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown Source)
>	at org.apache.derby.impl.db.BasicDatabase.bootStore(Unknown Source)
>	at org.apache.derby.impl.db.BasicDatabase.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
>	at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
>	at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(Unknown Source)
>	at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Unknown Source)
>	at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(Unknown Source)
>	at org.apache.derby.impl.jdbc.EmbedConnection.<init>(Unknown Source)
>	at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(Unknown Source)
>	at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Unknown Source)
>	at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
>	at java.sql.DriverManager.getConnection(Unknown Source)
>	at java.sql.DriverManager.getConnection(Unknown Source)
>(...)
>
>Now I have the questions:
>1. How can I diagnose the bug? Do you have any idea what way can I reproduce it or something?
>2. Is it possible to restore lost data from such corrupted file?
>3. Is there possibility that db gets corrupted for example where app is closed wrong way (for example there is power off) - 
>
>it should not I suppose?
>4. Are there any tools that could help me to look at the problem closely?
>
>Thanks.
>
>Maciek
>
>
>-------------------------------------------------------------------
>Fotoerotica! >>> http://link.interia.pl/f1904
>
>
>  
>
What Knut suggestes could cause this error and would hardware problems 
related to I/O but the most common cause of this type of  problem is 
double booting the database.  Take care that two instances of the 
application are not started at the same time.  I believe that double 
booting is more likely to be a problem on Unix / Linux platforms and 
when using an older JVM.  What JVM are you using?

When using older JVMs, double-booting problems can be minimized by 
setting the property |derby.database.forceDatabaseLock=true|. One 
side-effect of setting |forceDatabaseLock| is that the existence of the 
database lock file (db.lck) will always prevent a database from booting. 
When a database is not properly shutdown (for example, a crash or an 
abort) an 'orphan' database lock file will be left. When 
|forceDatabaseLock| is set, this orphan file will need to be removed 
manually.