อะไรคือจุดร้อนในบริบทของการเพิ่มไฟล์ไปยัง tempdb?


12

ฉันพยายามค้นหาว่าสามารถเพิ่มไฟล์ tempdb ลงใน SQL Server ได้หรือไม่โดยไม่ต้องเริ่มบริการ SQL Server อีกครั้ง ฉันเห็นคำตอบนี้ที่นี่ในผู้ดูแลฐานข้อมูล:

และหนึ่งคำตอบระบุว่า:

เพิ่ม - ไม่จำเป็นต้องหยุดทำงาน แม้ว่าฌอนจาก Microsoft ชี้ให้เห็นว่า SQL จะต้องการใช้ไฟล์ที่เติมด้านล่าง หากคุณไปจากไฟล์ข้อมูล 1 ไฟล์และเพิ่มมากขึ้นแล้ว SQL จะใช้ไฟล์ใหม่ชั่วครู่หนึ่ง แต่ประสิทธิภาพของคุณจะไม่แย่ไปกว่าการมีเพียงไฟล์เดียว อย่างไรก็ตามหากคุณมี 2+ แล้วและเพิ่มอีกหนึ่งมันจะฮอตสปอตในใหม่และลดประสิทธิภาพ

อย่างไรก็ตามความคิดเห็นข้อควรระวังต่อไปนี้:

ฉันจะใส่ภาคผนวกไว้ในส่วน "เพิ่ม": "เพิ่ม: ไม่ แต่คุณมักจะมีความไม่สมดุลดังนั้นคุณจะพบว่าร้อนแรงซึ่งอาจทำให้สิ่งต่าง ๆ แย่ลงมาก"

ฉันมีคำถามต่อไปนี้เกี่ยวกับความคิดเห็นนั้น แต่ได้รับคำแนะนำให้ถามคำถามเหล่านั้นในคำถามใหม่ของฉันเอง (คำถามนี้) แทนที่จะถามผู้แสดงความคิดเห็นผ่านความคิดเห็นในคำตอบของคำถามนั้น

โดยเฉพาะ:

  1. การจำที่ร้อนแรงคืออะไร (ฉันได้รับข้อมูลบางอย่างผ่านทาง Google แต่ไม่มีรายละเอียดว่าจะเกิดอะไรขึ้นกับฮอตสปอตบน tempdb หลังจากเพิ่มไฟล์)
  2. สิ่งที่เกี่ยวกับการจำร้อนทำให้สิ่งเลวร้ายยิ่งขึ้นใน tempdb?
  3. มีอะไรพิเศษในฐานข้อมูลที่จะแย่ลงไปอีก?

คำตอบ:


16
  1. การจำที่ร้อนแรงคืออะไร

    "Hot spotting" ในบริบทนี้หมายความว่าแม้ว่า tempdb จะมีหลายไฟล์งาน I / O ทั้งหมดจะถูกดำเนินการในไฟล์เดียว หาก tempdb ไม่ว่างพอที่จะพิสูจน์การเพิ่มไฟล์ความไม่สมดุลที่นำไปสู่การหาจุดร้อน (เนื่องจากการเติมตามสัดส่วน ) จะสั้นดังนั้นฉันคิดว่าคำเตือนอาจเป็น Chicken Little เล็กน้อย จากประสบการณ์ของฉัน

  2. สิ่งที่เกี่ยวกับการจำร้อนทำให้สิ่งเลวร้ายยิ่งขึ้นใน tempdb?

    ฉันคิดว่ามันเลวร้ายกว่าใน tempdb เพราะใช้ความรุนแรงของกิจกรรมการเขียนในปริมาณงานส่วนใหญ่ คุณสามารถประสบปัญหาที่คล้ายกันในฐานข้อมูลผู้ใช้ แต่เนื่องจากคุณพยายามแก้ไขปัญหาใน tempdb ...

  3. มีอะไรพิเศษในฐานข้อมูลที่จะแย่ลงไปอีก?

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

    ตรวจสอบให้แน่ใจ:


10
  1. การจำที่ร้อนแรงคืออะไร

แอรอนถูกต้องแล้วและฉันจะไม่ทำสิ่งที่เขาพูดไว้ข้างต้น แต่มันไม่ใช่แค่ดิสก์ IO ส่วนหลักที่คนส่วนใหญ่มีปัญหากับใน TempDB เกิดจากการช่วงชิงโครงสร้างการติดตามบางอย่าง

