db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby db files get corrupted
Date Sat, 18 Feb 2006 02:12:20 GMT
ACKKKKKKKKK.  I second Stan's comments here.  Removing log files by
hand is VERY likely to corrupt the database.  Yes the db will likely
boot as there are now no log records to process, but all manner of
corruption can occur if the log records are not processed.

The only time I ever consider removing log files is if there is a last
ditch effort needed to recover data from a database, in these cases
I recommend the check table command Stan has below, to see somewhat
where you stand.  Unfortunately it does not catch all corruptions, it
mostly catches inconsistencies between indexes and base tables.  After
this the only safe thing to do is export all the data into a new
database (or recovery from a backup, which should always be the first
step if possible).

Under jdk1.5 derby should be stopping multiple JVM access from the
same machine.  It can't stop multiple JVM access from different machines
if somehow the media is shared.

Stanley Bradbury wrote:
> Maciek wrote:
> 
>> Knut Anders Hatlen <Knut.Hatlen@...> 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.
>>
>>
>>
>>  
>>
> This sends shivers down my spine.  Deleting the log files will certainly 
> resolve any recovery problems by removing any record that a recovery is 
> needed.  Kind of like killing the messenger.  The log files maintain the 
> databased integrity so the integrity is compromised by this procedure 
> and can no longer be guaranteed.  I would run CHECK_TABLE on the 
> database to insure that the table stucture and indexes are OK:
> 
> SELECT schemaname, tablename,
> SYSCS_UTIL.SYSCS_CHECK_TABLE(schemaname, tablename)
> FROM sys.sysschemas s, sys.systables t
> WHERE s.schemaid = t.schemaid
> 
> If this shows no problems and the user has verified that all the data in 
> the DB is fine then there is a good chance the DB is OK but the root 
> cause of the problem has not been corrected.  See my previous post for 
> information on the common cause of this problem.
> 
> 
> 
> 
> 
> 
> 


Mime
View raw message