[
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 disks.
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:
http://db.apache.org/derby/docs/10.2/ref/rrefbackupdbenablelogproc.html
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
row.
> Getting SQLState.LANG_IGNORE_MISSING_INDEX_ROW_DURING_DELETE
> ------------------------------------------------------------
>
> Key: DERBY-2835
> URL: https://issues.apache.org/jira/browse/DERBY-2835
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0
> 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.
