RE: unexpected heavy buffered IO during partition bitmap index rebuild
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <JTornblad@xxxxxxxxxx>
- Date: Wed, 26 Sep 2012 15:50:39 -0400
apparently the top of this message didn't make it through something to the
list.
-----Original Message-----
From: Mark W. Farnham [mailto:mwf@xxxxxxxx]
Sent: Wednesday, September 26, 2012 7:08 AM
To: 'JTornblad@xxxxxxxxxx'
Cc: 'oracle-l@xxxxxxxxxxxxx'
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>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
