Re: $sysmetric 'Session Count' != Count(*) from v$session;

Thanks for all the details on this!

1. 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).

Is this like Oracle using v$sysmetric for # of sessions licensing and charging on the potential of running parallel query and job queue processes even though they are not actually running ... bizarre

On Thu, Mar 10, 2022 at 11:25 AM Jonathan Lewis <jlewisoracle_at_gmail.com> wrote:

>
> 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
>
> a) 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).
>
> b) 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:
>
>>
>> Anyone know why the following two are different?
>>
>> SQL> select metric_name, value from v$sysmetric where metric_name = 'Session Count';
>>
>> METRIC_NAME VALUE
>> ---------------------------------------------------------------- ----------
>> Session Count 84
>>
>> SQL>
>> SQL> select Count(*) from v$session;
>>
>> COUNT(*)
>> ----------
>> 58
>>
>>
>> Thanks
>>
>> Kyle
>>
>>

--
http://www.freelists.org/webpage/oracle-l