Yeah, *oddc.sql* is just using *O*RA*D*EBUG *D*OC *C*OMPONENT to list all
Oracle kernel components registered with the 11g+ new diagnostic
infrastructure.
I haven't officially announced it yet, but I recently put all my scripts in
to Github and they're formally open sourced too (Apache 2.0 license):
https://github.com/tanelpoder/tpt_oracle/
Also, Frits has consolidated lots of function/module names (some are known
for sure, some are educated guesses) here:
https://fritshoogland.wordpress.com/2017/10/16/oracle-c-functions-annotations/
Tanel.
On Fri, May 18, 2018 at 12:41 PM, Chris Taylor <
christopherdtaylor1994@xxxxxxxxx> wrote:
Tanel,
I was hoping you'd take a look - that's very helpful and I did consult
with the developer earlier and indeed there is a CLOB object used.
I need to go find your oddc script - that looks useful :)
Thanks,
Chris
On Fri, May 18, 2018 at 12:34 PM, Tanel Poder <tanel@xxxxxxxxxxxxxx>
wrote:
Looks like you have a LOB handle leak or something, plenty of bugs around
temporary LOB handles etc. A single process should normally not use that
much memory anyway (if you're not holding some big PL/SQL collection or
workarea in memory).
SQL> @oddc koll
ORADEBUG DOC COMPONENT | grep -i koll
LOB LOB (koll, kola)
LOB_Default LOB Default (koll, kole, kokl, koxs)
LOB_DBLINK LOB DBLink (koll, kokl, kpolobr, kkxlr)
