Re: SYSCOLUMNS Locking Under High Load
On 1/14/15 7:00 AM, Chip Mitchell wrote: Hey all - I was wondering if anyone has come accross this situation before. We have a relatively simple table (below). And it seems that during high insert loads, we see long running transactions and locking. But what I was surprised to see was that the lock was coming out of the SYSCOLUMNS table. The only thing I was suspect of was whether or not that it's the IDENTITY on the first field that might be contributing here. Some additional info follows, but if there is a specific piece that would also help, let me know and I can reply with it. Derby: 10.8.2.2 Table Definition: CREATE TABLE TEST.INFO ( SEQUENCE INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), ID CHARACTER(18) NOT NULL, TYPE INTEGER NOT NULL, DESC CHARACTER(18) NOT NULL, DESC_TYPE INTEGER NOT NULL, CREATED TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); derby.locks.waitTimeout - 600 derby.locks.escalationThreshold - 7000 XID |TYPE |MODE|LOCKCOUNT|LOCKNAME |STATE|TABLETYPE / LOCKOBJ |INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID| *** The following row is the victim *** 1995383222|ROW |S |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS| *** The above row is the victim *** 1995383233|ROW |X |2|(44,53) |GRANT|S |NULL |SYSCOLUMNS| 1995383236|ROW |S |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS| 1995383242|ROW |X |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS| 1995383254|ROW |X |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS| 1995383255|ROW |X |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS| 1995383257|ROW |X |0|(44,53) |WAIT |S |NULL |SYSCOLUMNS Any thoughts or insights are greatly appreciated. Thank you all! Hi Chip, We have certainly seen lock contention on SYSCOLUMNS when identity columns were stressed under heavy loads. Substantial work went into 10.11 to fix this problem. I recommend that you hard-upgrade your database to 10.11 and see if that fixes your issue. Please see the detailed note for DERBY-6542 listed in the 10.11.1.1 release notes: http://db.apache.org/derby/releases/release-10.11.1.1.cgi#Issues Hope this helps, -Rick
Re: Getting fail to start database and unknown page format Exception
It looks like derby database is corrupt, and it is causing critical problem in our e derby.log http://apache-database.10148.n7.nabble.com/file/n143610/derby.log nd with the huge business impact. And the path which its saying derby not found is valid and correct path . Still why suddenly derby got corrputed and what are the reasons for the corruption ? There are various possibilities: 1) You experienced a hard-disk failure on the disk holding /usr/ironhide/var/db 2) or, you experienced a power-failure which caused the operating system to write incorrect data to the filesystem, or fail to flush its buffers properly, perhaps because write-caching was enabled on the filesystem hardware 3) or, you filled up the filesystem /usr/ironhide/var/db, and all the databases and their redo logs were on the same filesystem and all were damaged simultaneously 4) or, some other piece of software, not Derby, wrote updates to the Derby files directly There are certainly other possibilities. Have you inspected your system logs and talked to your system administrators for more information about what was going on at the moment that you noticed the problems? Do you have backups of these databases? Can you print the *full* exception logs from your attempts to access the databases (http://wiki.apache.org/db-derby/UnwindExceptionChain) thanks, bryan
Re: Getting fail to start database and unknown page format Exception
On 1/14/2015 6:34 AM, Bryan Pendleton wrote: It looks like derby database is corrupt, and it is causing critical problem in our e derby.log http://apache-database.10148.n7.nabble.com/file/n143610/derby.log nd with the huge business impact. And the path which its saying derby not found is valid and correct path . Still why suddenly derby got corrputed and what are the reasons for the corruption ? There are various possibilities: 1) You experienced a hard-disk failure on the disk holding /usr/ironhide/var/db 2) or, you experienced a power-failure which caused the operating system to write incorrect data to the filesystem, or fail to flush its buffers properly, perhaps because write-caching was enabled on the filesystem hardware 3) or, you filled up the filesystem /usr/ironhide/var/db, and all the databases and their redo logs were on the same filesystem and all were damaged simultaneously 4) or, some other piece of software, not Derby, wrote updates to the Derby files directly There are certainly other possibilities. Have you inspected your system logs and talked to your system administrators for more information about what was going on at the moment that you noticed the problems? Do you have backups of these databases? Can you print the *full* exception logs from your attempts to access the databases (http://wiki.apache.org/db-derby/UnwindExceptionChain) thanks, bryan I agree with bryan's suggestions. A full derby.log may help. The following also may be helpful: https://wiki.apache.org/db-derby/DatabaseCorruption
Getting fail to start database and unknown page format Exception
Hi, We are in the Apache Derby - 10.8.2.2 version. We are getting repeated exception in derby logs stating 1)java.sql.SQLException: Database '/usr/ironhide/var/db/piprepository/derby' not found. 2)java.sql.SQLException: Database '/usr/ironhide/var/db/remote/derby' not found. 3)java.sql.SQLException: Database '/usr/ironhide/var/db/agent/AgentDB' not found. 4)java.sql.SQLException: Database '/usr/ironhide/var/db/thirdparty/derby' not found. 5)java.sql.SQLException: Database '/usr/ironhide/var/db/connectorrepository/derby' not found. 6)Failed to start database '/usr/ironhide/var/db/thirdparty/derby' 7) ERROR XSDBB: Unknown page format at page Page(302,Container(0, 560)), page dump follows: Hex dump: It looks like derby database is corrupt, and it is causing critical problem in our e derby.log http://apache-database.10148.n7.nabble.com/file/n143610/derby.log nd with the huge business impact. And the path which its saying derby not found is valid and correct path . Still why suddenly derby got corrputed and what are the reasons for the corruption ? Our Product Environment is , we have Java application where 2 java processes connects to derby and perform operations. Both the java processes contacts derby databases (sometime same database) asynchronously frequently. We are using network Derby. We suspect its a bug in the derby ?? do we get any patch for this ? we have attached the logs for further analysis. -- View this message in context: http://apache-database.10148.n7.nabble.com/Getting-fail-to-start-database-and-unknown-page-format-Exception-tp143610.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
