Querying v$session will not work for many applications.
SAP and Agile ( mfg app ) come to mind. They each use their
own integrated app server. Hundreds of users may make use
of the database via 20 connected sessions. These are databases
that legitimately use Named user licenses: they don't require
a CPU license.
By querying v$session it's also difficult to catch occasionaly users
that none the less must be licensed.
Jared
Stephane Faroult <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
02/19/02 12:40 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: Re: Oracle Licensing - Concurrent users
"Smith, Ron L." wrote:
>
> We have been asked to gather statistics on the number of clients using
> Oracle. This is being done to determine if we have sufficient
licensing.
> We have about 100 instances to monitor.
>
> Has anyone done this? Any ideas on what "Concurrent users" might mean
to
> the majority of people?
>
> We have both Oracle 7 and Oracle 8.
>
> Ron Smith
> DBA
> Kerr-McGee Corp
>
Well, I have just been working on this for one of my customers last
week. The obvious thing is to query V$SESSION at regular intervals
(dbms_job can help) and what you can do is store the result through a
database link to a single instance. Where it was tricky was that we
wanted to identify 'system' processes (easy, except that job processes
are marked as 'USER', which is debatable), and (that's where the snag
is) processes which are the results of a connection through a database
link. The logic is that a database link is initiated by a 'normal'
connection - for which the full-blown licence is already paid. So they
should not exactly count as much as regular connection; and if this is
not a good argument, then it is probably possible to reduce their number
by shifting around applications. Ultimately we could apply Larry's
favorite concept of 'single instance' (anyway I have always found DB
links messy).
My trouble was that nothing, but human knowledge, can tell whether the
connection comes from a database link or is genuine (if somebody has a
way, please share !). All the user information (machine, program,
module, action ...) comes from the initial connection and is propagated.
I have solved this (not fully satisfactorily) by having a table
automatically inserted with unknown (machine, program) pairs and
manually updated to say 'If we see this program on this database, then
it comes from a database link' - or 'anything coming from this machine
must come from a database link'. Added something for connection from
HTTP servers, although I doubt that those will be spontaneously
discussed during the negotiation.
--
Regards,
Stephane Faroult
Oriole Ltd
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Stephane Faroult
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
