LOBs, NOLOGGING, control file and event 10359

Oracle 11.1.0.7 Std. Linux.

In my DB - LOBs are basicfile-s and NOLOGGING mode. During workload - too much time in
control file sequential read , control file parallel write and CF - enq contetion waits.

Let's ask BOM!

and Bom said...
Don't try to move them to securefile-s or ORA-00600 [ktslghb-1] began parting in your alert.log. Stay with basicfile-s and set event 10359.

From Metalink Note 1058851.6

event="10359 trace name context forever, level 1".

Explanation:
============

If event 10359 is set to level 1, update of the control file with invalidation
redo is stopped. This will not affect any recovery, but note that recovery
manager reports will be stale.

dbms_xmldom. Memory leak. createXMLCharacterInputStream, closeCharacterInputStream

Oracle 11.1.0.7 Std. Linux.

I have such a code.

procedure ...(a_node dbms_xmldom.domnode,a_text in out nocopy CLOB)
...
as
BEGIN
dt2 := dbms_xmldom.getChildNodes(a_node);
dt3 := dbms_xmldom.item(dt2,0);


stream_id := dbms_xmldom.createXMLCharacterInputStream(dt3.id);
...
LOOP
...
dbms_xmldom.readCharacterInputStream (stream_id,
buffer,
num_chars,
false);
...
END LOOP;
dbms_xmldom.closeCharacterInputStream(stream_id);
dbms_xmldom.freeNode(dt3);

END;

Under havy workload my db instance crashes, - being killed by Linux VM OOM killer. Yes, - Out of memory.

Let's Ask Bom!

Memory leaks under tags qmxdsjniAlloc(68 and 28 bytes) and qmxCreateMemCtx(20 bytes) - Yes ?

dbms_xmldom.createXMLCharacterInputStream (creation call)
 qmxdsplsnode_createXMLCIS (C)
  {
...
 qmxdsGetPullNodeAsCharacterStream(...)
 {
      ...
     OraStreamInit(...) ---> memory allocation inside!!!
     OraStreamOpen(...)
 }
  }

dbms_xmldom.closeCharacterInputStream (free call)
qmxdsplsnode_closeStream (C)
{
OraStreamClose(...)
}

Where is OraStreamTerm ?!!! ;))
i patched qmxdsplsnode_closeStream - add OraStreamTerm call.
Now it like watch ;)

dbms_xmldom. Possible Memory leak.LpxInitEncoded0

Oracle 11.1.0.7 Std Linux.

And Bom Said...
While processing XMLType code flows thr LpxInitEncoded0 func.
This function is extended wrapper for XmlCreateNew func with settupping MemManagerFuncs structure as task.

LpxInitEncoded0(...)
{

MemManagerFuncs* p1;
if(...)
 {
     p1 = OraMemInit(...,qmxsaxAllocMem, qmxSaxFreeMem);
 }
 else
 {
     //My DB now using this way
   p1 = 0;
 }
 XmlCreateNew(...,p1,...);
...
}

memory management funcs recived thr p1 would be used for all allocs and frees during parsing XMLType.
Let's detail it.

qmxsaxAllocMem()
{
allocs memory from Oracle heaps
}

qmxSaxFreeMem
{
empty! ;))
}

You saying: "Baby tt's simple - garbage collector". May be, but why Oracle LPX fanatically calls it ?
Using qmxsaxAllocMem and qmxSaxFreeMem funcs inside LPX have another limitation, Oracle could not initialize XMLType for documents with tags(nodes) above 32M(Limitation of Oracle heaps).

I solve both troubles by calling XmlCreateNew with zero as address of MemManagerFuncs struct. In such case XmlCreateNew initializing it by self using simple malloc and free.
Two rabbits killed - no leaks and welcome big nodes.

Flush Buffer Cache

alter session set events 'immediate trace name flush_cache level 1';

Found in Metalink Note : 268302.1