In the interests of trying to highlight Oracle related material of "questionable" merit, I would like to draw your attention to (yet another) www.DBAzine.com document. This time, it's the recently available free download "Oracle Space Management Handbook" that has caught my attention. I have as usual contacted the Series Editor, the one and only Donald K. Burleson with my concerns and I have as usual received no reply.
Within the pages of the above mentioned Handbook, you will find the following samples of "expert" advice: a.. Separate indexes from their tables to improve performance via reduced disk contention (with "classic" example) a.. Set pctincrease to 1 to coalesce fragmented tablespaces a.. Oracle guarantees that the undo entries will not be overwritten within the undo_retention period a.. A physical I/O is 10s of thousands of times slower than a memory I/O a.. Actually, a physical I/O is 14,000 times slower than a memory I/O a.. More that 1024 extents leads to performance problems with LMTs and look out for more that 5 extents generally a.. Rebuild tables that have the above numbers of extents to reduce performance problems a.. After rebuiulding a table, coalesce the tablespace a.. After a table move, a "fast" index rebuild can be used rather than a slow drop/re-create (as the invalid index is used during the rebuild) a.. Deleted space within an index is evidently not reused (with "clear" example) a.. Index access is "so fast" because deleted space is not reused a.. Any index with more than 4 extents should be rebuilt (even if using LMTs) a.. Ideally, indexes should fit into one extent a.. As deleted space is never reused, indexes must periodically be rebuilt a.. Place indexes into separate tablespaces with a uniform size that ensures no index has more than 4 extents a.. Index Row length is calculated as (sum of data length) + 1 (with the 10 byte rowid being of no consequence) a.. If the number of leaf blocks + branch blocks is less than the number of blocks in dba_segments, rebuild the index a.. Don't just rebuild indexes the once, but rebuild them twice, once in another tablespace so you can defragment the original tablespace and then re-create them again back in the original tablespace a.. Multiple block sizes should be used to improve performance, unconditionally a.. The System tablespace can (and should) have a block size different from the DB_BLOCK_SIZE a.. The size of the "Default" Pool is calculated as DB_CACHE_SIZE - (DB_RECYCLE_CACHE + DB_KEEP_CACHE) a.. ......... As remarkable as it might sound, the above recommendations are all found within the handbook, I kid you not !! Many of the articles appear to be years old (5 years + ?) with several of the chapters referring to Locally Managed Tablespaces as being relatively new. The issue of course is that all the above (and more) is utter tripe but the more unfortunate issue is that there is some good stuff in there, it's just that it's been "buried" among the rubbish. And as the handbook is obviously aimed at the newer Oracle audience (due to it's modest level of technical details), the truth and the myths become hopelessly mixed. The end result is a new bunch of Oracle folk who believe that more than 1 or 4 or 5 or 1024 extents is bad, believe indexes need to be rebuilt all the time, believe the Default pool is 1/2 it's actual size and are confused why the System TS block size can't differ from the db_block_size. With handbooks such as these still being developed, it's no wonder some of these myths never die as newbies simply don't have a fine enough sieve and fast water flow to separate the "crap" from the "gold". Good grief !! All I can do is highlight these things in the hope it might do some good and urge some of these so-called "experts" to lift their game and produce materials that actually helps to advance the level of understanding in the Oracle community, rather than complicate, confuse and confound. Hence my definition of a "real" expert ... If "experts" can't correctly calculate the size of the Default Pool, perhaps they should spend more time "reading" than "writing" !! Cheers Richard -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Richard Foote 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).
