เหตุใดจึงต้องมี sid ใน 'KILL SESSION' (Oracle SQL)

มีคำถามข้อสอบแต่หาคำตอบไม่ได้ เหตุใดจึงจำเป็นต้องมี sid เพื่อดำเนินการคำสั่ง KILL SESSION
KILL SESSION ไวยากรณ์: ALTER SYSTEM KILL SESSION 'sid,session#[@inst_id]' [IMMEDIATE];
โดยที่ sid คือตัวระบุเซสชัน 'ไม่ซ้ำกัน' ไม่ซ้ำกันในเครื่องหมายคำพูด เนื่องจากไม่ซ้ำกันใน ช่วงเวลาปัจจุบัน เซิร์ฟเวอร์ Oracle จึงสามารถมีเซสชันบาง sid ได้ แต่หลังจากเซสชันนี้จบลง sid นี้สามารถใช้สำหรับเซสชันอื่นได้ Sid มีความคล้ายคลึง pid ใน OS
เซสชัน# คือหมายเลขเซสชัน อนุกรม; มันเป็นตัวนับเซสชั่น เซิร์ฟเวอร์ล้างตัวนับเมื่อเริ่มต้น DB ดังนั้น session# จึงเป็น ตัวระบุที่ไม่ซ้ำ สำหรับเซสชัน

ฉันไม่เข้าใจว่าเหตุใดจึงต้องบังคับ sid สำหรับคำสั่ง KILL SESSION ฉันคิดว่ามันเป็นไปได้ที่จะใช้ session# เท่านั้น

ขอบคุณ.


sql oracle sessionid
person Jury    schedule 19.05.2012    source แหล่งที่มา
comment
ฉันเคยใช้ SERIAL# มากกว่า SESSION# เช่น ALTER SYSTEM KILL SESSION 'sid,serial#'; ตามมาจาก V$SESSION   -  person Glenn    schedule 19.05.2012
comment
ใช่ @inst_id เป็นทางเลือกและใช้ในเซิร์ฟเวอร์ RAC เท่านั้น IMMEDIATE ก็เป็นทางเลือกเช่นกัน มันใช้สำหรับการปิดเซสชันอย่างสวยงาม ฉันไม่เข้าใจว่าเหตุใดจึงต้องบังคับ sid   -  person Jury    schedule 19.05.2012

คำตอบ (3)


arrow_upward
6
arrow_downward

คุณต้องมี SID และ SERIAL# ข้อมูลอ้างอิงของ oracle กล่าวถึงสิ่งนี้ : :

SID ตัวระบุเซสชัน

SERIAL# หมายเลขซีเรียลของเซสชัน ใช้เพื่อระบุอ็อบเจ็กต์ของเซสชันโดยไม่ซ้ำกัน รับประกันว่าคำสั่งระดับเซสชันจะถูกนำไปใช้กับวัตถุเซสชันที่ถูกต้องหากเซสชันสิ้นสุดลงและเซสชันอื่นเริ่มต้นด้วยรหัสเซสชันเดียวกัน

ดังนั้นแม้ว่า SID จะไม่ซ้ำกัน แต่ก็สามารถนำมาใช้ซ้ำได้ ดังนั้นฉันเดาว่าการเพิ่ม SERIAL# จะช่วยให้แน่ใจว่าคุณจะไม่ฆ่าเซสชันที่เชื่อมต่อใหม่ซึ่งเกิดขึ้นเพื่อใช้ SID เดียวกันกับสิ่งที่คุณพยายามจะฆ่า (หากพวกมันตัดการเชื่อมต่อไปแล้วก่อนที่คุณจะดำเนินการคำสั่ง)

อัปเดตเพื่อตอบสนองต่อความคิดเห็นของคณะลูกขุน:

