hello
I ahve a small query regarding sql server. Is SQL Server 2000 affected by 2007 DST changes? Do we need to apply patches for not having any changes in the present sql server? What should i do for the DST changes?
hello
I ahve a small query regarding sql server. Is SQL Server 2000 affected by 2007 DST changes? Do we need to apply patches for not having any changes in the present sql server? What should i do for the DST changes?
SQL Server (2000 and 2005) retrieves the date/time from the OS. So if by affected you mean that 'if I apply the patch will SQL be patched automatically' the answer is yes. If you are running Windows 2000, you will ahve to apply this manually.
If you have SQL Server installed on a computer that is configured for automatic DST adjustments, and the time zone of the computer follows the changes to DST in 2007, you must take the following actions:Install the update for Windows that is described in Microsoft Knowledge Base article 924840. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
924840 A test version of the 2007 global time zone update for Windows is available
If you have SQL Server Notification Services installed on the computer, install the update that is described in Microsoft Knowledge Base article 931815. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
931815 2007 time zone update for SQL Server 2005 Notification Services and for SQL Server 2000 Notification Services
You do not have to apply any specific updates for SQL Server to make sure that SQL Server works correctly. However, you must update the operating system. Additionally, you must update the products and applications that interact with SQL Server. These products and applications may include Notification Services, Windows SharePoint Services, Microsoft CRM, and so on.
In SQL Server 2005 and in SQL Server 2000, the SQL Server database engine uses the following two forms of timer to generate time information: High-resolution timer
Low-resolution timer
High-resolution timer
Low-resolution timer
In the high-resolution timer, the timer resolution is based on the Read Time-Stamp Counter (RDTSC) instruction of the CPU. In the low-resolution timer, the timer resolution is based on the GetTickCount function in the Microsoft Windows API.
Various timer-based background tasks and critical system components rely on these timers for their correct functioning. Because these timers work as relative measures from a specific time, internal components and internal activities will not be affected by the changes to DST in 2007.
For example, you perform tasks that involve the following timer-based activities or timer-based componentsystem components such as lazy writer, lock monitor, and scheduler monitor
Background tasks such as ghost cleanup and auto-shrink
Time-out-based resources such as locks and latches
Scheduled activities such as SQL Server Agent jobs and maintenance plans
System statements such as the WAITFOR statement
System components such as lazy writer, lock monitor, and scheduler monitor
Background tasks such as ghost cleanup and auto-shrink
Time-out-based resources such as locks and latches
Scheduled activities such as SQL Server Agent jobs and maintenance plans
System statements such as the WAITFOR statement
SQL Server also generates time information that is made available to external components and applications. This time information is retrieved from the Windows operating system. Therefore, the time information is accurate as long as the operating system returns the correct time value.
For example, you perform tasks that involve the following external components and applicationsQL Server Profiler or SQL Profiler event columns such as the Start Time column, the End Time column, and the Duration column for various events
Time information that is reported in various logs such as the SQL Server Errorlog, event logs, and system tables
System functions such as the GetDate function and the GetUtcDate function
SQL Server Profiler or SQL Profiler event columns such as the Start Time column, the End Time column, and the Duration column for various events
Time information that is reported in various logs such as the SQL Server Errorlog, event logs, and system tables
System functions such as the GetDate function and the GetUtcDate function
Consider the following scenario. You create a SQL Server trace by using SQL Server Profiler or SQL Profiler. The trace records a query that starts before the March 2007 DST time change and finishes after the March 2007 DST time change. In this scenario, the time information is accurate and is not affected by the DST changes.
Effect of the DST end date on scheduled SQL Server Agent jobs:
Consider the following scenario. You have a scheduled SQL Server Agent job that prints current local time. The job runs every 15 minutes. When the DST change occurs in November 2007, SQL Server Agent automatically tracks the DST change. SQL Server Agent bases its tracking on the operating system and updates the next scheduled run of the job correctly.
However, there is a known issue in which scheduled SQL Server Agent jobs cannot run for one hour during the period when the November 2007 DST change occurs. After the clock is changed back from 2:00 A.M. to 1:00 A.M. on November 4, 2007, SQL Server Agent jobs would skip the next hour and wait until 2:00 A.M. to start next run. This is a known issue. This issue occurred even under the pre-2007 DST conventions. This issue does not result from the changes to DST in 2007.
Notice that in the sample output of the job, there is a one-hour-and-15-minute gap between the run of the job at 2007-11-04 01:45:00 and the run of the job at 2007-11-04 02:00:00. This behavior could affect the replication agent jobs, the backup jobs, log shipping jobs, and other scheduled jobs in SQL Server.
Bookmarks