คำอธิบายของ SQL Server การบล็อคที่เกิดจากการล็อกการคอมไพล์

หมายเลขบทความ (Article ID): 263889 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
แปลโดยคอมพิวเตอร์คลิกที่นี่เพื่อดูข้อจำกัดความรับผิดชอบของ KB ที่แปลโดยคอมพิวเตอร์
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

สรุป

ใน Microsoft SQL Server การคัดลอกแผนการกระบวนงานที่เก็บไว้ที่เดียวเท่านั้นคือโดยทั่วไปในแคชในแต่ละครั้ง บังคับใช้นี้ต้องใช้อนุกรมของบางส่วนของกระบวนการคอมไพล์ และซิงโครไนซ์นี้ได้ในส่วน โดยใช้การล็อกการคอมไพล์ ถ้าเชื่อมต่อมากพร้อมใช้กระบวนงานที่เก็บไว้เดียวกัน และล็อกการคอมไพล์ต้องได้รับสำหรับกระบวนงานที่เก็บไว้ทุกครั้งที่มีการทำงาน กระบวนการระบบ IDs (Spid) อาจเริ่มบล็อกอื่น ตามที่แต่ละพยายามล็อกการคอมไพล์แบบเอกสิทธิ์เฉพาะบุคคลบนวัตถุได้รับ
กลับไปด้านบน | ให้ข้อเสนอแนะ

ข้อมูลเพิ่มเติม

