Truncate Table MyTable Reuse Storage

I have a table with approximately 46,000 records in it which gets truncated and re-filled once or twice per month. I have been truncating it in a procedure and was reading about the REUSE STORAGE clause which I am interested in for efficiency's sake. But I was wondering, if my newly inserted rows exceed the 46,000 by a few thousand, will I get an error and run out of space for the inserts? In other words, does it lock me into the space for the former 46,000 records and that's it? It works fine right now, and I don't want to introduce risks, but I thought to do a few little things to speed things up.

After 46,000 rows if more space is needed and your table does not reaches maximum extent allowed limit .you will not face any problem.
Thanks.

Similar Messages

TRUNCATE with/without REUSE STORAGE

Hi,
Daily 3 million records are INSERT'd into table BIGTABLE.
At month-end data from this table is INSERT'd into another table and then BIGTABLE is TRUNCATE'd.
The TRUNCATE takes 3-4 hours.
BIGTABLE
Field1 Varchar2
Field2 Date
Field3 Number
I'd like to know if significant time can be saved if TRUNCATE TABLE BIGTABLE REUSE STORAGE is used.
If not, is there a better approach to quickly empty this table?

I'd like to know if significant time can be saved if TRUNCATE TABLE BIGTABLE REUSE STORAGE is used.
Don't be afraid of breaking Oracle by actually TRYING things.
What happened when you tried using REUSE STORAGE?
If you are going to be reloading the table with about the same amount of data then just use REUSE STORAGE. That way Oracle does not have to deallocate all of the extents and then reallocate them again as you INSERT new rows.

Sqlloader truncate with Reuse storage

hi Gurus,
Version in use is 10g
How to use "Reuse storage" option with Truncate option in SQLLOADER
pls help
Thanks in advance

SQL> create table a (id number);
Table created.
SQL> alter table a allocate extent;
Table altered.
SQL> select * from user_extents where segment_name='A';
SEGMENT_NAME                   PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME         EXTENT_ID
A                                                             TABLE              DATA                            0
A                                                             TABLE              DATA                            1
SQL> truncate table a reuse storage;
Table truncated.
SQL> select * from user_extents where segment_name='A';
SEGMENT_NAME                   PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME         EXTENT_ID
A                                                             TABLE              DATA                            0
A                                                             TABLE              DATA                            1
SQL> truncate table a;
Table truncated.
SQL> select * from user_extents where segment_name='A';
SEGMENT_NAME                   PARTITION_NAME                 SEGMENT_TYPE       TABLESPACE_NAME         EXTENT_ID
A                                                             TABLE              DATA                            0
SQL>

Truncate with Reusing Storage

Hi ,
Is there any side effects if i ssue
SQL > turncate table Reusing Storage;
the Reusing Storage makes my deleting process faster then normal truncate Or delete right ?
pls tell me in simple why Reusing Storage on truncateing ?
thnx a lot guy's
-Raj

Your best bet is to check out the documentation:
TRUNCATE
*REUSE STORAGE*Specify REUSE STORAGE to retain the space from the deleted rows allocated to the table or cluster. Storage values are not reset to the values when the table or cluster was created. This space can subsequently be used only by new data in the table or cluster resulting from insert or update operations. This clause leaves storage parameters at their current settings.
If you have specified more than one free list for the object you are truncating, then the REUSE STORAGE clause also removes any mapping of free lists to instances and resets the high-water mark to the beginning of the first extent.
Examples
Truncating a Table: Example
The following statement removes all rows from a hypothetical copy of the sample table hr.employees and returns the freed space to the tablespace containing employees:
TRUNCATE TABLE employees_demo;
The preceding statement also removes all data from all indexes on employees and returns the freed space to the tablespaces containing them.
Retaining Free Space After Truncate: Example
The following statement removes all rows from all tables in the personnel cluster, but leaves the freed space allocated to the tables:
TRUNCATE CLUSTER personnel REUSE STORAGE;
The preceding statement also removes all data from all indexes on the tables in the personnel cluster.

Recovering Data from a truncated table in OraXE?

A funny thing happened, i truncated a table containing BLOBs and other stuff, with over 700 entries!!, now i wanna know if it´s feasible to recover that truncated data, i'm just wondering about it, i know it sounds silly i know, but the storage space didn´t get shorter after the data was truncated from the table, so after this´s been said, can any body explain me what happened, can i retrieved this truncated data that i truncated from the table (without any previous backup)?
Message was edited by:
efebo_abel2002
Message was edited by:
efebo_abel2002
Mensaje editado por:
efebo_abel2002

Truncate simply resets the pointer that marks the 'end of data' in a table to the beginning of the table. The storage is still allocated, on the assumption that you want to reuse the table and want to avoid the overhead associated with extending the table. The system knows there are never any rows past the 'end of data' and it won;t bother looking past that point.
Recovering that data from the actual current database - about as likely as recovering data from the Windows recycle bin when you've set the max allowable storage in the recycle bin to '0'. Technically possible, but needing someone with a lot of experience and patience ... and absolutely no changes to the database after truncate. An expensive proposition.
You have, of course, switched to archive log mode and been taking regular backups. (Have you not?) In which case, a 'point in time' recover, to just before the truncate, would be the solution. This brings back the database (or at least a tablespace) back to a former 'life', and is quite different from restoring a table.

Truncate table that has 2 billion rows

Hi,
Our DB is 11g and approximately any idea howmuch time it takes and do we need to rebuild indexes after truncate?

>
Our DB is 11g and approximately any idea howmuch time it takes and do we need to rebuild indexes after truncate?
>
Before you do that - do you plan to reload the table with a similar amount of data?
If so then you might want to use the REUSE STORAGE clause so that Oracle doesn't have to deallocate and then immediately reallocate the storage.
See the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_10007.htm
>
REUSE STORAGE Specify REUSE STORAGE to retain the space from the deleted rows allocated to the table. Storage values are not reset to the values when the table or cluster was created. This space can subsequently be used only by new data in the table or cluster resulting from insert or update operations. This clause leaves storage parameters at their current settings.
>
If you plan to do a large reload you should consider dropping or disabling the indexes and then adding/rebuilding them after the data load.

ORA-01502: Index or Partition is in unusable status. while truncating table

Hi All,
One of our Devlopers compalined that he is getting ORA-01502 : Index or partition is unusable status while truncating the a table in our Dataware house production database. He is using the following commands.
Alter index <index_name> unusable;
Truncate table <table_name> ;
He is running a scripts to truncate each table and ecah time he is passing the table name as an input parameter to script. He is using same method to truncate four tables each having a BITMAP and a REGULAR index. For two tables every thing is working fine, but for other two tables the he is getting ORA-01502 for BITMAP indexes. It a weekly process and every week he is getting the same issue. I checkd the Index status, they are in valid status only.
For a work around I have created a table with BITMAP and regular index in our dev database. made the indexes unusable, checked their status. I truncated the table. Importent thing here is the Indexes are becoming vaild when I truncate the table.
I suspect that my devloper's Indexes were already in unusable status (before he use the command ALTER INDEX), when he truncated the table, oracle trying to validate the index and throwing the error ORA-01502 because the Indexes are in unusabel statsu for a while.
I tried searching for the mechanism of truncate table command and its effect on Indexes. But I did not find any luck, no one is speaking about index when truncating the table. Can any one please help me????
Sorry for lengthy post. Any help is greatly appriciated and I thank every one in advance.

DDL for Indexes getting ORA-01502 error
CREATE BITMAP INDEX DWHMGR.ACT_TXN_LN_STG_01_XN3 ON DWHMGR.ACCT_TXN_LINE_TERM_BAL_STG_01 (TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN3 ON DWHMGR.ACCT_TERM_BAL_STG_01 TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Indexes that have no issues.
CREATE INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN2 ON DWHMGR.ACCT_TERM_BAL_STG_01 (ACCT_REF_NB ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_PRC_STG_01_XN1 ON DWHMGR.ACCT_PRC_STG_01 (ACCT_ORG_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Please look at the DDL of the indexes and let me know if you need any other information.

Does a truncate table solve corrupt blocks in a table

Hi Guys,
Got a question:
Does a truncate table solve corrupt blocks in a table?
I have found corrupt blocks in rman, located them, they are in 1 table.
And contacted the business, and have permission to drop and recreate the table,
but my question is does truncate table drop storage also solves my problem?
And will it let me to do a full backup without set max corrupt blocks?
To my knowledge does a truncate table moves the high watermark to 0 + 1 extend, but I am unsure how this will effect the corrupt blocks.
Thanks in advance for your advice

Hi,
Yes truncate/drop table fixes the corruption at the database level. You may like to take the backup(if you have index on it) of that table so that you may restore it later if anything goes wrong.
Note: This would not fix any corruption at the disk level (like bad sectors).
Regards
Anurag

Data factory truncate table

I'm copying data from table storage to a sql azure database. Im using ADF. Im able to setup the process. I want to schedule a recurring meeting and add a truncate table. How do you delete all records in the sql azure database?

Hi Julius,
You could use a Stored Procedure to handle the delete and insert, in the Sink (Destination) side of the Copy Activity.
Borrowing from another recent reply:
You can specify the property "SqlWriterStoredProcedureName" and "SqlWriterTableType" in SqlSink, and add the merge logic in your own stored procedure. Notice that don't use a simple delete operation in the stored procedure, as it may
be called several times in a single Copy.
For more information about how to use this feature, refer to this post.
and the Azure documentation here http://azure.microsoft.com/en-us/documentation/articles/data-factory-copy-activity-advanced/
Thanks, Jason
Didn't get enough help here? Submit a case with the Microsoft Customer Support teams for deeper investigation - Azure service support: https://manage.windowsazure.com/?getsupport=true For on Premise software support go here instead: http://support.microsoft.com/select/default.aspx?target=assistance

Full Load: Error while executing :TRUNCATE TABLE: S_ETL_PARAM

Hi All,
We are using Bi Apps 7.9.6.1. Full Load was running fine. But Now we are facing a problem with truncating a table "S_ETL_PARAM".
I have restart informatica Server And also DAC Srever. But still I am getting the same in the DAC Log as, *"NOMALY INFO::: Error while executing : TRUNCATE TABLE:S_ETL_PARAM*
*MESSAGE:::com.siebel.etl.database.IllegalSQLQueryException: DBConnection_OLTP:SIEBTRUN ('siebel.S_ETL_PARAM')*
*Values :*
*Null Map*
*EXCEPTION CLASS::: java.lang.Exception"*
Any Suggestion.....
Thanks in Advance,
Deepak

are you trying to run incremental load when you get this truncate error? can you re-run full load and see that still runs ok? pls also check your DW side database logs like alert lor any DB level issue. such errors do not throw friendly messages in DAC/Informatica side.

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

What is the recommended way to truncate tables in ODI?

I want to create a separate step to truncate the result tables, before the start of the actual job. What is the recommended way of doing this?
I am currently putting the truncate statements in the ODI procedure, but that has a lot of typing. Is there a odi command in the toolbox that I can use?
Thanks.

Ok,
If the table will be loaded by interfaces, you have the "Truncate" option at the IKM's, just change it to "Yes".
If you need to Truncate but they won't be loaded by Interfaces a possible way is:
- requirements: it will be necessary to have some common "string" at tables names.
1) create a procedure
2) create an step
3) at source tab put:
Select table_name from user_tables where table_name in '%THE_STRING%'
4) at target tab put:
Truncate table #table_name
If you don't have a common "string" you, instead, can create a table with all table names that you need to truncate and change the select command at 3).
Does it help you?
Message was edited by:
Cezar_Santos

Truncate Table before Insert--Performance

HI All,
This post is in focus of special requirement where a table is truncated before inserting records in the table.
Now, when a table is truncated the High Water Mark(HWK) is reset to lowest memory allocated for table in tablespace. After this, would insert with append can boost the performance of the insert query?
In simple insert query, the oracle engine consults the free list to look for free spaces.
But in insert with apppend, the engine starts above the HWM. And the argument is when truncate has been executes on table, would the freelist be used in simple insert.
I just need to know if there are any benefits of using append insert on truncated table or simple insert would be same in term of performance with respect to insert with append.
Regards
Nits

Hi,
if you don't need the data truncate the table. There is no negativ impact whether you are using an conventional path or a direct path insert.
If you use append less redo is written for the table if the table is in NOLOGGING mode, but redo is written for all indexes. I would recommand to create a full backup after that (if needed), because your table will not be recoverable after that (no REDO Information).
Dim

Raising ora-01426 error while truncating table

Hi,
We have a procedure which executes in the following process for few set of tabls
1. disables the constraints
2. truncating the tables
3. enabling the constraints
but after processing for 5 tables, while truncating the error throws
BEGIN <procedure name >; END;
ERROR at line 1:
ORA-01426: numeric overflow
ORA-06512: at "<procedurename> ", line 33
ORA-06512: at line 1
this line 33 point to execute immeidate 'truncate table < table name>
Can i know what would be reason for throwing ' numeric overflow' error while truncating table..
Thanks in advance

user9080289 wrote:
thanks.
My oracle verision is 11gThen you could have the bug described there. Follow the instruction how to workaround (monitoring flush, set stats to low value) or apply the patch #8226471.
Nicolas.

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.

Truncate Table MyTable Reuse Storage

Similar Messages

Maybe you are looking for