Re: Using AUDSID to identify a session

The easiest way I have found up to now to solve this problem is by using the sid of system view v$mystat instead. Following query returns the correct session information even in a job (v$mystat contains several rows, but the sid is always the same in the same session):

select *
from v$session
where sid = (select sid from v$mystat where rownum = 1)

Marc

Sybrand Bakker wrote in message
<929987314.22558.0.pluto.d4ee154e_at_news.demon.nl>...
>Regrettably this isn't for 100 percent true, and I only just hit it last
>week (in 7.3.4)
>Oracle jobs, run by the SNPx process dont' have an audsid. This was the
>reason why our checks failed. Basically it was used to retrieve the user,
>and select user from dual still shows the user submitting the job.
>If you don't use this code as a job it will work as you describe.
>
>Best regards,
>
>Sybrand Bakker, Oracle DBA
>
>markp7832_at_my-deja.com wrote in message <7klm3j$d94$1_at_nnrp1.deja.com>...
>>In article <7kl9sb$i3$1_at_news3.Belgium.EU.net>,
>> "Pascal Waterkeyn" <pwk_at_offis.be> wrote:
>>> I am using the V$SESSION dynamic performance table in a package
>>> in order to determine if a certain session is still valid, or if the
>>> user has been disconnected.
>>>
>>> In order to identify the session, I use the AUDSID because I can
>>> easily get the value for the current session using
>>> USERENV('SESSIONID').
>>>
>>> My question is: can I safely use the AUDSID value to identify a
>>> session, or in other words, is the AUDSID unique within an instance ?
>>>
>>> If you suggest me to use the SID and/or SERIAL# instead, please
>>> indicate how I can easily get the values for the current session.
>>>
>>> Thanks.
>>>
>>> Pascal
>>>
>>The audsid should be safe to use to use. There have been several posts
>>to this effect in the past.
>>
>>--
>>Mark D. Powell -- The only advice that counts is the advice that
>> you follow so follow your own advice --
>>
>>
>>Sent via Deja.com http://www.deja.com/
>>Share what you know. Learn what you don't.
>
>
Received on Tue Jun 22 1999 - 00:31:12 CDT