I don’t understand where the problem might be with this – unless Exadata does something strange.

The basic command for each file would be something like:

alter database datafile '+DATA/linux/datafile/fpw_idx.277.766339579' resize 200M;

If this works you need only do something like:

begin
    for r in (
        select  file_name
        from    dba_data_files
        where   tablespace_name = 'FPW_IDX'
    ) loop
        execute immediate
            'alter database datafile ''' || r.file_name || ''' resize 50M';
    end loop;
end;
/

Obviously you may want to add an exception handler to trap and report error ORA-03297 (file contains used data beyond requested RESIZE value)

Appreciate your help.

Regards,
Nooresh

Thanks for coming back on this.
“shrink space compact” moves the rows from the end of the table to the beginning of the table, but doesn’t drop the highwater mark. “shrink space” drops the highwater mark after compacting. (This also requires a lock to be taken on the table, of course).

When you used “shrink space cascade” you were explicitly requesting that oracle tidy up the indexes as well, but implicitly (because there was no compact) telling it to drop the highwater mark.

SQL> exec dbms_stats.gather_table_stats('NOORESH','G1');

PL/SQL procedure successfully completed.

SQL> select blocks,empty_blocks,num_rows from dba_tables where table_name='G1';

    BLOCKS EMPTY_BLOCKS   NUM_ROWS
---------- ------------ ----------
      7068            0     508592

SQL> select blocks, extents from dba_segments where segment_name='G1';

    BLOCKS    EXTENTS
---------- ----------
      7168         71

SQL> select count (distinct dbms_rowid.rowid_block_number(rowid)) "used blocks" from G1;

used blocks
-----------
       6999

SQL> DELETE FROM G1 WHERE ROWNUM  select count (distinct dbms_rowid.rowid_block_number(rowid)) "used blocks" from G1;

used blocks
-----------
       4127

SQL> select blocks, extents from dba_segments where segment_name='G1';

    BLOCKS    EXTENTS
---------- ----------
      7168         71

SQL> ALTER TABLE G1 ENABLE ROW MOVEMENT;

Table altered.

SQL> ALTER TABLE G1 SHRINK SPACE COMPACT;

Table altered.

SQL> select count (distinct dbms_rowid.rowid_block_number(rowid)) "used blocks" from G1;

used blocks
-----------
       4129

SQL> exec dbms_stats.gather_table_stats('NOORESH','G1');

PL/SQL procedure successfully completed.

SQL> select blocks, extents from dba_segments where segment_name='G1';

    BLOCKS    EXTENTS
---------- ----------
      7168         71

----- While using Cascade Option

SQL> TRUNCATE TABLE G1;

Table truncated.

SQL> insert into g1 select * from  g1

816560 rows created.

SQL> exec dbms_stats.gather_table_stats('NOORESH','G1');

PL/SQL procedure successfully completed.

SQL> select blocks, extents from dba_segments where segment_name='G1';

    BLOCKS    EXTENTS
---------- ----------
     23552         94

SQL> select count (distinct dbms_rowid.rowid_block_number(rowid)) "used blocks" from G1;

used blocks
-----------
      22383

SQL> delete from g1 where rownum  commit;

Commit complete.

SQL> select count (distinct dbms_rowid.rowid_block_number(rowid)) "used blocks" from G1;

used blocks
-----------
      15531

SQL> alter table g1 shrink space cascade;

Table altered.

SQL> exec dbms_stats.gather_table_stats('NOORESH','G1');

PL/SQL procedure successfully completed.

SQL> select blocks, extents from dba_segments where segment_name='G1';

    BLOCKS    EXTENTS
---------- ----------
     15704         87

Could you clarify what you mean – as far as I recall the “cascade” option applies when shrinking tables and directs Oracle to shrink dependent objects. It’s not relevant to the question from Rajkumar.

A late thought on his question though is whether the shrink command did anything, or whether it was silently ignored. There are several restrictions on it, and it’s possible that some restrictions don’t report an error. From the 10.2 SQL Reference manual:

Restrictions on the shrink_clause The shrink_clause is subject to the following restrictions:

- You cannot specify this clause for a cluster, a clustered table, or any object with a LONG column.
- Segment shrink is not supported for tables with function-based indexes or bitmapjoin indexes.
- This clause does not shrink mapping tables of index-organized tables, even if you specify CASCADE.
- You cannot specify this clause for a compressed table.
- You cannot shrink a table that is the master table of an ON COMMIT materialized view. Rowid materialized views must be rebuilt after the shrink operation.

Sorry, I missed this comment when you first posted it. There’s probably no standard answer to your question since different strategies have different costs, risks, and side effects. You may find some relevant comments in one of my fragmentation notes:
http://jonathanlewis.wordpress.com/2010/07/16/fragmentation-2/

If shrink is not appropriate then a complete rebuild somewhere else (thinking about options for parallelism, nologging, properly backups etc.) could be the next best thing. Here’s another reference that supplies a warning about the problems of rebuildling tables, though: http://jonathanlewis.wordpress.com/2007/11/23/table-rebuilds/

Regards,
Nooresh

Thank you for your help,
Wissem