แนะนําการกําหนดค่าฐานข้อมูล

เสร็จสมบูรณ์เมื่อ

ก่อนที่คุณจะสามารถปรับแต่งคิวรีหรือแก้ไขปัญหาการทํางานพร้อมกัน ฐานข้อมูล Azure SQL ให้แบบจําลองทรัพยากรสองแบบและระดับบริการหลายระดับ ชุดค่าผสมที่คุณเลือกจะกําหนดเพดานการประมวลผล หน่วยความจํา I/O และพื้นที่จัดเก็บสําหรับปริมาณงานของคุณ เลือกน้อยเกินไปและประสิทธิภาพจะลดลง เลือกมากเกินไปและคุณเสียงบประมาณ

เปรียบเทียบแบบจําลองทรัพยากร

ฐานข้อมูล Azure SQL รองรับโมเดลทรัพยากรสองแบบ: vCore และ DTU พวกเขาวัดและเรียกเก็บเงินทรัพยากรต่างกัน ดังนั้นการทําความเข้าใจความแตกต่างจะช่วยให้คุณตัดสินใจได้ถูกต้องตั้งแต่เริ่มต้น

โมเดล vCore ช่วยให้คุณควบคุมคอร์เสมือน หน่วยความจํา และที่เก็บข้อมูลได้โดยตรง คุณเลือกการสร้างฮาร์ดแวร์ ระดับบริการ และระดับการประมวลผลอย่างอิสระ หากคุณกําลังโยกย้ายจาก SQL Server ในองค์กร โมเดลนี้จะแมปกับ CPU และหน่วยความจําจริงอย่างหมดจด ซึ่งทําให้การวางแผนความจุตรงไปตรงมามากขึ้น นอกจากนี้ยังรองรับการกําหนดราคาอินสแตนซ์แบบเหมาจ่ายและ Azure Hybrid Benefit เพื่อการประหยัดต้นทุน

โมเดล DTU รวม CPU, หน่วยความจํา และ I/O ไว้ในหน่วยเดียวที่เรียกว่า Database Transaction Unit (DTU) ระดับที่ใช้ DTU (พื้นฐาน มาตรฐาน และพรีเมียม) มีแพ็คเกจทรัพยากรที่กําหนดค่าไว้ล่วงหน้า โมเดลนี้ใช้ได้เมื่อคุณไม่ต้องการการควบคุมแบบละเอียดในมิติทรัพยากรแต่ละรายการ

สําหรับการปรับใช้ใหม่ส่วนใหญ่ Microsoft ขอแนะนําโมเดล vCore มีขีดจํากัดทรัพยากรที่สูงขึ้น ความละเอียดในการปรับขนาดที่มากขึ้น และความยืดหยุ่นในการกําหนดราคาที่มากขึ้น

ทําความเข้าใจระดับบริการในแบบจําลอง vCore

โมเดล vCore มีสามระดับบริการ: วัตถุประสงค์ทั่วไป Business Critical และ Hyperscale แต่ละระดับใช้สถาปัตยกรรมที่แตกต่างกัน ซึ่งส่งผลต่อประเภทพื้นที่จัดเก็บ ประสิทธิภาพ I/O และความพร้อมใช้งาน

วัตถุประสงค์ทั่วไป แยกการประมวลผลและพื้นที่จัดเก็บ กลไกจัดการฐานข้อมูลทํางานบนโหนดการประมวลผลในขณะที่ไฟล์ข้อมูลอยู่บนที่เก็บข้อมูล Azure Blob เวลาแฝงของพื้นที่จัดเก็บโดยทั่วไปจะอยู่ระหว่าง 5 มิลลิวินาทีถึง 10 มิลลิวินาที สถาปัตยกรรมนี้ให้ราคาที่เป็นมิตรกับงบประมาณและทํางานได้ดีกับปริมาณงานทางธุรกิจส่วนใหญ่ หากโหนดคอมพิวท์ล้มเหลว Azure Service Fabric จะย้ายกระบวนการไปยังโหนดสํารองและแนบไฟล์ที่เก็บข้อมูลระยะไกลอีกครั้ง

