[
https://issues.apache.org/jira/browse/DERBY-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308279#comment-14308279
]
Myrna van Lunteren commented on DERBY-6792:
-------------------------------------------
That was my first idea too.
However, I did a search and found DERBY-6766, which has the same error.
Note that there was no fix for that situation, and the problem would reoccur.
Mike had some ideas but no clear solution.
DERBY-6766 refers to an earlier issue which did get fixed, DERBY-4923, but
looks like the build that you are on (10.8.3.3 - (1557911)) already has this
fix.(was backported to the 10.8 branch with revision 1535576).
I talked to Mike (because he commented on DERBY-6766) off-line about this issue
and he said:
" In the past when this type of error has happened the page is kind of "stuck"
in that state, so same error will happen over and over again if nothing else on
the page changes. From the stack it looks like the problem page is the base
page of a row. The locking system of derby requires that updates to base page
of a row leave the "front" of the row on the page.
If the update adds more data than fits what is supposed to happen is there
should always be enough space in the row so that at worst you just leave a
small pointer there and then link to other pages - that pointer is something on
order of 16 bytes. What is weird is that there is relatively a lot of free
space on the page in this case "freeSpace: 601", so not sure what is going on.
If it can be reproduced likely would be easy to fix."
He also suggested that the problem would only be fixed for new data. So if the
database was created with a previous build of 10.8.3.3, the problem could have
gotten in and be still there.
So, follow up questions are:
- as Rick said, is the disk full (or was it full at one point?)
- does the problem reoccur, i.e. like Mike suggested, is the database 'stuck'?
- is the problem reproducible, i.e. going back to a backup or clean database,
does the problem reoccur? Not sure if it's feasible to start with a clean
database - this seemed to be happening for the folks of DERBY-6766.
- Does the CastIron application log also show the query that caused the
problem? Is it similar to DERBY-6766 where there is a combination of updates
and inserts?
One experiment that might possibly fix the current situation is to run offline
compress on the affected table.
The table name can be found using the container id mentioned in the error
message Rick quoted, so it's container (table, in this case, index would be a
1) with id 1328. To get the table name, use a query like this:
SELECT C.CONGLOMERATENUMBER, C.CONGLOMERATENAME, S.SCHEMANAME FROM
SYS.SYSCONGLOMERATES C, sys.sysschemas s WHERE CONGLOMERATENUMBER = 1328 AND
s.schemaid = C.schemaid ;
(documented on this page:
http://wiki.apache.org/db-derby/DatabaseConsistencyCheck)
Information/syntax on how to run off line compress (call
SYSCS_UTIL.SYSCS_COMPRESS_TABLE) can be found in the manuals (see:
http://db.apache.org/derby/manuals/index.html#docs_10.8, Reference guide is a
good starting point) but it's also mentioned on that same
DatabaseConsistencyCheck wiki page mentioned above.
Of course, before doing anything with the database you should make a backup, or
copy, so we can possibly analyze it.
On that note, is there a backup process in place?
> Could not execute JDBC batch update
> -----------------------------------
>
> Key: DERBY-6792
> URL: https://issues.apache.org/jira/browse/DERBY-6792
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.3.3
> Environment: Derby 10.8.3.3, IBM JAVA 7 SR7, Linux
> Reporter: Raja
> Priority: Critical
> Attachments: Derby_error.txt, derby.log, derbyserver.out
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> We are using Derby v10.8.3.3 for our product CastIron. Our customer is
> getting the following error in their production environment.
> SEVERE [T-84] [job:96CC8CC6085B45D13583E180C1014E82]
> [com.approuter.maestro.vm.Task] Internal error:
> org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch
> update
> org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch
> update
> at
> org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
> at
> org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
> at
> org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at
> org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
> at
> org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
> at
> org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
> at
> org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2354)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
> at
> org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:142)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
> at
> org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
> at
> org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
> at
> com.approuter.maestro.opera.rdbms.RdbmsSession.commit(RdbmsSession.java:363)
> at com.approuter.maestro.vm.Task.commit(Task.java:1136)
> at com.approuter.maestro.activities.Invoke.persist(Invoke.java:280)
> at sun.reflect.GeneratedMethodAccessor278.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at
> com.approuter.maestro.activities.Instruction.call(Instruction.java:45)
> at com.approuter.maestro.vm.Program.call(Program.java:596)
> at com.approuter.maestro.vm.Task.run(Task.java:692)
> at com.approuter.maestro.vm.Task.run(Task.java:631)
> at
> com.approuter.maestro.vm.Program$RunnableWrapper.run(Program.java:2207)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:450)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:109)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:217)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:761)
> ------------------------------
> Need quick analysis and solution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
