Lob segments have lots of storage attributes. Despite that lots of DBA' s never throw an eye on it. I guess the moment is there for you to do it now.

One of the attributes is disable storage in rowthis means that no matter what the size of the lob data is about, the lob data will be stored in dedicated blocks in a dedicated lob segment.

Another storage attribute is the chunk size. The minimum chunk size is the size of a block no matter what the size of the lob data is about. In your case the minimum size will be 16K.

If I read your posting it is as if in your source db you had x records with lob data of which the actual length (dbms_lob.getlength) was below a 8K block size, but per record there was the minimum of 8K / 1 block allocated.

Now you have x records with lob data of which the actual length (dbms_lob.getlength) is below a 16K block size, but per record there is the minimum of 16K / 1 block allocated.

This explains why the space lost has doubled

I am afraid I am right that your choice to move the lobs towards a bigger block size tablespace was wrong ( it is human to be wrong now an then )

Since your lobsegment is built in a 16K tablespace, the minimum space allocation per lob record is 16K since 16K is the minimum chunk size.

If you can afford downtime I would suggest you

1) capture the table DDL using dbms_metadata, indexes, constraints, triggers
2) capture privileges, which users, user roles have grants on the table concerned
3) export the table using exp or expdp
4) create a tablespace of 8K and assure you have a db_8K_cache_size
5) adjust the table DDL in order to built your lob segment in the 8K tablespace, and precreate the table
6) import using imp or impdp

There are commands to move log segments only towards another tablespace but given the size, even though much of lost space, I would not use those commands to move such a big segments in production databases. The move is supposed to be online but you should monitor the undo tablespace which could grow that much you better don' t do it.

SQL> create table student1.t_LOB ( col1 number, col2 clob );

Table created.

SQL> select table_name,column_name,tablespace_name from dba_lobs where table_name='T_LOB' and owner='STUDENT1';

SQL> select table_name,column_name,tablespace_name from dba_lobs where table_name='T_LOB' and owner='STUDENT1';

T_LOB
COL2
TS1_LOB

In the above example TS1_LOB is a 8K block size tablespace.

You may want to list what the avg lob length is about

SQL> select avg(dbms_lob.getlength(col2)) from student1.t_lob;

if the average is below 4K, then you could consider
1) to configure a small db_4K_cache_size
2) to create a 4K block size tablespace at you choice
3) to move your lob segment towards that tablespace with the below syntax

So you have configured a db_cache_size which is the amount in bytes for your 16K cache ( since db_block_size = 16K you sized the default (16K) buffer cache using db_ccahe_size in stead of db_16K_cache_size )

As you pointed out yourself you first need to configure a cache for the non default block size before you can create a tablespace with that block size

In your case you first had to specify a db_8K_cache_size prior to you 8K lob tablespace creation.

According to the documentation as well according to the test I did the minumuml amount of memory per pool = 4M * cpu_count