it's all in the buzzwords, obviously :)
- "Deshpande, Kirti" <kirti.deshpande_at_verizon.com> wrote:
> We were asked, not too long ago, to create one Oracle8i database with
> only
> *one* table with some 700+ columns. While at it, the consultant
> (hired by
> end user dept) also suggested that we make it an IOT using an LMT,
> and since
> the table will never grow over 1GB, asked if there was a way to put
> it in
> KEEP buffer pool. He was helping re-write/enhance some MS Access
> Apps.
>
> Talk about knowing all the right lingo... ;)
>
> - Kirti
>
> -----Original Message-----
> Sent: Friday, October 11, 2002 8:59 AM
> To: Multiple recipients of list ORACLE-L
>
>
> April,
>
> What can I say? Ouch! I feel your pain. I've been trapped in some
> pretty ridiculous situations too. (Though, I think you have me beat!
> A
> 37 column primary key?? Really??) Well, you at least seem to have
> the
> proper attitude. ;-) Without a sense of humor, I'm afraid you'd go
> insane in short order! ;-)
>
> The only other thing I can think of when people shut you down like
> that
> is: document. "At meeting X, on such and such a date, I identified
> this
> problem, and Mr. Z told me to not to worry about it." It may not
> help,
> but from a sanity point of view, there is a certain amount of
> satisfaction in "I told you so!", even if you never verbalize
> it....;-)
>
> Hang in there,
>
> -Mark
>
> On Fri, 2002-10-11 at 08:43, April Wells wrote:
> > Mark...
> >
> > If this were the MOST serious design flaw in the whole mess, I
> wouldn't
> care
> > so much. There is a point where you just shut up (gee, I have been
> TOLD
> to
> > do that in meetings) and wait till it breaks (or worse, one of our
> clients
> > buys it and we have to TRY to implement). I am the funny one...
> the one
> to
> > laugh at and make fun of because I keep trying to tell them that
> you can't
> > do things. You can't have a totally denormalized Oracle table if
> there
> 1500
> > columns in it... yes queries will fly on a table that can't be
> built. You
> > can't have 37 columns in a primary key. Date really isn't an
> acceptable
> > name for a column.
> >
> > April Wells
> > Oracle DBA
> > Keep yourself well oiled with life, laughter, new ideas and action.
> > Otherwise you will rust out. _Anonymous
> >
> >
> > -----Original Message-----
> > Sent: Thursday, October 10, 2002 7:34 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Hi Dick,
> >
> > I have to disagree with you here. Particularly in the case where
> this
> > sequence will see any sort of concurrency, from multiple concurrent
> > sessions accessing it. This is due to the serialization on the SQ
> > enqueue. This will cause far worse scalability issues than any
> I/O.
> > Not that I/O is insignificant, but in this situation, serialization
> on
> > the enqueue will be the real showstopper for scalability.
> >
> > As to losing the cached values, well, so what? If your design is
> such
> > that it's important to have an unbroken contiguous sequence of
> numbers
> > with no gaps, then I would argue that is a serious design flaw.
> Also,
> > if that's your requirement, then a sequence is not appropriate,
> since it
> > can and will end up causing gaps, the first time you roll back a
> > transaction.
> >
> > Finally, as to sequences losing cached values, unless your instance
> > crashes or does a shutdown abort, Oracle should not loose any
> sequence
> > values.
> >
> > -Mark
> >
> >
> >
> > On Thu, 2002-10-10 at 18:18, dgoulet_at_vicr.com wrote:
> > > Actually there is no IO penalty since Oracle has to treat the
> sequence
> > just like
> > > any table with the old LRU algorithm. I have several sequences
> with a
> > cache of
> > > 0 and they perform as well as those with a cache value. The big
> > difference is
> > > when you shut down the database and all of those cached values
> end up in
> > the
> > > trash.
> > >
> > > Dick Goulet
> > >
> > > ____________________Reply Separator____________________
> > > Author: "Yechiel Adar" <adar76_at_inter.net.il>
> > > Date: 10/10/2002 1:38 PM
> > >
> > > I think that you will have an update to the sequence number EVERY
> time
> > instead
> > > of every 20 times. That's mean I/o for every nextval.
> > >
> > > Yechiel Adar
> > > Mehish
> > > ----- Original Message -----
> > > From: Tim Gorman
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: Thursday, October 10, 2002 7:43 PM
> > > Subject: Re: sequence numbers
> > >
> > >
> > > CACHE 20 is the default, so if you remove the clause, it will
> have
> > absolutely
> > > no impact on performance or anything else...
> > >
> > > ...of course, I get the feeling that that wasn't the gist of
> your
> > question,
> > > was it?
> > > ----- Original Message -----
> > > From: April Wells
> > > To: Multiple recipients of list ORACLE-L
> > > Sent: Wednesday, October 09, 2002 8:54 AM
> > > Subject: sequence numbers
> > >
> > >
> > > I have been given create scripts for sequences to be used in
> tables
> > that
> > > will be loaded via bulk loads. How huge is the potential
> performance
> hit
> > if I
> > > take out the cache 20?
> > >
> > > April Wells
> > > Oracle DBA
> > > There is neither good nor bad, but thinking makes it so.
> -Shakespeare
> > >
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> > > <HTML><HEAD>
> > > <META content="text/html; charset=iso-8859-1"
> http-equiv=Content-Type>
> > > <META content="MSHTML 5.00.2314.1000" name=GENERATOR>
> > > <STYLE></STYLE>
> > > </HEAD>
> > > <BODY bgColor=#ffffff
> > > style="FONT: 10pt Times New Roman; MARGIN-LEFT: 2px; MARGIN-TOP:
> 2px">
> > > <DIV><FONT face=Arial size=3>I think that you will have an update
> to the
>
> > > sequence number EVERY time instead of every 20 times. That's mean
> I/o
> for
> > every
> > > nextval.</FONT></DIV>
> > > <DIV> </DIV>
> > > <DIV>Yechiel Adar<BR>Mehish</DIV>
> > > <BLOCKQUOTE dir=ltr
> > > style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px;
> MARGIN-RIGHT:
> > 0px;
>
=== message truncated ===
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
Received on Fri Oct 11 2002 - 10:19:55 CDT
