Tiết kiệm thời gian ban ngày


9

Trong môi trường của tôi, có các máy chủ chạy trên bản sao lưu gốc và các kế hoạch Ola Hallengren. Các máy chủ của chúng tôi là sự kết hợp của năm 2008, 2012 và 2014. Tất cả các bản sao lưu đầy đủ được thực hiện vào lúc 12 giờ sáng và sao lưu nhật ký được thực hiện sau mỗi 15 phút.

Tôi chưa bao giờ tính đến Tiết kiệm thời gian ban ngày trước đây, vì vậy xin vui lòng cho tôi biết tôi nên điều chỉnh gì.

12h sao lưu toàn bộ sẽ bị ảnh hưởng và điều gì xảy ra với các bản sao lưu nhật ký?


6
Thành thật mà nói tôi sẽ chạy các máy chủ của tôi trong UTC.
Aaron Bertrand

Thật không may là chúng tôi là CST
SqlNovice

1
Chắc chắn, nhưng công bằng mà nói, đó không phải là mã hóa cứng trên bo mạch chủ.
Aaron Bertrand

Câu trả lời:


12

Chuyên gia SQL Server Paul Randal giải quyết chính chủ đề này trong Làm thế nào để tiết kiệm thời gian ban ngày ảnh hưởng đến việc khắc phục thảm họa? . Đây là một bài viết tương đối ngắn, vì vậy tôi trích dẫn nó toàn bộ. Vì bạn lo ngại về các bản sao lưu nhật ký giao dịch của mình, tôi cũng đánh dấu một chút bài đăng để thu hút sự chú ý của bạn.

Đó là kiến ​​thức phổ biến rằng SQL Server đối phó với thời gian tiết kiệm ánh sáng ban ngày (DST) một cách chính xác, vậy tại sao bạn nên quan tâm?

Chà, kiến ​​thức không phổ biến đến mức khi kết thúc DST khi đồng hồ quay trở lại một giờ (luôn luôn là 02:00 ở Mỹ), về cơ bản, SQL Agent tạm dừng trong một giờ (ít nhất là SS2000 trở đi). Điều này có nghĩa là nếu bạn có một công việc đang làm gì đó cứ sau 15 phút, sẽ có một khoảng cách 75 phút giữa thời gian thực hiện công việc lúc 01:45 và thực hiện công việc lúc 02:00. Điều này xảy ra bởi vì vào lúc 02:00, thời gian được đặt lại là 01:00 nhưng thời gian chạy tiếp theo của tất cả các công việc vẫn giữ nguyên - vì vậy công việc của bạn không thể thực hiện cho đến thời gian dự kiến ​​tiếp theo là 02:00. Vì vậy, ở bán cầu bắc vào mỗi mùa thu và ở bán cầu nam vào mỗi mùa xuân, bạn sẽ mất một giờ công việc của các tác nhân SQL. Tuy nhiên, tại sao bạn nên quan tâm?

Vâng, nó phụ thuộc vào những công việc bị trì hoãn một giờ. Nếu bạn có một công việc nhận sao lưu nhật ký cứ sau 15 phút thì vào ngày DST kết thúc, thực tế có khoảng cách 75 phút giữa các lần sao lưu nhật ký. Nếu bạn có Thỏa thuận cấp độ dịch vụ (SLA) giới hạn số lượng công việc bị mất tối đa là 15 phút trong trường hợp xảy ra thảm họa, thì trong 75 phút đó bạn sẽ không thể gặp SLA đó!

Đó có thể là một vấn đề khá lớn, đặc biệt là nếu có sự cố xảy ra trong giờ đó (không ít nhiều khả năng xảy ra sự cố bất cứ lúc nào, nhưng vẫn có thể xảy ra). Trong trường hợp đó, bạn cần đưa ra một giải pháp thay thế. Một vài cách để giải quyết vấn đề mà tôi có thể nghĩ ra:

  • Có ai đó thức khuya trong giờ đó và thực hiện sao lưu nhật ký thủ công.
  • Chuyển sang phản chiếu cơ sở dữ liệu, liên tục truyền nhật ký đến máy chủ dự phòng và do đó không ảnh hưởng đến vấn đề DST.

Cả hai đều là giải pháp khả thi nhưng tôi nghĩ cách tốt nhất là tạo một công việc SQL Agent chạy vào lúc 01:59 và tạo thêm các công việc sao lưu để chạy vào lúc 01:00, 01:15, 01:30 và 01:45. Tôi không thấy lý do tại sao điều này là không thể. Lúc 10:36 sáng nay tôi đã tạo một công việc đại lý đơn giản để in ngày vào một tệp và đặt nó để thực thi lúc 09:40 - trong quá khứ. Sau đó tôi đặt thời gian hệ thống của mình trở lại một giờ và công việc được thực hiện hoàn hảo. Nhược điểm duy nhất của giải pháp này là bạn cần tạo và lên lịch cho các công việc bổ sung bằng cách sử dụng SP T-SQL Agent được nhúng trong các bước công việc cho công việc 01:59 của bạn - tẻ nhạt nhưng không khó. Có lẽ ai đó có thể gửi cho tôi một kịch bản và tôi sẽ viết blog như một phần tiếp theo?

Vì vậy, với việc DST sắp kết thúc vào ngày 4 tháng 11, đây chắc chắn là điều bạn cần lưu ý ngay cả khi bạn không muốn gặp rắc rối khi đối phó với việc tiếp xúc thêm giờ. Như một bên - ngày khi DST bắt đầu và kết thúc thay đổi trong năm nay. Bài viết KB 931975 thảo luận về phần nào của SQL Server không biết về ngày thay đổi và những gì bạn có thể làm về nó.


Vì vậy, tôi có thể thấy mất dữ liệu tiềm năng trong 75 phút ... Nếu tôi ổn với điều đó thì tôi cần phải thay đổi bất kỳ cài đặt nào, tôi có thể để nguyên như vậy
SqlNovice

Nếu bạn ổn với khả năng mất 75 phút cho đến lần sao lưu nhật ký được lên lịch thường xuyên tiếp theo, thì tôi không nghĩ bạn cần thực hiện bất kỳ thay đổi nào.
Scott Hodgin

Hơn nữa, máy chủ mà tôi lo lắng là một nhóm luôn có sẵn, vì vậy tôi đoán nếu có gì sai tôi có thể chuyển đổi.
SqlNovice

@SqlNovice giả sử nhóm khả dụng của bạn nằm trên hai máy chủ không bị tác động bởi cùng một sự kiện và tất cả các sự kiện đã cam kết với (các) trường hợp khác = True. Bạn có thể được dùng nhiều hơn cho rằng đó là an toàn để giả định. Máy chủ PS không có trong Nhóm sẵn có, cơ sở dữ liệu. (tức là "" máy chủ mà tôi lo lắng luôn nằm trong nhóm khả dụng)
James Jenkins

Xin lỗi, tôi nhầm cơ sở dữ liệu trong nhóm khả dụng là một bản sao là chế độ đồng bộ và một cơ sở khác ở chế độ asyn
SqlNovice
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.