RE: unexpected heavy buffered IO during partition bitmap index rebuild

From: Mark W. Farnham <mwf_at_rsiz.com>
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-l
Received on Wed Sep 26 2012 - 14:50:39 CDT

Original text of this message