I've just taken a look at x$ksuse to see if I could spot the significance
of the kssspaflg predicate:
select 'U' flag, indx, ksuseser, ksspatyp, ksusepnm, bitand(ksspaflg,1)
spaflg, bitand(ksuseflg,1) useflag, con_id, ksusepro
from x$ksuse
where bitand(ksuseflg,1)!=0
union all
select 'S' flag, indx, ksuseser, ksspatyp, ksusepnm, bitand(ksspaflg,1)
spaflg, bitand(ksuseflg,1) useflag, con_id, ksusepro
from x$ksuse
where bitand(ksspaflg,1)!=0
order by flag, ksusepro, ksusepnm
What I found with a little grep and vi was that
- there were a few entries that still had program name and ksuseflg set
to 1, but didn't have a process linked, and had the ksspaflg set to 0 - so
they didn't show in v$session. The visible names for these all were
(happened to be) Jnnn or Pnnn (job queue or parallel).
- there were a number of session that had no program name showing, but did
have a linked process. These had the ksuseflg set to 0 (so didn't show in
v$sesion) and the ksspaflg set to 1. Every process (paddr) that appeared in
this set was connected with another session, and the sessions had program
names:
oracle_at_linux183.localdomain (AQPC)
oracle_at_linux183.localdomain (CJQ0)
oracle_at_linux183.localdomain (DBRM)
oracle_at_linux183.localdomain (GEN0)
oracle_at_linux183.localdomain (GEN1)
oracle_at_linux183.localdomain (LREG)
oracle_at_linux183.localdomain (M000)
oracle_at_linux183.localdomain (M001)
oracle_at_linux183.localdomain (M002)
oracle_at_linux183.localdomain (M003)
oracle_at_linux183.localdomain (M004)
oracle_at_linux183.localdomain (M005)
oracle_at_linux183.localdomain (MMNL)
oracle_at_linux183.localdomain (MMON)
oracle_at_linux183.localdomain (OFSD)
oracle_at_linux183.localdomain (Q003)
oracle_at_linux183.localdomain (QM02)
oracle_at_linux183.localdomain (W000)
oracle_at_linux183.localdomain (W001)
oracle_at_linux183.localdomain (W002)
oracle_at_linux183.localdomain (W003)
oracle_at_linux183.localdomain (W004)
oracle_at_linux183.localdomain (W005)
oracle_at_linux183.localdomain (W006)
oracle_at_linux183.localdomain (W007)
(i.e. as the ksuseflg indicates, they're not user processes).
FLights of fancy - do all these sessions actually set up two x$ksuse rows
as they start so that (e.g.) pmon has a "spare" ready if one of them gets
corrupted?
Regards
Jonathan Lewis
On Wed, 9 Mar 2022 at 18:55, kyle Hailey <kylelf_at_gmail.com> wrote:
