การช่วงชิง TempDB

เรามีฐานข้อมูล OLTP 40GB ที่ใช้งานอยู่บน SQL Server 2014 SP1 พบว่าแบบสอบถามจะช้าเมื่อรอ IO_Completion ความยาวคิวดิสก์ที่เพิ่มขึ้นเป็น 900 และ SQL Server หยุดตอบสนอง สิ่งที่เราพยายาม:

1. รีสตาร์ทอินสแตนซ์และในอีกไม่กี่นาทีมันก็จะเริ่มทำงานในลักษณะเดียวกัน

2. หลังจากรีสตาร์ทครั้งที่สองเราเปลี่ยนขนาดเริ่มต้นของแต่ละ tempdb datafile (มีไฟล์ข้อมูล 16 ไฟล์ที่สร้างขึ้น) และเริ่มทำงานได้อย่างถูกต้อง

หมายเหตุ: เรากำลังใช้ตัวแปรตารางสำหรับชุดผลลัพธ์ระดับกลาง ชุดผลลัพธ์เหล่านี้มีขนาดเล็กมาก

มันเกิดขึ้นสองครั้งในหนึ่งเดือน ทุกครั้งที่ฉันเพิ่มพื้นที่ว่างเล็กน้อยลงในไฟล์ข้อมูลด้วยตนเองจากนั้นจะเริ่มทำงานตามปกติ สิ่งที่น่าสนใจกว่าก็คือการตั้งค่าเดียวกัน (ฮาร์ดแวร์เดียวกัน, โฟลเดอร์เดียวกันและการตั้งค่าไฟล์, ปริมาณงานเดียวกัน) ที่เรามีใน SQL Server 2008 R2 และ SQL Server 2012 ทำงานได้ดี

กรุณาช่วยเราหาวิธีแก้ไขปัญหาอย่างถาวร

ขนาดเริ่มต้นของไฟล์ข้อมูลทั้งหมดคือ 1,000MB เดียวกันปัจจุบันเป็นแต่ละไฟล์ 1500MB ทั้งหมดเหมือนกัน Autogrowth คือ 100MB สำหรับแต่ละอัน ก่อนหน้านี้เรากำลังเผชิญหน้ากับการช่วงชิงหน้า PFS และ GAM และเราเพิ่มขึ้นเป็น 16 และแก้ไขปัญหาได้ เปิดใช้งานแฟล็กการติดตามทั้ง 1117 และ 1118 24 cores บน 2 NUMA nodes datafiles ทั้งหมดอยู่ในปริมาณเดียวกัน ดิสก์ธรรมดาไม่มี SAN

อินสแตนซ์อยู่บนเครื่องฟิสิคัล แบบสอบถามที่มีตัวแปรตารางและแบบสอบถามที่มีตัวเชื่อมแฮชส่วนใหญ่กำลังสร้างการรอ IO_Completion

คำตอบโดยละเอียดโดย wBob ทำให้เราค้นหารายละเอียดเพิ่มเติม เราไม่เคยพลาดมาก่อน:

Autogrow ของไฟล์ 'templog' ในฐานข้อมูล 'tempdb' ถูกยกเลิกโดยผู้ใช้หรือหมดเวลาใช้งานหลังจาก 7704 มิลลิวินาที ใช้ ALTER DATABASE เพื่อตั้งค่า FILEGROWTH ที่เล็กลงสำหรับไฟล์นี้หรือเพื่อกำหนดขนาดไฟล์ใหม่อย่างชัดเจน

เราพบสิ่งนี้ในบันทึกเมื่อเกิดปัญหาประเภทนี้ขึ้น เรากำลังย้าย TempDB เพื่อแยกไดรฟ์ที่รวดเร็ว

ฉันคิดว่าคุณ overpagmented tempdb ของคุณและมีความไม่ตรงกันระหว่าง CPU ของเซิร์ฟเวอร์และการตั้งค่าดิสก์ แต่ขอรวบรวมข้อมูลเพิ่มเติม:

คำถาม / ข้อมูลเพิ่มเติมที่จำเป็น

