การช่วงชิง DDL บน TempDB

ฉันมี SQL Server 2005 Standard x64 ที่ประสบปัญหากับการช่วงชิงการแข่งขัน DDDB ของ TempDB ในช่วงสองสามเดือนที่ผ่านมา เซิร์ฟเวอร์จะได้รับการช่วงชิงทรัพยากรรอ 2: 1: 103 (ประเภทรอเป็น PAGELATCH_EX)

ปัญหานี้เกิดขึ้นเป็นระยะ ๆ เมื่อเซิร์ฟเวอร์อยู่ในช่วงโหลดที่เหมาะสม ฉันได้ตรวจสอบอัตรา "ตารางชั่วคราวสำหรับการทำลาย" และสามารถข้ามไปที่ 5,000+ ในช่วงเวลาที่เรามีปัญหาของ PAGELATCH_EX ใน 2: 1: 103 จากสิ่งที่ฉันได้อ่านตัวนับนี้ควรเป็น 0 เวลาส่วนใหญ่ แต่ดูเหมือนว่าพวกเราจะอยู่ที่ใดก็ได้ตั้งแต่ 300-1100 ส่วนใหญ่ ตัวนับจะไปที่ 0 เมื่อมีผู้ใช้น้อยมากในระบบ

ฉันจะแคบลงสิ่งที่ทำให้เกิดการแข่งขัน DDL ใน tempdb โดยไม่ต้องมองหาเข็มในกองหญ้าแห้งได้อย่างไร

