RE: unexpected heavy buffered IO during partition bitmap index rebuild
Date: Wed, 26 Sep 2012 15:50:39 -0400
Message-ID: <01a501cd9c20$35574250$a005c6f0$_at_rsiz.com>
apparently the top of this message didn't make it through something to the list.
-----Original Message-----
From: Mark W. Farnham [mailto:mwf_at_rsiz.com]
Sent: Wednesday, September 26, 2012 7:08 AM
To: 'JTornblad_at_emdeon.com'
Cc: 'oracle-l_at_freelists.org'
Subject: RE: unexpected heavy buffered IO during partition bitmap index
rebuild
At least a four things happen with a create table as select (CTAS) that
could be relevant:
1) CTAS grabs a chunk of blocks in order regardless of segment space
management style (bitmap versus Freelists aka automatic versus manual [but
they both are different kinds of automatic]), so depending on whether there
was an order by on your select feeding the CTAS you could potentially have
made the data in a new order that is friendlier to the bitmap index creation
2) CTAS is going to minimize row migrations and chaining and even if there
remains 255+ column chaining it is more likely to be intra-block
3) CTAS is going to take care of any delayed block cleanout issues, which
could mean lots less reading of undo
4) Any "empty front" or honeycomb empty blocks are eliminated.
From the evidence at hand I cannot tell whether any of these is actually relevant to your case.
Also please note I wrote "At least three" and might be something completely different.
<snip>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Sep 26 2012 - 14:50:39 CDT