From oracle-l-bounce@freelists.org Thu Mar 11 11:18:35 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i2BHIZv30849 for ; Thu, 11 Mar 2004 11:18:35 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i2BHIYo30842 for ; Thu, 11 Mar 2004 11:18:35 -0600 Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 40E8A3975C7; Thu, 11 Mar 2004 11:52:20 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Thu, 11 Mar 2004 11:51:17 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from mail.sagelogix.com (unknown [69.15.85.3]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id A805039714A for ; Thu, 11 Mar 2004 11:36:56 -0500 (EST) Received: (qmail 28345 invoked from network); 11 Mar 2004 16:30:51 -0000 Received: from unknown (HELO ocs.sagelogix.com) (192.168.25.20) by 0 with SMTP; 11 Mar 2004 16:30:51 -0000 Received: from servicemagic.com by ocs.sagelogix.com with ESMTP id 509111079022574; Thu, 11 Mar 2004 09:29:34 -0700 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 11 Mar 2004 09:40:42 -0700 Subject: Re: RAC gv$session From: Tim Gorman To: Message-ID: In-Reply-To: <1C9727B12F498543A43CBB988F30515C029B7E54@uswaumsx14medge.med.ge.com> Mime-version: 1.0 Content-Type: multipart/alternative; boundary="B_3161842843_8220106" X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: tim@sagelogix.com Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l --B_3161842843_8220106 Content-Type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable SID and SERIAL# are not guarenteed unique across instances. INST_ID is the last part of that implied primary key, for all GV$ views. Look at V$FIXED_VIEW_DEFINITION The data for each instance, including memory-based V$ views like V$SESSION, is maintained solely within that instance. When necessary, those GV$ views are populated using cross-instance queries via parallel execution =B3slave=B2 (i.e. =B3ora_pXXX_SID=B2) processes. Exceptions include the V$ views that are based in the control file, such as V$DATABASE, V$THREAD, V$DATAFILE, etc. whose data is visible to all instances through the shared control files. A= t least, that is how it was done for 8/8i OPS =8B I haven=B9t verified whether 9i RAC has found something more clever involving cache fusion and the =B3block-shipping=B2 processes or something. The GV$ views did not exist in Oracle7 and prior =8B we had to write them custom. Can anyone confirm or correct about how 9iRAC displays GV$ info? Still, although you can view SID and SERIAL# from across the cluster (thoug= h GV$ views), you can only utilize them in =B3DBMS_=B2 package calls or from ALTE= R SYSTEM KILL SESSION, etc. from the appropriate instance... on 3/11/04 7:48 AM, Kommareddy, Srinivas (MED, Wissen Infotech) at Srinivas.Kommareddy@med.ge.com wrote: > Hi All, > =20 > We have 2 nodes set for RAC. > =20 > When I try to kill a session from node 1, is the sid,serial# going to be > unique among the nodes, > Or is there any possibility that another session on node 2 will be killed= (if > sid, seiral# are same for another session on node 2). > =20 > Does my select sid,serial# checks v$session or gv$session. > =20 > Can someone through some light on this. > =20 > Tx and Regards, > Srinivas >=20 --B_3161842843_8220106 Content-Type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: RAC gv$session SID and SERIAL# are not g= uarenteed unique across instances.  INST_ID is the last part of that im= plied primary key, for all GV$ views.  Look at V$FIXED_VIEW_DEFINITION<= BR>
The data for each instance, including memory-based V$ views like V$SESSION,= is maintained solely within that instance.  When necessary, those GV$ = views are populated using cross-instance queries via parallel execution R= 20;slave” (i.e. “ora_pXXX_SID”) processes.  Exception= s include the V$ views that are based in the control file, such as V$DATABAS= E, V$THREAD, V$DATAFILE, etc. whose data is visible to all instances through= the shared control files.  At least, that is how it was done for 8/8i = OPS — I haven’t verified whether 9i RAC has found something more= clever involving cache fusion and the “block-shipping” processe= s or something.  The GV$ views did not exist in Oracle7 and prior ̵= 2; we had to write them custom.  Can anyone confirm or correct about ho= w 9iRAC displays GV$ info?

Still, although you can view SID and SERIAL# from across the cluster (thoug= h GV$ views), you can only utilize them in “DBMS_” package calls= or from ALTER SYSTEM KILL SESSION, etc. from the appropriate instance...


on 3/11/04 7:48 AM, Kommareddy, Srinivas (MED, Wissen Infotech) at Srinivas= .Kommareddy@med.ge.com wrote:

Hi All,
 
We have 2 nodes set for RAC.
 
When I try to kill a session from node 1, is the sid,serial# going to be un= ique among the nodes,
Or is there any possibility that another session on node 2 will be killed (= if sid, seiral# are same for another session on node 2).
 
Does my select sid,serial# checks v$session or gv$session.
 
Can someone through some light on this.
 
Tx and Regards,
Srinivas


 --B_3161842843_8220106-- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------