Is alter table shrink space a logged operation?

Hello -
I am running alter table xxxxxx shrink space. I have a few questions:
1. Is this a logged operation? Oracle handles this interanally as insert/delete operations, but I am not seeing more arch logs being generated.
2. If I stop in the middle of the shrink process, can Oracle resume where it left off?
3. How can I monitor the progress of the shrink operation? I am not seeing the sid, serial# in v$session_longops.
Any help is much appreciated!
Thanks,
mike

I'm not sure that you will be able to "monitor" it.
You could test using dbms_space to see if it shows any changes will the shrink is in progresss.
One other way would be to watch V$TRANSACTION USED_UREC (which will reflect counts for rows and index entries) to see USED_UREC approaching the expected number of table+index entries being rebuilt.
Hemant K Chitale
http://hemantoracledba.blogspot.com

Similar Messages

  • Alter SHRINK SPACE in oracle 10g

    Hello,
    My table PRICE_T table gets deleted and inserted almost 50 million records everyday.
    Now it takes too much time to perform this operation because of TABLE fragmented.
    i can use "CREATE table as select” option to remove fragmentation from table.
    but i dont want to use this option.
    so i hv tried ALTER TABLE SHRINK SPACE as i m using ORACLE 10g
    alter table price_t enable row movement;
    alter table price_t shrink space
    alter table price_t disable row movement;
    and i have applied following query to check table gets remove free space but still having free space after applying ALTER SPACE COMMAND
    select table_name,round((blocks*8),2)||'kb' "size1",round((num_rows*avg_row_len/1024),2)||'kb' "size"
    from DBA_tables
    where table_name = 'PRICE_T';
    Tablespace in PRICE_T table fall into is SEGMENT SPACE MANAGEMENT AUTO
    please help me to remove fragmentation from table using SHRINK command.
    Thanks.

    Now it takes too much time to perform this operation because of TABLE fragmented.How do you define "fragmented"?
    Why do you believe that your table is fragmented?
    Why do you believe that the fragmentation is causing performance problems?
    select table_name,
           round((blocks*8),2)||'kb' "size1",
           round((num_rows*avg_row_len/1024),2)||'kb' "size"
      from DBA_tables
    where table_name = 'PRICE_T'; - What is the output of this query before and after you shrink the table?
    - Are your statistics up to date? NUM_ROWS, BLOCKS and AVG_ROW_LENGTH provide information to the optimizer-- they are estimates gathered when object statistics are gathered. They are not maintained by Oracle in real time and may be substantially out of date.
    - I don't see any attempt to account in this query for overhead like PCTFREE.
    - Is there a reason that you aren't using the DBMS_SPACE package? This query seems highly suspect.
    Justin

  • Shrink,alter table move

    hi
    This is the scenerio
    a,b,c: distinct blocks
    f:free blocks
    Assume the extent is like:
    aaafffccccbbfb
    after shrink does it become like
    aaabbbccccffff
    or
    aaafffccccbbbf

    Ricardo,
    Both the things are same.They both are used to remove the fragmentation.The way they work may be different but the output of either will be the same.Free space will be on one side only ie after the hight water mark.You do it by move or by shrink,you will end up with the same thing.You put free space anywhere in the scenerio,it will come up to one end only.If it wont than I guess we are back from where we started.
    That said,check back the Oracle doc for both the commands.Also search for the same topic in http://hemantoracledba.blogspot.com/2008/03/alter-table-shrink-space.html
    HTH
    Aman....

  • Alter table modify lob shrink space hangs despite ddl_lock_timeout

    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
    The following command hangs despite session parameter ddl_lock_timeout being set to 0:
    alter table <table> modify lob (<column>) (shrink space);
    Data type of <column> is CLOB. In another session a transaction on <table> is open, with a simple update on a different (non-LOB) column.
    Looks like a bug to me, but have no access to metalink for confirmation/SR submission and would appreciate any comments/help on this issue.

    From Oracle 11 documentation ( http://docs.oracle.com/cd/B28359_01/server.111/b28310/schema003.htm#CBBBIADA )
    "Segment shrink is an online, in-place operation. DML operations and queries can be issued during the data movement phase of segment shrink."
    Simon

  • Impact to production if I shrink space on table...

    Hello experts.
    I am running Oracle 11.2 and saw in OEM that I have a table that is candidate for shrinking space.
    According to OEM, I can gain 5G by shrinking the table.
    The table is 16G, so if I shrink the table, then it should reduce to approx. 11G, right?
    This table is the primary table used by our application, so impact to production is very important.
    Okay, so I'm wondering what the impact to production is on the table while I shrink the space on the table.
    I am testing it now in my test environment.
    First, I found I had a function based index which has to be dropped before I can shrink the table.
    So I ran dbms_metadata to get the syntax to recreate the FBI, then dropped the FBI.
    Next, i ran alter table owner.tablename enable row movement;
    Then, I ran alter table owner.tablename shrink space cascade;
    While I am running the shrink table command, I opened another session and I queried the table and even did updates on the table.
    I was quite surprised in that the table is not locked and is still accessible for update and select statements.
    In fact, I do not see any noticeable impact by the shrink table command.
    Obviously, I am not in the production environment with hundreds of concurrent users, but my question is what kind of impact should I expect to see if I do this in production with people hitting this table? (No, this is not an IOT.)
    Any ideas?
    Edited by: 974632 on Feb 19, 2013 5:54 AM
    NOTE: The table shrink command took: Elapsed: 00:43:17.19
    Recreating the function based index took: Elapsed: 00:00:28.80

    Uwe Hesse wrote:
    What you observe is standard behavior.
    A potential impact comes from the massive internal DELETE & INSERT during the shrink operation.
    Will generate lots of redo & undo therefore.
    That's is not necessarily a problem, though.
    Kind regards
    Uwe Hesse
    "Don't believe it, test it!"
    http://uhesse.com
    Uwe,
    Correct me if I'm wrong, but my thought on reading the OP is that he could very well see a performance degradation during the shrink operation, but I'd also expect to see some overall improvement after the operation due to a large decrease in the number of blocks that would have to be scanned during any FTS, and possibly some cascading of that effect back through any indexes on that table.

  • Alter Table Space Autoextend

    Hi,
    I got an Error like this
    "ORA-01630 max # extents (string) reached in temp segment in tablespace string
    Cause: A temporary segment tried to extend past MAXEXTENTS."
    Is it possible to alter table space to Auto Extend in Oracle 8i With out Shutting down the
    Database. What Exact Commands for this? Is this effect the performance of the database?
    Please reply
    With thanks Naseer

    user13098327 wrote:
    Hi,
    I got an Error like this
    "ORA-01630 max # extents (string) reached in temp segment in tablespace string
    Cause: A temporary segment tried to extend past MAXEXTENTS."
    Is it possible to alter table space to Auto Extend in Oracle 8i With out Shutting down the
    Database. What Exact Commands for this? Is this effect the performance of the database?
    Please reply
    With thanks NaseerThe error you hit and your request is something different:
    ORA-01630 - limitation of extents per object or per tablespace.
    Tablespace autoextend - May be you mean datafile autoextend option.
    Pls, specify.

  • Regarding the Cost of ALTER TABLE Operations

    Hi All,
    I am a starter in Oracle. I like to know what will happen in the storage level in Oracle when we alter tables like following
    1. Add a primary or a foreign key to the table
    2. Create an Index on some of the columns in the table.
    I am asking this because I found that these operations are taking long time for me for some of the big tables. So I am curious to know about the inner details of these operations. Can anyone please clarify me?
    Thanks in advance.
    Best regards,
    Vijay

    user7665191 wrote:
    Hi All,
    I am a starter in Oracle. I like to know what will happen in the storage level in Oracle when we alter tables like following
    1. Add a primary or a foreign key to the table
    2. Create an Index on some of the columns in the table.
    I am asking this because I found that these operations are taking long time for me for some of the big tables. So I am curious to know about the inner details of these operations. Can anyone please clarify me?
    Thanks in advance.
    Best regards,
    VijayI think that a good first starting point would be the Oracle Concepts guide, available from http://docs.oracle.com. Look at the 11g version. That will tell you about contraints and indexes.
    But briefly, adding a primary key requires that the table is scanned, the primary key values are sorted into order and checked for uniqueness, and the values written to disk as an index segment with each value having a rowid associated with it that points to the location of that value in the table's data segment (file id, block id and row number). So, the duration of the command is most likely driven by scanning the table, and then writing the index data to disk.
    A foreign key constraint requires that the system check that all of the values in the column exist as values in the referenced column -- no index is automatically created although you probably ought to create one.
    Creating an index is similar to the primary key workload, except that for a non-unique index it won't check for duplicates of course.

  • Segment Shrink Space Compact option in Oracle 10g

    Dear All,
    1. Is it Compulsory to run the Segment Shrinking Jobs advised by Segment Advisor?
    2. Running online will it affect the perfomance
    3. Is this same as table re organization
    Thanks in Advance

    1. NO. As with any "Advisor" it is your discretion and decision as to what action to take and when. I would schedule shrinks / rebuilds / reorgs during/without maintenance/outages. But first, I would evaluate the advice. In many cases, it wouldn't be worth the effort to rebuild/shrink. Also, you have to consider that the table/index may/will grow again.
    I do a shrink/rebuild only as part of any archival job which deletes a significant portion of the data. Not otherwise.
    2. Running it online will impact performance. Furthermore, the SHRINK actually generates a lot of Undo (as it runs as if it is normal DML) and, consequently, Redo and ArchiveLog.
    3. It is different. However, the "it" also depends on what you mean to be a "table reorganization". A reorganization that is done with an ALTER TABLE MOVE (and ALTER INDEX REBUILD) is quite a different operation from a SHRINK. A DBMS_REDEFINITION is also a very different operation.

  • Options for resize datafile lower than high watermark besid alter table mov

    hello all,
    I have an issue where i am getting ORA-03297 error when trying to resize the datafile. Its becuase of high watermarks. I know i have couple of options...either resize it till the high watermark or Drop or move segments containing extents in this region prior to
    resizing the file....but the situation is this....this a test env...and we have couple of chained rows and doing that(alter table move) will get rid of our chained rows and we do not want that....as we are testing the removal of chained row from our prod systems....as i mentioned we cant do alter table move
    what other options do we have in order to shrink datafile below highwater mark besides moving or droping the segment into a different tablespace as we want to preserve the chianed rows for our testing and making the DB smaller in size (space issue on the server ) ??? any ideas or any thoughts ??
    we are on 10.2.0.3 on AIX system
    i have already went thru these metalink doc .... on that error
    Note 1029252.6 - How to Resize a Datafile
    Note 130866.1 - How to Resolve ORA-03297 When Resizing a Datafile by Finding the Table Highwatermark
    Note 237654.1 - Resizing a Datafile Returns Error ORA-03297

    i am sorry not able to get your question ??
    I want to shrink the space of the Datafile without removing the chaned rows for testing the removal of chianed row for prod. The reason why is becoz of rman backup space issue. If we shrink the datafile our DB will be down to 150GB....and if we cant its about 450GB...which is big difference...and the reason for backup for this dev env is because once we have tested teh removal of chained rows...we will restore it again and re-test it and its a very mission critial system...we need to test this min of 3 times to get teh change approved...thats why...if we have a backup now...we can remove chain rows and then restore it back to this point and test it again...if you know wat i mean

  • Index status after table shrink

    Dear all,
    As we know,the indexes will be invalid after move,and I want to know whether the indexes will be invalid after shrink.

    user7244870 wrote:
    hi,
    I found the shrink command can not use parallel.
    SQL> alter table tb_hxl_user shrink space cascade parallel 4;
    alter table tb_hxl_user shrink space cascade parallel 4
    ERROR at line 1:
    ORA-10630: Illegal syntax specified with SHRINK clause
    Here see the restriction of shrink clause usage :
    "+You cannot combine this clause with any other clauses in the same ALTER TABLE statement.+"
    http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_3001.htm#i2192484
    Nicolas.

  • Shrink space of datafile

    Oracle 11.1.0.7:
    I need to give some space back to the storage. I am trying to figure out what process should I follow to shrink the datafiles and drop the datafiles.
    1. Should I first do shrink space on tablespace and then drop few datafiles?
    2. How do I know how much space can be shrunk?
    3. How do I know if after shrinking which datafiles are ready for drop?
    Is there any other better way?

    I"ve just gone through a very similar procedure.
    First i had to identify the high water mark in each datafile, and then shrink it back to that or just above that value.
    NOTE: It's best to do this when your DB is not in use, specifically growing or if it is some of the commands might fail saying that there is data beyond that size.
    Now most likely your data is spread across the datafiles in some sort of "optimal" way by oracle, so it's unlikely that you'll be able to get any "clean" datafiles that you can just drop.
    So what i did was to create a new tablespace big enough to hold the objects, MOVED the tables and REBUILT the indexes in the new TS.
    Now one option here is to just keep the new TS's and drop the old ones, if needed you can even rename your tablespace (10g and above)
    ALTER TABLESPACE old_ts RENAME TO new_ts;
    However, you must follow the rules when renaming a tablespace (also need to separetly rename the df if you want to keep your naming standard) :
    You cannot rename the SYSTEM or SYSAUX tablespaces.
    You cannot rename an offline tablespace.
    You cannot rename a tablespace that contains offline datafiles.
    Here we wanted to keep the file names locations so i ended up copying everything back into the originals, but before i did that , i could querried dba_segments to get the minimum size required, and I then I shrunk and dropped the datafiles in the original TS as appropriate.
    To get the hight water mark, i used this script :
    SELECT 'ALTER DATABASE DATAFILE ''' || FILE_NAME || ''' RESIZE ' || HWMM || ';' CL_DYN_SQL
    FROM (
    SELECT DF.FILE# FILE_ID, DF.NAME FILE_NAME, NVL(DFD.MAX_BLOCK_COUNT,1)*DF.BLOCK_SIZE HWM,
    DECODE(SIGN((1024)-(CEIL(NVL(DFD.MAX_BLOCK_COUNT,1)*DF.BLOCK_SIZE/(1024*1024)))),
              1,1024, CEIL(NVL(DFD.MAX_BLOCK_COUNT,1)*DF.BLOCK_SIZE/(1024*1024))) || 'M' HWMM,
              DF.BYTES
    FROM V$DATAFILE DF, V$TABLESPACE TS,
    SELECT FILE_ID, MAX(BLOCK_ID+BLOCKS-1) MAX_BLOCK_COUNT
              FROM DBA_EXTENTS DE
              WHERE DE.TABLESPACE_NAME IN ('TS_D', 'TS_I')
              GROUP BY FILE_ID
    ) DFD          
    WHERE DF.FILE# = DFD.FILE_ID (+)
    AND DF.TS# = TS.TS#
    AND TS.NAME IN ('TS_D', 'TS_I')
    WHERE HWM < BYTES
    ORDER BY 1;

  • Truncate table and materialized view log

    I user oracle 10 R2
    I have a table and on that table a materialized view log.
    I execute in a pl/sql procedure:
    1) execute immediate('drop materialized view log on tab1');
    then:
    2) execute immediate('truncate table tab1');
    3) Now I insert a lot of records in tab1
    4) execute immediate('create materialized view log on tab1 WITH rowid INCLUDING NEW VALUES');
    When I create the materialized view log I recieved this message:
    ora32321: refresh fast on tab2 unsupported after detail table truncate
    Why?

    Refresh fast after truncate operation on container table is not supported, regardless the container table is or is not partitioned.
    Perform a refresh complete.
    ORA-32321 :
    Cause:     A detail table has been truncated and no materialized view
         supports fast refersh after a detail table has been truncated
    Action:     Use REFRESH COMPLETE. Note: you can determine why your
         materialized view does not support fast refresh after TRUNCATE
         using the DBMS_MVIEW.EXPLAIN_MV() API.

  • Multiple Alter Table Statements in one batch

    Hi Team,
    We have in one of our upcoming release two columns being added to a table that has over 20 million records and 14 indexes.
    We needed to add two columns to the table both not null (bit). Because it was taking a while to add the columns, we thought that putting these two alter statements in one batch would speed up the operation significantly but to my surprise it did not.
    Conclusion from my test: individual alter statements or batch alter statements take the same time
    Here are me test and results - table Order1 and Order2 are exactly the same structure and data.
    Test case 1:
    ===================
    ALTER TABLE Order1
    ADD OR_N BIT DEFAULT 0 NOT NULL
    go
    ALTER TABLE AccountTradeConfirmation_Alter1
    ADD OR_S BIT DEFAULT 0 NOT NULL
    Go
    Elapsed Time: 2 hrs
                 Mar 18 2015 5:56PM
    (1 row affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
                 Mar 18 2015 7:52PM
    Test case 2:
    ===================
    ALTER TABLE Order2
    ADD OR_N BIT DEFAULT 0 NOT NULL, OR_S BIT DEFAULT 0 NOT NULL
    go
    2 hrs elapsed time
                 Mar 20 2015 11:10AM
    (1 row affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
                 Mar 20 2015 1:12PM

    Hi Kiran,
    I have read your response a few times and I was not able to understand your angle. I assume based on the results of my test that Sybase does the following in processing the alter statements
    ALTER TABLE Order2
    ADD OR_N BIT DEFAULT 0 NOT NULL, OR_S BIT DEFAULT 0 NOT NULL
    go
    process alter ADD OR_N BIT
    -- > make copy of table
    ---> alter original table
    --> put data back in
    process alterOR_S BIT
    -- > make copy of table
    ---> alter original table
    --> put data back in
    rebuild index
    my expectation was that it would make a copy of the table only once and process the two alter statements. Also when doing the alter separately (test1) it rebuilt the index twice, however using the batch the index was rebuilt once (at least only one message displayed).
    Regards.

  • (oracle 8i)Alter Table table coalesce partition

    Hi all,
    Need assistance in solving a problem. I have a possibly large fragemented table. I tried to run a coalese command ALTER TABLE EMPTY_COPY COALESCE PARTITION
    got an error: 'ora -14501 - object is not partitioned'
    NOt sure how to proceed, I am working in oracle 8i environment.
    Should I do :
    ALTER TABLESPACE MY_DATA COALESCE
    ALTER INDEX EMPTY_COPY_PK COALESCE
    ALTER INDEX EMPTY_COPY_PK REBUILD
    ALTER TABLE MY_DATA.EMPTY_COPY MOVE TABLESPACE NEW_DATA
    Not sure if the syntax is correct or which to use, are there any redundancies in the commands above.
    Thanks kindly for any input you may provide.

    thanks.
    My real problem is an ora 1653 'UNABLE TO EXTEND TABLE' error where I could not insert into a table. The PCT_INCREASE was at 25 and the next_extext was at 160mb. Way too large. There still looks to be l plenty of space available for an another extent but it is not being allocated.
    Would this apply?

  • Alter Table problem

    Hi there. I'm new in Oracle environments. I've a problem with this procedure with the alter table statement.
    CREATE OR REPLACE PROCEDURE HR.PROC_ETL_TAB IS
    CURSOR cursor_ETL IS
    SELECT * FROM ETL_TAB_REF WHERE AVAILABLE_FLAG = 1;
    record_etl ETL_TAB_REF%ROWTYPE;
    VAR_ALTER VARCHAR2(100);
    BEGIN
    OPEN cursor_ETL;
    LOOP
    FETCH cursor_ETL INTO record_etl;
    EXIT WHEN cursor_ETL%NOTFOUND;
    VAR_ALTER:='ALTER TABLE '||record_etl.EXT_TABLE_NAME||' LOCATION('''||record_etl.FILE_NAME||''')';
    DBMS_OUTPUT.PUT_LINE(VAR_ALTER);
    EXECUTE IMMEDIATE VAR_ALTER;
    END LOOP;
    CLOSE cursor_ETL;
    EXCEPTION
    WHEN NO_DATA_FOUND THEN
    NULL;
    WHEN OTHERS THEN
    -- Consider logging the error and then re-raise
    RAISE;
    END PROC_ETL_TAB;
    When I try to call the procedure (call proc_etl_tab()) this error occurs: ORA-01735: invalid ALTER TABLE option. Can anyone help me please? Thanks.

    Pl post details of OS and database versions, along with a sample of what this command would look like when the variables are evaluated
    VAR_ALTER:='ALTER TABLE '||record_etl.EXT_TABLE_NAME||' LOCATION('''||record_etl.FILE_NAME||''')';
    I do not believe ALTER TABLE ... LOCATION ... is a valid command.
    http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_3001.htm
    HTH
    Srini

Maybe you are looking for