Subscribe to this blog
Briefcase
Print
If you're in the United States, chances are you've already heard about Daylight Saving Time (DST) occurring 3 weeks early this year. This is due to the Energy Policy Act of 2005, so it's not new news, but a lot of systems and applications are only now getting the updates. The Energy Policy Act of 2005 changes DST to start on the 2nd Sunday in March instead of the first Sunday in April. In addition, it now lasts one week longer, ending the first Sunday of November instead of the last Sunday in October. For this year that means DST starts on March 11.
For the most part SQL Server isn't affected. The only SQL Server component which is happens to be Notification Services. You can find information on how to update Notification Services here:
2007 time zone update for SQL Server 2005 Notification Services and for SQL Server 2000 Notification Services (931815)
Though most SQL Server components aren't affected, the operating system on which SQL Server is installed does need to be updated (with the exception of Vista). For Windows XP and 2003 there is a patch available. You can grab the update for these operating systems here:
February 2007 cumulative time zone update for Microsoft Windows operating systems (931836)
Windows 2000, since it has passed into Extended support, does not have a publically available update. As a result, these systems must be updated by making modification to the registry. More information can be found here:
How to configure daylight saving time for the United States in 2007 (914387)
Do note that if you have Outlook on the system (such as on a workstation), there are updates to Outlook which must follow almost immediately. Outlook isn't the only Microsoft based application to be affected. To find out more information on what Microsoft applications are impacted, see here:
Microsoft Daylight Saving Time Help and Support Center
Technorati Tags: Daylight Saving Time |
SQL Server |
Microsoft SQL Server |
SQL Server 2000 |
SQL Server 2005 |
Windows 2000 |
Windows 2003 |
Windows XP
K. Brian Kelley - Databases, Infrastructure, and Security
IT Security, MySQL, Perl, SQL Server, and Windows technologies.
Posted by Tim Mitchell on 19 February 2007
Posted by K. Brian Kelley on 20 February 2007
Posted by Sorry on 1 March 2007
Posted by K. Brian Kelley on 5 March 2007
Posted by Dave B on 8 March 2007
Posted by Terrence Nevins on 9 March 2007
Since so many enterprises depend on Agent for so many critical tasks -- like 'backup' ;>) -- you need to consider how the time change may impact your particular situation.
I looked far and wide for the single best resource (before I tried to create my own) and was happy to find that Brian Moran did a splendid job of documenting Ron Talmage's test results.
http://www.sqlmag.com/Article/ArticleID/44493/sql_server_44493.html
The article title is: SQL Server Agent Got an Extra Hour of Sleep, Too
There are a number of cases where this does/doesn't apply as there are timezones and settings it seems.
The take-away is this: If you are responsible for making sure Agent completes ALL the jobs in the given window of vulnerability, you need to be watchful. If anyone makes that claim that it'll just work, don't settle for that. Be paranoid within the parameters set, think about how you can reschedule jobs to run earlier -- or later -- to completely avoid the window and be watchful.
With just a little precaution this should be a total non-event for your enterprise and your Monday will be just like any other Monday.
Terrence Nevins
tnevins@microsoft.com
Posted by K. Brian Kelley on 12 March 2007
No, I have a lot of Windows 2000 systems, too. We pulled the registry settings from the KB article, rolled that into a patch and applied it via UpdateExpert (from St. Bernard, now owned by Shavlik). We also had to touch a handful of NT4 servers still around... basically the same registry hack, but the top line needed to be REGEDIT4 instead of the longer 5.00 line.
All in all, the OS pieces weren't that bad. It's the apps that have caused us pause. For instance, my mobile device is running on a slightly older mobile OS. The vendor didn't provide a DST-patched version of the application for handling email/contacts (it's not ActiveSync) so I've switched the application to think it's in Puerto Rico. Those are the kinds of issues that have given us pause.
Posted by K. Brian Kelley on 12 March 2007
thanks for those comments. They bring up a good point in that any jobs during a time-change window need to be checked. There are some reports of issues with Symantec's NetBackup and APC's Powerchute and appointments in those windows. There is speculation that the java dependency (which likely wasn't handled) may be the cause. In those cases, reboots and backups didn't happen when they were expected.