เวลาออมแสง


9

ในสภาพแวดล้อมของฉันมีเซิร์ฟเวอร์ที่ทำงานบนการสำรองข้อมูลดั้งเดิมและแผน Ola Hallengren เซิร์ฟเวอร์ของเรามีการรวมกันของปี 2008, 2012 และ 2014 การสำรองข้อมูลเต็มรูปแบบทั้งหมดจะดำเนินการเวลา 12.00 น. และมีการสำรองข้อมูลบันทึกทุก 15 นาที

ฉันไม่เคยคิดที่จะปรับเวลาตามฤดูกาลมาก่อนดังนั้นโปรดบอกฉันว่าควรปรับอะไรบ้าง

การสำรองข้อมูลเต็มรูปแบบ 12am จะได้รับผลกระทบหรือไม่และจะเกิดอะไรขึ้นกับการสำรองข้อมูลบันทึก


6
ค่อนข้างตรงไปตรงมาฉันจะใช้เซิร์ฟเวอร์ของฉันใน UTC
Aaron Bertrand

น่าเสียดายที่ CST ของเรา
SqlNovice

1
แน่นอน แต่เพื่อความเป็นธรรมนั่นไม่ใช่การเขียนโค้ดลงบนเมนบอร์ด
Aaron Bertrand

คำตอบ:


12

พอลแรนดัลผู้เชี่ยวชาญ SQL Server กล่าวถึงหัวข้อนี้มากในการปรับเวลาตามฤดูกาลให้มีผลต่อการกู้คืนจากความเสียหายอย่างไร . มันเป็นโพสต์ที่ค่อนข้างสั้นดังนั้นฉันจึงอ้างถึงทั้งหมด เนื่องจากคุณมีความกังวลเกี่ยวกับการสำรองข้อมูลบันทึกธุรกรรมของฉันฉันจึงได้ทำการโพสต์เล็กน้อยเพื่อดึงความสนใจของคุณ

เป็นความรู้ทั่วไปที่ SQL Server copes กับ daylight saving time (DST) อย่างถูกต้องดังนั้นทำไมคุณควรดูแล?

ไม่ใช่ความรู้ทั่วไปที่ในตอนท้ายของ DST เมื่อนาฬิกาย้อนกลับไปหนึ่งชั่วโมง (เสมอที่ 02:00 ในสหรัฐอเมริกา), เอเจนต์ของ SQL จะหยุดทำงานชั่วคราวเป็นเวลาหนึ่งชั่วโมง (อย่างน้อย SS2000 เป็นต้นไป) ซึ่งหมายความว่าหากคุณมีงานที่ทำอะไรทุก ๆ 15 นาทีจะมีช่องว่าง 75 นาทีระหว่างการดำเนินงานเวลา 01:45 น. และการดำเนินงานเวลา 02:00 น สิ่งนี้เกิดขึ้นเพราะเวลา 02:00 นเวลาจะถูกตั้งค่ากลับเป็น 01:00 แต่เวลาทำงานต่อไปของงานทั้งหมดจะยังคงเหมือนเดิมดังนั้นงานของคุณจะไม่สามารถดำเนินการได้จนกว่าจะถึงเวลา 02:00 ดังนั้นในซีกโลกเหนือทุกฤดูใบไม้ร่วงและในซีกโลกใต้ในทุกฤดูใบไม้ผลิคุณจะสูญเสียงาน SQL Agent มูลค่าหนึ่งชั่วโมง ยังทำไมคุณควรดูแล

มันขึ้นอยู่กับงานที่ล่าช้าไปหนึ่งชั่วโมง หากคุณ มีงานที่ต้องทำการสำรองข้อมูลบันทึกทุก ๆ 15 นาทีจากนั้นในวันที่ DST สิ้นสุดลงจริง ๆ แล้วจะมีช่องว่าง 75 นาทีระหว่างการสำรองข้อมูลบันทึก หากคุณ มีข้อตกลงระดับการให้บริการ (SLA) ที่ จำกัด จำนวน งานที่สูญเสีย สูงสุดถึง 15 นาทีในกรณีที่เกิดภัยพิบัติจากนั้นเป็นเวลา75 นาทีที่คุณพบว่าอาจไม่สามารถปฏิบัติตาม SLA นั้นได้!

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

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

ทั้งสองนี้เป็นโซลูชันที่ทำงานได้ แต่ฉันคิดว่าสิ่งที่ดีที่สุดคือการสร้างงาน SQL Agent ที่ทำงานในเวลา 01:59 น. และสร้างงานสำรองเพิ่มเติมเพื่อให้ทำงานที่ 01:00, 01:15, 01:30 และ 01:45 ฉันไม่เห็นสาเหตุที่เป็นไปไม่ได้ เมื่อ 10:36 เช้านี้ฉันได้สร้างงานตัวแทนง่าย ๆ เพื่อพิมพ์วันที่ไปยังไฟล์และตั้งให้ทำงานที่ 09:40 - ในอดีต จากนั้นฉันตั้งเวลาให้ระบบของฉันย้อนกลับไปหนึ่งชั่วโมงและทำงานได้อย่างสมบูรณ์แบบ ข้อเสียเพียงข้อเดียวของโซลูชันนี้คือคุณต้องสร้างและกำหนดเวลางานพิเศษโดยใช้ T-SQL Agent SPs ที่ฝังอยู่ในขั้นตอนงานสำหรับงาน 01:59 ของคุณ - น่าเบื่อ แต่ไม่ยาก อาจมีใครบางคนสามารถส่งสคริปต์มาให้ฉันและฉันจะบล็อกมันเป็นแบบติดตาม

ดังนั้นด้วย DST ที่จะมาถึงจุดจบในวันที่ 4 พฤศจิกายนนี่เป็นสิ่งที่คุณต้องระวังแม้ว่าคุณไม่ต้องการที่จะเผชิญกับปัญหาในการรับมือกับการได้รับชมชั่วโมงพิเศษ ในฐานะที่เป็นกัน - วันที่ DST เริ่มต้นและสิ้นสุดการเปลี่ยนแปลงในปีนี้ บทความ KB 931975 กล่าวถึงส่วนของ SQL Server ที่ไม่ทราบวันที่เปลี่ยนแปลงและสิ่งที่คุณสามารถทำได้


ดังนั้นฉันจะได้เห็นการสูญเสียข้อมูลที่อาจเกิดขึ้นเป็นเวลา 75 นาที ... ถ้าฉันตกลงกับสิ่งนั้นฉันต้องเปลี่ยนการตั้งค่าใด ๆ หรือฉันจะปล่อยให้มันเป็น
SqlNovice

หากคุณตกลงกับโอกาสที่จะเสียเวลา 75 นาทีจนกว่าจะมีการสำรองข้อมูลบันทึกตามกำหนดครั้งต่อไปฉันไม่คิดว่าคุณจะต้องทำการเปลี่ยนแปลงใด ๆ
Scott Hodgin

ยิ่งกว่านั้นเซิร์ฟเวอร์ที่ฉันกังวลเป็นกลุ่มที่ว่างเสมอดังนั้นฉันเดาว่ามีอะไรผิดปกติฉันสามารถสลับ
SqlNovice

@SqlNovice สมมติว่ากลุ่มความพร้อมใช้งานของคุณอยู่บนเซิร์ฟเวอร์สองเครื่องที่ไม่ได้รับผลกระทบจากเหตุการณ์เดียวกันและกิจกรรมทั้งหมดมีความมุ่งมั่นต่ออินสแตนซ์อื่น = True คุณอาจใช้เวลามากขึ้นสำหรับการได้รับที่ปลอดภัยที่จะคิด เซิร์ฟเวอร์ PS ไม่ได้อยู่ในกลุ่มความพร้อมใช้งานฐานข้อมูลคือ (เช่น "" เซิร์ฟเวอร์ที่ฉันกังวลเป็นกลุ่มที่ว่างเสมอ)
James Jenkins

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