일광 절약 시간


9

내 환경에는 기본 백업 및 Ola Hallengren 계획에서 실행되는 서버가 있습니다. 당사의 서버는 2008, 2012 및 2014의 조합입니다. 모든 전체 백업은 오전 12시에 수행되고 로그 백업은 15 분마다 수행됩니다.

이전에 일광 절약 시간을 고려한 적이 없으므로 어떤 조정을해야하는지 알려주십시오.

12am 전체 백업이 영향을 받고 로그 백업은 어떻게됩니까?


6
솔직히 UTC로 서버를 운영 할 것입니다.
Aaron Bertrand

우리는 불행히도 CST입니다
SqlNovice

1
물론 이것은 공정하지만 마더 보드에는 하드 코딩되어 있지 않습니다.
Aaron Bertrand

답변:


12

SQL Server 전문가 Paul Randal 은 일광 절약 시간이 재해 복구에 어떤 영향을 줍니까? 에서 바로이 주제를 다룹니다 . . 상대적으로 짧은 게시물이므로 전체적으로 인용하고 있습니다. 트랜잭션 로그 백업에 대해 걱정했기 때문에 관심을 끌기 위해 게시물을 약간 높였습니다.

SQL Server가 일광 절약 시간 (DST)을 올바르게 처리한다는 것은 일반적인 지식이므로 왜 신경 써야합니까?

글쎄, DST가 끝날 때 시계가 한 시간 뒤로 이동하면 (미국에서는 항상 02:00) SQL 에이전트가 기본적으로 한 시간 동안 (SS2000 이상) 일시 중지한다는 것은 일반적인 지식이 아닙니다. 즉, 15 분마다 작업을 수행하는 작업이있는 경우 01:45의 작업 실행과 02:00의 작업 실행 사이에 75 분의 간격이 있습니다. 이는 02:00에 시간이 다시 01:00으로 설정되었지만 모든 작업의 ​​다음 실행 시간은 동일하게 유지되므로 다음 예약 시간 02:00까지 작업을 실행할 수 없습니다. 따라서 가을마다 북반구에서, 봄마다 남반구에서 1 시간 분량의 SQL 에이전트 작업이 손실됩니다. 그래도 왜 걱정해야합니까?

글쎄, 그것은 한 시간 지연되는 작업이 무엇인지에 달려 있습니다. 15 분마다 로그 백업을 수행하는 작업이있는 경우 DST가 종료 되는 날 에는 실제로 로그 백업간에 75 분의 간격이 있습니다. 당신이 경우 한도의 최대 크기하는 서비스 수준 계약 (SLA)가 재해 발생시 15 분 손실 된 작업을하는 경우, 그 75 분은 잠재적으로 충족 SLA 할 수없는 노출있어!

특히 그 시간 동안 무언가가 잘못되면 (다른 시간에 잘못 될 가능성이 있지만 여전히 가능할 때) 상당히 큰 문제가 될 수 있습니다. 이 경우 대체 솔루션을 마련해야합니다. 내가 생각할 수있는 문제를 해결할 수있는 몇 가지 방법 :

  • 그 시간 동안 누군가 늦게 일어나 수동 로그 백업을 수행하도록하십시오.
  • 데이터베이스 미러링으로 전환합니다.이 미러링은 지속적으로 로그를 중복 서버로 스트리밍하므로 DST 문제에 영향을 미치지 않습니다.

둘 다 가능한 솔루션이지만 01:59에서 실행되는 SQL 에이전트 작업을 작성하고 01:00, 01:15, 01:30 및 01:45에서 실행할 추가 백업 작업을 작성하는 것이 가장 좋습니다. 왜 이것이 불가능해서는 안되는지 모르겠습니다. 오늘 아침 10시 36 분에 날짜를 파일로 인쇄하고 09시 40 분에 실행하도록 간단한 에이전트 작업을 만들었습니다. 그런 다음 시스템 시간을 한 시간 뒤로 설정하고 작업이 완벽하게 실행되었습니다. 이 솔루션의 유일한 단점은 01:59 작업의 작업 단계에 포함 된 T-SQL 에이전트 SP를 사용하여 추가 작업을 작성하고 예약해야한다는 것입니다. 누군가가 나에게 스크립트를 보낼 수 있고 후속 블로그로 블로그에 올릴 것인가?

따라서 DST가 11 월 4 일에 끝날 때까지는 추가 시간 노출에 대처하는 데 어려움을 겪고 싶지 않더라도 분명히 알아야 할 사항입니다. 제쳐두고 – 올해 DST가 시작되고 끝나는 날짜가 변경되었습니다. 기술 자료 문서 931975에서는 변경된 날짜를 알 수없는 SQL Server 부분과 수행 할 수있는 작업에 대해 설명합니다.


75 분 동안 데이터가 손실 될 가능성이 있습니다 ... 그런데 설정을 변경해야합니까
SqlNovice

정기적으로 예약 된 다음 로그 백업까지 75 분이 손실 될 가능성이 있다고 생각되면 변경할 필요가 없다고 생각합니다.
Scott Hodgin 2013 년

또한 내가 걱정하는 서버는 항상 가용성 그룹에 있으므로 문제가 발생하면 전환 할 수 있습니다.
SqlNovice

@SqlNovice는 가용성 그룹이 동일한 이벤트의 영향을받지 않는 두 서버에 있고 모든 이벤트가 다른 인스턴스 (들) = True에 커밋되었다고 가정합니다. 추측하기에 안전한 것은 당연한 것으로 여겨 질 수 있습니다. PS 서버가 가용성 그룹에없고 데이터베이스가 있습니다. (예 : ""걱정되는 서버는 항상 사용 가능한 그룹입니다.)
James Jenkins

유감스럽게도 가용성 그룹의 데이터베이스는 하나의 복제본은 syn 모드이고 다른 하나는 asyn 모드입니다.
SqlNovice
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.