Re: ** latest stable oracle 10G client

Dan Norris wrote,on my timestamp of 8/02/2009 3:52 PM:




I disagree. The product was released at 11.1.0.6 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@xxxxxxxxxxxx
--
http://www.freelists.org/webpage/oracle-l


Other related posts: