งาน SQL ที่ใช้เวลานาน: ให้มันทำงานต่อเมื่อ VPN ขาด
VPN ที่ขาดไปทิ้งคำถามหนึ่งข้อที่ข้อผิดพลาดของไคลเอนต์ตอบไม่ได้: งานถูกคอมมิตแล้วหรือยัง? มอบงานยาวให้เจ้าของที่คงทนและกระทบยอดก่อนลองใหม่
VPN ขาดกลางทางการสร้างดัชนีใหม่ที่ยี่สิบนาที ไคลเอนต์ SQL ของคุณแสดงการเชื่อมต่อที่ขาด และคำถามที่ชัดเจนก็ไม่มีคำตอบในข้อผิดพลาดนั้น ข้อความสั่งนั้นจบลงแล้ว ย้อนกลับไปแล้ว หรือยังทำงานต่อไปโดยไม่มีคุณ การเชื่อมต่อใหม่แล้วส่งซ้ำเป็นตัวเลือกที่แย่ที่สุดในสามอย่าง เพราะมันเปลี่ยนผลลัพธ์ที่ไม่แน่นอนหนึ่งอย่างให้กลายเป็นสองอย่างที่เป็นไปได้ ย้ายงานไปยังสิ่งที่มีเจ้าของถาวรก่อนหน้าต่างถัดไป
สิ่งที่ข้อผิดพลาดการเชื่อมต่อไม่ได้บอกคุณ
ข้อผิดพลาดฝั่งไคลเอนต์อธิบายไคลเอนต์ มันรายงานว่าซ็อกเก็ตถูกปิด ไม่ใช่ว่าเซิร์ฟเวอร์ทำอะไรกับทรานแซกชัน ข้อความสั่งอาจยังทำงานอยู่ อาจถูกคอมมิตก่อนลิงก์จะขาดเพียงเสี้ยววินาที หรืออาจถูกย้อนกลับเมื่อเซสชันของมันถูกทำความสะอาด ทั้งสามกรณีให้ข้อความเดียวกันบนแล็ปท็อปของคุณ
มีเพียงสถานะของเซิร์ฟเวอร์เท่านั้นที่ตัดสินได้ ไปดูที่นั่นก่อนตัดสินใจอะไร
มอบงานให้เจ้าของฝั่งเซิร์ฟเวอร์
สำหรับงานที่ไม่ต้องมีคนเฝ้า ให้โฮสต์ฐานข้อมูลเป็นเจ้าของการเรียกใช้ SQL Server Agent รันงานตามคำขอหรือตามกำหนดการและบันทึกทุกครั้งที่รัน วงจรชีวิตของงานจึงเป็นอิสระจากเซสชัน VPN ของคุณ ตัวตนของงานต้องการสิทธิ์ที่งานนั้นกำหนดเท่านั้น ไม่ใช่บริบทแบบโต้ตอบเต็มรูปแบบของผู้ดูแลระบบ จากนั้นแล็ปท็อปก็เริ่มงานและอ่านผลลัพธ์ แทนที่จะเป็นโปรเซสที่คอยให้มันมีชีวิตอยู่
EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';ความพร้อมใช้งานของ Agent ขึ้นอยู่กับรุ่นและบริการที่คุณติดตั้งใช้งาน ใช้กลไกที่แพลตฟอร์มของคุณมีให้จริง แทนที่จะถือว่ากลไกนี้มีอยู่ทุกที่
จัมป์โฮสต์ใกล้ฐานข้อมูลช่วยย่นเส้นทางและควรมีไว้ แต่ไม่เปลี่ยนคำถามเรื่องความเป็นเจ้าของ เซสชันยังคงจบเมื่อเครือข่ายจบ ใช้มันเพื่อสังเกต ไม่ใช่เป็นสิ่งที่คอยให้งานมีชีวิตอยู่
ทิ้งบันทึกที่เซสชันถัดไปอ่านได้
บันทึกชื่องานหรือตัวระบุ ฐานข้อมูลเป้าหมาย และผลลัพธ์ที่คุณคาดหวัง บันทึกนั้นคือสิ่งที่ทำให้เซสชันอื่นหรือคนอื่นตอบคำถามที่ข้อผิดพลาดตอบไม่ได้ ถ้าไม่มีคุณก็เหลือเพียงความทรงจำเลือนรางเกี่ยวกับการอัปเดตและไม่มีทางตรวจสอบ
EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';ประวัติแสดงผลลัพธ์และเวลาของแต่ละขั้น ซึ่งมีประโยชน์กว่าธงความสำเร็จเพียงอันเดียว สำหรับงานที่เปลี่ยนข้อมูล ให้เพิ่มการตรวจสอบของแอปพลิเคชันเองด้วย: จำนวนแถว เช็กซัม หรือแถวสถานะที่งานเขียนขึ้น บันทึกอิสระสองรายการคือสิ่งที่ทำให้การลองใหม่ปลอดภัย และประวัติงานที่บันทึกไว้คือรายการแรกในนั้น
กระทบยอดก่อนส่งซ้ำ
เมื่อการเชื่อมต่อที่ใช้สังเกตหายไป ให้ค้นหาการรันที่มีอยู่ก่อนเริ่มการรันใหม่ อ่านผลของแต่ละขั้นแล้วตัดสินว่างานคอมมิตแล้ว เสร็จบางส่วน หรือไม่เคยเริ่ม จากนั้นจึงใช้กฎการลองใหม่ที่เวิร์กโฟลว์กำหนด เพราะการส่งซ้ำแบบไม่ดูอะไรอาจทำให้การโหลดซ้ำซ้อนหรือล้มเหลวกลางทางเป็นครั้งที่สอง
รักษาเจ้าของถาวรและผลลัพธ์ที่ตรวจสอบได้ไว้ แล้วความล้มเหลวในการเข้าถึงช่วงสั้นๆ ก็กลายเป็นความไม่สะดวกแทนการเดา นั่นคือเป้าหมายการออกแบบทั้งหมด: งานควรมีอายุยืนกว่าการเชื่อมต่อที่ขอให้มันทำ