พิจารณาแอปพลิเคชันอีคอมเมิร์ซจากบทนํา ในช่วงเวลาทําการปกติ General Purpose จะจัดการปริมาณการสั่งซื้อโดยไม่มีปัญหา แต่ในระหว่างการลดราคาแฟลชในช่วงวันหยุด เวลาแฝง I/O ที่ 5 มิลลิวินาทีถึง 10 มิลลิวินาทีอาจไม่เร็วพอสําหรับขั้นตอนการชําระเงิน

Business Critical รวมการประมวลผลและพื้นที่จัดเก็บข้อมูลในแต่ละโหนด กลไกฐานข้อมูลและไฟล์ข้อมูลใช้ทั้ง SSD ที่แนบมาในเครื่องในกลุ่มความพร้อมใช้งาน Always On พร้อมแบบจําลองรองสามแบบ การออกแบบนี้ให้เวลาแฝง I/O ต่ําที่สุด (โดยเฉลี่ย 1 มิลลิวินาทีถึง 2 มิลลิวินาที) IOPS สูงสุด (การดําเนินการอินพุต/เอาต์พุตต่อวินาที) และแบบจําลองแบบอ่านอย่างเดียวฟรีที่คุณสามารถใช้สําหรับการสืบค้นการรายงาน การแลกเปลี่ยนคือต้นทุน ซึ่งมากกว่าวัตถุประสงค์ทั่วไปประมาณ 2.7 เท่าสําหรับจํานวน vCore เดียวกัน สําหรับทีมอีคอมเมิร์ซ Business Critical นั้นสมเหตุสมผลหากธุรกรรมการชําระเงินของพวกเขาต้องการเวลาแฝงต่ํากว่า 2 มิลลิวินาทีที่สม่ําเสมอ

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

ตารางต่อไปนี้สรุปความแตกต่างที่สําคัญ:

คุณสมบัติ	วัตถุประสงค์ทั่วไป	วิกฤตธุรกิจ	Hyperscale
ชนิดที่เก็บข้อมูล	รีโมต (ที่เก็บข้อมูล Azure Blob)	SSD ในเครื่อง	แยกออกจากกันด้วยแคช SSD ในเครื่อง
พื้นที่เก็บข้อมูลสูงสุด	วัณโรค 4	วัณโรค 4	วัณโรค 128
IOPS สูงสุดต่อ vCore	320	4,000	5,500 (SSD ในเครื่อง)
แบบจําลองความพร้อมใช้งาน	1 (ไม่มีแบบจําลองการอ่าน)	3 + 1 แบบจําลองการอ่าน	0 ถึง 4 (กําหนดค่าได้)
เหมาะสำหรับ	ปริมาณงานที่เน้นงบประมาณ	เวลาแฝงต่ํา I/O สูง	ฐานข้อมูลขนาดใหญ่ การปรับขนาดที่ยืดหยุ่น

เลือกระดับการประมวลผล

ภายในโมเดล vCore คุณยังเลือกระหว่างระดับการประมวลผลสองระดับ: การเตรียมใช้งานและแบบไร้เซิร์ฟเวอร์

การประมวลผลที่มีการเตรียมใช้งาน จะจัดสรร vCore จํานวนคงที่ที่พร้อมใช้งานโดยไม่คํานึงถึงกิจกรรมปริมาณงาน คุณจ่ายในอัตรารายชั่วโมงคงที่ ระดับนี้เหมาะกับปริมาณงานที่มีการใช้ทรัพยากรที่สม่ําเสมอหรือคาดการณ์ได้ เช่น แอปพลิเคชันอีคอมเมิร์ซที่ประมวลผลใบสั่งตลอดทั้งวัน

