Relax, I’m talking about the Oracle Database kernel here, not the corporation ;-)
Here’s a couple of more reasons why not to play around with undocumented debug events unless you’re really sure why and how would they help to solve your specific problem (and you’ve gotten a blessing in some form from Oracle support too):
$ oerr ora 10665 10665, 00000, "Inject Evil Literals" // *Cause: Event 10665 is set to some number > 0, causing 1/(value-1) of all // literals to be replaced by 2000 letter 'A's. A value of 1 does // not corrupt anything. // *Action: never set this event $ oerr ora 10668 10668, 00000, "Inject Evil Identifiers" // *Cause: event 10668 is set to some number > 0, causing 1/(value-1) of all // identifiers to be replaced by a maximum amount of x's. It is // common for an identifier to be parsed once with a max of 30 bytes, // then reparsed later with a max of 4000, so it may not be possible // to inject such an identifier without the aid of this event. A // value of 1 causes no identifiers to be corrupted. // *Action: never set this event
Some events are meant to be left alone. You don’t want to wake up the evil sleeping deep in the core of the Oracle Kernel-land!
By the way, Karl Arao once managed to capture what this evil creature looks like:
NB! If you want to move to the "New World" - offload your data and workloads to Hadoop, without having to re-write your existing applications - check out Gluent. We are making history! ;-)