เหตุใด SET ARITHABORT ON จึงเร่งการสืบค้นอย่างรวดเร็ว

แบบสอบถามเป็นตัวเลือกเดียวที่มีระดับการจัดกลุ่มจำนวนมากและการดำเนินการ aggragate เมื่อ SET ARITHABORT ON ใช้เวลาน้อยกว่าหนึ่งวินาทีมิฉะนั้นจะใช้เวลาหลายนาที เราได้เห็นพฤติกรรมนี้ใน SQL Server 2000 และ 2008

เก่าไปหน่อย แต่สำหรับใครที่มาจบที่นี่ด้วยปัญหาที่คล้ายกัน ...

ฉันมีปัญหาเดียวกัน. สำหรับฉันมันกลายเป็นการดมกลิ่นพารามิเตอร์ซึ่งในตอนแรกฉันไม่เข้าใจเพียงพอที่จะสนใจ ฉันเพิ่ม 'set arithabort on' ซึ่งแก้ไขปัญหา แต่แล้วก็กลับมา จากนั้นฉันก็อ่าน:

http://www.sommarskog.se/query-plan-mysteries.html

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

แอปพลิเคชัน. NET เชื่อมต่อกับตัวเลือกที่ปิดใช้งานโดยค่าเริ่มต้น แต่จะเปิดใช้งานโดยค่าเริ่มต้นใน Management Studio ผลลัพธ์คือเซิร์ฟเวอร์เก็บแคชแผนการดำเนินการแยกต่างหาก 2 รายการสำหรับกระบวนการส่วนใหญ่ / ทั้งหมด สิ่งนี้มีผลต่อวิธีที่เซิร์ฟเวอร์ทำการคำนวณเชิงตัวเลขและเช่นนั้นคุณจะได้ผลลัพธ์ที่แตกต่างกันขึ้นอยู่กับกระบวนการ นี่เป็นเพียงหนึ่งในวิธีการทั่วไป 2 วิธีที่ proc สามารถรับแผนการดำเนินการที่แย่มากอีกวิธีหนึ่งคือการดมพารามิเตอร์

ลองดูที่https://web.archive.org/web/20150315031719/http://sqladvice.com/blogs/gstark/archive/2008/02/12/Arithabort-Option-Stored-Procedure-Performance aspxสำหรับการสนทนาเพิ่มเติมเล็กน้อยเกี่ยวกับมัน

ฉันจะยืนยันว่านี่เป็นพารามิเตอร์ในการดมกลิ่น

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

ในกรณีนี้ (สำหรับ SQL2005 + และถ้าฐานข้อมูลของคุณอยู่ในโหมดความเข้ากันได้ของ SQL2000 ) หากคุณมีทั้งARITHABORTและANSI_WARNINGS OFFแล้วคุณจะพบดัชนีไม่ได้ถูกนำมาใช้เพื่อให้อาจมีการสแกนมากกว่าที่ต้องการแสวงหา (และค่าใช้จ่ายบางส่วนเป็นผลการคำนวณงานอยู่ไม่สามารถใช้) ADO.NET ดูเหมือนว่าจะเป็นค่าเริ่มต้นANSI_WARNINGS ONจากการทดสอบอย่างรวดเร็วที่ฉันทำ

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

การทดสอบอย่างรวดเร็วในหน้าต่างสตูดิโอการจัดการแสดงให้เห็นว่าเมื่อSET ARITHABORT OFFเปิดใช้งานและมีการเรียกใช้คิวรีที่ปัญหาประสิทธิภาพการทำงานเกิดขึ้นอีกครั้งเพื่อให้เห็นได้ชัดว่าเป็นกรณีปิด แน่นอนว่านี่เป็นวิธีการแก้ไขปัญหาที่ใช้ในลิงก์Gregg Stark

แต่ที่ไม่สนใจความจริงที่ว่ามีตัวเลือกที่ตั้งที่คุณสามารถจบลงด้วยการที่แน่นอนแผนไม่ดีเหมือนกันจากแคช

การใช้แผนนี้ซ้ำอาจเกิดขึ้นได้แม้ว่าคุณจะลงชื่อเข้าใช้ในฐานะผู้ใช้อื่นที่ไม่ใช่การเชื่อมต่อแอปพลิเคชันที่ใช้

ฉันทดสอบสิ่งนี้โดยการเรียกSET ARITHABORT OFFใช้คิวรีทดสอบก่อนจากเว็บแอปพลิเคชันจากสตูดิโอการจัดการด้วยและสามารถเห็นจำนวนผู้ใช้เพิ่มขึ้นจากแบบสอบถามด้านล่าง

SELECT usecounts, cacheobjtype, objtype, text ,query_plan
FROM sys.dm_exec_cached_plans 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) 
CROSS APPLY sys.dm_exec_query_plan(plan_handle) 

เพื่อให้แผน pf ที่แชร์นี้เกิดขึ้นจริงคีย์แคชแผนจะต้องเหมือนกัน เช่นเดียวกับarithabortตัวเองบางตัวอย่างอื่น ๆ คือผู้ใช้ที่ดำเนินการต้องการ schema เริ่มต้นเดียวกัน (ถ้าแบบสอบถามอาศัยการจำแนกชื่อโดยปริยาย) และการเชื่อมต่อจำเป็นต้องมีlanguageชุดเดียวกัน

รายการคีย์แคชของแผนที่นี่