การประมวลผลแบบไร้เซิร์ฟเวอร์ จะปรับขนาด vCore โดยอัตโนมัติตามความต้องการและค่าบริการต่อวินาทีสําหรับการประมวลผลที่ใช้ เมื่อฐานข้อมูลไม่ได้ใช้งาน ฐานข้อมูลจะสามารถหยุดชั่วคราวโดยอัตโนมัติและขจัดต้นทุนการคํานวณได้ทั้งหมด แม้ว่าปัจจุบันการหยุดชั่วคราวอัตโนมัติจะได้รับการสนับสนุนเฉพาะในวัตถุประสงค์ทั่วไปเท่านั้น การประมวลผลแบบไร้เซิร์ฟเวอร์นั้นพร้อมใช้งานสําหรับทั้งระดับวัตถุประสงค์ทั่วไปและระดับไฮเปอร์สเกล ทํางานได้ดีสําหรับสภาพแวดล้อมการพัฒนา เครื่องมือภายใน หรือแอปพลิเคชันที่มีการรับส่งข้อมูลไม่ต่อเนื่อง

จับคู่การกําหนดค่ากับปริมาณงานของคุณ

เมื่อคุณเข้าใจตัวเลือกแล้ว คุณจะตัดสินใจอย่างไร? ประเมินภาระงานของคุณโดยพิจารณาจากปัจจัยเหล่านี้:

• ข้อกําหนดเวลาแฝง: หากแอปพลิเคชันของคุณต้องการเวลาแฝง I/O ต่ํากว่า 2 มิลลิวินาทีอย่างสม่ําเสมอ ให้เลือก Business Critical สําหรับความทนทานต่อเวลาแฝงปานกลาง General Purpose ก็เพียงพอแล้ว
• ขนาดพื้นที่เก็บข้อมูล: หากฐานข้อมูลของคุณมีขนาดเกิน 4 TB หรือคุณคาดว่าจะเติบโตอย่างรวดเร็ว Hyperscale เป็นตัวเลือกเดียวที่รองรับได้สูงสุด 128 TB
• ปริมาณงานที่อ่านหนัก: Business Critical มีแบบจําลองแบบอ่านอย่างเดียวฟรี ไฮเปอร์สเกลรองรับแบบจําลองที่มีชื่อเพื่อการปรับขนาดการอ่านที่ยืดหยุ่น
• ความอ่อนไหวต่อต้นทุน: วัตถุประสงค์ทั่วไปพร้อมการประมวลผลที่มีการเตรียมใช้งานให้ราคาที่คาดการณ์ได้ การประมวลผลแบบไร้เซิร์ฟเวอร์ในการใช้งานทั่วไปหรือไฮเปอร์สเกลช่วยลดต้นทุนสําหรับปริมาณงานที่ไม่ต่อเนื่อง
• ข้อกําหนดด้านความพร้อมใช้งาน: Business Critical ให้ความยืดหยุ่นสูงสุดด้วยแบบจําลองแบบซิงโครนัสสามแบบและการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาดที่เร็วที่สุด ไฮเปอร์สเกลช่วยให้คุณสามารถกําหนดค่าจํานวนแบบจําลองเพื่อปรับสมดุลความยืดหยุ่นกับต้นทุน

เคล็ดลับ

เมื่อโยกย้ายจาก SQL Server ภายในองค์กร ให้ใช้แบบจําลอง vCore เนื่องจากแมปโดยตรงกับ CPU และหน่วยความจําทางกายภาพ แบบจําลอง DTU ไม่เปิดเผยมิติทรัพยากรแต่ละรายการ ซึ่งทําให้การวางแผนกําลังการผลิตยากขึ้นสําหรับการโยกย้าย

กําหนดการตั้งค่าระดับฐานข้อมูล

คุณเลือกระดับและรูปแบบการประมวลผลของคุณ ตอนนี้ดูภายในฐานข้อมูลเอง การตั้งค่าหลายอย่างส่งผลต่อวิธีที่ฐานข้อมูล Azure SQL จัดการกับความขนาน การเพิ่มประสิทธิภาพคิวรี และการกู้คืน คุณปรับการตั้งค่าเหล่านี้ได้โดยไม่ต้องเปลี่ยนระดับบริการ

ควบคุมความขนานด้วย MAXDOP

