db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sai Pullabhotla <sai.pullabho...@jmethods.com>
Subject Re: Issue with SYSCS_UTIL.SYSCS_COMPRESS_ TABLE
Date Fri, 05 Jun 2009 19:09:57 GMT
Kathey,

Thanks for replying. This error occurred on a production system at a
customer's site and the stack trace I posted is what I've  available. Since
the customer restarted the app, by the time we got the derby.log, it was
empty (I guess the log is overwritten everytime?).

Here is the sequence on what happened when the failure occurred:

6/3/09 12:04:58 AM            INFO      Preparing to backup the database
6/3/09 12:05:14 AM            INFO      Database was successfully backed up
to /linoma/goanywhere/userdata/database/backups/2009-06-03.zip.
6/3/09 12:05:14 AM            INFO      Backup operation took 16 seconds.
6/3/09 12:05:14 AM            INFO      Compressing and performance tuning
the database tables...
6/3/09 12:05:39 AM            INFO      Job 1243782054134 started for
project '/PTP Tax Upload'
6/3/09 12:05:40 AM            ERROR     Job 1243782054134 completed with an
error
                                        com.linoma.dpa.dao.DAOException: The
conglomerate (71,409) requested does not exist.
[STACK TRACE OMMITTED AS IT WAS POSTED IN THE ORIGINAL POST]
6/3/09 12:05:43 AM            INFO      Database compression completed
successfully.  Operation took 28 seconds.
6/3/09 12:05:43 AM            INFO      Verifying the database
consistency...
6/3/09 12:05:49 AM            INFO      Database consistency check completed
successfully. Operation took 5 seconds.
6/3/09 12:10:39 AM            INFO      Job 1243782054135 started for
project '/PTP Tax Upload'
6/3/09 12:10:39 AM            ERROR     Job 1243782054135 completed with an
error
                                        com.linoma.dpa.dao.DAOException: The
conglomerate (71,409) requested does not exist.
[SEVERAL JOBS FAILED WITH THE SAME EXCEPTION UNTIL THE SYSTEM WAS RESTARTED]

As you can see, we first did a backup using the stored procedure -
SYSCS_UTIL.SYSCS_BACKUP_DATABASE.
Then we started the compression of all the tables... while the tables are
being compressed, a SELECT statement was executed because of a job
submission. This SELECT errored out. Then the compression completed
normally. Then we performed a database consistency check using the following
statement:

SELECT
    schemaname || '.' || tablename as TableName,
    SYSCS_UTIL.SYSCS_CHECK_TABLE(schemaname, tablename) AS OK
FROM
    sys.sysschemas s, sys.systables t
WHERE
    s.schemaid = t.schemaid and t.tabletype = 'T'

The consistency check succeeded with no issues. All subsequent queries
failed with the same error until the app was restarted.

The isolation level is READ_COMMITTED (2).

I will try to see if I can reproduce the error here and send you any
additional logs.

Sai Pullabhotla
www.jMethods.com



On Fri, Jun 5, 2009 at 1:25 PM, Kathey Marsden
<kmarsdenderby@sbcglobal.net>wrote:

> Sai Pullabhotla wrote:
>
>> Hello,
>>
>>
>>
> Hello and thank you for reporting this issue.
>
>> Our application using Derby 10.4 (in embedded mode) has a background
>> process
>> that runs the SYSCS_UTIL.SYSCS_COMPRESS_TABLE procedure periodically. We
>> have been reported the following error while this procedure is being
>> executed and a SELECT statement came in at the same time:
>>
>>        com.linoma.dpa.dao.DAOException: The conglomerate (71,409)
>> requested does
>> not exist.
>>
>>
> Mike just fixed a corruption issue related to inplace compress,
> https://issues.apache.org/jira/browse/DERBY-4239  but my understanding is
> that it should not be an issue with offline compress and also I would expect
> your database to be unbootable even after you completely shutdown your
> application and Derby.    Can you
> 1) Post the full nested stack trace from the derby.log.
> 2) Run a consistency check on your database.
> http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
> 4) Tell us the isolation level of your select statement.
> 3)   Modify the reproduction attached to DERBY-4239
> https://issues.apache.org/jira/secure/attachment/12408948/reproBackgroundCheckpoint.zip
> to use SYCS_UTIL.SYSCS_COMPRESS_TABLE and see if you can reproduce your
> issue.  You might need to modify it to add in a select.
>
>
> Thanks
>
> Kathey
>
>

Mime
View raw message