• โปรดยืนยันชื่อโปรเซสเซอร์และประเภท (โดยทั่วไปฉันกำลังพยายามสร้างหากเป็น 2 x hex-core พร้อม HT) ใช้ข้อมูลระบบ (เช่นแผงควบคุม> ระบบและความปลอดภัย> ระบบบน Windows Server 2012 R2) และ / หรือเครื่องมือ sysinternals CoreInfoเพื่อยืนยัน
• โปรดยืนยันเซิร์ฟเวอร์ maxdop (เช่นEXEC sp_configure 'max degree of parallelism') หาก CPUs เป็น hex-core เซิร์ฟเวอร์ maxdop ควรมีค่าสูงสุด 6 (ตามที่นี่ ) หรือต่ำกว่าในระบบ OLTP ปกติฉันจะเก็บไฟล์ tempdb ของฉันให้สอดคล้องกับ DOP ของเซิร์ฟเวอร์ของฉันไม่เกิน 8 แต่เราจะเข้าสู่ที่
• กรุณายืนยันหน่วยความจำทั้งหมดของเซิร์ฟเวอร์ในกล่องและหน่วยความจำ SQL Server (เช่นEXEC sp_configure 'max server memory (MB)')
• โปรดยืนยันว่าบริการอื่น ๆ กำลังทำงานอยู่บนกล่อง (เช่น SSIS, SSAS, SSRS, แอปพลิเคชัน, iTunes เป็นต้น)
• โปรดยืนยันว่ามีการเปิดใช้งานการเริ่มต้นไฟล์ทันทีสำหรับบัญชีบริการ SQL Server (วิธีทดสอบที่นี่ )
• ทำไมถึงมีความแตกต่างอย่างมากระหว่างซีพียู (การตั้งค่าจำนวนเต็ม 2 โหนด NUMA) verus หนึ่งดิสก์ (พีซีที่บ้าน) พิจารณาการเพิ่มดิสก์การสตริป SSD สำหรับ tempdb (แม้ว่าจะหลีกเลี่ยงการทำปฏิกิริยามากเกินไป )
• โปรดเพิ่มแผนการดำเนินการจริงสำหรับหนึ่งในแบบสอบถามที่มีปัญหา ไม่ระบุชื่อกับ SQL Sentry Plan Explorerหากคุณต้องการ

• แฮเข้าร่วมกับตัวแปรตารางในระบบ OLTP หรือไม่ สิ่งนี้ชี้ให้เห็นว่าการขาดการจัดทำดัชนีตัวแปรตาราง, ตารางหลักหรือทั้งสองอย่าง คุณกำลังประกาศตัวแปรตารางของคุณเช่นนี้ (ไม่มีดัชนี) หรือไม่?

  DECLARE @t TABLE ( x INT )

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

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• การโพสต์แผนการดำเนินการจะช่วยวินิจฉัยปัญหานี้

• ตรวจสอบรหัสป้องกันแคชตัวแปรตารางตามที่นี่ , ที่นี่ ฉันคิดว่า dynamic SQL และ proc ดำเนินการกับ RECOMPILE เป็นสิ่งเดียวที่ส่งผลต่อตัวแปรตาราง

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• ตรวจสอบบันทึก SQL Server (Object Explorer> Management> SQL Server Logs) เพื่อดูข้อความเช่นคำเตือน IO

• ตรวจสอบ Windows Event Viewer
• มีบิลด์จำนวนหนึ่งวางจำหน่ายตั้งแต่ SP1 ตรวจสอบการแก้ไข CU ใส่ในตั้งแต่ SP1 อาจเป็นไปได้ว่ามีข้อบกพร่องใน SP1 ได้รับการแก้ไขใน CUs ที่ตามมาเช่นการแก้ไข: เรียงลำดับตัวดำเนินการที่รั่วไหลไปยัง tempdb ใน SQL Server 2012 หรือ SQL Server 2014 เมื่อจำนวนแถวและขนาดแถวโดยประมาณถูกต้อง https://support.microsoft.com/en- เรา / กิโลไบต์ / 3088480
• สร้างนี้เป็นสาเหตุของคุณก่อนที่จะใช้โปรแกรมแก้ไขด่วนใด ๆ แม้ว่าจะเป็นสิ่งที่สำคัญกว่าเพื่อให้ทันสมัยกับ CUs กับ SQL Server 2014 เนื่องจากจำนวนของคุณสมบัติใหม่ (OLTP ในหน่วยความจำคอลัมน์ในคลัสเตอร์)
• ในที่สุดความต้องการไฟล์ tempdb หนึ่งไฟล์ต่อหนึ่งคอร์เป็นตำนานและการตั้งค่าดิสก์ของคุณฉันเดาว่า tempdb มีการแยกส่วนมากเกินไป ฉันมีความรู้สึกที่ดุด่าว่าคุณมีหนึ่งหัวดิสก์, tempdb มีหนึ่งกลุ่มไฟล์, หลายไฟล์

อย่างไรก็ตามลืมสิ่งที่เราคิดว่าเรารู้ สร้างอุปกรณ์ทดสอบที่ทำซ้ำปัญหาของคุณและทดสอบด้วยการลดจำนวนไฟล์ temp ... เริ่มต้นที่ 1, 2, 4, 6 และอื่น ๆ รวบรวมข้อมูลเพื่อทำการตัดสินใจตามหลักฐาน ตอนนี้เป็นบิตยากขึ้นเนื่องจากปัญหาของคุณดูเหมือนเป็นระยะ ๆ และคุณอาจไม่สามารถยุ่งกับการตั้งค่า tempdb ของคุณ แต่นั่นเป็นวิธีที่ฉันจะเข้าหานี้

โชคดี. แจ้งให้เราทราบว่าคุณจะไปได้อย่างไร