SQL Server - ชั่วคราวเทียบกับตารางทางกายภาพ

มีการเคลื่อนไหวอยู่ในสถานที่ของฉันจ้างเพื่อย้ายออกจากการใช้ตาราง #temp และแทนที่จะใช้ตารางทางกายภาพถาวรกับ SPID เมื่อใดก็ตามที่หนึ่งก่อนหน้านี้จะถูกแทรกลงในตาราง #temp ตอนนี้INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)จำเป็นต้องมี - พร้อมกับDELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDคำสั่งที่จุดเริ่มต้นของเช่นขั้นตอนการจัดเก็บ นอกจากนี้มันจะไปได้ทุกที่โดยไม่บอกว่าเหล่านี้ตารางถาวรสำหรับการจัดเก็บข้อมูลชั่วคราว WHERE SPID = @@SPID'ถูกนำมาใช้อย่างใดอย่างหนึ่งต้องมีความระมัดระวังที่จะรวมถึง

ตรรกะเบื้องหลังการย้ายไปสู่การปฏิบัตินี้คือมันจะปรับปรุงประสิทธิภาพโดยรวมของเซิร์ฟเวอร์ที่การสืบค้นกำลังทำงานอยู่ (โดยการลด I / O และการช่วงชิงใน tempdb) ฉันไม่กระตือรือร้นกับวิธีการนี้ด้วยเหตุผลหลายประการ - มันน่าเกลียดอาจเป็นอันตรายและดูเหมือนว่าอาจเป็นอันตรายต่อประสิทธิภาพการทำงานของข้อความค้นหาเหล่านั้นที่ใช้รูปแบบใหม่

ใครบ้างมีประสบการณ์กับวิธีนี้หรือคล้ายกันในการกำจัดตาราง #temp หรือไม่

มันสามารถแสดงให้เห็นได้อย่างง่ายดายมากว่ามันจะไม่ลด IO หรือความขัดแย้ง แต่เพิ่มทั้งสองอย่าง

• IO : ทุกแถวที่แทรกอ่านหรือลบออกจากตาราง #temp จะถูกแทรกอ่านหรือลบออกจากตาราง @@ SPID แต่ทุกแถวจะกว้างขึ้นด้วยคอลัมน์ @@ SPID เพิ่มเติมดังนั้นจำนวนหน้าที่ต้องการจะเพิ่มขึ้นเล็กน้อยและ IO จะใหญ่ขึ้นเล็กน้อย แต่ที่สำคัญยิ่งกว่านั้นการลดลงของตาราง #temp และการเริ่มต้นของตาราง #temp ของเซสชันใหม่โดยเซสชันจะต้องมีการจำลองด้วย a DELETE FROM @@spidTable WHERE spid = @@SPIDดังนั้นการตัดทอน / สร้างการดำเนินการ (เช่นการดำเนินการจัดการขอบเขตหน้า) จะถูกเปลี่ยน ในการดำเนินงานแถวหาที่เปรียบมิได้ช้าลง
• ความขัดแย้ง : การสแกนทุกครั้งที่ใช้การล็อกหน้าบนตาราง #temp จะมีโอกาสที่จะล็อกหน้าด้วยแถว spid ที่ไม่เกี่ยวข้องดังนั้นการสร้างความขัดแย้งที่ไม่มีอยู่ก่อนหน้านี้ อัปเดตทุกคนที่ไม่ขึ้นว่าฮิตเกณฑ์ล็อกมีโอกาสที่จะขยายการล็อคเพื่อล็อคตารางและทำให้ปิดกั้นทุก spid อื่น ๆ

ดังนั้นแม้ว่าจะเป็นความจริงที่ว่าคุณจะไม่ได้รับความขัดแย้งในตำนานของ IAM / SGAM / GAM ใน tempdb แต่เพียงผู้เดียวเหตุผลที่สิ่งนี้จะเกิดขึ้นก็คือการดำเนินการของคุณจะช้าลงเนื่องจาก IO ทั่วไปและการโต้แย้งเพิ่มเติม

ดูเหมือนว่าจะเป็นทางออกที่รุนแรง มีบทความออนไลน์มากมายเกี่ยวกับการลดการช่วงชิง tempdb (และเพิ่มประสิทธิภาพการใช้งาน) - องค์กรของคุณได้ตรวจสอบถนนสายนี้อย่างถี่ถ้วนหรือไม่?

http://www.sql-server-performance.com/tips/tempdb_p1.aspx

http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

เป็นต้น

ฟังดูฉันชอบคุณควรแก้ไขปัญหาประสิทธิภาพการทำงานภายใน tempDB มีคำแนะนำเล็กน้อยที่นี่