I've had one too many experiences with "but the environment is EXACTLY
the same" only to find out that it isn't.
- Freeman Robert - IL <FREEMANR_at_tusc.com> wrote:
> Oooooohhhh, that *IS* a good one.... May need to add that to the list
> somewhere somehow.
>
> RF
>
> Robert G. Freeman
> Technical Management Consultant
> TUSC - The Oracle Experts www.tusc.com
> 904.708.5076 Cell (It's everywhere that I am!)
> Author of several books you can find on Amazon.com!
>
>
> -----Original Message-----
> Sent: Monday, February 24, 2003 7:04 AM
> To: Multiple recipients of list ORACLE-L
>
>
> You brought to mind another one... DON'T assume that changes in one
> environment will have the same impact across all environments so DO
> test the impact of any change in all environments that you can,
> before
> implementing it in production. We had a change go in to the dev
> environment that fixed the performance problem there. Unfortunately,
> it
> made performance fall through the floor in test, which was closer to
> the production environment in data volume. Fortunately it was caught
> before it went into production.
>
>
> --- Cary Millsap <cary.millsap_at_hotsos.com> wrote:
> > You guys are very kind, thank you.
> >
> > My "LIO vs PIO" thesis is this:
> >
> > 1. Too many PIOs *is* a bad thing.
> > 2. But eliminating unnecessary PIOs isn't enough. Even completely
> > memory-resident databases can perform horribly (not scale, consume
> > dozens of hours per query, etc.)
> > 3. If you begin by eliminating unnecessary LIOs first, then you
> often
> > eliminate all the PIOs you needed to eliminate, by side-effect.
> >
> > About the Top-10 list, I'll add...
> >
> > DON'T "do something to make the system faster" until you understand
> > the
> > impact that your proposed activity will have upon the response time
> > of
> > your important user actions. (Some proposed activities create
> > negligible
> > impact, and some even create negative impact. When you try those
> > activities that don't create sufficient *positive* impact, then you
> > *waste* your company's resources.)
> >
> > DO learn how to figure out--quickly, accurately, and
> > inexpensively--the
> > impact of a proposed activity upon end-user response time.
> >
> >
> > Cary Millsap
> > Hotsos Enterprises, Ltd.
> > http://www.hotsos.com
> >
> > Upcoming events:
> > - RMOUG Training Days 2003, Mar 5-6 Denver
> > - Hotsos Clinic 101, Mar 25-27 London
> >
> >
> > -----Original Message-----
> > Landrum
> > Sent: Sunday, February 23, 2003 5:49 PM
> > To: Multiple recipients of list ORACLE-L
> >
> > Yes, regarding these 3, how can they be considered absolute do's or
> > don'ts?
> > I didn't take Cary's material to mean ignore physical IO's but
> rather
> > to
> > show the importance and impact of logical IO's. Too many PIOs
> could
> > still be an issue.
> > (I would say maybe Cary could speak to this, but I'd rather him
> spend
> > that time on his book, which I'll be ordering as soon as it's
> > available.)
> > The others have their places as well. I wouldn't practice or
> preach
> > that bind variables are always, always the right way (usually, but
> > not
> > always).
> > Why not ASSM? Surely, there could be circumstances where ASSM is a
> > good
> > way, or at least ok.
> > Do Use Bind Variables
> > Do tune to Reduce Logical IO's Not Physical IO's.
> > Don't Use ASSM
> >
> > Please consider, Robert, that I'm not challenging your list as
> these
> > may
> > be very good rules to live by. I don't usually take any 'rule' as
> > hard
> > and fast until I can test it, but there may be others reading the
> > list
> > that would benefit greatly to understand why these things should or
> > should not be done.
> > Thanks for your input, it helps us all learn.
> >
> > Darrell Landrum
> >
> >
> >
> > >>> FREEMANR_at_tusc.com 02/23/03 04:23PM >>>
> > Here is the list of top 10 do's and don't that I came up with.
> >
> > #1 - Do Maintain your Expertise
> > #2 - Do Use the DBMS_STATS Package to Collect Statistics
> > #3 - Do Use Bind Variables
> > #4 - Do Put your Production Database in ARCHIVELOG Mode
> > #5 - Do Use Locally Managed Tablespaces
> > #6 - Do Monitor Your Database
> > #7 - Do Practice Recoveries
> > #8 - Do Get Involved with User Groups and Other Resources
> > #9 - Do Establish Standards and Change Control Processes
> > #10 - Do Think Ahead
> >
> > Bonus! - Do tune to Reduce Logical IO's Not Physical IO's.
> > (With regards to Cary!)
> >
> > Oracle Database Top 10 Don'ts
> > #1 - Don't Waste Time Re-Organizing Your Databases
> > #2 - Don't Use .Log or Other Common Extensions For Your Database
> File
> > Names
> > #3 - Don't Leave Your Database Open To Attack
> > #4 - Don't Decide Against Hot Backups
> > #5 - Don't Use ASSM
> > #6 - Don't Forget the 80/20 Rule
> > #7 - Don't Stack Views
> > #8 - Don't Be a Normalization Bigot
> > #9 - Don't Forget to Document Everything
> > #10 - Do Not Use Products You are Not Licensed For.
> >
> > Bonus!! - Do Not Assume A Good or Bad Hit Ratio Means Anything
> >
> > Ok, anyone wanna comment?
> >
> >
> > Robert G. Freeman
> > Technical Management Consultant
> > TUSC - The Oracle Experts www.tusc.com
> > 904.708.5076 Cell (It's everywhere that I am!)
> > Author of several books you can find on Amazon.com!
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Freeman Robert - IL
> > INET: FREEMANR_at_tusc.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: Darrell Landrum
> > INET: dlandrum_at_zalecorp.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: Cary Millsap
> > INET: cary.millsap_at_hotsos.com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting
> services
>
=== message truncated ===
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
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 Mon Feb 24 2003 - 12:54:30 CST
