Re: Quality of response to TARs

You got a lot of responses to this one. That's because support has gone downhill over the past year as Oracle has tried to force everyone on to Metalink. Once everyone is on Metalink, it can be moved completely offshore at a significant savings for Oracle. My favorite is when you post a problem, an analyst gives a bad answer and then marks the posting closed. At that point your only recourse is to open another post and wait another 24 hours for another bad answer.

Van

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message news:987586080.14922.0.nnrp-02.9e984b29_at_news.demon.co.uk...
>
>
> How bad does Oracle support get when you raise a TAR -
> I have a client running 8.0.5 on Solaris, they upgraded
> to 8.1.6 after spending a lot of time and effort running
> a series of regression tests, checking software compatibility
> etc. 48 hours after upgrading we had to downgrade because
> of the catastrophic performance impact of a bug we had managed
> to miss in testing. (Non-elimination of partitions when
> running parallel query against partitioned tables - 1700705)
>
> Unfortunately, we then discovered a pretty annoying bug
> in 8.0.5 as a new series of reports came on-line: non-
> elimination of partitions when running parallel query,
> surprisingly enough: The biggest surprise with this was
> that the SQL read:
>
> where partitioning_column between 200101 and 200113
>
> clearly identifying 13 partitions out of 173 on the
> completely identified partitioning key, passed in as
> a literal constant !!!
>
> To date I have had a suggestion that we replace the
> partitioned table with a partitioned view that is
> a UNION ALL of all partitions named explicitly -
> you remember partition views, the deprecated feature
> replaced by the far superior partitioned table. It
> doesn't matter, of course that this requires an
> infrastructure change, regression testing, etc. to
> handle a rolling history. It is an improvement,
> the query only runs 5 times as slowly as it should,
> rather than 40 times as slowly.
>
> I have sent in a simple, reproducible test case -
> the first problem with that was that I sent in
> a listing from v$parameter when the analyst had
> asked for the init.ora file. The second problem
> was that I has used the in-house wrapper for
> dbms_sql to generate data using dynamic SQL, the
> analyst was unable to replace this with a call
> to dbms_sql.
>
> I also sent in a 10053 trace from the production
> system to highlight the arithmetic that the CBO
> was doing. This confused the analyst because the
> table-names it mentioned were different from the
> table-names used in the test case.
>
> I pointed out that his suggestion to put in a
> first_rows hint didn't work, and also pointed
> out that I could not set the optimiser mode to
> first_rows at the session or database level
> because of other considerations: the analyst
> suggest therefore that I change the optimiser_mode
> in the init.ora !!
>
> At one point, after some pressure, the analyst
> was persuaded to try the test case, and seemed
> to think that 'set autotrace on' - which does
> not reflect partition start and stop values,
> and only the first few characters of the SQL
> sent to the PX slaves. When pressed to do a
> full explain plan, the analyst seemed to think
> that the following was a 'full' plan for a parallel
> query running against a partitioned table.
>
> 0 SELECT STATEMENTCost=10701479128
> 1 SORT
> 2 NESTED LOOPS
> 3 TABLE ACCESS WEEKS1
> 4 TABLE ACCESS BIG_PT1
>
>
> I now have a new analyst on the job who, in consultation
> with his team leader, tells me I have to upgrade to 8.0.6.3
> in case this fixes the problem, is refusing to run the
> test case on an 8.0.6 database on the basis that it is
> the client's responsibility to run a test system.
>
> We ARE running test and development systems - on 8.1.6.
> Oracle Corp. is telling us we have to downgrade our test
> and development systems to a version that will soon be
> desupported because they are either too lazy, too arrogant,
> or too incompetent to run a simple test case.
>
> How do you save $1,000,000,000 per year ? Lay off as
> many of the expensive, competent people, and let the
> clients sort out their own problems.
>
>
> Apologies for ranting - I've got a test case which took
> me 30 minutes to construct, 3 minutes to run - and I've
> had Oracle support wasting my time for days in efforts
> to avoid addressing the issue.
>
>
>
>
> --
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> Practical Oracle 8i: Building Efficient Databases
> Publishers: Addison-Wesley
>
> Reviews at: http://www.jlcomp.demon.co.uk/book_rev.html
>
>
>
>
>
Received on Wed Apr 18 2001 - 20:00:34 CDT