Recompilation กระบวนงานที่เก็บไว้มีคำอธิบายหนึ่งสำหรับการล็อกการคอมไพล์บนกระบวนงานที่เก็บไว้หรือทริกเกอร์ การแก้ไขปัญหาในกรณีนี้คือ ลด หรือกำจัดการ recompiles คำอธิบายของเหตุผลทั่วไปมากที่สุดซึ่งอาจมีกระบวนงานที่เก็บไว้เพื่อจะ recompiled และบางข้อมูลที่เป็นประโยชน์ในการลดความถี่ของ recompiles ดูบทความฐานความรู้ของ Microsoft ต่อไปนี้:
243586
(http://support.microsoft.com/kb/243586/ )
Recompilation กระบวนงานที่เก็บไว้ในการแก้ไขปัญหา
สถานการณ์อื่นที่คอมไพล์ล็อกเกิดขึ้นคือเมื่อเงื่อนไขต่อไปนี้เป็นจริง:
  • ผู้ใช้ที่เรียกใช้กระบวนงานที่เก็บไว้ไม่ได้เป็นเจ้าของกระบวนงาน
  • ชื่อของกระบวนงานที่เก็บไว้ไม่ครบถ้วน ด้วยชื่อของเจ้าของวัตถุ
ตัวอย่างเช่น ถ้าผู้ใช้ "dbo" เป็นเจ้าของวัตถุdbo.mystoredprocและผู้ใช้อื่น "Harry เรียกใช้กระบวนงานนี้เก็บไว้ โดยใช้คำสั่ง"exec mystoredproc การค้นหาเริ่มต้นแค ด้วยการล้มเหลวของชื่อวัตถุได้เนื่องจากวัตถุไม่มีคุณสมบัติของเจ้าของ (ไม่ได้ทราบว่าว่า มีกระบวนงานอื่นที่ชื่อว่า Harry.mystoredproc เก็บไว้ ดังนั้น SQL Server จะไม่แน่ใจว่า แผนการแคชกับ dbo.mystoredproc ถูกต้องในการปฏิบัติการ) SQL Server ล็อคการคอมไพล์แบบเอกสิทธิ์เฉพาะบุคคลบนกระบวนงานที่ได้รับแล้ว และทำให้บ้างในการรวบรวมกระบวนงาน ซึ่งรวมถึงการแก้ไขชื่อวัตถุ id ของวัตถุ ก่อนที่แผนการคอมไพล์ราย SQL Server, SQL Server ใช้ ID ออปเจ็กต์นี้เพื่อทำการค้นหาที่ชัดเจนยิ่งขึ้นของแคกระบวนงาน และสามารถหาตำแหน่งที่ตั้งของแผนที่คอมไพล์แล้วก่อนหน้านี้แม้ไม่ มีคุณสมบัติของเจ้าของ

หากพบการแผนที่มีอยู่ SQL Server นำแผนการแคช และคอมไม่จริงไพล์กระบวนงานที่เก็บไว้ อย่างไรก็ตาม ไม่มีเจ้าของคุณสมบัติบังคับให้ SQL Server เพื่อทำการค้นหาที่สองของแคช และได้รับการล็อกแบบเอกสิทธิ์เฉพาะบุคคลการคอมไพล์ก่อนที่โปรแกรมพิจารณาว่า แผนปฏิบัติการแคชอยู่แล้วสามารถนำ การขอรับการล็อก และการดำเนินการค้นหาและการทำงานอื่น ๆ ที่จำเป็นเพื่อที่มาถึงจุดนี้จะทำให้เกิดการหน่วงเวลาสำหรับการล็อกการคอมไพล์ที่ให้บล็อก นี้คือผู้ใช้จริงโดยเฉพาะอย่างยิ่งถ้าจำนวนมากที่ไม่ใช่เจ้าของกระบวนงานเก็บไว้ที่พร้อมให้เรียกใช้กระบวนงานโดยไม่มีการป้อนชื่อของเจ้าของ คุณควรตระหนักว่า ถึงแม้ว่าคุณไม่เห็น Spid ที่กำลังรอการคอมไพล์ล็อก ขาดคุณสมบัติของเจ้าของสามารถทำให้เกิดความล่าช้าในการปฏิบัติการกระบวนงานที่เก็บไว้ และทำให้เกิดการใช้งาน CPU สูงท่อ

จะถูกบันทึกลำดับเหตุการณ์ต่อไปนี้ในการสืบค้นกลับของผู้สร้างโปรไฟล์ของเซิร์ฟเวอร์ SQL เมื่อเกิดปัญหานี้ (การติดตามเหตุการณ์ที่เกี่ยวข้องกับการแคช คุณต้องเปิดใช้งานเหตุการณ์ขั้นสูง เมื่อต้องการทำเช่นนี้ ให้คลิกตัวเลือกบนเครื่องเครื่องมือและเมนูแล้วเลือกระดับชั้นของเหตุการณ์ทั้งหมด)

ยุบตารางนี้ขยายตารางนี้
คลาสเหตุการณ์ข้อความ
RPC: เริ่มต้นmystoredproc
SP:CacheMissmystoredproc
SP:ExecContextHitmystoredproc
SP: เริ่มต้นmystoredproc
......

SP:CacheMissเกิดขึ้นเมื่อแคค้นหาตามชื่อล้มเหลว ต่อไปนี้SP:ExecContextHitบ่งชี้ว่า แผนการแคชตรงท้ายที่สุดพบในแคชหลังจากรับการแก้ไขเป็น id ของวัตถุชื่อวัตถุที่ไม่ชัดเจน ทั้งนี้ขึ้นอยู่กับสถานการณ์SP:CacheHitอาจปรากฏขึ้นแทนSP:ExecContextHit.

วิธีแก้ไขปัญหาของการคอมไพล์ล็อกคือการ ตรวจสอบให้แน่ใจว่า การอ้างอิงไปยังกระบวนงานที่เก็บไว้เป็นเจ้าของมีคุณสมบัติ (แทนที่เป็นของexec mystoredprocใช้ execdbo.mystoredproc.) ในขณะที่เจ้าของคุณสมบัติสำคัญคือเหตุผลด้านประสิทธิภาพการทำงาน คุณไม่มีการกำหนดลักษณะ proc เก็บไว้ ด้วยชื่อฐานข้อมูลเพื่อป้องกันการค้นหาเพิ่มเติมแค

การบล็อคที่เกิดจากการคอมไพล์ที่ล็อกสามารถตรวจพบ โดยการใช้บล็อกสคริปต์เช่นที่ที่กำหนดไว้ในบทความฐานความรู้ของ Microsoft ต่อไปนี้:
251004
(http://support.microsoft.com/kb/251004/ )
INF: วิธีการตรวจสอบ SQL Server 7.0 บล็อก
271509
(http://support.microsoft.com/kb/271509/ )
INF: วิธีการตรวจสอบการบล็อก SQL Server 2000
ต่อไปนี้คือ บางลักษณะทั่วไปของบล็อกการคอมไพล์ที่สามารถตรวจสอบในผลลัพธ์การบล็อคของสคริปต์:
  • lastwaittypeสำหรับ Spid ถูกบล็อค และการบล็อค (ปกติ) คือ LCK_M_X (exclusive) และwaitresourceมีของแบบฟอร์ม "แท็บ: dbid:object_idคอม [[ไพล์]],"ที่"object_id"เป็น ID ออปเจ็กต์ของกระบวนงานที่เก็บไว้
  • ตัวบล็อกป้ายได้waittype0x0000 สถานะที่เรียกใช้ได้ Blockees ได้waittype0x000e (ล็อกแบบเอกสิทธิ์เฉพาะบุคคล), การเข้าสู่โหมดสลีสถานะ
  • แม้ว่าระยะเวลาในการแก้ไขปัญหาการบล็อกอาจจะยาว มีคือไม่มี SPID เดียวที่กำลังบล็อค Spid อื่น ๆ เป็นเวลานาน ไม่มีการบล็อก rolling ทันทีที่คอมไพล์หนึ่งเสร็จสมบูรณ์แล้ว SPID อื่นใช้เวลาผ่านบทบาทของพนักงานตัวบล็อกป็อปอัพกี่วินาที หรือน้อยกว่า และอื่น ๆ
ข้อมูลต่อไปนี้คือจาก snapshot ของsysprocessesในระหว่างการชนิดนี้ของ บล็อก:
   spid  blocked  waittype  waittime  lastwaittype  waitresource
   ----  -------  --------  --------  ------------  -------------------------
   
   221    29      0x000e    2141      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   228    29      0x000e    2235      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    29   214      0x000e    3937      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    13   214      0x000e    1094      LCK_M_X       TAB: 6:834102 [[COMPILE]]
    68   214      0x000e    1968      LCK_M_X       TAB: 6:834102 [[COMPILE]]
   214     0      0x0000       0      LCK_M_X       TAB: 6:834102 [[COMPILE]]
ในการwaitresourceคอลัมน์ ("6:834102"), 6 รหัสฐานข้อมูล และ 834102 เป็น id ของวัตถุ คุณควรตระหนักว่า ID ออปเจ็กต์นี้เป็นของกระบวนงานที่เก็บ การตาราง (นอกจากชนิด lock "แท็บ") ไม่

บันทึกย่อ
  • ถ้าคุณใช้ SQL Server 2005 จำนวนมากในตารางระบบจาก SQL Server 2000 มีการนำมาใช้เป็นชุดของมุมมองในขณะนี้ มุมมองเหล่านี้ทราบว่าเป็นมุมมองของความเข้ากันได้ และจภาษาสำหรับกันเท่านั้น มุมมองของความเข้ากันได้เปิดเผยข้อมูลเมตาเดียวกันที่ใช้ได้ใน SQL Server 2000 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการแม็ประหว่างตารางระบบ SQL Server 2000 และมุมมองระบบ SQL Server 2005 ดูหัวข้อ "การแมป SQL Server 2000 ระบบตารางไปยัง SQL Server 2005 ระบบวิว" ใน SQL Server 2005 Books Online
  • ถ้าชื่อของกระบวนงานที่เก็บไว้ของคุณเริ่มต้น ด้วยคำนำหน้า "sp_" และไม่ได้อยู่ในฐานข้อมูลหลัก คุณเห็นSP:CacheMissก่อนในการเข้าชมสำหรับแม้แต่ละการปฏิบัติการแคช คุณเจ้าของเกิดกระบวนงานที่เก็บไว้ นี้คือเนื่องจากคำนำหน้า sp_ บอกว่า กระบวนงานที่เก็บไว้เป็นระบบ SQL Server กระบวนงานที่เก็บไว้ และขั้นตอนของระบบที่เก็บไว้มีกฎการแก้ปัญหาชื่อที่แตกต่างกัน (ตำแหน่งที่ตั้ง "ที่ต้อง" อยู่ในฐานข้อมูลหลัก) ชื่อของผู้ใช้สร้างกระบวนงานที่เก็บควรเริ่มต้น ด้วย "sp_"
  • ถ้ากระบวนงานที่มีคุณสมบัติเจ้าของจะดำเนินการ ด้วยกรณีที่แตกต่างกันมากกว่าสร้างกระบวนงานที่มีคุณสมบัติเจ้าของเป็น กระบวนงานที่มีคุณสมบัติเจ้าของสามารถขอรับการCacheMissหรือการร้องขอการล็อกการคอมไพล์ แต่ใช้แผนการแคช ดังนั้น ซึ่งจะต้องไม่จริง ๆ คอมไพล์ใหม่ขั้นตอน และควรทำให้มากที่มีค่าใช้จ่ายใน แต่ในบางสถานการณ์ การร้องขอสำหรับการล็อกการคอมไพล์อาจทำให้เกิดสถานการณ์ที่ "บล็อกลูกโซ่" ถ้า Spid ที่พยายามที่จะเรียกใช้กระบวนการเดียวกันกับกรณีที่แตกต่างกันกว่ากระบวนงานถูกสร้างขึ้นเป็นจำนวนมาก นี้เป็นจริงที่คำนึงถึงการเรียงลำดับหรือการเปรียบเทียบที่ถูกใช้ บนเซิร์ฟเวอร์ หรือ บนฐานข้อมูล เหตุผลที่ใช้ในการทำงานนี้คือ ว่า อัลกอริทึมที่ใช้ในการค้นหาขั้นตอนในแคช จะขึ้นอยู่กับค่าแฮช (เหตุผลประสิทธิภาพการทำงาน), ซึ่งสามารถเปลี่ยนแปลงถ้ากรณีแตกต่าง

    วิธีแก้ปัญหามีการปล่อย และสร้างกระบวนงานที่ มีกรณีเดียวกันเป็นกระบวนการจะดำเนินการ โดยแอพลิเคชัน คุณยังสามารถทำให้แน่ใจว่า กระบวนการที่จะดำเนินการจากโปรแกรมประยุกต์ทั้งหมดที่ใช้ในกรณีเดียวกัน
  • ถ้าคุณพยายามที่จะเรียกใช้กระบวนงานที่เก็บไว้เป็นเหตุการณ์ภาษาแทนที่จะเป็น RPC ใช้ SQL Server ต้องแยกวิเคราะห์ และคอมไพล์แบบสอบถามเหตุการณ์ภาษา การตรวจสอบว่า แบบสอบถามจะพยายามดำเนินการตามขั้นตอนใด และพยายามค้นหาแผนการใช้พลังงานในแคชสำหรับขั้นตอนที่ เมื่อต้องการหลีกเลี่ยงสถานการณ์นี้ที่ SQL Server ต้องแยกวิเคราะห์ และคอมไพล์เหตุการณ์ภาษา การตรวจสอบให้แน่ใจว่า แบบสอบถามที่ส่งไปยัง SQL เป็น RPC ใช้

    สำหรับข้อมูลเพิ่มเติม โปรดดูที่ส่วน "ระบบเก็บไว้ตอน" ในหนังสือออนไลน์บทความ "สร้างกระบวนการ Stored"


ปัญหาที่ทราบ

ต่อไปนี้เป็นปัญหาที่ทราบบางอย่างที่สามารถทำให้แผนการแคช:
  • คุณสามารถใช้ตัวแปร BLOB เป็นพารามิเตอร์ของกระบวนงานที่เก็บไว้ สำหรับข้อมูลเพิ่มเติม ให้คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
    2380435
    (http://support.microsoft.com/kb/2380435/ )
    การแก้ไข: วางแผนแบบสอบถามสำหรับกระบวนงานที่เก็บไว้จะไม่ถูกแคชถ้ากระบวนงานที่เก็บไว้ใช้ตัวแปร BLOB และตัวแปรที่ใช้ในฟังก์ชันสายอักขระใน Microsoft SQL Server 2008
  • คุณสามารถใช้คีย์ SYMMETRIC เปิดในกระบวนงาน/แบบสอบถามชุดที่เก็บไว้ สำหรับข้อมูลเพิ่มเติม ให้ดูบล็อกรายการต่อไปนี้ของ MSDN:
    http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx
    (http://blogs.msdn.com/b/sqlserverfaq/archive/2010/09/08/open-symmetric-key-command-prevents-query-plan-caching.aspx)

กลับไปด้านบน | ให้ข้อเสนอแนะ

คุณสมบัติ

หมายเลขบทความ (Article ID): 263889 - รีวิวครั้งสุดท้าย: 28 มกราคม 2554 - Revision: 4.0
ใช้กับ
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
Keywords: 
kbinfo kbmt KB263889 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:263889
(http://support.microsoft.com/kb/263889/en-us/ )
กลับไปด้านบน | ให้ข้อเสนอแนะ

ให้ข้อเสนอแนะ

 
กลับไปด้านบนกลับไปด้านบน