10.2.0.3 not that bad, after all...
Thought I'd never be able to say this again from an Oracle patch, but 10.2.0.3 is not that bad at all, at least in the AIX environment and running Peoplesoft.
Been a while since my last post. Most of the time has been taken by a Peopletools upgrade - to 8.48.10 - that left our HR system in tatters!
Suffice to say that it broke the 10.2.0.2 optimizer in various and serious places. We had a bit of everything: data loss, queries that would never finish, plain wrong results, unable to compile SQL code, you name it!
After three patches from Oracle and well over half the functionality of the optimizer disabled thanks to a long string of "_" undocumented parameters installed at the recommendation of Oracle support, we were left with a database that absolutely didn't work well at all.
And still with major performance problems that caused us a never ending string of circular tuning - you know, you tune some sql, then that breaks another, then you fix the other and the first one breaks again? - and batch programs that simply would run fine and then go South on the next execution, only to be OK again on the very next one!
Yeah: fun and games...
To cut a long story short, a few weeks ago I decided that all this rigmarole of patching and parameter changing was just plain silly. Managed to convince the powers that be to let us try installing 10.2.0.3 - which has a bucket load of bug fixes in the problem areas we were experiencing - and see if at least we could end up with a stable system.
So, we did the usual "dirt digging" about 10.2.0.3 in Metalick and a few other choice places. Turns out the vast majority of problems with this release is with things like LOBs - we don't use them - and upgrades from 32-bit to 64-bit databases - ours have been 64-bit since day one, no problem.
And so upgrade we did. First the test and development dbs, with two weeks of extensive regression testing and a little patching and tuning here and there. Basically: we disabled the long list of non-documented parameters, patched vanilla 10.2.0.3 with two Peoplesoft recommended patches, and ran the dbua to upgrade the instances. Easy as pie, compared to the sad joke that 10.2.0.2 proved to be.
We've yet to experience any of the serious performance problems we were seeing with the previous patch level and so far only one undocumented parameter has had to be turned back on. Everything seems to be OK and performance and capacity has actually improved!
The ORA-1445 bug on ANSI joins has reared its head now - it didn't happen with 10.2.0.2 - but we can live with that one for the time being. This is where you can't reference more than 1050 or so column names in a complex SQL statement. Doesn't take long in Peoplesoft, where views on views on views are common place!...
Still: at least it's easy to workaround. Just don't use the ANSI syntax!
Been a long time since I've been able to report ANY positive news from ANY Oracle db installation, let's hope a trend has been started...
Anyways, back to real life. Been busy with some new experimentation and some new hardware: a new camera and some new lenses.
Told you folks that where I work there are some strange people going around:
:-)
This handsome fella hangs around our place now:
they are called "Royal Spoonbill". I
call this one "bartok", so there!
The Matrix was shot in Sydney, for good reason:
This couple of lovebirds was at the Floriade.
Canberra, late September:
And why I still shoot film:
simply impossible to do with a dslr, unless you want to mortgage the house and get a full frame sensor...
Lots more at my photo site
Catchyalata, folks!
Been a while since my last post. Most of the time has been taken by a Peopletools upgrade - to 8.48.10 - that left our HR system in tatters!
Suffice to say that it broke the 10.2.0.2 optimizer in various and serious places. We had a bit of everything: data loss, queries that would never finish, plain wrong results, unable to compile SQL code, you name it!
After three patches from Oracle and well over half the functionality of the optimizer disabled thanks to a long string of "_" undocumented parameters installed at the recommendation of Oracle support, we were left with a database that absolutely didn't work well at all.
And still with major performance problems that caused us a never ending string of circular tuning - you know, you tune some sql, then that breaks another, then you fix the other and the first one breaks again? - and batch programs that simply would run fine and then go South on the next execution, only to be OK again on the very next one!
Yeah: fun and games...
To cut a long story short, a few weeks ago I decided that all this rigmarole of patching and parameter changing was just plain silly. Managed to convince the powers that be to let us try installing 10.2.0.3 - which has a bucket load of bug fixes in the problem areas we were experiencing - and see if at least we could end up with a stable system.
So, we did the usual "dirt digging" about 10.2.0.3 in Metalick and a few other choice places. Turns out the vast majority of problems with this release is with things like LOBs - we don't use them - and upgrades from 32-bit to 64-bit databases - ours have been 64-bit since day one, no problem.
And so upgrade we did. First the test and development dbs, with two weeks of extensive regression testing and a little patching and tuning here and there. Basically: we disabled the long list of non-documented parameters, patched vanilla 10.2.0.3 with two Peoplesoft recommended patches, and ran the dbua to upgrade the instances. Easy as pie, compared to the sad joke that 10.2.0.2 proved to be.
We've yet to experience any of the serious performance problems we were seeing with the previous patch level and so far only one undocumented parameter has had to be turned back on. Everything seems to be OK and performance and capacity has actually improved!
The ORA-1445 bug on ANSI joins has reared its head now - it didn't happen with 10.2.0.2 - but we can live with that one for the time being. This is where you can't reference more than 1050 or so column names in a complex SQL statement. Doesn't take long in Peoplesoft, where views on views on views are common place!...
Still: at least it's easy to workaround. Just don't use the ANSI syntax!
Been a long time since I've been able to report ANY positive news from ANY Oracle db installation, let's hope a trend has been started...
Anyways, back to real life. Been busy with some new experimentation and some new hardware: a new camera and some new lenses.
Told you folks that where I work there are some strange people going around:
:-)
This handsome fella hangs around our place now:
they are called "Royal Spoonbill". I
call this one "bartok", so there!
The Matrix was shot in Sydney, for good reason:
This couple of lovebirds was at the Floriade.
Canberra, late September:
And why I still shoot film:
simply impossible to do with a dslr, unless you want to mortgage the house and get a full frame sensor...
Lots more at my photo site
Catchyalata, folks!
posted by Noons at 10/28/2007 10:31:00 pm
4 Comments:
Hey Noons,
You are a very talented Photographer . . .
Do you use Kodachrome film, or is that outdated?
Are digital cameras as good as 35mm yet?
You have inspired me to dig-out my Nikkormat!
Thanks, Don. Much appreciated.
Kodachrome? Pah!, I wish...
Kodak dropped the ball on that one years ago. It was my preferred film until about 95. Then it just got impossible to use it.
Now I use Fuji Velvia and Astia for slides and Fuji pro 160S and Reala for colour negatives.
If I need speed, then I go with Fujichrome 400X or Superia 400.
Black and White: I use Ilford XP2, Delta 400 and Kodak BW400CN.
Top end digital slrs are a match for 35mm film, IMHO. By that I mean top end pro gear and lenses, not the average dslr you see at the corner store with a kit lens. And pro gear costs a LOT. So do medium format digital backs.
That's why I stay with film: it'd cost me a minor house mortgage to retool for digital only, with no distinct advantage that I can't compensate for easily with post-processing.
Word of warning though: I use a professional scanner, not the run of the mill flatbed stuff you see advertised for a coupla hundred bucks. And I do a lot of post-processing to eliminate scanner grain and other defects. It's like everything: if one puts in the effort, the results show.
Nikkormat, eh? That's a very nice camera, by the way. Get it tuned up and calibrated before you start using it: mechanical cameras need to be re-oiled every once in a while or their shutter speed goes off. And make sure the batteries are OK and the right type or right equivalent.
I use a F2-AS and a FE2 quite often: they are still my most reliable workhorses. Both have been cleaned, lubricated and calibrated to within 1/4 stop precision: it makes a difference, believe me!
Don't eat your children!
joel:
Heh! Who is eating who?
I'm glad I'm not a bird!
Post a Comment
<< Home