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
> ---------------------------------------------------------------------
> 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).
>
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 - 07:04:05 CST
