อัปเดตสถิติที่มีการสแกนเต็มรูปแบบใน SQL Server 2014 ใช้ 100% cpu บน 2008 R2, 15%


10

เหตุใดสถิติการปรับปรุงการสแกนแบบสมบูรณ์จึงใช้ 100% ของ CPU ใน SQL Server 2014 เมื่อใช้ CPU 20% ของ SQL Server 2008 R2 สำหรับตารางเดียวกันโดยมีความสามารถด้านฮาร์ดแวร์ที่คล้ายกัน

ฉันได้ดูMAXDOPทางเลือกอื่น ๆ และไม่เห็นอะไรที่ชัดเจน ฉันรู้ว่าอาจมีการตั้งค่าที่อาจทำให้เกิดปัญหานี้ แต่การตั้งค่าคล้ายกันมากสำหรับฐานข้อมูลทั้งสอง (ตัวอย่างเช่นMAXDOPคือ 4 สำหรับทั้งคู่โดยที่ทั้งคู่มีหลายคอร์) ทั้งสองเป็น Enterprise Edition

มีบางสิ่งที่ "แตกต่าง" ใน SQL Server 2014 เทียบกับ SQL Server 2008 R2 ที่สามารถอธิบายสิ่งนี้ได้หรือไม่ ฉันมีตัวเลือกหน่วยความจำที่ 90% สำหรับเซิร์ฟเวอร์ทั้งสอง มีความคิดเกี่ยวกับสิ่งที่จะมองหา?

ฉันรันสถิติการอัพเดทด้วยการสแกนเต็มรูปแบบ (100%) สัปดาห์ละครั้งบนเซิร์ฟเวอร์สองเครื่องโดยใช้ SQL Server 2008 R2 / SP3 และ SQL Server 2014 / SP2 และฐานข้อมูลมีโครงสร้างเดียวกัน บนเซิร์ฟเวอร์ 2008 R2 สถิติการอัปเดตของสองตารางที่มีขนาดใหญ่มากใช้เวลาหลายชั่วโมงซึ่งเป็นสิ่งที่ฉันคาดหวัง แต่ CPU ยังคงต่ำกว่า 20% หรือการใช้ประโยชน์ตลอดเวลา บนเซิร์ฟเวอร์ 2014 แม้ว่า CPU จะไปที่ 100% เป็นเวลาประมาณ 40 นาที ตารางมีขนาดเล็กกว่าเล็กน้อยบนเซิร์ฟเวอร์ 2014 ฉันเห็นสิ่งนี้โดยใช้เมนูการวิเคราะห์ของ SQL Monitor

นี่คือผลลัพธ์ของ Ola log file บน 2014 SQL Server, CPU ไปที่ 100% จากประมาณ 2:10 ถึง 2:45:

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  
Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

นี่คือผลลัพธ์ของไฟล์บันทึก Ola บน 2008 R2 SQL Server สำหรับสองสถานะด้านบน แต่ CPU อาจไปถึง 15%:

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  
Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

ฉันไม่สามารถเรียกใช้พวกเขาด้วยเซิร์ฟเวอร์ maxdop = 1 เพราะนั่นจะกำจัดการสร้างแผนคู่ขนานทั้งหมดและนั่นอาจทำให้แอปพลิเคชันเสียหาย ฉันวางแผนที่จะไปในทิศทางตรงกันข้ามและเพิ่มเป็น 8 (มี 16 แกนในกล่อง) และดูว่าเกิดอะไรขึ้น อาจไปเร็วขึ้นเพื่อลดระยะเวลาที่ซีพียูถูกตรึง งานนี้ทำงานในขณะที่ผู้ใช้ส่วนใหญ่หายไป


คุณตรวจสอบว่ากระบวนการเชื่อมโยง IO กับเซิร์ฟเวอร์ 2008 R2 หรือไม่ การtempdbกำหนดค่าเหมือนกันหรือไม่ มันสามารถใช้งานได้ในขณะที่UPDATE STATISTICSกำลังทำงานดังนั้นอาจเป็นปัญหาได้เช่นกัน
MicSim

1
ฉันก็จะสงสัยว่าขนานกันน่าจะเป็นผู้กระทำผิด คุณได้ตรวจสอบเกณฑ์ต้นทุนสำหรับความเท่าเทียมโดยบังเอิญหรือไม่ นอกจากนี้อาจเป็นความคิดที่ดีที่จะได้รับรายการ sp_configure เต็มรูปแบบจากทั้งสองกล่องและแตกต่างกันเพื่อดูว่ามีอะไรแตกต่างกัน
DBADon

คำตอบ:


1

การอัพเดตสถิติสามารถทำงานแบบขนานโดยยึดตามตัวเลือกต่าง ๆ มากมายใน SQL Server:

  • เกณฑ์ค่าใช้จ่ายสำหรับความเท่าเทียม - ข้อความค้นหาจะต้องสูงพอที่จะนั่งรถไฟขนานกันได้ เซิร์ฟเวอร์ทั้งสองของคุณอาจมีการตั้งค่า CTFP ที่แตกต่างกันซึ่งทำให้การอัปเดต 2008R2 เป็นแบบเธรดเดี่ยวในขณะที่ 2014 สามารถไปแบบมัลติเธรดได้
  • Max Degree of Parallelism - กำหนดจำนวนของคอร์ที่สามารถใช้งานได้มากที่สุดถ้า SQL Server ตัดสินใจที่จะทำการขนานกันมาก กล่อง 2008R2 อาจตั้งค่า MAXDOP เป็น 1 ในขณะที่กล่อง 2014 อาจตั้งเป็นค่าเริ่มต้นเป็น 0 (ไม่ จำกัด )
  • Resource Governor - ฟีเจอร์ Enterprise Edition นี้จะช่วยให้คุณเร่งกลุ่มผู้ใช้หรือแอพพลิเคชั่นต่าง ๆ ให้กับ MAXDOPs ที่แตกต่างกัน

ใน SQL Server รุ่นที่ใหม่กว่า (2016 และใหม่กว่า) สิ่งนี้มีความซับซ้อนมากยิ่งขึ้น:

  • ตัวเลือกที่กำหนดขอบเขตระดับฐานข้อมูล - คุณสามารถคลิกขวาที่ฐานข้อมูลไปยังคุณสมบัติและตั้งค่าระดับ MAXDOP สำหรับฐานข้อมูลนั้น
  • คำแนะนำเกี่ยวกับความเท่าเทียมกันทางสถิติ - เริ่มในปี 2559 SP2 คำสั่งการสร้างและอัปเดตสถิติจะยอมรับคำแนะนำ MAXDOP

ดังที่คุณได้บันทึกไว้ 2008R2 ของคุณจะเป็นแบบเธรดเดียวในขณะที่ปี 2014 นั้นจะเป็นแบบมัลติเธรด

เพื่อหาสมดุลที่เหมาะสมสำหรับงานสถิติของคุณคิดเกี่ยวกับ:

  • ปริมาณงานอื่น ๆ ที่เกิดขึ้นในฐานข้อมูลในเวลาเดียวกัน? คุณสามารถที่จะครองกล่องในช่วงเวลาสั้น ๆ ? ตัวอย่างเช่นในคลังข้อมูลที่ไม่ได้ใช้งานในช่วงสุดสัปดาห์ที่ผ่านมาฉันเคยเห็นผู้คนจำนวนมากต่างอัปเดตสถิติด้วย fullscans เมื่อพวกเขารู้ว่าไม่มีใครใช้เซิร์ฟเวอร์อยู่ดี ในสภาพแวดล้อมการทำธุรกรรมหนักคุณต้องเริ่มใช้ผลกระทบน้อยลงสำหรับงานบำรุงรักษาหากผู้ใช้บ่นแม้ในช่วงเวลาเที่ยงคืน
  • fullscan จำเป็นจริงๆหรือ คุณเห็นข้อความค้นหาที่ได้รับแผนการที่ดีเมื่อคุณใช้ตัวเลือก fullscan หรือคุณเพียงทำตามวิธีปฏิบัติที่ดีที่สุด? เมื่อฐานข้อมูลของคุณเติบโตขึ้นหากการลงทุนด้านฮาร์ดแวร์ของคุณไม่ก้าวหน้าคุณอาจต้องเริ่มทำการแลกเปลี่ยนในการสุ่มตัวอย่างสถิติแทนที่จะทำการสแกนแบบเต็ม ๆ
  • คุณสามารถอัพเดตสถิติได้บ่อยน้อยลงหรือไม่? ตัวอย่างเช่นอัปเดตสถิติ 1/4 ของคุณในสุดสัปดาห์และจากนั้นทุกเดือนทุกอย่างจะได้รับการอัปเดตสถิติ
  • คุณสามารถปรับปรุงวัตถุให้น้อยลงได้ไหม? บ่อยครั้งที่ฉันเห็นผู้คนอัปเดตสถิติแม้ในตารางตรวจสอบขนาดใหญ่หรือเก็บถาวรเพียงเพราะมีการเพิ่มเม็ดมีดใหม่จำนวนไม่กี่โหล

0

ชุมชนวิกิพีเดียคำตอบ :

ดีที่สุดเดา: แผนที่เลือกเพื่ออัปเดตสถิติเป็นแบบขนานหรือขนานในกล่อง 2014 มากกว่าในกล่อง 2008 R2

สถิติการอัปเดตแบบขนานสำหรับfullscanมีมาตั้งแต่ปี 2005 และสำหรับสถิติตัวอย่างที่เริ่มต้นด้วย 2016 ดูการเพิ่มประสิทธิภาพของเครื่องมือค้นหาใน SQL Server 2016โดย Gjorgji Gjeorgjievski ในบล็อก SQL Server Database Engine

หากคุณมี Enterprise Edition คุณสามารถใช้ตัวควบคุมทรัพยากรเพื่อ จำกัด CPU ที่ใช้โดยงานบำรุงรักษาของคุณ

ยังพิจารณาการลงคะแนนสำหรับการเชื่อมต่อข้อเสนอแนะเพิ่มMAXDOPพารามิเตอร์เพื่อปรับปรุงสถิติโดย Javier Villegas

คำถาม & คำตอบที่เกี่ยวข้อง: การอัปเดตสถิติแบบขนาน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.