Re: Performens - empty blocks, 7.1 Unix

From: Peter H. Larsen <petlars_at_ibm.net>
Date: 1996/06/19
Message-ID: <4q9qtn$q30_at_news-s01.ny.us.ibm.net>#1/1


In <4q7a2k$o25_at_thymaster.interaccess.com>, akaplan_at_interaccess.com (Ari Kaplan) writes:

>I have had the same symptoms myself (both Oracle 7.0.16 and 7.1.3).
Are they gone in later versions?

>You are correct in that the internal pointers indicate a table at its largest
>state in its history.
Well - that might be so, but in my child years of computer resolvement, I learned how to manage large amounts of data-space in a very easy/fast way: To implement to points: one for next free space, and one for first USED dataspace. It seems to me, that somehow the later is not implemented internal in Oracle?

And if the above is true, why does Oracle not process halv-empty blocks it creates by the default PCT_USAGE of 40 percent? Anyway, I know that deleting records does not actually delete the data itself, but only mark it as deleted, for later resuage (old Oracle technology), but that shouldn't be true when performing a rollback after inserting approx 70,000 records into a empty table, and STILL having performensproblems ? A rollback should restore the old blocks from the rollback segments? As as no data was allocated BEFORE the insertion, no blocks should be left in the database? I must admit, I havn't checked that out right now - because eventhough I've been a Consultant with DBA and Development of Oracle since 1989, I'm in a present position, where I do not have ANY DBA privilegde or access on the database I'm working on, so I do it little by little after teaching the DBA how to do it on HIS terminal :) But please confirm (or visa versa): A rollback does not leave any allocated EMPTY blocks after rolling back on large inserts?

>In your INSERT statement, if you have a constraint that needs to check
>the table for integrity reasons, it might be scanning the empty
>blocks, explaining the longer times you have been getting.
Well - a unique index (primary key) seems to do that :) And that might be the problem - not the dataspace, but unallocated INDEX space ???

>Best of luck!

Thx. I you have additional information, I'll gladly accept it.


Peter H. Larsen             Email: Petlars_at_ibm.net
Complete Data Service       Fidonet: 2:235/134.0

Happy Computing Received on Wed Jun 19 1996 - 00:00:00 CEST

Original text of this message