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 <[email protected]> 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.
>> 
> 
> 


Reply via email to