See my website:
Index of topics - Miscellaneous - Block Cleanout
Jonathan Lewis
Seminars on getting the best out of Oracle
Last few places available for Sept 10th/11th
See http://www.jlcomp.demon.co.uk/seminar.html
-Original Message-
To: Multiple recipients of list ORACLE-L
I remember in slightly older versions of Oracle,
delayed_logging_block_cleanouts is by default true, so redo won't be written
immediately at block cleanout. Correct me if I'm wrong.
Yong Huang
[EMAIL PROTECTED]
Jonathan Lewis wrote:
bear in mind that a scan after deleting 100,000
rows would
delayed_logging_block_cleanout was introduced
in newer (7.3+) versions of Oracle to smooth things
out with OPS. But delayed block cleanout has been
around much longer - the documents tended to
hint that it no longer happened with the introduction
of the fast commit and
On Fri, 17 Aug 2001, [EMAIL PROTECTED] wrote:
delayed_logging_block_cleanout was introduced
in newer (7.3+) versions of Oracle to smooth things
out with OPS.
I just read the first chapter and it already explained things
that I have always been fuzzy about. I am looking forward to the
rest
Hi Walter,
The extents you refer to in ur thread is the allocated
space. Oracle by default scans upto the high
watermark. The reason truncate is fast is cause it
resets the high watermark so oracle did not scan
anything for u when it returned 0 rows .. however in
case of delete, it still scanned
Yes,
It has been known if you delete all records, use a truncate and not delete.
Otherwise it will still behave like it is full as it has to touch all the
extents.
Do not criticize someone until you walked a mile in their shoes, that way
when you criticize them, you are a mile a way and have
Truncate basically resets the table's highwater mark to 0. Deletes don't
do that. A 'select count(*)' does a full table scan, which much touch all
the blocks up to the HWM, and that's what's taking the time. The REUSE
STORAGE option keeps the extents allocated to the table, but the HWM is
HWM, oracle will search up to the high water mark when doing a count, like
you proposed, so if you're gonna delete all of the rows anyways, save time(now
and later) by doing the truncate.
joe
[EMAIL PROTECTED] 08/16/01 05:32PM
I have a user that deleted all of the rows in a table(i.e.
Hi Jonathan,
Can you tell us a little bit more about delayed block
cleanouts .. if you can
Thx
Deepak
--- Jonathan Lewis [EMAIL PROTECTED]
wrote:
Apart from the comments other posters
have made about truncate and the HWM,
bear in mind that a scan after deleting 100,000
rows would probably
by Select Count(1) - SLOW
Date: Thu, 16 Aug 2001 13:32:50 -0800
I have a user that deleted all of the rows in a table
(i.e. 100,000), waited for it to complete, and then
ran a SELECT COUNT(1) FROM table. It took a few
minutes for '0 rows' to be returned to the prompt. The
table has ~60 extents (128k ea
10 matches
Mail list logo
