Comments on: Free Space

By: Jonathan Lewis

Jonathan Lewis — Sun, 10 Mar 2013 11:55:36 +0000

Richard,
I’m not quite sure I understand your comments about, but I think you are mixing up the bitmaps for the extents and the bitmaps for the tablespace as you work through the numners.

Each block in the bitmap for the tablespace allows us to map 14,336 extents.
In this version of Oracle, the first extent of the tablespace starts after a 1MB file header section (which, of course, includes the tablespace bitmaps).

By: Richard.

Richard. — Mon, 04 Mar 2013 11:27:35 +0000

Hi Jonathan,

I can´t understand the above operation:

512 + 2 * 14,336

If an extent consists of two blocks, and there is only a bitmap control header for each extent, it means there is 14336 bits in the first block of the extent but the second block should be full available (except its own control information, of course). I mean:

Block 1, extent Nth Block 2, extent Nth
——————————————————– + ——————————————————-
bitmap header: 256 B | 14336 bits=1792B + Full 2048 B – block header(22B for example)
———————————————————+——————————————————–

So, If it is correct, the next bit map should be at: 1792 B + 2048B, isn´t?.

Best regards.

By: Valentin Nikotin

Valentin Nikotin — Tue, 26 Feb 2013 13:38:37 +0000

Actually “28672 block = 14336 extents and require 14336 / 8″ makes sense only if we use uniform extents, more correctly to use “units” instead of “extents”.

By: Valentin Nikotin

Valentin Nikotin — Tue, 26 Feb 2013 08:54:02 +0000

I guess it’s just internal implementation of x$ktfbfe that provides access to bitmap blocks.

By: Sayan Malakshinov

Sayan Malakshinov — Tue, 26 Feb 2013 07:20:51 +0000

As I understand, free space for each datafile calculated by each freespace bmb separately, because each freespace bmb contains a header and bitmap, so bitmaps in these blocks are not continuous(although located in a row). Number of bmb depends on datafile size.

By: Anju Garg

Anju Garg — Tue, 26 Feb 2013 06:44:32 +0000

Since we are using locally managed tablespace, It is storing the information about the space available in a file in the bitmaps in the file header. One unit of information contains information about one extent. If the information can fit in the space allocated in the file header, all the free space appears as contiguous. As the size of the file increases and extent size decreases , the units of the information to be stored increases and more space is allocated beyond the file header. Until any objects are created in the tablespace, the bits corresponding to all the extents are not set and appear as free space. As objects are created in the tablespace, corresponding bits are set and free space available decreases (Starting block_id rises).

This is the conclusion I have reached after trying with block/extent/file sizes.
I don’t know if it is correct.

By: Sayan Malakshinov

Sayan Malakshinov — Tue, 26 Feb 2013 05:29:38 +0000

Moreover, i found Jonathan’s answer to this question :)

By: Sayan Malakshinov

Sayan Malakshinov — Mon, 25 Feb 2013 22:44:29 +0000

Yep. you are right! :) I’ve tested on 400m and got 8 rows :)

By: Sayan Malakshinov

Sayan Malakshinov — Mon, 25 Feb 2013 22:23:57 +0000

Hmm, in trace i see queries to recyclebin$. What does it means? Some objects was created and dropped? Or was initialized recyclebin for this tablespace?

select nvl(sum(space),0) 
from
 recyclebin$ where ts# = :1

select file#, block# 
from
 recyclebin$ where ts# = :1     and file# != 0 and block# != 0 and space = 0

By: Valentin Nikotin

Valentin Nikotin — Mon, 25 Feb 2013 22:16:24 +0000

It seems depend on size of File Space Bitmap Block and uniform size, in your case 28672 block = 14336 extents and require 14336 / 8 = 1792 bytes per File Space Bitmap Block.