ระดับสูงสุดของความขนาน (MAXDOP) ควบคุมจํานวนเธรดตัวประมวลผลที่เอ็นจิ้นกําหนดให้กับคิวรีเดียว ฐานข้อมูล Azure SQL มีค่าเริ่มต้นเป็น 8 ซึ่งใช้ได้กับปริมาณงานที่หลากหลายที่สุด ก่อนเดือนกันยายน 2020 ฐานข้อมูลใหม่มีค่าเริ่มต้นเป็น 0 ความขนานไม่จํากัด และนั่นทําให้เกิดปัญหา การสืบค้นการวิเคราะห์เดียวอาจใช้ทุกเธรดที่มีอยู่ทําให้ขั้นตอนการชําระเงินของ CPU อดอยาก

คุณตั้งค่า MAXDOP ที่ระดับฐานข้อมูลด้วยALTER DATABASE SCOPED CONFIGURATION SET MAXDOP คุณยังสามารถตั้งค่าที่แตกต่างกันสําหรับแบบจําลองรองเมื่อปริมาณงานแบบอ่าน-เขียนและอ่านอย่างเดียวของคุณมีความต้องการการทํางานพร้อมกันที่แตกต่างกัน สําหรับคําค้นหาที่เฉพาะเจาะจง ให้ใช้ OPTION (MAXDOP) คําใบ้ กฎข้อเดียว: หลีกเลี่ยง MAXDOP 0 ในการผลิต การขนานแบบไม่จํากัดนําไปสู่การหมดทรัพยากร การหมดเวลาการสืบค้น และการหยุดทํางานของแอปพลิเคชัน

ให้การปรับแต่งอัตโนมัติจับการถดถอย

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

ฐานข้อมูล Azure SQL รองรับสามตัวเลือก:

• FORCE_LAST_GOOD_PLAN ตรวจจับการถดถอยของแผนและบังคับให้แผนด่วนก่อนหน้านี้ เปิดใช้งานตามค่าเริ่มต้น
• CREATE_INDEX ระบุดัชนีที่ขาดหายไป ปิดใช้งานตามค่าเริ่มต้น
• DROP_INDEX จะลบดัชนีที่ไม่ได้ใช้และซ้ํากัน ปิดใช้งานตามค่าเริ่มต้น ดัชนีที่ไม่ซ้ํากัน รวมถึงดัชนีที่สนับสนุนคีย์หลักและข้อจํากัดที่ไม่ซ้ํากันจะไม่ถูกทิ้ง

การเปลี่ยนแปลงทุกครั้งจะผ่านกรอบเวลาการตรวจสอบความถูกต้อง 30 นาทีถึง 72 ชั่วโมง ขึ้นอยู่กับความถี่ในการสืบค้น หากประสิทธิภาพแย่ลง การเปลี่ยนแปลงจะถูกเปลี่ยนกลับโดยอัตโนมัติ

ALTER DATABASE CURRENT
SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN = ON,
                      CREATE_INDEX = ON,
                      DROP_INDEX = OFF);

ลองนึกถึงแอปพลิเคชันอีคอมเมิร์ซในช่วงลดราคาวันหยุด รูปแบบการสืบค้นเปลี่ยนไปเมื่อหน้าผลิตภัณฑ์ต่างๆ ได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว FORCE_LAST_GOOD_PLAN จับการถดถอยเหล่านั้นโดยอัตโนมัติ ดังนั้นการเปลี่ยนแปลงแผนที่ไม่ดีในเวลาตี 2 จะไม่ทําให้การชําระเงินช้าลงจนกว่าจะมีคนสังเกตเห็นเช้าวันจันทร์ คุณอาจต้องการปล่อยให้ CREATE_INDEX และ DROP_INDEX จนกว่าสิ่งที่พวกเขาเสนอจะได้รับการตรวจสอบ

ปลดล็อกคุณสมบัติเครื่องมือเพิ่มประสิทธิภาพด้วยระดับความเข้ากันได้