ฉันได้เห็นปัญหานี้มากและการแก้ไขด่วนที่ออกมาเพื่อแก้ไขในที่สุดมันก็เป็นผลโดยตรงจากเคสของฉันกับ Microsoft CSS ไม่มีบทความ KB สาธารณะสำหรับการแก้ไข โปรดตรวจสอบให้แน่ใจว่าคุณได้ใช้Service Pack 4และการอัปเดตสะสมล่าสุดไปยัง SQL Server (ณ เวลาที่เขียนนั่นคือCumulative Update # 3 (9.00.5259 )

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

เพื่อติดตามการใช้งาน tempdb มีสคริปต์หลายบทที่สามารถช่วยได้เช่นดูที่ Adam Machanic's sp_whoIsActiveโดยเฉพาะ:

• sp_whoisactive: การวิเคราะห์การแข่งขันชั่วคราว
• วิธีการระบุแบบสอบถามที่กรอกบันทึกธุรกรรม tempdb?

และสคริปต์นี้ (และสิ่งที่อยู่ในความคิดเห็น) จาก @SQLSoldier:

• ทำลายการแข่งขัน TempDB

ฉันจะตรวจสอบให้แน่ใจว่าเคอร์เซอร์ทั้งหมดของคุณใช้อยู่LOCAL STATIC READ_ONLY FORWARD_ONLY(ดูนี่และสิ่งนี้ ) และดูว่ามีคิวรี่ราคาแพงใด ๆ ที่รู้จักซึ่งใช้ #temp tables / @table variable, CTEs หรืออาจมีการเรียงลำดับที่ไม่จำเป็นหรือนำไปสู่การแฮช ... สิ่งเหล่านี้สามารถนำไปสู่ปัญหาได้ (ฉันสงสัยว่าคุณจะพบสาเหตุหนึ่งประการ) การแก้ปัญหาการกวาดที่ง่ายที่สุดในฐานะจุดเริ่มต้น "สำหรับบางสิ่งบางอย่าง" จะใช้ตัวเลือกเคอร์เซอร์ที่เหมาะสมและไม่แพงแทนที่จะเป็นค่าเริ่มต้น

ในระหว่างนี้ฉันจะ (a) ติดตั้ง CU # 3 และ (b) เรียก PSS บอกพวกเขาว่าคุณกำลังหลังจากการแก้ไขที่เฉพาะเจาะจงซึ่งได้รับการยืนยันแล้วว่าเป็นข้อบกพร่องและเผยแพร่ให้ผู้ใช้รายอื่นในฐานะโปรแกรมแก้ไขด่วนส่วนตัว: "VSTS # 109112 - การเลื่อนการเลื่อนเวลาของตารางชั่วคราวไม่ปรับขนาดสำหรับปริมาณงานบางอย่าง" คุณอาจต้องชำระค่าธรรมเนียมกรณีแรก แต่เนื่องจากเป็นข้อผิดพลาดจึงควรคืนเงินให้

คุณอาจต้องใช้ค่าสถานะการติดตาม 1118

ดูตำนานของ Paul Randal เกี่ยวกับ tempdbก่อนและบทความ TF 1118ของเขาด้วย

TF อธิบายไว้ที่นี่ในKB 328551

ฉันไม่มีประสบการณ์ตรงเกี่ยวกับเรื่องนี้ แต่ดูเหมือนว่าฉันจะอ่าน

ฉันคิดว่าคุณได้แบ่งไฟล์ข้อมูล TempDB ของคุณออกไปแล้วเพื่อลดความขัดแย้ง (ผ่านการเตรียมการก่อนอย่างชัดเจน) หากคุณกล้าลองพิจารณาการตั้งค่าสถานะการติดตามที่ Paul Randal ใช้อ้างอิงอย่างเป็นทางการ: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb ควรเสมอมีหนึ่งข้อมูลไฟล์ต่อโปรเซสเซอร์ core.aspx

ในแง่ของสิ่งที่ก่อให้เกิดความเจ็บปวดคุณต้องทำงานสืบสวนบางอย่าง:

• สิ่งนี้เพิ่งเริ่มเกิดขึ้น? มีการเปลี่ยนแปลงอย่างไร
• เซิร์ฟเวอร์ที่อยู่ภายใต้ความกดดันหน่วยความจำจึงต้องทำใน TempDB?
• มีกระบวนการ DBA ใด ๆ เช่น CheckDB หรือการสร้างดัชนีออนไลน์อีกครั้งกำลังทำงานอยู่หรือไม่
• ใช้ระดับการแยกที่แปลกใหม่มากขึ้นหรือนายหน้าบริการหรือไม่ ดูที่ sys.database

มีการสืบค้นที่ดีที่ด้านล่างของเอกสาร Microsoft TempDB นี้เพื่อพยายามหาสิ่งที่ใช้ tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

หากคุณยังคงต้องการติดตามสิ่งนี้อยู่ฉันเพิ่งพบปัญหาประสิทธิภาพการทำงานที่แปลกประหลาดคล้ายกับการลดลงของตารางซิงโครนัส หากคุณมีฐานข้อมูลจำนวนมาก (> 100 หรือมากกว่านั้น) บนอินสแตนซ์ sql ที่รัน SQL 2005 และคุณมีตาราง temp จำนวนมากที่สร้างและวางคำสั่งคุณจะได้รับตาราง temp ที่ช้าลง การตรวจสอบจำนวนแถวที่ส่งคืนจาก sys.dm_db_index_usage_stats สามารถแยกแยะสิ่งนี้ออกมาได้ทันทีในฐานะผู้กระทำผิด

บทความ KB อธิบายถึงปัญหา http://support.microsoft.com/kb/2003031

ประสิทธิภาพของแบบสอบถามลดลงเมื่อ sys.dm_db_index_usage_stats มีจำนวนแถวมาก

พิจารณาสถานการณ์สมมติต่อไปนี้:

ใน Microsoft SQL Server 2005 คุณมักดำเนินการ DDL ที่เกี่ยวข้องกับการปล่อยและการสันทนาการของตารางจำนวนมาก (โดยเฉพาะอย่างยิ่งตารางชั่วคราวในฐานข้อมูล tempdb) คุณมีรายการจำนวนมาก (100,000 หรือมากกว่า) ในมุมมอง sys.dm_db_index_usage_stats การจัดการแบบไดนามิก (DMV)

นำมาจากคำตอบที่ฉันยอมรับสำหรับคำถามนี้ มีรายละเอียดเพิ่มเติมที่นั่นเช่นกัน ตาราง temp ช้าลงใน sql 2005