I have another video (in addition to what Stefan posted) about channels and
background process communication and even how to trace reliable message
activity between processes (using X$TRACE):
- https://www.youtube.com/watch?v=mkmvZv58W6w&t=2701s
As Jonathan said, these reliable message waits are usually a result of some
higher level activity (too frequent posting of CKPT process due to direct
path reads or truncate/drop operations, where CKPT falls behind, etc).
v$channel_waits may give you an idea of which communication channel types
have the most waits (but doesn't expose which sessions/communication
endpoints or which exact channel cause the most waits).
I also have a channels.sql script (that uses x$) that lists sessions
involved in the communication and shows the channel memory address
(context_ptr). The output is wider than what I pasted here:
SQL> *@channels context_ptr=HEXTORAW('00000000BCE49368')*
CHANNEL_NAME DESCR
FLAGS MESG_COUNT SID
---------------------------------------------------------------- ----------
----------- ---------- ----------
CKPT ksbxic channel XC01
SUB 0 236
SQL> @channels 1=1
CHANNEL_NAME DESCR
FLAGS MESG_COUNT SID
---------------------------------------------------------------- ----------
----------- ---------- ----------
ACL propagation channel sacl
SUB 0 7
AQ post/wait channel 1
PUB 0 -1
AQ post/wait channel 1
PUB 0 -1
AQ post/wait channel 1
PUB 0 707
AQ post/wait channel 1
PUB 0 -1
CKPT ksbxic channel XC01
SUB 0 236
File Extent Array Channel
SUB 10 700
GEN0 ksbxic channel XC07
SUB 0 464
Get Segment Information Channel
SUB 0 700
...
On Mon, May 15, 2023 at 4:55 AM Jonathan Lewis <jlewisoracle@xxxxxxxxx>
wrote:
Is the time spent significant or is this just curiosity.
You've probably got all the information you need from the video that
Stefan referenced, but if not I can add that I've seen this event creeping
up the "Top 10" a couple of times, but I think it's always been a side
effect of something much higher up the list.
One case was an application that kept dropping and creating tables (when
it could have used GTTs or even WITH subqueries in most cases); the others
were RAC systems where there was far too much chatter across the
interconnect all the time, with hundreds or thousands of gc cr and gc cu
requests and blocks hammering back and forth all the time. One of them was
doing a huge number of direct path tablescans with a huge demand for undo
blocks to get read-consistent results.
A query like the following will give you the channel name from the p1
value:
select
ctx.waitcount_ksrcctx,
ctx.waittime_ksrcctx,
nam.name_ksrcdes
from
x$ksrcctx ctx,
x$ksrcdes nam
where
ctx.addr = '000000008C4BA208' -- your p1 left padded to 16
characters with 0
and nam.indx = ctx.name_ksrcctx
/
Regards
Jonathan Lewis
On Mon, 15 May 2023 at 02:13, Jack van Zanen <jack@xxxxxxxxxxxx> wrote:
Hi All
I am trying to find out what the wait
Reliable message with P1 channel context is. I have tried google but no
dice
One of my sessions seem to encounter it a fair bit
Oracle 12.2.01
Thank you
Jack van Zanen
-------------------------
This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.
Thank you for your cooperation