Re: SECUREFILES disaster
Date: Sat, 28 Apr 2012 13:36:17 +0000 (UTC)
Message-ID: <pan.2012.04.28.13.36.17_at_gmail.com>
On Sat, 28 Apr 2012 10:01:37 +0100, Jonathan Lewis wrote:
> I have seen that, but not for quite a long time, and it was with ASSM
> tablespaces.
>
> But I've also seen that with bitmap indexes, btree indexes, and simple
> heap tables in various versions and under various circumstances in the
> complete absence of LOBs. Apart from things that you could definitely
> call bugs, these phenomena also appear when some Oracle developer has
> missed a possible boundary condition in how an application may use their
> feature so my typical approach is to figure out where the collision is
> between the types of things that Oracle is probably doing and the nature
> of the application activity.
Jonathan, I am not aware of any free space regulating mechanisms within a LOB segment. Within the table segment, there are free lists or the lists of blocks with 25%,50% and 75% of used space, index segments have their own mechanism, but no such things for LOB segments. Mathias Hoys has recently posted a thread about less then 7000 rows consuming 900MB. It was an Apex table and the culprit was LOB. I had a close encounter with LOGMNR_SPILL$ table, which had its LOB column SPILL_DATA grow over 32GB. The version was 10.2.0.5, 64bit. The database itself is a logical standby used for reporting purposes, LogMiner cannot be avoided. I had to run "SHRINK SPACE COMPACT CASCADE" on that table. The table is owned by the user SYSTEM and is located in SYSAUX tablespace. I have been firefighting LOB segments explosion for the last 5 years.
-- http://mgogala.byethost5.comReceived on Sat Apr 28 2012 - 08:36:17 CDT