db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6425) DB got corrupted during the heavy operations.
Date Tue, 03 Dec 2013 13:44:52 GMT

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

Rick Hillegas commented on DERBY-6425:
--------------------------------------

Hi Patil,

Hm, that may be the cause of the corruption. We do not recommend running Derby with the write-cache
enabled. In that situation, Derby has no guarantee that the data it wrote actually made it
to disk. Going forward, you should always run Derby with the write-cache disabled. You may
want to review the material on database integrity in the Derby Server and Administration Guide:
http://db.apache.org/derby/docs/10.10/adminguide/cadmindbintegrity.html

Unfortunately, you have a corrupt base table. That means that you can't fix this corruption
by dropping and recreating indexes. Your best solution would be to restore your database from
a recent backup as described in the Admin Guide: http://db.apache.org/derby/docs/10.10/adminguide/cadminhubbkup98797.html
. If you have a usable backup, then you can skip the rest of this comment.

If you don't have a backup, then you will need to discover just how corrupt the database is.
You may have other corrupt tables. To figure out what's corrupt, please read the Admin Guide
section on this topic: http://db.apache.org/derby/docs/10.10/adminguide/cadminconsist01.html
Corrupt indexes can be fixed by dropping and recreating them.

But if the base tables are corrupt, then you will need to dump their data, recreate the tables,
and reload the data. 

The standard way to dump a table into a file is to use the SYSCS_UTIL.SYSCS_EXPORT_TABLE system
procedure described here: http://db.apache.org/derby/docs/10.10/ref/rrefexportproc.html However,
I don't have high hopes for this approach if the table is corrupt. The internal query which
dumps the table is likely to choke on the invalid checksums. But, it's worth a try.

If the SYSCS_UTIL.SYSCS_EXPORT_TABLE system procedure doesn't work for you, then you can try
an experimental tool which was written for this situation. The tool is described by https://issues.apache.org/jira/browse/DERBY-6136
To run the tool, you will need to use Derby version 10.10 and you will need to compile the
classes attached to DERBY-6136.

Those would be my suggestions.

Hope this helps,
-Rick

> DB got corrupted during the heavy operations.
> ---------------------------------------------
>
>                 Key: DERBY-6425
>                 URL: https://issues.apache.org/jira/browse/DERBY-6425
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.9.1.0
>         Environment: Suse 10.
>            Reporter: patil devidas
>            Priority: Critical
>
> ------------  BEGIN SHUTDOWN ERROR STACK -------------
> ERROR XSDG2: Invalid checksum on Page Page(5482,Container(0, 2032)), expected=3,506,219,016,
on-disk version=492,279,644, page dump follows: Hex dump:
> 00000000: 0075 0000 0001 0000 0000 0000 0067 0022  .u...........g..
> 00000010: 0000 0028 0000 0000 0000 0000 0000 0000  ................
> 00000020: 0000 0000 0001 0000 0000 0000 0000 0000  ................
> 00000030: 0000 0000 0000 0000 0000 0000 0406 000a  ................
> 00000040: 0026 0024 6139 3630 3261 6266 2d33 3163  ....a9602abf.31c
> 00000050: 662d 3131 6533 2d38 3363 632d 6231 3935  f.11e3.83cc.b195
> 00000060: 6138 3139 3263 6334 000b 0009 434f 4d50  a8192cc4....COMP
> 00000070: 4c45 5445 4400 0c07 dd0a 0a00 1310 0c05  LETED...........
> 00000080: 4e08 4000 0c07 dd0a 0a00 1310 1c03 1975  N..............u



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message