Skip to main content

We’re only 3 months live with Apps 10 UPD18 (hosted) and have had a proactive warning from IFS that “/oradata” has reached disk usage of 90%.

I asked for more info and they gave us a list of the biggest objects:

Looks like a HUGE (171GB in 3 months?!) problem with a particular LOB, but how do we interpret what a “SEGMENT_NAME” actually relates to in the system?

I’ve gone back to Support to ask them for more info but if we can be self sufficient that would be good.

select table_name from dba_lobs where segment_name = 'SYS_LOB0000912014C00009$$';

What you might find is that there is not that much actual data in the table (column) you find with the above select. The oracle lob segments get easily fragmented when lots of inserts and deletes happens. there is a background job that should be run frequently (weekly at least in your env).

But now when you have a large lobsegment the first time you run the shrink_lob bg job it might be really heavy. Do it in a service window and have a DBA at hand. Under the hood the Oracle mechanism called to shrink_lob will make a copy of each lobsegment and copy it back… this mean that it will require in your case that you have at least 17Gb free disk space.

Also note that defragmenting the  lobsegment’s will not lower the high-water mark of the datafiles - i.e. it will not return allocated diskspace. (Here is where a DBA will come in handy!)


@hhanse thanks but I’m unable to query that table via EE - does it need to be done through PL/SQL developer or is the table name possibly wrong?

We are hosted by IFS so looks like I’ll need to get our Account Manager involved as we are not in control of the database.


Reply