Shrink table after delete

Hi,
I want to remove some data from a Oracle table, too free up some space on hard drive.
I use delete clause with where condition to delete data, but then after i would need some shrink clause to shrink up the table as i understand.
I cant use truncate because it doesn't allow to use where clause. I need something like:
delete from table 1 where condition1;
shrink table1; --rfree up space                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Simply deleting rows doesn't make blocks eligible for deallocation. Try this:
truncate table mette reuse storage;
CALL DBMS_STATS.GATHER_TABLE_STATS(USER,'mette');
SELECT t.blocks used, s.blocks allocated
FROM   user_tables t JOIN user_segments s ON s.segment_name = t.table_name
WHERE  t.table_name = 'METTE';
   USED ALLOCATED
      0     20480
alter table mette deallocate unused;
CALL DBMS_STATS.GATHER_TABLE_STATS(USER,'mette');
SELECT t.blocks used, s.blocks allocated
FROM   user_tables t JOIN user_segments s ON s.segment_name = t.table_name
WHERE  t.table_name = 'METTE';
   USED ALLOCATED
      0         8
alter table mette allocate extent;
-- ...same query...
   USED ALLOCATED
      0        16
alter table mette deallocate unused;
-- ...same query...
   USED ALLOCATED
      0         8

Similar Messages

  • Shrink Oracle Table after Deletion

    A few database tables are very big. An Oracle table still holds the disk space occupied by deleted records according to http://stackoverflow.com/questions/6540546/oracle-10g-table-size-after-deletion-of-multiple-rows. Re: shrink table after delete teaches the following commands to release the idle space from the table.
    ALTER TABLE TABLE1 DEALLOCATE UNUSED;
    ALTER TABLE TABLE1 ENABLE ROW MOVEMENT;
    ALTER TABLE TABLE1 SHRINK SPACE;
    ALTER TABLE TABLE1 MOVE;
    1. Are the commands feasible?
    2. Are they safe?
    3. What will be the impacts of running the commands?
    4. Is there any other workable safe approach shrinking a table?

    Hi,
    I advise using shrink table operation.
    The tablespace which belong to your table must be in ASSM (Automatic segment space management) to use shrink.
    Shrink is safe but you need to run two commands :
    1)ALTER TABLE TABLE1 SHRINK SPACE COMPACT; (This is long operation which moves data, but can be done online)
    2)ALTER TABLE TABLE1 SHRINK SPACE; (this is quick if you run SHRINK SPACE COMPACT before, it only shift the High Water Mark. Be carreful if you don't run SHRINK SPACE COMPACT before your table will be locked for a long time)
    Another point, is that execution plans are calculed using the HWM so SHRINK the table (The 2nd command) will invalidate all the cursors in shared pool where the table is in. So execution plan need to be recalculated (often not a problem).
    Regards,

  • Restoring the data from table after deletion

    Hi,
    If  I delete the data from the database (using delete command) , is there anyway to restore that data. I know it looks bit weird but I'm checking whether there is any technique in abap by which we can restore the data.
    Your help would be appreciated.
    Thanks,
    Kranthi.

    Hi Kranthi,
               When you delete lines of a database table using the DELETE command, the process is only complete after a database commit. Before the commit, any database change can be reset using a database rollback.To be able to perform a database rollback, a database system must generate a copy of each database object before making a change. These copies are kept in a rollback log until the end of an LUW. An overflow of the rollback log always results in the termination of the transaction which caused it. For example, attempting to remind a large number of defaulting customers in the same transaction could trigger such an error. You can only solve this problem by dividing the set of database updates into several smaller units ( LUWs) for the database system. You use this statement if you cannot be certain that all the database changes have been executed correctly.
    For your information :
    An LUW begins each time you start a transaction,when the database changes of the previous LUW have been confirmed (database commit) or when the database changes of the previous LUW have been cancelled (database rollback)
    An LUW ends when the database changes have been confirmed (database commit) or when the database changes have been canceled (database rollback). Within an LUW, database changes are not made until after a database commit. Prior to this, any database change can be canceled by a database rollback.
    Cheers
    Nishanth

  • How to purge PERFSTAT.STATS$SQLTEXT table, after deleting snapshots

    I had an alarm on the free space of the PERFSTAT tablespace. In order to free up some space I tried to delete some old StatsPack snapshots, with the following query:
    DELETE from perfstat.stats$snapshot where snap_time < sysdate - 10 ;
    COMMIT;
    After running it the space usage on the tablespace was not significantly reduced. I checked again and I saw that the table PERFSTAT.STATS$SQLTEXT was very big, almost 8 Gb, but all the other tables were a lot smaller. I read somewhere that the sppurge.sql procedure, that comes with Oracle, could be used to purge the statspack data, but that it comes with the lines related to PERFSTAT.STATS$SQLTEXT commented, because it is a big query and it can take a lot of undo space. I tried to run the followiung query, which I found in the forum, by Don Burleson, but it failed, because of running out of undo:
    DELETE /*+ index_ffs(st)*/
    FROM perfstat.stats$sqltext st
    WHERE (hash_value, text_subset) NOT IN (
    SELECT /*+ hash_aj full(ss) no_expand*/ hash_value, text_subset
    FROM perfstat.stats$sql_summary ss
    WHERE snap_id NOT IN (SELECT DISTINCT snap_id FROM perfstat.stats$snapshot)
    COMMIT;
    Is there any way to know if the PERFSTAT.STATS$SQLTEXT table has records that could be purged, and an easier way, that don't use as much undo, to purge it?
    My oracle version is:
    Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
    PL/SQL Release 9.2.0.7.0 - Production
    CORE 9.2.0.7.0 Production
    TNS for Solaris: Version 9.2.0.7.0 - Production
    NLSRTL Version 9.2.0.7.0 - Production
    I. Neva
    Oracle DBA

    Is there any way to know if the PERFSTAT.STATS$SQLTEXT table has records that could be purged, yes, just transform Delete to Select
    SELECT /*+ index_ffs(st)*/ count(*)
    FROM perfstat.stats$sqltext st
    WHERE (hash_value, text_subset) NOT IN (
    SELECT /*+ hash_aj full(ss) no_expand*/ hash_value, text_subset
    FROM perfstat.stats$sql_summary ss
    WHERE snap_id NOT IN (SELECT DISTINCT snap_id FROM perfstat.stats$snapshot)
    and an easier way, that don't use as much undo, to purge it?yes. do it smaller chunks
    BEGIN
    LOOP
    DELETE /*+ index_ffs(st)*/
    FROM perfstat.stats$sqltext st
    WHERE (hash_value, text_subset) NOT IN (
    SELECT /*+ hash_aj full(ss) no_expand*/ hash_value, text_subset
    FROM perfstat.stats$sql_summary ss
    WHERE snap_id NOT IN (SELECT DISTINCT snap_id FROM perfstat.stats$snapshot)
    ) AND ROWNUM<=10000;
    EXIT WHEN SQL%ROWCOUNT = 0;
    COMMIT;
    END LOOP;
    COMMIT;
    END;
    /

  • Try to shrink datafiles after deleting huge amount of records

    Dear Sir;
    I have deleted more than 50 million records along with table’s partitions for the previous year.
    now I'm trying to shrink datafile with more than 10GB free space but still unable to delete due to
    ORA-03297: file contains used data beyond requested RESIZE value.
    How can we shrink these datafile or otherwise what is the best way to delete huge amount of records and get additional space in HD
    Thanks and best regards
    Ali Labadi

    Hi,
    You could see this article of Jonathan LEWIS:
    http://jonathanlewis.wordpress.com/2010/02/06/shrink-tablespace

  • Sending email after deleting the records in a table

    Hi
    I am deleting the records in a table. After deleting the records,
    i want to send an email to another person. I am planning to follow this steps.
    1. Create a trigger on the table(AFTER DELETE ON table FOR EACH ROW)
    to copy the deleted records to temporary table.
    2. Read the temporary table and send an email.
    Is there any other way we can do with out creating temporary table ?.
    Govind

    I don't know what you plan to use to send the mail but here's a solution that would work.
    -- Create a send mail procedure
    create or replace procedure send_mail (
    sender      IN VARCHAR2,
    recipient   IN VARCHAR2,
    message     IN VARCHAR2)
    IS
      mailhost VARCHAR2(30) := 'localhost';
      mail_conn utl_smtp.connection;
    BEGIN
    mail_conn :=  utl_smtp.open_connection(mailhost, 25);
      utl_smtp.helo(mail_conn, mailhost);
      utl_smtp.mail(mail_conn, sender);
      utl_smtp.rcpt(mail_conn, recipient);
      utl_smtp.data(mail_conn, message);
      utl_smtp.quit(mail_conn);
    END;
    /-- Create the trigger to email deleted rows
    create or replace trigger email_del_rows
    after delete on <table>
    for each row
    declare
    msg varchar2(2000);
    begin
    msg := 'COL1  COL2  COMPANY NAME  DATE'||chr(10);
    msg := msg||:old.col1||'    '||:old.col2||'    '||:old.company_name||'       '||:old_date|| chr(10);
    msg := msg||'END OF FILE';
    send_mail('SENDER','[email protected]',msg);
    end;
    /You can make it look pretty but you get the basic idea.

  • BOM table for deleted item

    Hi All,
    In which table shall i get the deleted item from Bill of material. I checked in STPO but in this table after deleting the item it will not appear.
    Regards,
    RBS

    Hi  RBS,
    Please go through the Tables  below Pertaining to BOM
    STPO BOM Item Details
    STPU BOM Sub Items (designators)
    STKO BOM Header Details
    MAST BOM Group to Material
    STZU BOM History Records
    STAS BOM Item Selection
    STPF BOM Explosion Structure
    PLMZ Allocation of bill of material items to operations
    Regards
    Varma

  • Table space not reduce after delete in oracle 11G

    Hi Team,
    I have a DB 11.1.0.7 on unix.
    I have execute delete tables on tablespace, but this not reduce.
    Thanks

    935299 wrote:
    What segment space management type is defined for the tablespace in question?
    MANUAL
    Then you should check out the documentation some more.
    But even if you shrink the table segement what is that going to do for the data file size?
    I don't undertand you.
    ThanksYour thread is titled "Table space not reduce after delete in oracle 11G" which implies to me that you are interested in reducing the size of a tablespace (which really means reducing the size of the underlying datafile(s)).
    So, if you shrink the size of the sys.aud$ table, will that cause the datafile(s) to become smaller? Will it accomplish your goal? What else, if anything, needs to happen?

  • TABLESPACE cleanup not happening after table data delete

    Hi all
    I have a partitioned table with 4 partitions all residing in a single tablespace. I populated the table with sample data and then deleted all with a simple delete statement followed by a commit. But the tablespace is still showing data from the 4 partitions under the bytes column in query below:
    select segment_name, partition_name, tablespace_name, bytes
    from dba_segments
    where tablespace_name='tb_name'
    Am I missing something here? Do I need to run some other command after delete and commit to fully flush out the data?
    FYI, my system specs are:
    Windows 2008 Server Standard (32-bit)
    ORACLE 11.1.0.7.0

    HI,
    LMT is Locally Managed Tablespace.
    +Moreover, when you say the blocks will not be available immediately when do you reckon they will be available? How do I go about automating this to free up space as soon as data is deleted?+
    You cannot automate this job, this is already automated by Oracle.
    +FYI, both pct_free and pct_used come up as empty values for my table.+
    reason for a NULL-value for PCT_USED is that the tablespace where the table resides uses automatic segments space management (ASSM). With ASSM there is no need for PCT_USED only for PCT_FREE. Oracle manages blocks automatically.
    You dont worry about releasing the space, Oracle will take care of it automatically.
    Go through the below link
    [http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#ADMIN10065]
    [http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/schema.htm#sthref2100]
    [http://www.dba-oracle.com/art_builder_assm.htm]
    This is an extract form Oracle docs
    Understanding Reclaimable Unused Space
    Over time, updates and deletes on objects within a tablespace can create pockets of empty space that individually are not large enough to be reused for new data. This type of empty space is referred to as fragmented free space.
    Objects with fragmented free space can result in much wasted space, and can impact database performance. The preferred way to defragment and reclaim this space is to perform an online segment shrink. This process consolidates fragmented free space below the high water mark and compacts the segment. After compaction, the high water mark is moved, resulting in new free space above the high water mark. That space above the high water mark is then deallocated. The segment remains available for queries and DML during most of the operation, and no extra disk space need be allocated.
    You use the Segment Advisor to identify segments that would benefit from online segment shrink. Only segments in locally managed tablespaces with automatic segment space management (ASSM) are eligible. Other restrictions on segment type exist. For more information, see "Shrinking Database Segments Online".
    If a table with reclaimable space is not eligible for online segment shrink, or if you want to make changes to logical or physical attributes of the table while reclaiming space, you can use online table redefinition as an alternative to segment shrink. Online redefinition is also referred to as reorganization. Unlike online segment shrink, it requires extra disk space to be allocated. See "Redefining Tables Online" for more information.Regards,
    Vijayaraghavan K

  • Space reusage after deletion in compressed table

    Hi,
    Some sources tell, that free space after DELETE in compressed table is not reused.
    For example, this http://www.trivadis.com/uploads/tx_cabagdownloadarea/table_compression2_0411EN.pdf
    Is it true?
    Unfortunatly I cannot reproduce it.

    Unfortunatly the question is still open.
    In Oracle 9i space, freed after DELETE in compressed block, was not reused in subsequent inserts.
    Isn't it?
    I saw many evidences from other people. One link I gave above.
    But in Oracle 10g I see another figures. After delete rows in compressed blocks, and subsequent insert into that block, block defragmented!
    Please, if who know any documentation about change in this behavior, please post links.
    p.s.
    in 10g:
    1. CTAS compress. Block is full.
    2. after, deleted every 4 from 5 rows.
    avsp=0x3b
    tosp=0x99e
    0x24:pri[0]     offs=0xeb0
    0x26:pri[1]     offs=0xea8 -- deleted
    0x28:pri[2]     offs=0xea0 -- deleted
    0x2a:pri[3]     offs=0xe98 -- deleted
    0x2c:pri[4]     offs=0xe90 -- deleted
    0x2e:pri[5]     offs=0xe88 -- live
    0x30:pri[6]     offs=0xe80 -- deleted
    0x32:pri[7]     offs=0xe78 -- deleted
    0x34:pri[8]     offs=0xe70 -- deleted
    0x36:pri[9]     offs=0xe68 -- deleted
    0x38:pri[10]     offs=0xe60 -- live
    0x3a:pri[11]     offs=0xe58 -- deleted
    0x3c:pri[12]     offs=0xe50 -- deleted
    0x3e:pri[13]     offs=0xe48 -- deleted
    0x40:pri[14]     offs=0xe40 -- deleted
    0x42:pri[15]     offs=0xe38  -- live
    0x44:pri[16]     offs=0xe30 -- deleted
    0x46:pri[17]     offs=0xe28 -- deleted
    0x48:pri[18]     offs=0xe20 -- deleted
    0x4a:pri[19]     offs=0xe18 -- deleted
    0x4c:pri[20]     offs=0xe10 -- live
    ...3. insert into table t select from ... where rownum < 1000;
    Inserted rows were inserted in a several blocks. Total number of not empty blocks was not changed. Chains did not occure.
    Block above looks as follow:
    avsp=0x7d
    tosp=0x7d
    0x24:pri[0]     offs=0xeb0
    0x26:pri[1]     offs=0x776 - new
    0x28:pri[2]     offs=0x84b - new
    0x2a:pri[3]     offs=0x920 - new
    0x2c:pri[4]     offs=0x9f5 - new
    0x2e:pri[5]     offs=0xea8 - old
    0x30:pri[6]     offs=0xaca - new
    0x32:pri[7]     offs=0xb9f - new
    0x34:pri[8]     offs=0x34d - new
    0x36:pri[9]     offs=0x422 - new
    0x38:pri[10]     offs=0xea0 - old
    0x3a:pri[11]     offs=0x4f7 - new
    0x3c:pri[12]     offs=0x5cc - new
    0x3e:pri[13]     offs=0x6a1 - new
    0x40:pri[14]     sfll=16  
    0x42:pri[15]     offs=0xe98 - old
    0x44:pri[16]     sfll=17
    0x46:pri[17]     sfll=18
    0x48:pri[18]     sfll=19
    0x4a:pri[19]     sfll=21
    0x4c:pri[20]     offs=0xe90 -- old
    0x4e:pri[21]     sfll=22
    0x50:pri[22]     sfll=23
    0x52:pri[23]     sfll=24
    0x54:pri[24]     sfll=26As we see, that old rows were defragmented, and repacked, and moved to the bottom of block.
    New rows (inserted after compressing of table) fill remaining space.
    So, deleted space was reused.

  • Release of space after delete/truncate table

    Hello,
    How does release of space after delete/truncate table works? Is the space used before deletion released once delete is complete or not? Will I see the space occupied by deleted table as free in dba_segments or will I need to reorganize the table (drop and recreate again?). Reason why I am asking is that I can see table with 0 rows, but in dba_segment I can see it is occupying few gigabytes....
    Thank you

    Here is a little illustration for you;
    SQL> conn ogan/password
    Connected.
    SQL> create table ogan_deneme as select * from all_objects;
    Table created.
    SQL> select count(*) from ogan_deneme;
      COUNT(*)
        228470
    SQL> set line 1000
    SQL> set pagesize 1000
    SQL> select * from dba_segments where owner='OGAN';
    OWNER    SEGMENT_NAME        PARTITION_NAME           SEGMENT_TYPE       TABLESPACE_NAME                HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE  FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
    OGAN      OGAN_DENEME          TABLE              SYSTEM                                 854       319981   *30408704*       *1856*         *44*          65536                       1  2147483645                       1               1          854 DEFAULT
    SQL> truncate table ogan_deneme;
    Table truncated.
    SQL> select * from dba_segments where owner='OGAN';
    OWNER    SEGMENT_NAME        PARTITION_NAME           SEGMENT_TYPE       TABLESPACE_NAME                HEADER_FILE HEADER_BLOCK      BYTES     BLOCKS    EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE  FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_
    OGAN      OGAN_DENEME           TABLE              SYSTEM                                 854       319981      *65536*          *4*          *1*          65536                       1  2147483645                       1               1          854 DEFAULT
    SQL>Hope it Helps,
    Ogan

  • How do I restore column headings in Response table after accidently deleting them? Undo doesn't work.

    How do I restore column headings in Response table after accidently deleting them? Undo doesn't work (only seems to go back one level). I also have so many headings I won't be able to type them in manually!

    With the help of information from user, ptressel, in [https://support.mozilla.org/en-US/questions/1032154#answer-673322 a post here about the existence of sessionstore.js when version 33 was released], I was able to easily recover my tabs and tab groups as follows:
    # close Firefox and, perhaps, allow a few seconds (30s?) for any final closing of files;
    # check to see if you have a sessionstore.js file in your profile folder, named like the one I documented in my original post above;
    # if it is not timestamped prior to the discovery of your problem, open the sessionstore-backups folder;
    # check if the recovery.js file is suitably timestamped and, if not, the recovery.bak.
    # At this point, you are likely to find that none of them are prior to your problem occuring. If so, open your backups of this folder and go through steps 2-4 to find a file prior to your problem occuring.
    # When you find a file, copy it to the root of your current profile folder and name it, "sessionstore.js"
    # Open Firefox. Mine opened up as desired.
    This is a Windows solution. Sorry I can't comment on other platforms, but I'd bet that as this is just a file copy and renaming, it is likely the same.
    For Windows users, you may find you need to sign out and login as an administrator in order to access the backups. You need not logoff your standard account, but do have Firefox closed as described above.
    Hope that helps.

  • Table grows to 6 GB with 6k records only after Delete ORA-01653:

    Hello,
    I have a Table that i delete data from using
    DELETE FROM DJ_20255_OUTPUT a where trunc(a.LOADED_DATE) <trunc(sysdate -7);
    COMMIT;
    the issue i have is when i want to repopulate the table i get the Error ORA-01653: unable to extend table.
    The table grows to over 6gb but if i truncate that table and in both cases there is no data left in the table after either action the table will only grow to 0.8 Mb once populated.
    so with truncate table size is 0.8MB and if i use delete from.... the table grows to 6GB
    The repopulation of the table uses mutiple insert statments commiting after each one.
    is this a bug or is there an action i should perform onece I have deleted the data?
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi

    Is this an Index Organized table ? (select IOT_TYPE from user_tables where table_name = 'DJ_20255_OUTPUT' ;)
    Are you saying that you use this sequence :
    DELETE .... in one single call to delete all the rows
    INSERT ... in multiple calls with COMMIT after each row
    Hemant K Chitale

  • Table size not reducing after delete

    The table size in dba_segments is not reducing after we delete the data from the table. How can i regain the space after deleting the data from a table.
    Regards,
    Natesh

    I think when you do DELETE it removes the data but
    it's not releasing any used space and it's still
    marked as used space. I think reorganizing would help
    to compress and pack all block and relase any unused
    space in blocks. Why do you think that? Deleting data will create space that can be reused by subsequent insert/ update operations. It is not going to release space back to the tablespace to make it available for inserts into other tables in the tablespace, but that's not generally an issue unless you are permanently decreasing the size of a table, which is pretty rare.
    Would you also please explain about different about
    LOB and LONG ? or point me to any link which explain
    baout it.From the Oracle Concepts manual's section on the LONG data type
    "Note:
    Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB) instead. LONG columns are supported only for backward compatibility.
    Oracle also recommends that you convert existing LONG columns to LOB columns. LOB columns are subject to far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG functionality has been static for several releases."
    LONG was a very badly implemented solution to storing large amounts of data. LOBs are a much, much better designed solution-- you should always be using LOBs.
    Justin

  • Tree Table Selection after deletion

    Hi,
    We have a tree table where we are displaying hierarchy of information. We have a "Delete" operation. This operation is available in the context menu associated to each node. When user selects "Delete" operation, the selected row is deleted and the next node is automatically selected. We have implemented a selection listener on this table but when this automatic selection happens after deletion this event is not triggered. How do we trigger the selection event after deletion? We require the selection event because, we are keeping track of the selected nodes. Even for delete, we are identifying the item to be deleted from the list of tracked nodes. When this auto selection happens and the user clicks delete menu, the auto selected row it is not available in the tracked list as the selection listener is not fired for the auto selection.
    Can any throw some light on how to address this?
    thanks,

    Hi,
    what if - after deleting a node - you call for the selectedRowKeys on the tree to get the new selected row. This way you can update what otherwise the listener does.
    Frank

Maybe you are looking for