db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE
Date Thu, 11 Aug 2011 15:04:24 GMT
Thanks, Brett. Some comments inline...

On 8/11/11 4:12 AM, Bergquist, Brett wrote:
> Ran it again.  It took quite a bit longer with the sane jars, almost 24 hours this time.
 However, the same error is reported.  Derby.log has no stack trace either.  I ran the check
on all schemas and all tables except this one with no problem.  I will try this again just
to double check that the sane jars are absolutely used but maybe I will just write a quick
app and call the procedure without going through IJ.
Sounds like a good plan. In unraveling the exception, keep in mind the 
possibility that the original error may be chained off of the top level 
exception. The exception chaining can be a bit involved because you may 
need to follow both SQLException.getNextException() and 
Throwable.getCause().
> Any other suggestions are welcome.
>
> I am writing a utility to make a copy of the database by using dblook, syscs_util.syscs_export_table
and syscs_util.syscs_import_table procedures to create a new database with the same schema
and then export each table from one database and import the table into the new database. 
I did find a couple of problems with dblook:
>
> 1. dblook does not set an error code when exiting so there is no easy way to see if it
had a problem
> 2. dblook does not output a statement for the derby.database.classpath property.  If
the database has jars in the database then this property is probably set to access the procedures
and functions within and as such should be output by dblook.
These sound like defects to me. Would you mind filing JIRAs for these 
problems? Problem (2) seems to be part of a larger defect: dblook 
doesn't dump the values of properties stored in the database.

Thanks,
-Rick
> ________________________________________
> From: Bergquist, Brett [BBergquist@canoga.com]
> Sent: Tuesday, August 09, 2011 12:56 PM
> To: derby-dev@db.apache.org
> Subject: RE: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE
>
> I will try it with the sane jars tonight.  I am able to export all of the data in the
table using the SYSCS_UTIL.SYSCS_EXPORT_TABLE procedure.  I am also running SYSCS_UTIL.SYSCS_CHECK_TABLE
on all of the other tables right now to see if it just this one.
>
> -----Original Message-----
> From: Rick Hillegas [mailto:rick.hillegas@oracle.com]
> Sent: Tuesday, August 09, 2011 11:58 AM
> To: derby-dev@db.apache.org
> Subject: Re: Error when running SYSCS_UTIL.SYSCS_CHECK_TABLE
>
> Hi Brett,
>
> Is there anything in derby.log? If you run with the debug/sane jars, I
> would expect that derby.log would hold a complete stack trace with line
> numbers.
>
> Thanks,
> -Rick
>
> On 8/9/11 8:24 AM, Bergquist, Brett wrote:
>> Database engine is 10.8.1.2 (built from source with a patch for
>> Restricted table support) and I am running this in embedded mode.  Am
>> getting the following error:
>>
>> ERROR 38000: The exception 'java.lang.NullPointerException' was thrown
>> while evaluating an expression.
>>
>> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
>>
>> Note that this database is suspect to have corruption.  The table I am
>> trying to check has 74M rows in it and this runs for about 15 hours
>> before this gets reported.  Derby.log looks like:
>>
>> ----------------------------------------------------------------
>>
>> Thu Sep 01 12:21:29 EDT 2011:
>>
>> Booting Derby version The Apache Software Foundation - Apache Derby -
>> 10.8.1.2 - (678001): instance a816c00e-0132-25cb-8e35-00003ceac520
>>
>> on database directory
>> /opt/canoga/canogaview/glassfish/databases/csemdb  with class loader
>> sun.misc.Launcher$AppClassLoader@12360be0
>>
>> Loaded from file:/opt/canoga/canogaview/glassfish/javadb/lib/derby.jar
>>
>> java.vendor=Sun Microsystems Inc.
>>
>> java.runtime.version=1.6.0_21-b06
>>
>> user.dir=/opt/canoga/canogaview/glassfish/javadb
>>
>> derby.system.home=null
>>
>> Database Class Loader started - derby.database.classpath='CSEM.csemderby'
>>
>> ----------------------------------------------------------------
>>
>> Thu Sep 01 14:27:50 EDT 2011: Shutting down Derby engine
>>
>> ----------------------------------------------------------------
>>
>> Thu Sep 01 14:27:50 EDT 2011:
>>
>> Shutting down instance a816c00e-0132-25cb-8e35-00003ceac520 on
>> database directory /opt/canoga/canogaview/glassfish/databases/csemdb
>> with class loader sun.misc.Launcher$AppClassLoader@12360be0
>>
>> Is there anything I can turn on that would get better diagnostics of
>> where the problem is  (where the NPE is being reported)?
>>
>
>
>
>
>


Mime
View raw message