[
https://issues.apache.org/jira/browse/DERBY-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2835:
----------------------------------
This issue is indicative of a corruption in the table and indexes. To
determine at any given time if there is a problem you can
run the check table command. It will only tell you the first problem and is
likely to take a long time on such a big table as it
will check every row in the table against every row in the table. If your db
is active you may want to make a backup and do
the checking on a copy of the db.
http://db.apache.org/derby/docs/10.2/ref/rrefsyscschecktablefunc.html
Running compress table may fix the existing problems in the table:
http://db.apache.org/derby/docs/10.2/ref/rrefaltertablecompress.html
> 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.
