Re: ** latest stable oracle 10G client
Date: Mon, 09 Feb 2009 00:12:13 +1100
Dan Norris wrote,on my timestamp of 8/02/2009 3:52 PM:
> I disagree. The product was released at 188.8.131.52 18 months ago and has
> had one patchset since then. To me, that indicates that they vetted the
> beta releases well and issued several patchsets before FCS (I was part
> of that beta--the testing was pretty extensive IMO).
Or there are simply not enough production sites out there yet to truly pan out how bad/good it is.
> The same vendors didn't support 10g R2 for a very long time after it was
> available IIRC, so I don't necessarily base my trust in a release on how
> fast vendors like SAP and others support the release.
Well, I do. Given that ALL my databases run third party applications and not ONE of those yet supports 11g, it's gonna be a while before 11g in any release disguise sees the light of day in production with us.
> Maybe you'll think I've been drinking too much of the kool aid, but I
> have met some very conscientious Oracle developers and product managers
> that truly want to make the product solid before it heads out the door.
That is completely irrelevant. I've been hearing about the great and dedicated developers since release 6. No change. No disrespect, but what do I care how great they are and how many unasked for bells and whistles they can cram into the database? What I asked for was very clear: less bugs. Didn't get it ONCE, in the last 10 years.
> I think it's a pretty large generalization to say that "Oracle doesn't
> give a hoot..." I'm sure some decisions are made to ship it without
> fixing certain issues (no doubt to be fixed "later") in the interest of
> meeting a release schedule. After all, anyone that has been involved
> with any product, especially software, knows that you'll never release a
> perfect product.
Sorry: that is no justification for the egregious bugs still in 10g - and 11g! - that haven't been fixed since 8i. Of course no product is perfect. But when a product is buggy for 10 years, on the SAME features, it's just plain slackness and incredibly irresponsible bug management.
> Heck: you need 10.2.0.3 to get stable support for ASSM which has
> been out since 8i and even then you MUST still install a patch,
> and you want folks to merrily upgrade to 11g?
> Yeah, right: like, it's gonna happen...
> If it's fixed in 10.2.0.3, then it would have had plenty of time to be
> included in 11g. Both sides of this issue have technical merit. However,
Bzzzt, wrong. It's NOT fixed in 10.2.0.3. Like I said very clearly: it NEEDS a patch. And so does 11g for exactly the same problem! The release that was supposed to be perfect and have all the fixes.
This is a feature that first came out in 8i and it STILL is not stable, after all these years. What a sad joke!
And like that one I could cite heaps more, to do with optimizer, LOB support, etcetc.
Heck, in 9i we even had tables being updated in the WRONG schema when using auto-SGA sizing! I haven't chased it recently but I'd bet it's still there in 10 and likely 11g. Talk about slack!
New features might be very nice and dandy for those who can afford the time and resources to play. Unfortunately, that is not what I and a lot of others get paid to do.
For those of us who actually have to run things at the coal face with ever diminishing budgets, and continue to find the same old same old bugs, again and again, 11g is just another sad joke in a long string.
But don't let the "old cynic", convince you. Just ask yourself the question: why is it that 6, 7 and 8 were adopted in a jiffy and 11g 18 months later is in production in a vast *minority* of sites?
Ah yes: because the "bad dbas" like me are against it
and "don't want to learn new features".
That one is getting soooooo old...
> However, I wonder when you and others that share your view would
> consider it "safe" or at least tolerable to consider using 11g as their
> version of choice.
When we see the apps we run support it.
Until then, whatever Oracle might yap about 11g's features is completely irrelevant.
We run applications in production. Not database features.
If a database release breaks our applications, the release gets thrown out. Simple as that. Far from our first priority.
> If you think I'm being reckless by advising customers to use 11g, help
> me understand how 10g R2 is better for them. For the sake of discussion,
> let's assume that they test their brand new, custom application on both
> releases without encountering any oops in the DB and performance is
> comparable. Should they still avoid 11g?
What you have to understand Dan, is that "testing an application with a new release of db" costs lots of money. There is the hardware to do so, the logistics of slotting it in with other work, the need for external consultants to come in and help test for those who don't have in-house development, etcetc. The last upgrade we did under that umbrella cost us well over 250 grand. That was just ONE application!
Now: I just paid a motza for Oracle and *I* have to test the blessed thing as well at my own cost?
And convince my management to spend another fortune for every single point release?
Simply because a bunch of developers inside Oracle got code-happy with unasked features and want *us* to beta-test their product?
Instead of fixing the darn bugs once and for all - what everyone has been asking for nearly 10 years?
NO WAY it'll happen. Roll-on 11r2: another one for the never-to-be-installed file if it comes out with another bucket load of unasked for features. Is that clearer now?
-- Cheers Nuno Souto in sunny Sydney, Australia dbvision_at_iinet.net.au -- http://www.freelists.org/webpage/oracle-lReceived on Sun Feb 08 2009 - 07:12:13 CST