ฉันไม่สามารถพูดได้ว่าทำไมจึงมีการใช้งานเช่นนี้ เพียงความเข้าใจของฉันในการใช้งานตามเอกสารประกอบ: SID สามารถนำมาใช้ซ้ำได้ SERIAL# ภายใน SID ไม่ใช่ ดังนั้น ดังตัวอย่าง:

  • [1,1] JOE เชื่อมต่อและได้รับมอบหมาย SID 1, SERIAL# 1
  • JOE ตัดการเชื่อมต่อ
  • [1,2] TOM เชื่อมต่อและได้รับมอบหมาย SID 1 (ใช้ซ้ำ) แต่ SERIAL# จะเพิ่มขึ้นเป็น 2
  • [2,1] SUSAN เชื่อมต่อและได้รับมอบหมาย SID 2, SERIAL# 1

เหตุใดจึงมีการดำเนินการนี้ ช่วยให้สามารถจัดการขนาดตัวเลขได้หรือไม่ ลดความขัดแย้ง? ใช้ซ้ำทรัพยากรที่ได้รับการจัดสรรแล้ว (แสดงโดย SID) หรือไม่ ฉันไม่รู้.

person Glenn    schedule 19.05.2012
comment
ฉันรู้แล้ว คุณพูดถูก Serial# มีเอกลักษณ์เฉพาะตัวมากกว่า sid ไม่ซ้ำกันเท่ากับ sid ไม่จำเป็นต้องระบุเซสชัน....แต่จำเป็นสำหรับ KILL SESSION ทำไม - person Jury; 19.05.2012
comment
@Jury คุณสามารถเชื่อมโยงไปยังเอกสารของ Oracle บางส่วนที่ระบุว่า SERIAL# นั้นไม่ซ้ำกันใน SID ทั้งหมดได้หรือไม่ - person Glenn; 19.05.2012
comment
เป็นคำถามที่ดี...เพราะเคยได้ยินมาจากอาจารย์ครับ :) ผมพบว่า หลังจากเข้าสู่ระบบ 2,000,000,000 (2 พันล้าน) ครั้ง -- ตัวเลขจะถูกนำมาใช้ซ้ำ - person Jury; 20.05.2012
comment
ดังนั้น หลังจากการเข้าสู่ระบบ 2^31 - 1 ครั้ง session# จะได้รับค่าเริ่มต้น (0 หรือ 1) หากเป็นจริง คู่ sid,session# ดูเหมือนจะไม่ซ้ำกัน น่าสนใจ... - person Jury; 20.05.2012

arrow_upward
6
arrow_downward

เจอแล้ว! ลำดับสำหรับ serial# เป็นแบบวนรอบ ตัวเลขจะถูกนำมาใช้ซ้ำหลังจากเข้าสู่ระบบ 2 พันล้านครั้ง หากใช้ int หรือหลังจาก 32,000 หากใช้ short ดังนั้น การใช้ serial# โดยไม่มีสิ่งอื่นใดไม่ได้ให้การแจกแจงไม่ซ้ำกันจริงๆ
แต่ sid จะไม่ซ้ำกันในขณะนี้ ดังนั้น คู่ sid,serial# มีเอกลักษณ์จริงๆ
คุณไม่สามารถใช้ serial# หรือ sid ในการจัดการเซสชันได้ คุณควรใช้คู่กัน

ขอขอบคุณสำหรับเวลาของคุณ!

person Jury    schedule 20.05.2012

arrow_upward
4
arrow_downward

ฉันรู้ว่านี่เป็นหัวข้อเก่า แต่ฉันอยากจะชี้ให้เห็นว่า serial# โดยตัวมันเองนั้นไม่ได้ใกล้เคียงกับตัวระบุที่ไม่ซ้ำกันด้วยซ้ำ แม้แต่ ณ จุดใดจุดหนึ่งก็ตาม

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.

จาก 29 เซสชันที่ฉันมีในฐานข้อมูลในปัจจุบัน มีหมายเลขซีเรียลที่แตกต่างกันเพียง 11 รายการเท่านั้น

แก้ไข: และนี่คือฐานข้อมูลอินสแตนซ์เดียว ในสภาพแวดล้อม RAC คุณต้องรวม ID อินสแตนซ์เพื่อรับเซสชันที่ไม่ซ้ำใครอย่างแท้จริง จากสิ่งที่ฉันเข้าใจ (ฉันไม่เคยทำงานกับฐานข้อมูล RAC เป็นการส่วนตัว)

person BimmerM3    schedule 27.06.2013