Re: set events: control the number of sessions that dump trace

From: Mikhail Velikikh <mvelikikh_at_gmail.com>
Date: Tue, 20 Aug 2019 19:55:28 +0100
Message-ID: <CALe4HpnPZk4OD91SbMwsgA+eGBD6ws2-vyYBrZQAbGsU8ObQeQ_at_mail.gmail.com>



Hi Jared,

It is possible to setup an event generated incident like this:

alter system set events '1555 incident(sto)';

Then, a standard flood-control kicks in after a certain number of incidents (please see the following MOS article for the thresholds: DIA-49435 When Trying To Create An Incident Packet (Doc ID 1358087.1)).

For instance, in my 19c database I have got five incidents and the sixth was flood controlled.
Here is a relevant excerpt from the trace file:

DDE: Problem Key 'ORA 700 [EVENT_CREATED_INCIDENT] [1555] [STO]' was flood controlled (0x2) (incident: 111062)

That is not exactly what is required but it is the closest I can come up with.

Best regards,
Mikhail Velikikh

On Tue, 20 Aug 2019 at 17:49, Jared Still <jkstill_at_gmail.com> wrote:

> Hello,
>
> Does anyone know if it is possible to control the total number of trace
> files created by 'alter system set events' ?
>
> For example, the following command will cause all sessions to dump stack
> traces when there have been at least 2 occurrences (armcount) of ORA-1555
> in a session:
>
> alter system set events '1555 trace name errorstack level 3, armcount 2,
> lifetime 2';
>
> After 2 events have occurred (lifetime) then the session will stop dumping
> stacks for this error.
>
> What I would like to be able to do is limit this system wide.
>
> Say for instance 3 sessions dump stack traces for ORA-1555.
>
> I would like to limit this to N system wide dumps of stack trace.
>
> So after 3 sessions have created a trace file, no other sessions should do
> so.
>
> The reason is that if left unattended, when many session incur ORA-1555,
> then this could potentially be quite a few rather large files.
>
> The idea of course is to be able to set and forget, until the next event.
>
> And yes, I know that TFA could be setup to deal with this, but that is
> another story...
>
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Principal Consultant at Pythian
> Pythian Blog http://www.pythian.com/blog/author/still/
> Github: https://github.com/jkstill
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Aug 20 2019 - 20:55:28 CEST

Original text of this message