Usn's IT Blog

srvctl in Oracle Grid Infrastructure 11g Release 2 has at least one discrepancy between docs and functionality.

I saw EONS consuming lots of memory in a non-database grid installation, and wanted to get rid of it. (The eONS is used by Oracle Enterprise Manager to receive notification of change in status of components managed by Oracle Restart.) Documentation tells us, it would work:
See the docs for removing eons with “srvctl remove eons”.

But if you try in reality:

[oracle@ASM01 ~]$ LANG=C srvctl remove eons -f -v
Usage: srvctl <command> <object> [<options>]
commands: enable|disable|start|stop| <...>
objects: database|instance|service| <...>
For detailed help on each command and object and its options use:
srvctl <command> -h or
srvctl <command> <object> -h
PRKO-2013 : eons object is not supported in Oracle Clusterware
[oracle@ASM01 ~]$

Repeat: PRKO-2013 : eons object is not supported in Oracle Clusterware
Nice.

Read more…

Many topics are to be found on the web about IMPDP and UNDO_RETENTION. This one will become a more theoretical one, around the central question: Why, please why does a huge IMPDP fail with ORA-1555 if there is too less UNDO_RETENTION configured?

Like so often, these questions come from a problem. I had to impdp about 30GB from one machine to another via database link. (For newcomers to this technology, this is done via impdp on the target machine, no expdp needed, no dumpfile is created.) The impdp failed with ugly ORA-1555s after about 2 1/2 hours. It happened after the import itself, but during the index creation. The web said in several places, that increasing the UNDO_RETENTION period will help, but I have not been able to explain it. For my understanding, UNDO_RETENTION was something to enable flashback-table-like operations over a longer period in a busy database.

Oracle Support
So I opened a Service Request in order to get some clarification. The result was:

QUESTION
——–
Why does the undo_retention affect the impdp behaviour?

Read more…