Re: Re: Little competition

Ive been working on 'large' distributed databases lately and its not as high as alot of arrogant people make it out to be. Its just different. Im not sure tuning a database with alot of data and fewer transactions like in a datawarehouse necessarily 'harder' than tuning a higher transaction database with less data. You just look for different things.

I really dont care that much about LIOs for my batch loads since Im not going to scale it, Im just worried about response time. I routinely let my LIOs go up alot to increase response time. Is that harder than trying to get LIOs down in a database with less data? No its just different. Its not that different... same basic principles.

I think defining high end databases should have more to do with what you are doing with them, then how much data is in them. The biggest thing about working on database in the multi-TB range is that its a nice buzzword for your resume. Its not necessarily harder.

Besides, when your on a 'lower' end project with less resources and less people, Id argue that alot of times your job is alot harder. You dont have the same hardware and you have to do alot more different things yourself. Though it doesnt look as good on a resume...

Maybe Carrie Milsap can chime in since he is the resident tuner expert here? Do you necessarily find it harder to tune large databases over smaller ones?
>
> From: Jonathan Gennick <jonathan_at_gennick.com>
> Date: 2003/12/11 Thu AM 08:24:34 EST
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: Re: Little competition
>
> Thursday, December 11, 2003, 6:39:26 AM, Richard Foote (richard.foote_at_bigpond.com) wrote:
> RF> a.. What's wrong with the following piece of expert analysis ?
>
> I don't know what's wrong with this "analysis". There's not
> much really there. The claim is that it's bad not to be able
> to specify PCTFREE, but there's no real backup to that
> claim, no testing to prove the point, etc.
>
> Not sure I want to admit this publicly, but I don't recall
> ever needing to use PCTFREE. I know what it does, and I've
> played around with it a bit, but in production I always got
> along just fine with the default setting. I told this to a
> data warehousing person recently, and he was aghast, as he
> (apparently) uses PCTFREE often. But I have not worked on
> such huge databases, and maybe that's why I've never needed it.
>
> Bringing this back to automatic space management, it's my
> opinion that such features are targeted towards the "low
> end" (for lack of a better term, sorry) in which defaults
> work just fine. I'd guess that there's a class of databases
> for which the default PCTFREE setting is good-enough, and
> for which the automatic space management feature is
> good-enough, and for which automatic extent management is
> good-enough, etc. One of the things I've wondered about
> lately, is how to characterize the sort of database for
> which all the automatic features and the defaults are fine.
>
> Related to all this, as complicated as Oracle *can* be, I'm
> close to convinced that it's possible to define a greatly
> simplified database management regime. Work within a certain
> box, and you can ignore much of the complexity. I can even
> envision a user-manual targeted specifically at that box.
> Such a manual, for example, would show a simplified version
> of CREATE TABLE that omitted such things as PCTFREE,
> PCTUSED, etc. I haven't quite figured out yet how to define
> that box and how to characterize the sort of environment to
> which it applies.
>
> I once worked for a client who had a 5-10 gigabyte database
> with in the neighborhood of a dozen users. What they needed
> to know about managing Oracle would have fit into a really
> small book.
>
> Oracle is on to something with all the automatic features,
> but they need to present that feature set differently. Right
> now you get a database, you get told it can do all these
> automatic things (space mgmt, extent mgmt, SGA mgmt), but
> then you get pointed to this HUGE manual set that you need
> to wade through before you can begin to understand the
> automatic features. Maybe I'm wrong here, but I don't
> believe Oracle has put together the simplified DBA manual
> yet, and perhaps maybe they should. What do you think?
> Should Oracle define the box and write a manual for
> customers who want to live within that box?
>
> Best regards,
>
> Jonathan Gennick --- Brighten the corner where you are
> http://Gennick.com * 906.387.1698 * mailto:jonathan@gennick.com
>
> Join the Oracle-article list and receive one
> article on Oracle technologies per month by
> email. To join, visit http://four.pairlist.net/mailman/listinfo/oracle-article,
> or send email to Oracle-article-request_at_gennick.com and
> include the word "subscribe" in either the subject or body.
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Jonathan Gennick
> INET: jonathan_at_gennick.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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <ryan_oracle_at_cox.net
  INET: ryan_oracle_at_cox.net

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).