Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 14 Mar 2012 17:24:40 +0000 (UTC)
From: "Mike Matrigali (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1350298251.13996.1331745880418.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2038101811.7641.1331641177563.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5650) ERROR XSDBB: Unknown page format at
 page Page(1936,Container(0, 1009)), page dump follows: Hex dump: 00000000:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229399#comment-13229399 ] 

Mike Matrigali commented on DERBY-5650:
---------------------------------------

I agree with rick's assessment.  Some of the stacks seem to have btree in them, so you may be lucky and dropping and recreating the indexes may work.  To be safe I would make a copy of the db to try recovering on.  Running offline compress on the EVENTS_TABLE would probably be easiest first step.  Then I would suggest running a consistency check across the whole database.

As rick says, figuring out what happened 7 months ago is hard. 

In my quick look at the log it looks like all the corrupted pages (at least those found so far) are all zero's, which is definitely not a legal
page in derby.  Any chance the file system you are running this database on at that time was unique in some way?  Maybe with
a hardware crash or bad disk?   Derby depends
on being able to sync to disk at certain times, and will not run properly if this sync to disk feature is disabled at the hardware or
filesystem level.  The all zero's has the feel of an improper file allocation where the actual data never made it to disk.  

There is at least one outstanding report of a corruption due to running compress table concurrently.  Do you run either of the
compress table system procedures?  

I would also recommend running on a later release to make sure you have all available fixes.  The latest release is 10.8.2.2.
If for some reason you can't move
off of 10.6 at least move to latest 10.6 available which is 10.6.2.1.   Derby puts a lot of testing into backward compatibility, and most
users are able to upgrade to latest software with no problems.  
                
> ERROR XSDBB: Unknown page format at page Page(1936,Container(0, 1009)), page dump follows: Hex dump: 00000000:
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5650
>                 URL: https://issues.apache.org/jira/browse/DERBY-5650
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.6.1.0
>            Reporter: Deepika Kochhar
>         Attachments: derby.log
>
>
> i am trying to insert values into the database table EVENTS_TABLE where i have 18 columns with EVENT_ID as Unique but can be null. Indexes for this table is EVENT_INDEX which points to EVENT_ID internally. Now at some point of insertion into this Table, i am getting "The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'EVENT_INDEX' defined on 'EVENTS_TABLE'." error in my logs and in derby logs i am getting ERROR XSDBB: Unknown page format at page Page(1936,Container(0, 1009)), page dump follows: Hex dump: 00000000: error.
> Please let me know why this is happening and what is the meaning of this error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira