Shrinking ibt1/OIBT table

Hello all:
A Customer that does everything by batch (they are pharm) is reaching performance issue with their OIBT and ibt1 table. They have close to 1 million record in OIBT and probably twice as much on ibt1 table. And now their logistics operation are slow when they do pick, delivery pretty much anything. We see a huge CPU and paging memory surge whenever SBO try to eaccess the ibt1 table specially.
With archieving capability in 8.8 not covering the old batch records. What can we do to make their records samller. Keep in mind that 99% of table content are old stuff. I understand they need it to keep a transaction log. But if they keep on doing this way, their system will crash for sure!.
Sincerely Yours
Bo Peng

Hello there,
any news about this issue has been solved? We are experimenting the same problem but we are talking about thousand of transaction we are not even talking about millions of them. We got SAP B1 ver. 8.81 PL 10.
By the way I don't find anymore those table OIBT and IBT1 since when we switch from SAP 2005 to SAP 2007... what happend to those table? Has been replaced by what table? We had to make a work around creating some view called OIBT and IBT1 in order to don't change all the report based on those table
Thanx for any help

Similar Messages

"Invalid segment" when shrinking a partitioned table

I'm encountering the following error when trying to shrink space compact for a partitioned table. Would you know how can I go about this?
I need to make it work.
SQL> alter table PS_SGSN_1_MONTH modify partition P_201304 shrink space compact;
alter table PS_SGSN_1_MONTH modify partition P_201304 shrink space compact
ERROR at line 1:
ORA-10635: Invalid segment or tablespace type
My Oracle DB version is 11gR2

Yes, that would be the right thing to do to check how and where MV is being used and what downtime you can get to fix this. Check if you can change the Materialized view to create based on primary key instead of Row id.
Steps would be
1 drop the materialized views related
2 drop the materialized views logs
3 shrink the tables and indexes
4 recreate the materialized views log
5 recreate the materialized views
Also, there is a bug with the primary key as well. Check this
Bug 13709220 - ORA-10663 when shrinking a master table of an MVIEW with primary key (Doc ID 13709220.8)

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.

Error ORA-10635 when shrink a table!!

Hi all,
I have a table created in a tablespace using ASSM and when i try to shrink this table i receive the error ORA-10635. I can do shrink on other tables that are on the same tablespace of that table that is giving me this error.
Anyone can help please??
Tks,
Paulo.

10635, 00000, "Invalid segment or tablespace type"
// *Cause: Cannot shrink the segment because it is not in auto segment space
// managed tablespace or it is not a data, index or lob segment.
// *Action: Check the tablespace and segment type and reissue the statement

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,

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

Can I use shrink for Tables and Indexes

Hi Experts,
I am planning to run shrink on large tables and indexes to reclaim space, I would like to know what are the dis-advantages or limitations of shrink on e-business suite.
Architecture
Four node application server (R12.1.1)
Four node rac db (11gr2)
HP OS.

Hi;
Please see:
Using SHRINK or DELETE on tables FND_LOG_MESSAGES, FND_TEMP_FILE_PARAMETERS, FND_LOBS in EBS [ID 1066580.1]
Regard
Helios

Why Segment shrink is not supported for tables with function-based indexes

As we all know , Segment shrink is not supported for tables with function-based indexes.
But i'm very confused .
Why Segment shrink is not supported for tables with function-based indexes ?? what's its essential?

Creating a function based index creates a hidden virtual column (you'll see it if you query user_tab_cols) and once you index a virtual column you can no longer shrink the table:orcl> create table t1(c1 number,c2 as (c1 * 2)) segment creation immediate;
Table created.
orcl> alter table t1 enable row movement;
Table altered.
orcl>
orcl> alter table t1 shrink space;
Table altered.
orcl> create index i2 on t1(c2);
Index created.
orcl> alter table t1 shrink space;
alter table t1 shrink space
ERROR at line 1:
ORA-10631: SHRINK clause should not be specified for this object
orcl>so the issue is not with function based indexes per se, it is a level beneath that. Perhaps because the virtual column has no physical existance, when the row is moved there is no reason for Oracle to realize that an index needs updating? I haven't attempted to reverse engineer this, I would be interested to know if anyone else has.

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

Need to reclaim space from dwh tables.

We have couple of large tables (> 200G) in one of the DWH schema. I need to reclaim space on the mountpoint.
I have used ALTER TABLE <> MOVE COMPRESS; command to compress these tables.
Now in dba_segments it is showing the improvement. 200g table came down to 60G. However I am not able to see any change in datafile and in mountpoint, I beleive due to the HWM.
I tried shrink for the tables, it did not help.
Could you please suggest any other approach.

refer to
http://jonathanlewis.wordpress.com/2010/01/30/free-space/
http://jonathanlewis.wordpress.com/2010/02/06/shrink-tablespace/
Anand

Delete AUD$ table do not free space

Hi,
We have an Oracle 10g database (10.2.0.4) with the Oracle auditing feature on.
Our problem is that I delete on regular basis the AUD$ rows, but the system do not free the space on the tablespace. The system free the space only after a truncate.
The actual situation is:
SQL> select segment_name,bytes/1024/1024 as Mb from dba_segments where bytes/1024/1024 > 1000 and TABLESPACE_NAME='SYSTEM';
SEGMENT_NAME MB
AUD$ 10161
SQL> select count(*) from sys.aud$;
COUNT(*)
+1073+
Someone can help me with this!?
The delete of the table is done with a simple script:
select count(*) from sys.aud$;
delete from sys.aud$ where NTIMESTAMP# < sysdate -(1/24*6);
select count(*) from sys.aud$;
commit;
exit;
Thanks
Nunzio

Nunzio Cafarelli wrote:
EdStevens wrote:
Nunzio Cafarelli wrote:
Hi,
thanks for your answer.
The scrink and the coalesce feature do not works:
SQL> alter table SYS.AUD$ enable row movement;
alter table SYS.AUD$ shrink space;
alter table SYS.AUD$ coalesce;
Table altered.
SQL> SQL> alter table SYS.AUD$ shrink space
ERROR at line 1:
ORA-10635: Invalid segment or tablespace type
SQL> SQL> alter table SYS.AUD$ coalesce
ERROR at line 1:
ORA-01735: invalid ALTER TABLE optionthe only way I have is to move the table in a different tablespace and in case move back.
Do you know if that is a know bug!?No it is not a bug.
Why are you concerned about the space being released? If it were you'd just have to re-aquire it as new rows are added to the table.
As rows are added, when an extent is filled a new extent is allocated. If rows are deleted those extents remain allocated to the table and are re-used as needed. The aud$ table is a perfect example of a table which most definately will need to reuse that space, so it it a total waste of effor to try to reclaim it.Hi, that is the real point, it seems that the table don't use the allocated space.
It constantly grows and reclaim new space. That is the real problem for me.You haven't demonstrated that. You only showed us a one-time snapshot of the space used and the row count.
You need to track this over several days / iterations of deleting rows. Show us that over a period of time the row count is fairly stable and yet the space used continues to increase.
If, today the rowcount is 'x' and the space allocated (measured in blocks or extents) is 'y', and you delete a bunch (or even all) rows, space allocated should remain 'y'. Then tomorrow, you should have near 'x' rows again (assuming a fairly level amount of audited activity). And space allocated should still be 'y' .. maybe allowing for a slight increase in 'x' triggering one more extent. But if you are regularly pruning the row count, the number of extents should stabilize. If not, then you do have an issue, but I haven't yet seen proof of that happening.
>
>>
Can this create problems since AUD$ is a system table!?No, but you don't want a very active table like that in your SYSTEM tablespace. Oracle puts it there by default, but there have been well known procedures on the net for YEARS on how to move it to another TS. Thanks
With 11g, they've even introduced the dbms_audit_management package to help with these tasks.I know, I hope the my customer will authorize the upgrade soon.
Thanks for your suggestion to upgrade sybrand_b, but as you can understand, sometime the upgrade are not possible until the software vendor will authorize that, so, we need to work on version 10.2.0.4 for some other months.
Regards
Nunzio
P.S. I think that there are problems, after the move of the table to a different tablespace, and the move back to SYSTEM, the used space was around 2Gb, but I was not able to resize the datafile. Don't move it back. Get it out of SYSTEM and leave it there.I think that I'll do this, at least to not risk the corruption of the system tablespace.
Thanks again for your answers.
regards
Nunzio

Table Management in oracle 11g

I am using 11g database, I have to release some space tablespace level.
Here this is the situation.
One of the big table (CAMPAIGN_REPORT_RAW), i guess more fragmenation is there in that table.
It is created under INCIH_DATA tablespace (having 10 datafiles).INCHIH_DATA tablespace occupying 33 GB , in that 25 GB used space 8 GB freespace. We are using filesystem management.
In that respective filesystem we have to get 10 GB space for creating new tablespace. Unfortunately we dont have that much space in that filesystem, For that my plan is shrink the CAMPAIGN_REPORT_RAW table, resize the datafile!!
ALTER TABLE CAMPAIGN_REPORT_RAW SHRINK SPACE;
ALTER TABLE CAMPAIGN_REPORT_RAW SHRINK SPACE CASCADE;
alter database datafile '<full_file_name>' resize <size>M;
for that
I need your help to get the command for
1) how to find the size of the table
2) how to find the used size of the table
3) how to find the Hight Water Mark level of the table
4) how to find this table occupying which datafile
Thanks

Take a guideline from http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/schema003.htm#ADMIN10161
Size of a table can be seen by,
select * from dba_segments where segment_name='<your table name>';
Above query is the 'used' size of the table. Minimum unit of allocating space in Oracle is an 'extent'. So, even if 90% of the extent is empty, you cannot reclaim those blocks, so there is no point in finding empty/used blocks of data.
You can only find out which tablespace the table belongs to. We cannot find out which 'datafile' the table is in and we do not need to know that as well. Tell me why you want to know it?

Batch number not appearing in OIBT

Dear Experts,
I am facing a problem concerning a Receipt from production. In fact, I have a query running in order to print label. In this query I take the batch number on OIBT table, (link to IGN1 through Baseentry, BaselinNum and BaseType)
There is one case where there is no information on OIBT for the document whereas there is a Batch number assigned to the production receipt (see screen shots ).
What can explain this situation ?
Thank you for your help.
best regards
Sébastien TABORE

Dear Nagarajan,
The query is the following one :
Declare @res as table(docEntry int , linenum int , itemcode nvarchar(20) , itemname nvarchar(100), unit nvarchar(20) ,U_DKE_CONDITION nvarchar(8) , U_DKE_CONDITION_value numeric(19,6) , BatchNum nvarchar(20) , Expdate datetime ,Proddate datetime, quantity numeric(19,6))
Declare @DocEntry as int
Declare @Linenum as int
Declare @U_DKE_CONDITION_value as numeric(19,6)
Declare @quantity as numeric(19,6)
Declare @batchNum as nvarchar(20)
Declare @count as numeric(19,6)
Declare @ik as int
Declare cursor1 cursor for
SELECT T0.[DocEntry] , T0.[LineNum], case when isnumeric(t3.name) = 1 then cast(t3.name as numeric(15,2)) else 0 end as u_dke_condition_value
, T2.Quantity , T2.batchNum FROM [dbo].[ign1] T0
inner join [dbo].[OITM] T1 on T0.Itemcode = T1.ItemCode
Inner join [dbo].[OIBT] T2 on T2.Baseentry = T0.DocEntry and T2.BaseLinNum = T0.LineNum and T2.BaseType = T0.ObjType
inner join [dbo].[@DKE_CONDITION] T3 on T1.u_dke_condition = t3.code
Where T0.Docentry = [%DocEntry]
order by T0.[DocEntry] , T0.[LineNum], T2.batchNum
open cursor1
fetch next from cursor1 into @DocEntry , @Linenum , @u_dke_condition_value , @quantity , @batchnum
if @@fetch_status = 0 set @ik = 0 else set @ik = 1
while @ik = 0 and @u_dke_condition_value > 0
Begin
set @count = 0
While @count < @quantity
Begin
Set @count = @count + @u_dke_condition_value
Insert into @res
SELECT T0.[DocEntry] , T0.[LineNum], T0.[ItemCode], T1.Itemname , T1.SalUnitMsr , T1.U_DKE_CONDITION ,
case when isnumeric(t3.name) = 1 then cast(t3.name as numeric(15,2)) else 0 end as u_dke_condition_value
, T2.BatchNum , T2.ExpDate, T2.PrdDate , T2.Quantity FROM [dbo].[ign1] T0
inner join [dbo].[OITM] T1 on T0.Itemcode = T1.ItemCode
Inner join [dbo].[OIBT] T2 on T2.Baseentry = T0.DocEntry and T2.BaseLinNum = T0.LineNum and T2.BaseType = T0.ObjType
inner join [dbo].[@DKE_CONDITION] T3 on T1.u_dke_condition = t3.code where T0.[DocEntry] = @Docentry and T0.[LineNum] = @LineNum and T2.batchnum = @batchnum
End
fetch next from cursor1 into @DocEntry , @Linenum , @U_DKE_CONDITION_value , @quantity, @Batchnum
if @@fetch_status = 0 set @ik = 0 else set @ik = 1
END
Close cursor1
deallocate cursor1
Select * from @res
For your information
The concerned batch is included in your query's result.
Thank you for your help.
best regards
Sébastien TABORE

Best practices in Queue table maintenance

Hi Fellow AQ Users,
I am looking to hear from the community about best practices in queue table maintenance.
I have been mining through metalink about various Oracle recommendations and putting
together a set of recommendations as a starting point for my DBAs.
I am looking to answer questions like these --
How often (in relation to messaging load) would you coalesce and rebuild the indexes?
How often would you rebuild the table itself to get rid of the high water mark issues ?
and what procedure would you use to do that?
Would really love to learn from your experiences in this area. We are using 9.2.0.7
64 bit DB and have plans to go to 10g over the next year. So, I am looking at 9i related
stuff and then 10g.
Thanks
Vijay

Hello,
In general you coalesce once per day ideally during a quiet time to avoid ORA-54 errors as per <Note:271855.1>. Some customers do it more often than that but once per day is a good starting point.
In terms of shrinking the queue tables you can use the procedure in <Note:304522.1> with a null 3rd parameter. This is an offline procedure so you could only run it during a maintenance window. In 10.2 onwards you can dynamically shrink the queue table and IOTS. Again it depends on exactly what you are doing with your queue tables how often you might need to do this.
Thanks
Peter

Table rebuild should be done after removing most of its data?

Hi All,
We are on Oracle 10.2.0.4 on Solaris 10. There is a table in my production db that has 872944 number of rows. Most of its data is now unnecessary, we need to retain, based on a date column in the table just last one month's data and delete rest of the data. So after that the table will have just 3000 rows.
However as the table was huge earlier(872k rows prior to delete) , does the delete of data release its oracle blocks and does the size of the table reduce? If not, will it help to rebuild the table online (online redefinition) so that the query that does a full scan on this table goes faster?
I checked using an example table that just delete of data does not remove the oracle blocks - they remain in the user_tables for that table and cost of full table scan remains same. We have a query that does the full table scan so I am thinking that after this delete I should do an online table re-definition , is that the right decision?
Thanks

If you really really need to do some such thing, look at the ALTER TABLE tablename SHRINK and ALTER TABLE tablename SHRINK COMPACT commands.
Note that these will generate a high volume of Undo and Redo !!!
(also, the commands require that the target tables/indexes be in ASSM tablespaces)
And :
Also aware about the effect the shrink will have on the clustering factor of the table indexes. The shrink command allows you to gain space by filling gaps at the start of the table by data coming from the end of the table. This move of data will damage the clustering factor of related indexes and hence their desirability by the CBO.
Hemant and Mohamed Houri @ Re: Adjusting high water mark with move
So, it does not mean that what can be done or not; the thing should be considered that whether it is required, is it feasible, will it gain some performance.
Anti-biotic are good, but when and how; doctors knows it... :)
Regards
Girish Sharma
Edited by: Girish Sharma on Oct 23, 2012 7:25 PM
Continued....
If ALTER TABLE...SHRINK SPACE is good option for you, John would have mentioned, but he did not, because its not that much "considerable" thing.
Edited by: Girish Sharma on Oct 23, 2012 7:30 PM
Probably some issue with forum software on Opera on Windows xp, it corrupts earlier posted links...

Shrinking ibt1/OIBT table

Similar Messages

Maybe you are looking for