you need to be careful if you are also using databases whose contents appear on the web, as Oracle will want you to use a web license (extremely expensive) even if the data is not directly accessed but appears on the web in static pages generated from the Oracle database.
--- Stephane Faroult <[EMAIL PROTECTED]> wrote: > "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). __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
