Thank you John. I guess I can revise my question, then, to say "Why not use SID/SERIAL# all the time?" :)
I suppose there are reasons but it seems unnecessary to have two sets of values that uniquely identify a session. Though of course, from the documentation, AUDSID is unique over the lifetime of the database (generated from sequence SYS.AUDSES$) and SID/SERIAL# would not be unique over the lifetime of the database.
> -----Original Message-----
> John Kanagaraj
> Sent: lundi, 6. octobre 2003 15:59
>
> >In what cases does the SERIAL# need to be used? Can someone
> give an example
> where a session-level command would be
> >applied to an incorrect session object if SERIAL# were not available?
>
> For backward compatibility reasons :) Looks like AUDSID
> wasn't generated 7.2
> and prior unless AUDIT_TRAIL was TRUE (even if you don't use
> auditing). A
> lot of scripts use SERIAL# and the ALTER SYSTEM KILL SESSION uses the
> serial#, which should always be available.
>
> >Why not use AUDSID all the time? Is there a reason why the
> database keeps
> track of two session identifying numbers?
>
> AUDSID is 0 if connecting as internal. Notes 123128.1 and
> 122230.1 may help!
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jacques Kilchoer
INET: Jacques.Kilchoer_at_quest.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).
Received on Mon Oct 06 2003 - 19:04:32 CDT