ทุกฐานข้อมูลมี ระดับความเข้ากันได้ ที่กําหนดลักษณะการทํางานของเครื่องมือเพิ่มประสิทธิภาพคิวรีที่พร้อมใช้งาน ฐานข้อมูลใหม่ในฐานข้อมูล Azure SQL มีค่าเริ่มต้นเป็นระดับ 170 หรือระดับสูงสุดที่พร้อมใช้งาน แต่ละระดับจะปลดล็อกชุดคุณสมบัติการประมวลผลแบบสอบถามอัจฉริยะ (IQP):

• ระดับ 150: โหมดแบทช์บน rowstore, การคอมไพล์ที่รอการตัดบัญชีของตัวแปรตาราง, การอินไลน์ของฟังก์ชันที่ผู้ใช้กําหนดเอง (UDF) แบบสเกลาร์
• ระดับ 160: การเพิ่มประสิทธิภาพแผนที่ละเอียดอ่อนของพารามิเตอร์ (PSP) ข้อเสนอแนะการประมาณค่าคาร์ดินาลลิตี้
• ระดับ 170: การเพิ่มประสิทธิภาพแผนพารามิเตอร์เพิ่มเติม

ฐานข้อมูลที่มีอยู่สามารถทํางานในระดับความเข้ากันได้ที่ต่ํากว่า เนื่องจาก Microsoft ไม่เคยปรับรุ่นการตั้งค่านี้โดยอัตโนมัติ ฐานข้อมูลที่สร้างขึ้นเมื่อค่าเริ่มต้นที่ต่ํากว่ามีผลบังคับใช้จะคงระดับเดิมไว้ ตัวอย่างเช่น หากคุณสร้างฐานข้อมูล Azure SQL ในปี 2024 ฐานข้อมูลจะยังคงอยู่ที่ระดับ 160 หากระดับไม่ได้รับการอัปเดตด้วยตนเอง ในทํานองเดียวกัน ถ้าคุณนําเข้าฐานข้อมูลผ่านแฟ้ม BACPAC ระดับความเข้ากันได้ของฐานข้อมูลที่นําเข้าจะขึ้นอยู่กับระดับความเข้ากันได้ของฐานข้อมูลต้นทาง วิธีเลื่อนขึ้น

ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 170;

อย่าเปลี่ยนการตั้งค่านี้อย่างสุ่มสี่สุ่มสี่สุ่มห้าในการผลิต ใช้ Query Store เพื่อบันทึกพื้นฐานประสิทธิภาพในระดับปัจจุบัน อัปเกรดในสภาพแวดล้อมการทดสอบ และเปรียบเทียบ หากคําค้นหาถดถอย คุณสามารถบังคับใช้แผนเก่าได้ในขณะที่คุณตรวจสอบ

ลดการบวมแคชของแผนด้วย OPTIMIZE_FOR_AD_HOC_WORKLOADS

แอปพลิเคชันอีคอมเมิร์ซสร้างคําค้นหาผลิตภัณฑ์ด้วยชุดตัวกรองหลายสิบชุด ข้อความคิวรีที่ไม่ซ้ํากันแต่ละข้อความจะได้รับแผนที่คอมไพล์ของตัวเองในแคช แม้ว่าคิวรีนั้นจะไม่ทํางานอีกก็ตาม เมื่อเวลาผ่านไป แคชของแผนจะเต็มไปด้วยแผนแบบใช้ครั้งเดียวหลายพันแผน ซึ่งผลักดันแผนที่ดําเนินการบ่อยซึ่งมีความสําคัญจริงๆ

OPTIMIZE_FOR_AD_HOC_WORKLOADS แก้ปัญหานี้ได้ เมื่อเปิดใช้งาน เอ็นจิ้นจะจัดเก็บ ต้นขั้วแผนที่คอมไพล์ ขนาดเล็กในการดําเนินการครั้งแรกแทนที่จะเป็นแผนทั้งหมด เฉพาะเมื่อคิวรีเดียวกันทํางานเป็นครั้งที่สองเท่านั้นที่กลไกจัดการจะคอมไพล์และแคชแผนทั้งหมด

