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: [EMAIL PROTECTED] 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: [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).
