If it's from Oracle, I would believe it, i.e., I would believe somebody did actually say that ;) But it does not make it right. Now only if management knew/believed that.
Some more from Oracle,
- Oracle writes to one log member and then the other. So you need both log members for recovery. Volunteered to help us use _allow_resetlogs_corruption when we had one intact log member. (Took a lot of effort not to tell him to read the concepts manual. Was from a Sev1 problem that happened a few years ago.)
- Increasing hit ratio, OS swap size to 3 times the OS memory and improving data proximity in an index (never really understood this one) among other bizarre ones to improve performance. This from an Oracle consultant who was called onsite by "Development Management" because we claimed the real reason was because the application was committing after every record to avoid locking issues on a table generating sequences, not to mention running 48 batch jobs on a 8CPU box with all of them committing after every record and using the table to generate keys (Cary would love this one) ;) They wanted to find "other reasons" and he conveniently ignored the real problem.
BTW, I personally don't like having a zillion extents for an object (more so when you have multiple "DBA Replacement Tools" querying dba_extents constantly and showing flashing red lights) and would expect the development team NOT to give me a deer in the headlights look when asked for table sizing info. Response most often heard is "Why do you need that. Oracle will be able to take care of it or can't Oracle take care of it or some variation thereof " What I really want to say is if you don't have any idea about your data, then please don't write any SQL. That should take care of most performance issues.
Barbara Baker wrote:
You probably think you're joking. Unfortunately . . .
We've been fighting with Oracle for several months about SEVERE performance degradation on an OpenVMS application after we upgraded the database to 8.1.7.4
One of Oracle's recommendations taken directly from our TAR just 2 weeks ago:
o Ensure tables and indexes have as few extents as possible.
sigh...
Barb
--- "Bobak, Mark" <[EMAIL PROTECTED]> wrote:
I think this subject has been done to death. We should talk about less contentious issues such as:
- The buffer cache hit ratio, your friend in expert Oracle tuning! - Rebuild your tables regularly to reduce the number of extents and improve performance! - Disk access is at least 10,000x slower than memory, to tune your database, eliminate physical I/O!
Anyone else got and good ones? ;-)
-Mark
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Denny Koovakattu INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