ALTER DATABASE SCOPED CONFIGURATION
SET OPTIMIZE_FOR_AD_HOC_WORKLOADS = ON;

การตั้งค่านี้ช่วยให้แคชไม่เป็นไร และทําให้แน่ใจว่าแผนสําหรับคําค้นหาที่สําคัญที่สุดของคุณจะยังคงอยู่ในหน่วยความจํา

ทําความเข้าใจการกู้คืนฐานข้อมูลแบบเร่งด่วน

การกู้คืนฐานข้อมูลแบบเร่งจะเปิดใช้งานในฐานข้อมูล Azure SQL เสมอ คุณไม่สามารถปิดได้ และคุณไม่จําเป็นต้องปิด การกู้คืนฐานข้อมูลแบบเร่ง (ADR) จะออกแบบกระบวนการกู้คืนใหม่เพื่อให้เวลาการกู้คืนคงที่โดยไม่คํานึงถึงจํานวนธุรกรรมที่ใช้งานอยู่ที่ทํางานอยู่เมื่อเกิดความล้มเหลว นอกจากนี้ยังให้การย้อนกลับธุรกรรมทันทีและการตัดทอนบันทึกเชิงรุก

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

PVS แบ่งปันพื้นที่เก็บข้อมูลที่จัดสรรของฐานข้อมูลของคุณ ดังนั้น PVS ที่เพิ่มขึ้นจะลดพื้นที่ว่างสําหรับข้อมูลของคุณ เมื่อต้องการตรวจสอบค่าโสหุ้ย PVS นอกแถว ให้สอบถาม sys.dm_tran_persistent_version_store_stats และตรวจสอบ persistent_version_store_size_kb คอลัมน์ ซึ่งรายงานขนาดของเวอร์ชันนอกแถวเท่านั้น และไม่รวมเวอร์ชันในแถวที่จัดเก็บไว้ในหน้าข้อมูล เมื่อต้องการสร้างพื้นฐานระหว่างปริมาณงานทั่วไป ให้เปรียบเทียบค่านั้นกับขนาดฐานข้อมูลทั้งหมดของคุณ หาก PVS เติบโตเกินกว่าพื้นฐานนั้นอย่างมีนัยสําคัญ ให้มองหาธุรกรรมที่ดําเนินมาเป็นเวลานานหรืออัตราการยกเลิกที่สูงซึ่งทําให้การล้างเวอร์ชันล่าช้า

ประเด็นสําคัญ

ฐานข้อมูล Azure SQL ให้โมเดลทรัพยากรสองแบบ ระดับบริการสามระดับ และระดับการประมวลผลสองระดับ โมเดล vCore ที่มีวัตถุประสงค์ทั่วไปครอบคลุมปริมาณงานส่วนใหญ่ Business Critical เพิ่มเวลาแฝงต่ํากว่า 2 มิลลิวินาที ไฮเปอร์สเกลจะขจัดขีดจํากัดการจัดเก็บและการปรับขนาด ภายในฐานข้อมูล MAXDOP 8 เป็นค่าเริ่มต้นที่ปลอดภัย การปรับแต่งอัตโนมัติจะจับการถดถอยของแผน และการอัปเกรดระดับความเข้ากันได้ของคุณจะปลดล็อกคุณสมบัติการประมวลผลแบบสอบถามอัจฉริยะ (IQP) ล่าสุด เปิดใช้งาน OPTIMIZE_FOR_AD_HOC_WORKLOADS เพื่อรักษาแคชแผนให้สะอาด และตรวจสอบการใช้ที่เก็บข้อมูล PVS จาก ADR โดยใช้ sys.dm_tran_persistent_version_store_statsโดยเฉพาะอย่างยิ่งในสถานการณ์ที่มีการเขียนหนัก ถัดไป คุณจะสํารวจว่าระดับการแยกและการควบคุมการทํางานพร้อมกันส่งผลต่อการสืบค้นที่ทํางานอยู่ภายในโครงสร้างพื้นฐานนี้อย่างไร