db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Date Mon, 18 Jun 2007 18:52:26 GMT

     [ https://issues.apache.org/jira/browse/DERBY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-2835:

Do you know if syncing to disk is enabled on this machine?  Sometimes on linux write sync
is not enabled and thus the database cannot properly insure it's transactions, especially
in crash conditions as you describe.

If you don't know how to check this a simple test is to run an simple app with autocommit
on (it is on be default) and measure how fast you can do a loop doing a single small insert.
 On a safely configured system the number of inserts per second should be about the number
of synced writes your disk can support - something in the area of 100 per second for modern

What you are describing is a serious problem in the database.  Unfortunately whatever caused
it probably happened awhile ago,
so is hard to guess.  If anyone can ever start with a good database and run a test program
and then see this issue and can 
post that to the list  I would be interested in working on this problem.  

Another way I have tracked down these problems in the past is somehow preserve all the transaction
log files after starting with
a database that was verified clean by check table.  If the production server then once again
causes this issue, I have in the past
been able to figure out what has gone wrong from examing the current db and the sum of all
the log files.  The easiest way for
a user to to do this is by verifying a db is clean with a check table run against all tables,
and then make a backup that enables
log archive mode:

This is the recommended backup mechanism for derby databases.  It allows one to recover from
a backup at one point in
time and apply all the changes that have happened to the database since that time.  For debugging
this particular problem it
also has the side effect of keeping copies of every log record which is key to figuring out
what happend to lose that index

> ------------------------------------------------------------
>                 Key: DERBY-2835
>                 URL: https://issues.apache.org/jira/browse/DERBY-2835
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:
>         Environment: Sun JDK 1.5
>            Reporter: Kurt Huwig
> I get messages like this about once a week:
> WARNING: While deleting a row from a table the index row for base table row (50813,81)
was not found in index with conglomerate id 1.297.  This problem has automatically been corrected
as part of the delete operation.
> I do not have a reproducing example besides the productive server, so here some hints
what it is doing and what happened the last few days:
> The table in question is a log file which gets a lot of updates and once it reaches a
certain limit, the oldest records will be deleted once per day.
> The database is embedded and accessed both embedded and via one network client on another
machine. Nearly all read/write requests come from the network client.
> The table's size is about 3,8 GB and contains a lot of entries (cannot check right now).
> The JVM is sometimes stopped via "killall java".
> Both machines are Linux-SMP.
> Both machines use HA-JDBC to access the database.
> Both machines have 1,5GB of memory.
> The JVM is started with -Xmx768M -Xms768M -Xss128k
> The application uses no transactions on this table.
> The network client used 4000+ simultaneous connections, sometimes reaching the ulimit
of the machine. The number of connections has been reduced to 1/10 and the ulimit has been
increased a few days ago. Still there are records in the database from this time.
> The network connection sometimes broke down as described in DERBY-2747.
> The network client gets "lock timeouts" several times a day, due to long running requests.
> The network client had a OutOfMemoryException regarding the Heap some days ago.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message