เนื่องจากการมีไฟล์ tempdb หลายไฟล์ทำให้อัลกอริทึมการเติมและปัดเศษเป็นสัดส่วนได้อย่างมีประสิทธิภาพในการเป็น "ยุติธรรม" ในการจัดสรรการเพิ่มไฟล์ใหม่โดยไม่มีการจัดสรรเกิดขึ้น ฉันไม่เห็นด้วยว่าเป็นคำเตือน "ไก่ตัวเล็ก" (ดูอัปเดตผลิตภัณฑ์ด้านล่าง) หากคุณเริ่มเห็นการPAGELATCH_*รอไฟล์ใหม่ที่กล่าวมาและไม่มากหรือน้อยในไฟล์อื่น ๆ สิ่งนี้มักเกิดขึ้นกับระบบที่มีกิจกรรม TempDB สูงและมีมากกว่าหนึ่งไฟล์

โปรดทราบว่ามีตัวเลือกใน SQL Server 2019 เพื่อเปลี่ยนตารางระบบพื้นฐานบางส่วนเป็นตารางในหน่วยความจำซึ่งอาจมีการปรับปรุงเนื่องจากวัตถุในหน่วยความจำได้รับการจัดสรรแตกต่างจากตารางที่ทำจากดิสก์ ตารางที่ยึดตามดิสก์เป็นตารางดั้งเดิมที่เราทุกคนทำงานด้วยกันมาหลายปี SQL Server 2014 แนะนำตารางที่ปรับให้เหมาะสมกับหน่วยความจำ SQL Server 2019 สามารถจัดการข้อมูลเมตาของการจัดสรรบางอย่างในตารางปรับให้เหมาะสมหน่วยความจำ

มีการเปลี่ยนแปลงอื่นใน SQL Server 2019 เพื่อช่วยในการเปลี่ยนแปลง PFS ที่เกิดขึ้นพร้อมกันซึ่งโดยทั่วไปแล้วสิ่งที่การโต้แย้งสำหรับโครงสร้างหน่วยความจำในการจัดสรรกำลังPAGELATCH_*รออยู่

  1. สิ่งที่เกี่ยวกับการจำร้อนทำให้สิ่งเลวร้ายยิ่งขึ้นใน tempdb?

IMHO ใช่ TempDB มีรายการเพิ่มเติมที่สามารถทำให้เขียนได้โดยไม่ต้องใช้โดยตรงเพื่อให้สามารถขัดขวางบางรายการ อย่างไรก็ตามฐานข้อมูลผู้ใช้ที่ยุ่งมากในแง่ของอัตราการเปลี่ยนแปลงข้อมูลนั้นไม่ดีเท่าที่ควร ไม่ จำกัด เพียงแค่ TempDB

  1. มีอะไรพิเศษในฐานข้อมูลที่จะแย่ลงไปอีก?

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

แอรอนชี้ให้เห็นแล้วว่าในเวอร์ชั่นเก่ามีแฟล็กการติดตามเพื่อให้แน่ใจว่ามีการใช้ extents สม่ำเสมอและไฟล์ทั้งหมดในกลุ่มไฟล์เติบโตร่วมกัน (แอรอนชี้ให้เห็นว่า 1117 และ 1118 ซึ่งเป็น NOP ในปี 2559+) สิ่งอื่น ๆ ที่ฉันต้องการจะชี้ให้เห็นอีกครั้งคือสิ่งนี้ไม่เพียง แต่สำหรับ TempDB แต่สำหรับฐานข้อมูลใด ๆ และรูปแบบทางกายภาพควรคำนึงถึงตามความต้องการ

นี่ไม่เพียง แต่สำหรับปัญหาฮอตสปอต แต่ใช้ได้กับส่วนอื่น ๆ ของระบบเช่นการสำรอง / กู้คืนการจัดการไฟล์การกระจายตัวเมตาดาต้าของระบบไฟล์ ฯลฯ ซึ่งทั้งหมดสามารถช่วยได้ด้วยการมีหลายไฟล์

คุณสามารถเห็นการช่วงชิงโครงสร้างการจัดสรรโดยค้นหาwaitresourceหน้า PFS (ซึ่งก็คือหน้า 1 และหน้า 8088 ทุกหน้า) หากคุณเห็นว่าทั้งหมดในไฟล์เดียวกัน (2: ไฟล์: หน้า) จากนั้นคุณรู้ว่าสิ่งนี้เกิดขึ้น

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