ฉันรู้ว่าฉันมางานปาร์ตี้ช้า แต่สำหรับผู้เยี่ยมชมในอนาคตมาร์ตินนั้นถูกต้องแน่นอน เราพบปัญหาเดียวกันนี้ - SP กำลังทำงานช้ามากสำหรับไคลเอนต์. NET ในขณะที่มันรวดเร็วสำหรับ SSMS ในการสำรวจและแก้ไขปัญหาเราทำการทดสอบอย่างเป็นระบบที่ Kenny Evitt ถามในข้อคิดเห็นของเขากับคำถามของ Martin

ด้วยการใช้คิวรี่ของมาร์ตินฉันค้นหา SP ในโพรซีเดอร์แคชและพบสองรายการ ในความเป็นจริงกรณีที่มี ARITHABORT ON และมี ARITHABORT OFF เวอร์ชัน ARITHABORT OFF มีการค้นหาดัชนีในขณะที่รุ่น ARITHABORT ON ใช้การสแกนดัชนีสำหรับผลลัพธ์เดียวกัน เมื่อพิจารณาถึงพารามิเตอร์ที่เกี่ยวข้องการค้นหาดัชนีจะต้องค้นหาระเบียนหลายสิบล้านรายการสำหรับผลลัพธ์

ฉันล้างสองขั้นตอนจากแคชและให้ไคลเอนต์. NET เรียกใช้ SP อีกครั้งโดยใช้พารามิเตอร์เดียวกัน (ซึ่งให้ช่วงวันที่กว้างสำหรับลูกค้าที่มีกิจกรรมมากมาย) SP ส่งคืนทันที แผนแคชใช้การสแกนดัชนีแบบเดียวกันกับที่เคยให้ความสำคัญในแผน ARITHABORT ON แต่คราวนี้แผนนี้ใช้สำหรับ ARITHABORT OFF เรารัน SP ด้วยพารามิเตอร์เดียวกันใน SSMS และได้ผลลัพธ์อีกครั้งทันที ตอนนี้เราเห็นว่าแผนสองถูกแคชสำหรับ ARITHABORT ON พร้อมการสแกนดัชนี

จากนั้นเราล้างแคชเรียกใช้ SP ใน SSMS ด้วยช่วงวันที่แคบ ๆ และได้รับผลทันที เราพบว่าแผนแคชผลลัพธ์ที่ได้มีการค้นหาดัชนีสำหรับผลลัพธ์เดียวกันนั้นถูกจัดการก่อนหน้านี้ด้วยการสแกน (ซึ่งเป็นการค้นหาในแผนเดิมด้วย ARITHABORT OFF) อีกครั้งจาก SSMS เราใช้ SP ในครั้งนี้ด้วยช่วงวันที่กว้างเดียวกันและเห็นประสิทธิภาพแย่มากเหมือนที่เรามีในการร้องขอ. NET ดั้งเดิม

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

ในขณะที่MSDNระบุว่า ARITHABORT OFF นั้นสามารถมีผลกระทบด้านลบต่อการปรับให้เหมาะสมของแบบสอบถาม แต่การทดสอบของเรายืนยันว่ามาร์ตินนั้นถูกต้อง - สาเหตุคือพารามิเตอร์การดมกลิ่นและแผนผลลัพธ์ไม่เหมาะสมสำหรับพารามิเตอร์ทุกช่วง

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

สิ่งนี้ทำให้ฉันนึกถึงปัญหาเดียวกันกับที่ฉันพบใน sql server 2008 วัน ในกรณีของเราเราพบงานหนึ่ง sql ก็ช้าลง (ปกติไม่กี่วินาทีและตอนนี้ 9+ นาที) งานจำเป็นต้องเข้าถึงเซิร์ฟเวอร์ที่เชื่อมโยงเราเพิ่มชุด ARITHABORT ในขั้นตอนของงานและดูเหมือนว่าปัญหา ได้รับการแก้ไขสองสามวันแล้วกลับมา

ต่อมาเราเปิดตั๋วด้วยการสนับสนุน MS และในขั้นต้นพวกเขาไม่สามารถค้นพบได้เช่นกันและตั๋วดังกล่าวก็ถูกส่งต่อไปยังทีม PFE ที่มีอาวุโสมาก

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

รายละเอียดผู้ใช้ไม่ได้รับอนุญาตในDBCC SHOW_STATISTICS (แม้ว่าผู้ใช้สามารถเลือกจากตาราง) ตามMSDNกฎการอนุญาตนี้มีการเปลี่ยนแปลงหลัง sql 2012 SP1

สิทธิ์สำหรับ SQL Server และฐานข้อมูล SQL

เพื่อที่จะดูวัตถุสถิติผู้ใช้จะต้องเป็นเจ้าของตารางหรือผู้ใช้จะต้องเป็นสมาชิกของบทบาทเซิร์ฟเวอร์ถาวร sysadmin, บทบาทฐานข้อมูลถาวร db_owner หรือบทบาทฐานข้อมูลคงที่ db_ddladmin

SQL Server 2012 SP1 แก้ไขข้อ จำกัด การอนุญาตและอนุญาตให้ผู้ใช้ที่มีสิทธิ์ SELECT ใช้คำสั่งนี้ โปรดทราบว่ามีข้อกำหนดต่อไปนี้สำหรับการอนุญาตให้ใช้สิทธิ์ SELECT ให้เพียงพอต่อการรันคำสั่ง:

ในการตรวจสอบปัญหานี้เราเพียงแค่เรียกใช้ตัวสร้างโปรไฟล์บนอินสแตนซ์ฝั่งเซิร์ฟเวอร์ที่เชื่อมโยงและเปิดบางเหตุการณ์ในส่วน "ข้อผิดพลาดและคำเตือน" ดังที่แสดงด้านล่าง

หวังว่าประสบการณ์นี้อาจช่วยชุมชนได้บ้าง