The first thing to do would be to check the space that is actually allocated to the LOB data.
select sum(dbms_lob.getlength ()) from ;
Please note that the UNDO data for a LOB segment is kept within the LOB segment space. The above query result is merely the still active LOB data. The rest of allocated data is undo space. The undo space can vary quite a lot, from being very small in size (when LOBs are only inserted) to being very large (when many LOBs are deleted) and is largely depending on the PCTVERSION LOB parameter or the RETENTION parameter.
Hence, The difference between these two is free space and/or undo space. It is not possible to assess the actual empty space using the queries above alone, because of the UNDO segment size, which is virtually impossible to assess. Furthermore, even when there is free space in the LOB, this does not mean this space can be released to the tablespace, it could be under the HWM. To find the freeable space, use the UNUSED_SPACE procedure as shown below.
Check the "free" space within a LOB segment.
First, remember that a lob can have 3 states: "inuse", "deleted" and "free". There are no statistics for the LOB segment, the DBMS_SPACE package is the only tool that could give an idea about it. As well, there is no view showing the deleted space within the LOB. The deleted space can be converted into free by rebuilding the freelist or by rebuilding the LOB segment itself, but this is not always possible.
LOB Partition sizing is not supported in DBMS_SPACE package until 10g.
Error ORA-00600 [ktsircinfo_num1] will be generated if the procedure is run against the lob partition on versions below 10g
P.S: When using dbms_lob.getlength, the output is in characters for CLOBs and NCLOBs, and in bytes for BLOBS and BFILES.
One can get an idea about how much space is actually used and what could be deallocated as follows:
1. Determine the unused space within the LOB segment, above the HWM. using the UNUSED_SPACE procedure.
set serveroutput on
TOTAL_BLOCKS, TOTAL_BYTES, UNUSED_BLOCKS, UNUSED_BYTES,
dbms_output.put_line('SEGMENT_NAME = ');
dbms_output.put_line('TOTAL_BLOCKS = '||TOTAL_BLOCKS);
dbms_output.put_line('TOTAL_BYTES = '||TOTAL_BYTES);
dbms_output.put_line('UNUSED_BLOCKS = '||UNUSED_BLOCKS);
dbms_output.put_line('UNUSED BYTES = '||UNUSED_BYTES);
dbms_output.put_line('LAST_USED_EXTENT_FILE_ID = '||LAST_USED_EXTENT_FILE_ID);
dbms_output.put_line('LAST_USED_EXTENT_BLOCK_ID = '||LAST_USED_EXTENT_BLOCK_ID);
dbms_output.put_line('LAST_USED_BLOCK = '||LAST_USED_BLOCK);
This is the only space that could be deallocated using the ALTER TABLE ... DEALLOCATE UNUSED command as seen below.
2.1. For tablespaces that are using free lists, the following procedures could be used to find the blocks that are on the freelists (which is not extremely useful when wanting to free up some space, as these blocks are just filled below the PCTUSED. Nevertheless, this shows there is some free space within the LOB.
2.1.1. for one freelist group:
DBMS_SPACE.FREE_BLOCKS('', '', 'LOB',0 ,free_blocks);
dbms_output.put_line('Nb of free blocks = '||free_blocks);
2.1.2. for multiple freelist groups:
variable free_blks number;
declare i int;
declare v_freelist_groups:=100; --- replace this with the actual number
FOR i IN 0..v_freelist_groups-1 LOOP
DBMS_SPACE.FREE_BLOCKS('','','LOB', i, :free_blks);
dbms_output.put_line('instance#: ' || i);
dbms_output.put_line('free_blks: ' || :free_blks);
the above procedures would not work for ASSM tablespaces, because the free_blocks procedure does not work with them.
2.2 SPACE_USAGE procedure could be used for ASSM segments instead:
dbms_space.space_usage ('', '', 'LOB', v_unformatted_blocks,
v_unformatted_bytes, v_fs1_blocks, v_fs1_bytes, v_fs2_blocks, v_fs2_bytes,
v_fs3_blocks, v_fs3_bytes, v_fs4_blocks, v_fs4_bytes, v_full_blocks, v_full_bytes);
dbms_output.put_line('Unformatted Blocks = '||v_unformatted_blocks);
dbms_output.put_line('FS1 Blocks = '||v_fs1_blocks);
dbms_output.put_line('FS2 Blocks = '||v_fs2_blocks);
dbms_output.put_line('FS3 Blocks = '||v_fs3_blocks);
dbms_output.put_line('FS4 Blocks = '||v_fs4_blocks);
dbms_output.put_line('Full Blocks = '||v_full_blocks);
Determine ASSM tablespaces or ASSM residing LOBs with:
from dba_tablespaces where segment_space_management='AUTO'
and tablespace_name NOT LIKE '%UNDO%'
and tablespace_name = ''
--Find LOBs that reside in ASSM tablespaces:
col Table format a24
col Tablespace format a22
col partitioned format a11
col column_name format a24
select column_name "Column",table_name "Table",tablespace_name "Tablespace",partitioned
where tablespace_name in (select tablespace_name
from DBA_TABLESPACES where segment_space_management='AUTO'
and tablespace_name NOT LIKE '%UNDO%'
and owner NOT IN ('SYS','SYSTEM','CTXSYS','MDSYS','ORDSYS','DBSNMP',
order by tablespace_name
3. The command used to deallocate the lob free space is:
modify lob () (deallocate unused);
This is not very useful in most circumstances. There is probably very little space above the high water mark. On top of this, the deleted space from inside the the lob segment is not even shown by the procedures above. This is the expected behaviour and, unfortunately, currently there is no procedure/view to show the deleted space. Having such an option is the current subject of an enhancement request.
However, the deleted space can be turned into free space and, when this happens, the procedure in 2.2 would show this free space. To turn the deleted space into free space, one has to rebuild the freepools. The command used to do this is:
modify lob() (freepools );
The free pools number can be taken from the dba_lobs view. When this value is null, the command can be run with a freepools number of 1. This procedure will not release the free space to the tablespace.
If one wants to release the space,
- for versions below 10.2, one has to rebuild the LOB segment using the MOVE command:
move lob () store as (tablespace );
- 10.2 introduced an even better option, it extended the SHRINK SPACE command to LOBs. As such, one can remove the deleted and free space altogether from the LOB segment and LOB index:
modify lob() (shrink space [cascade]);
#1. Be aware of the following bug before adjusting storage freelists for any LOB
Serious LOB corruption can occur after an