You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by BEK1976 <br...@gmail.com> on 2010/12/10 16:35:56 UTC
Error XSDBB When Trying to Access DB From Windows, But Works In
UNIX
Hi,
I'm trying to debug a strange error that just started occurring recently.
This past weekend, our Derby database began reporting error XSLA7 (Cannot
redo operation null in the log) and XSDBB (Unknown Page Format) when we try
to access data from the DB using a MATLAB GUI front-end tool that calls into
our internally-developed DB table utilities. When we run our actual
application, which runs on IBM AIX using the same database table utilities,
the database works fine.
Note that these MATLAB developed tools have been working fine for quite some
time, and the errors seem to correlate to database size. When we add enough
data to this one particular table to push one of the internal derby files
over 2 GB, that's when the error starts occurring. It's also worth noting
is that we are running AIX on 64-bit machines, and we are running Windows on
32 bit machines. Is there a known compatibility issue with Derby with
respect to populating a database in a 64 bit environment and then accessing
it in a 32 bit environment?
As another test, I tried connecting to the database via a portion of our
application code in Eclipse, bypassing the MATLAB tools. We again get the
error when trying to query the database.
This problem first began occurring under Derby 10.5.1. However, after
seeing this Derby error report
(https://issues.apache.org/jira/browse/DERBY-4239), which exactly matched
our errors, I upgraded to Derby 10.5.3 and reverted back to a version of the
database that did not exhibit the problem. Unfortunately, that did not seem
to help -- once the DB got larger once again, we got the mostly the same
errors. (I no longer get XSLA7, but still get XSDBB with the all-zeros hex
dump.)
Any help would be most appreciated!
Thanks,
-Brian
--
View this message in context: http://old.nabble.com/Error-XSDBB-When-Trying-to-Access-DB-From-Windows%2C-But-Works-In-UNIX-tp30427203p30427203.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: Error XSDBB When Trying to Access DB From Windows, But Works In
UNIX
Posted by BEK1976 <br...@gmail.com>.
I'd thought of that myself, and should have mentioned it. :) Windows
machine is using NTFS, and max file size is much larger than 2GB. (16 TB,
if a quick wikipedia check is to believed...)
-Brian
Kristian Waagan-2 wrote:
>
> On 10.12.10 16:35, BEK1976 wrote:
>> Hi,
>>
>
> Hi,
>
> What I'm asking may very well be a red herring, but it would be nice to
> get it confirmed anyway.
> What's the underlying file system on the Windows machine, and what's the
> maximum allowed file size for that file system?
>
>
> Regards,
> --
> Kristian
>
>> I'm trying to debug a strange error that just started occurring recently.
>> This past weekend, our Derby database began reporting error XSLA7 (Cannot
>> redo operation null in the log) and XSDBB (Unknown Page Format) when we
>> try
>> to access data from the DB using a MATLAB GUI front-end tool that calls
>> into
>> our internally-developed DB table utilities. When we run our actual
>> application, which runs on IBM AIX using the same database table
>> utilities,
>> the database works fine.
>>
>> Note that these MATLAB developed tools have been working fine for quite
>> some
>> time, and the errors seem to correlate to database size. When we add
>> enough
>> data to this one particular table to push one of the internal derby files
>> over 2 GB, that's when the error starts occurring. It's also worth
>> noting
>> is that we are running AIX on 64-bit machines, and we are running Windows
>> on
>> 32 bit machines. Is there a known compatibility issue with Derby with
>> respect to populating a database in a 64 bit environment and then
>> accessing
>> it in a 32 bit environment?
>>
>> As another test, I tried connecting to the database via a portion of our
>> application code in Eclipse, bypassing the MATLAB tools. We again get
>> the
>> error when trying to query the database.
>>
>> This problem first began occurring under Derby 10.5.1. However, after
>> seeing this Derby error report
>> (https://issues.apache.org/jira/browse/DERBY-4239), which exactly matched
>> our errors, I upgraded to Derby 10.5.3 and reverted back to a version of
>> the
>> database that did not exhibit the problem. Unfortunately, that did not
>> seem
>> to help -- once the DB got larger once again, we got the mostly the same
>> errors. (I no longer get XSLA7, but still get XSDBB with the all-zeros
>> hex
>> dump.)
>>
>> Any help would be most appreciated!
>> Thanks,
>> -Brian
>
>
>
--
View this message in context: http://old.nabble.com/Error-XSDBB-When-Trying-to-Access-DB-From-Windows%2C-But-Works-In-UNIX-tp30427203p30427479.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: Error XSDBB When Trying to Access DB From Windows, But Works
In UNIX
Posted by Kristian Waagan <kr...@oracle.com>.
On 10.12.10 16:35, BEK1976 wrote:
> Hi,
>
Hi,
What I'm asking may very well be a red herring, but it would be nice to
get it confirmed anyway.
What's the underlying file system on the Windows machine, and what's the
maximum allowed file size for that file system?
Regards,
--
Kristian
> I'm trying to debug a strange error that just started occurring recently.
> This past weekend, our Derby database began reporting error XSLA7 (Cannot
> redo operation null in the log) and XSDBB (Unknown Page Format) when we try
> to access data from the DB using a MATLAB GUI front-end tool that calls into
> our internally-developed DB table utilities. When we run our actual
> application, which runs on IBM AIX using the same database table utilities,
> the database works fine.
>
> Note that these MATLAB developed tools have been working fine for quite some
> time, and the errors seem to correlate to database size. When we add enough
> data to this one particular table to push one of the internal derby files
> over 2 GB, that's when the error starts occurring. It's also worth noting
> is that we are running AIX on 64-bit machines, and we are running Windows on
> 32 bit machines. Is there a known compatibility issue with Derby with
> respect to populating a database in a 64 bit environment and then accessing
> it in a 32 bit environment?
>
> As another test, I tried connecting to the database via a portion of our
> application code in Eclipse, bypassing the MATLAB tools. We again get the
> error when trying to query the database.
>
> This problem first began occurring under Derby 10.5.1. However, after
> seeing this Derby error report
> (https://issues.apache.org/jira/browse/DERBY-4239), which exactly matched
> our errors, I upgraded to Derby 10.5.3 and reverted back to a version of the
> database that did not exhibit the problem. Unfortunately, that did not seem
> to help -- once the DB got larger once again, we got the mostly the same
> errors. (I no longer get XSLA7, but still get XSDBB with the all-zeros hex
> dump.)
>
> Any help would be most appreciated!
> Thanks,
> -Brian
Re: Error XSDBB When Trying to Access DB From Windows, But Works
In UNIX
Posted by Bryan Pendleton <bp...@gmail.com>.
> I'm trying to debug a strange error that just started occurring recently.
I think you've done a great job trying to identify the causes and triggers
of this problem.
I think you should open a new JIRA issue and start working directly with the
Derby developers. It seems possible that you are experiencing DERBY-4239,
but it may also be that you've encountered something completely new which
just happens to have the same symptoms.
To clarify a bit:
- accessing the DB using AIX & 64-bit JVM: works fine
- accessing the DB using Windows & 32-bit JVM: XSLA7 and XSDBB errors
- restored the DB then re-accessed it: XSDBB errors, but not XSLA7 errors.
Am I understanding correctly?
Are the two JVM implementations identical (in version and vendor) other than
the 32-bit vs. 64-bit issue? Can you state exactly which Java environment(s)
you are using?
Is it the same exact database in these two environments? Is it mounted on
some sort of share-able file system? Or are you transporting it between
environments? If you are transporting it, what process do you use to do that?
> our errors, I upgraded to Derby 10.5.3 and reverted back to a version of the
> database that did not exhibit the problem. Unfortunately, that did not seem
> to help
Perhaps the reverting-back isn't really restoring your database to a state
of complete health. That is, perhaps in the reverted-back state, even though
the problem doesn't exhibit, perhaps the database is still damaged, but in
some way that doesn't show the symptoms until the database grows.
In your JIRA entry, I recommend that you ask the developers if there are any
tools that you can use to verify *for sure* that the reverted-back copy of
the database is clean and healthy.
Alternatively, you could try taking the reverted-back copy, and doing an
export-import step to completely unload your data and load it into a fresh
clean copy of the database created under Derby 10.5.3, at which point you should
be more confident that the DERBY-4239 problem is not present in your database.
Then if the problem still occurs at that point, that would be yet another
useful data point.
I'm sorry to hear that you're having these problems, but it sounds like you've
really got things narrowed down well, so hopefully you will be able to get
a quick resolution of your problem from the developer community.
thanks,
bryan