¿Por qué se requiere sid en 'KILL SESSION' (Oracle SQL)?

Question

Tengo una pregunta del examen y no puedo encontrar la respuesta. ¿Por qué es obligatorio el sid para realizar el comando KILL SESSION?
KILL SESSION sintaxis: ALTER SYSTEM KILL SESSION 'sid,session#[@inst_id]' [IMMEDIATE];
Dónde sid es un identificador de sesión 'único'. Único entre comillas porque es único en momento actual, el servidor Oracle puede tener, por ejemplo, sesión alguna sid, pero después de que esta sesión haya terminado, este sid se puede usar para otra sesión. Sid es la analogía pid en el sistema operativo.
Session # es un número de sesión serial; es un contador de sesión. El servidor borra el contador al inicio de DB. Por lo tanto, la sesión # es realmente identificador único para la sesión.

No entiendo por qué sid es obligatorio para el comando KILL SESSION. Creo que es posible usar session# solamente.

Gracias.

Answer 1

¡Lo encontré! La secuencia para serial# es cíclica. Los números serán reutilizados después de 2 mil millones de inicios de sesión si se usó int, o después de 32k si se usó short.Por lo tanto, usar serial# sin nada más no proporciona enumeración realmente única.
Pero sid es único en un momento. Entonces, el par sid,serial# es realmente único.
No puede usar serial# o sid para administrar sesiones, debe usarlo en un par.

¡Gracias por su tiempo!

Answer 2

Necesita el SID y el número de serie. El oráculo reference tiene esto que decir:

SID identificador de sesión

# número de serie sesión serie. Se utiliza para identificar de forma única los objetos de una sesión. Garantiza que los comandos de nivel de sesión se aplican a los objetos de sesión correctos si la sesión termina y empieza otra sesión con el mismo ID de sesión

Así, mientras que un SID es único, puede ser reutilizado. Así que supongo que la adición de un número de serie garantizaría que no mates una sesión recién conectada que usa el mismo SID de lo que intentabas matar (si ya se desconectaron antes de ejecutar el comando).

de actualización en respuesta a los comentarios del jurado:

No puedo decir por qué se lleva a cabo de esta manera, sólo mi comprensión de la aplicación de acuerdo con la documentación: SID es re-utilizable, la Serie No. dentro de un SID no es. Por lo tanto, como un ejemplo:

• [1,1] JOE conecta y se asigna SID 1, Serial # 1
• JOE desconecta
• [1,2] TOM conecta y se asigna SID 1 (reutilización), pero SERIE # se incrementa a 2
• [2,1] SUSAN conecta y se asigna SID 2, Serie No. 1

¿Por qué esta aplicación? ¿Mantiene los tamaños numéricos manejables, quizás? Minimizar la contención? ¿Reutilización de los recursos ya asignados (representados por el SID)? No lo sé.

Answer 3

Sé que este es un tema antiguo, pero quería señalar que el número de serie en sí mismo ni siquiera está cerca de un identificador único, incluso en un momento determinado.

SQL> select serial#, count(*) from v$session group by serial#; 

    SERIAL# COUNT(*) 
---------- ---------- 
     1   15 
     983   1 
     2   1 
     505   1 
     5   2 
     7076   1 
     7   2 
     58   1 
     3   3 
     9   1 
    22160   1 

11 rows selected. 

De las 29 sesiones que tengo actualmente en mi base de datos, solo hay 11 números de serie distintos.

EDITAR: Y esta es una base de datos de instancia única. En un entorno de RAC, debe incluir el ID de la instancia para obtener una sesión realmente única, según tengo entendido (nunca he trabajado personalmente con una base de datos de RAC).