Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: ASSM and tablespace fragmentation

Re: ASSM and tablespace fragmentation

From: Frits Hoogland <>
Date: Wed, 26 Sep 2007 09:10:26 +0200
Message-ID: <>


I've read (and witnessed) the phenomenon you are describing. ASSM uses bitmap blocks instead of one (or more) freelists. Probably because of the random bitmap block usage, and random data block allocation, some blocks did not fill up to their maximum. Also, using direct loads some blocks remained empty entirely (because the direct load is done behind the HWM)
- I don't know if ASSM is more optimised or better in 10gr2/11g (anyone?) - As far as I see ASSM, it is an optimisation for RAC (because of the randomness of administration in the bitmap blocks) - When data warehouse like actions are done, probably freelist based storage would be better, because multi block reads are really sequential, because multiblock reads are not done really sequential. (anyone did investigation in this area)

So, some answers, but also much more questions


On 9/26/07, <> wrote:
> There was an article written a few years ago talking about certain cases
> where you can have tablespace fragmentation when using ASSM. I think Niall
> Litchfield wrote this(I could be wrong). I believe this was due to deletes.
> I am not using deletes, but will be dropping alot of partitions and am
> wondering whether I may have problems with this down the road. Here is my
> scenario.
> 1. initally go to production with 500 GB of data
> 2. This will grow to between 25-50 TBs over 15 months.
> 3. We will load 1/10th of the data/day into the database. So at 500GB we
> will load 50 GBs/day at 25-50 TBs we will load 2.5 - 5 TBs/day.
> 4. tables are partitioned by date with hourly partitions.
> 5. We will drop partitions that are 10 days old.
> So we are recycling data every 10 days while our database size is growing.
> Does this scenario have any risk of tablespace fragmentation with ASSM? We
> may use ASM, but I don't think that matters in this case.
> --

Received on Wed Sep 26 2007 - 02:10:26 CDT

Original text of this message