แก้ไขปัญหาคลังสินค้า
นําไปใช้กับ:✅ Warehouse ใน Microsoft Fabric
บทความนี้ให้คําแนะนําในการแก้ไขปัญหาทั่วไปในคลังสินค้าใน Microsoft Fabric
ข้อผิดพลาดในการเชื่อมต่อชั่วคราว
ข้อผิดพลาดชั่วคราว หรือที่เรียกว่าข้อบกพร่องชั่วคราว มีสาเหตุพื้นฐานที่ช่วยแก้ไขตัวเองในไม่ช้า ถ้าการเชื่อมต่อกับ Warehouse ที่ใช้ทํางานได้ดี แต่เริ่มทํางานไม่สําเร็จโดยไม่มีการเปลี่ยนแปลงสิทธิ์ของผู้ใช้ นโยบายไฟร์วอลล์ และการกําหนดค่าเครือข่าย ให้ลองขั้นตอนเหล่านี้ก่อนที่จะติดต่อฝ่ายสนับสนุน:
- ตรวจสอบสถานะของ Warehouse และตรวจสอบให้แน่ใจว่าไม่สามารถ หยุดชั่วคราวได้
- อย่าลองคําสั่งที่ล้มเหลวอีกในทันที ให้รอ 5 ถึง 10 นาที สร้างการเชื่อมต่อใหม่ แล้วลองคําสั่งใหม่อีกครั้ง ในบางครั้งระบบ Azure จะเปลี่ยนทรัพยากรฮาร์ดแวร์อย่างรวดเร็วเพื่อปรับสมดุลการโหลดของปริมาณงานต่าง ๆ ให้ดียิ่งขึ้น เหตุการณ์การกําหนดค่าใหม่เหล่านี้ส่วนใหญ่จะเสร็จสิ้นในเวลาไม่ถึง 60 วินาที ในระหว่างระยะเวลาการกําหนดค่าใหม่นี้ คุณอาจมีปัญหาเกี่ยวกับการเชื่อมต่อกับฐานข้อมูลของคุณ การเชื่อมต่ออาจล้มเหลวเมื่อมีการเริ่มบริการใหม่โดยอัตโนมัติเพื่อแก้ไขปัญหาบางอย่าง
- เชื่อมต่อโดยใช้แอปพลิเคชันอื่นและ/หรือจากเครื่องอื่น
ความล้มเหลวของคิวรีเนื่องจากปัญหาช่องว่าง tempdb
tempdbคือฐานข้อมูลระบบที่ใช้โดยกลไกจัดการสําหรับความต้องการจัดเก็บชั่วคราวต่าง ๆ ระหว่างการดําเนินการคิวรี ไม่สามารถเข้าถึงหรือกําหนดค่าโดยผู้ใช้ได้ แบบสอบถามอาจล้มเหลวเนื่องจากมี tempdb เนื้อที่ไม่เพียงพอ ทําตามขั้นตอนเหล่านี้เพื่อลด tempdb การใช้พื้นที่:
- ดูที่บทความเกี่ยวกับ สถิติ เพื่อตรวจสอบว่ามีการสร้างสถิติคอลัมน์ที่เหมาะสมในตารางทั้งหมดหรือไม่
- ตรวจสอบให้แน่ใจว่ามีการอัปเดตสถิติของตารางทั้งหมดหลังจากธุรกรรม DML ขนาดใหญ่
- คิวรีที่มี JOINs, GROUP BY ที่ซับซ้อน และ ORDER BY และคาดว่าจะส่งกลับชุดผลลัพธ์ขนาดใหญ่ ใช้พื้นที่ในการดําเนินการมากกว่า
tempdbอัปเดตคิวรีเพื่อลดจํานวนคอลัมน์ GROUP BY และ ORDER BY ถ้าเป็นไปได้ - เรียกใช้คิวรีอีกครั้งเมื่อไม่มีคิวรีที่ใช้งานอยู่อื่นๆ ที่กําลังทํางานอยู่เพื่อหลีกเลี่ยงข้อจํากัดทรัพยากรระหว่างการดําเนินการคิวรี
ประสิทธิภาพการทํางานของคิวรีดูเหมือนจะลดลงเมื่อเวลาผ่านไป
ปัจจัยหลายอย่างสามารถส่งผลกระทบต่อประสิทธิภาพการทํางานของคิวรี เช่น การเปลี่ยนแปลงในขนาดตาราง การเบ้ของข้อมูล ภาวะพร้อมกันของปริมาณงาน ทรัพยากรที่พร้อมใช้งาน เครือข่าย ฯลฯ เพียงเพราะคิวรีทํางานช้าลงไม่ได้หมายความว่ามีปัญหาด้านประสิทธิภาพการทํางานของคิวรี ทําตามขั้นตอนต่อไปนี้เพื่อตรวจสอบคิวรีเป้าหมาย:
- ระบุความแตกต่างในปัจจัยที่ส่งผลกระทบต่อประสิทธิภาพการทํางานทั้งหมดระหว่างการเรียกใช้ประสิทธิภาพที่ดีและไม่ดี
- ดูที่บทความเกี่ยวกับ สถิติ เพื่อตรวจสอบว่ามีการสร้างสถิติคอลัมน์ที่เหมาะสมในตารางทั้งหมดหรือไม่
- ตรวจสอบให้แน่ใจว่ามีการอัปเดตสถิติของตารางทั้งหมดหลังจากธุรกรรม DML ขนาดใหญ่
- ตรวจสอบการเบ้ข้อมูลในตารางพื้นฐาน
- หยุดบริการชั่วคราวและทํางานต่อ จากนั้น ให้เรียกใช้คิวรีใหม่เมื่อไม่มีคิวรีอื่นที่กําลังทํางานอยู่ คุณสามารถตรวจสอบปริมาณงานคลังสินค้าได้โดยใช้ DMV
คิวรีล้มเหลวหลังจากเรียกใช้เป็นเวลานาน ไม่มีข้อมูลที่ส่งกลับไปยังไคลเอ็นต์
คําสั่ง SELECT อาจดําเนินการเสร็จสมบูรณ์ใน Backend และล้มเหลวเมื่อพยายามส่งกลับผลลัพธ์คิวรีที่ตั้งค่าไปยังไคลเอ็นต์ ลองทําตามขั้นตอนต่อไปนี้เพื่อแยกปัญหา:
- ใช้เครื่องมือไคลเอ็นต์ที่แตกต่างกันเพื่อเรียกใช้คิวรีเดียวกันอีกครั้ง
- SQL Server Management Studio (SSMS)
- Azure Data Studio
- ตัว แก้ไข คิวรี SQL ในพอร์ทัล Microsoft Fabric
- ตัว แก้ไข คิวรีวิชวลในพอร์ทัล Microsoft Fabric
- โปรแกรมอรรถประโยชน์ SQLCMD (สําหรับการรับรองความถูกต้องผ่านทาง Microsoft Entra ID (ชื่อเดิมคือ Azure Active Directory) ที่เป็นสากลกับ MFA ใช้พารามิเตอร์
-G -U)
- ถ้าขั้นตอนที่ 1 ล้มเหลว ให้เรียกใช้คําสั่ง CTAS ด้วยคําสั่ง SELECT ที่ล้มเหลวเพื่อส่งผลลัพธ์คิวรี SELECT ไปยังตารางอื่นในคลังสินค้าเดียวกัน การใช้ CTAS จะหลีกเลี่ยงชุดผลลัพธ์ของคิวรีที่ถูกส่งกลับไปยังเครื่องไคลเอ็นต์ หากคําสั่ง CTAS เสร็จสิ้นและตารางเป้าหมายถูกเติมข้อมูลเรียบร้อยแล้ว ความล้มเหลวของคิวรีเดิมอาจเกิดจากปัญหาส่วนหน้าของคลังสินค้าหรือไคลเอ็นต์
สิ่งที่ต้องรวบรวมก่อนติดต่อฝ่ายสนับสนุนของ Microsoft
- ระบุ ID พื้นที่ทํางานของคลังสินค้า
- ระบุ ID คําสั่งและรหัสคําขอแบบกระจาย โดยข้อความเหล่านั้นจะถูกส่งกลับเป็นข้อความหลังจากคิวรีเสร็จสมบูรณ์หรือล้มเหลว
- ระบุข้อความของข้อความแสดงข้อผิดพลาดที่แน่นอน
- ระบุเวลาที่คิวรีเสร็จสมบูรณ์หรือล้มเหลว