db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject Re: I need help on getting Derby to use a primary key index on a query
Date Sat, 24 Aug 2013 12:00:00 GMT
Derby developers (Mike, Manta, Bryan, Rick ,Knut, and if I forgot anyone that has help me in
the past), I just want to thank you for your help!   I realize that you guys have day jobs
just like me an taking the time out to give me some pointers is really appreciated!

I am trying to produce reduced size and readily reproducible case but would you knot know
it, the symptoms change :(   I saved a database that was working with 10.8.2.2 with (after
shutting down) tar cvEf - db | compress >db.8.tar.Z earlier.   So just to verify again
that this did indeed work correctly, I restored this database and the 10.8.2.2 libraries performed
the queue and darn if the 10.8.2.2 did not exhibit the same problem.    So then last night
I deleted the database and created it fresh again from the same exact script that allowed
10.8.2.2 to work and again it still has the same problem.

So now I have no confidence of my test setup and also don't think the issue is confined to
10.9.1.1.   So I will be quiet until I get a case where it works and then understand why and
what triggers it to not work.


On Aug 23, 2013, at 6:39 PM, mike matrigali <mikemapp1@gmail.com> wrote:

> On 8/23/2013 2:55 PM, Bergquist, Brett wrote:
>> Mike I would love to open a Jira but having a reproducible case is important as I
realize.  Right now, the reproducible database is 2Gb compressed which is really not practical
to upload.
>> 
>> My goal right now is to fix the problem.  The problem is in production, a large telecomm
company, and the real database is about 200Gb.  The database has been hard upgraded and has
been in use for about 2 weeks so rolling back to backup before the hard upgrade is not possible.
 Only going forward is possible.   So I have the debugger connected up right now and am going
through the code.  I am also comparing 10.8.2.2 version 10.9.1.0 to look for any suspicious
differences.  I have to fix this now, not months from now.
>> 
>> What would be really useful would be to:
>> 
>> 1. understand how to turn on the optimizer tracing facility that I see in the 10.9.1.0
source.  For example:
>> 
>> 		optimizerTrace = lcc.getOptimizerTrace();
>>    I can figure this out, but if anyone can point to a wiki page or some other resource
to enable the magic, sharing it will be most welcome.
> I have not used the following but have been pointed at it by those who do:
> http://wiki.apache.org/db-derby/OptimizerTracing
>> 
>> 2. understand if it would be possible to access my test database that has been hard
upgraded to 10.9.1.0 with 10.8.2.2.  I know that when I boot the database it will complain
and not boot but if I am just doing a read-only query on the database with 10.8.2.2 and the
query works, this will give me real confidence that the problem is in the code changes from
10.8.2.2 to 10.9.1.1 and not something related to the structure now stored in the database.
>> 
>> So I am working on this, am looking for pointers of where to look in the code, and
will open a Jira also supply a patch when I have this fixed.
> 
> this one is hard, definitely nothing is supported to to do this, and no 
> magic property is coming to mind.  If it does not take days to load your
> test db, I would just build a 10.8 db and load it.
> 
> Mostly catalog issues are what happen in hard upgrade, so doing a query
> with old code on a new hard upgrade db "probably" works.  But even 
> booting might write stuff that would then be a problem using it later,
> even if your intent is only to run read-only queries.
> 
> You could build your own 10.8 and just change the code to skip the 
> checks that don't allow it to boot.  This might work or it might corrupt
> the db during the boot process.  If you are trying this I would make
> a copy of the test db to try i on.
>> 
> 
> 



Mime
View raw message