| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re[2]: Re[2]:Upgrading Oracle
Yup, I'm singin' the same blues. I find that usually these things work =
GREAT in the vendor's teeny-tiny test database. It continually amazes =
them how performance can degrade when you put the thing into an actual =
customer's environment.
Jim
>>> carmichr_at_hotmail.com 10/25/00 11:20AM >>>
My developers I can control -- and they listen to me! It's an outside=20
product that I have no ability to change but will become responsible =
for....=20
so I get hit for someone else's problems....
good thing I live in NY, I'm used to abuse :)
>From: "Weaver, Walt" <wweaver_at_rightnow.com>
>Reply-To: ORACLE-L_at_fatcity.com=20
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: Re[2]: Re[2]:Upgrading Oracle
>Date: Wed, 25 Oct 2000 06:55:24 -0800
>
>FWIW, don't feel like the Lone Ranger, Rachel. I'm fighting the same =
battle
>here with our developers...
>
>--Walt Weaver
> Bozeman, Montana, USA
>
>-----Original Message-----
>Sent: Tuesday, October 24, 2000 10:06 PM
>To: Multiple recipients of list ORACLE-L
>
>
>
>oh that was minor compared to today's rant... a third party product that
>denormalizes tables because their "experts" told them that if you have =
more
>than 4 tables in a join performance suffers significantly.
>
>So instead of a parent table with a child table that contains one row for
>each option selected, I have ONE table with a column for every possible
>option, and a Y/N switch for each one. AND just to make it even more
>interesting, if you want to add a new option, the product automatically=20=
>adds
>
>a new column to the table. We expect to have something like 5-15 million
>rows in that table. And we will do selections for mass emails based on =
each
>of those columns. Which I can't index, so we will do multiple full table
>scans on a table way too large to pin into the buffer pool.
>
>I managed not to foam at the mouth. And made sure that EVERYONE in that
>meeting knew that I thought that this design was going to cause us major
>performance problems that I could not necessarily do DBA magic to remove.
>Sigh......
>
>Rachel
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com=20
>--
>Author: Weaver, Walt
> INET: wweaver_at_rightnow.com=20
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
Share information about yourself, create your own public profile at=20 http://profiles.msn.com.
--=20
Please see the official ORACLE-L FAQ: http://www.orafaq.com=20
--=20
Author: Rachel Carmichael
INET: carmichr_at_hotmail.com=20
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists --------------------------------------------------------------------To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may Received on Wed Oct 25 2000 - 10:32:25 CDT
 |
 |