等待延迟 [英] WAITFOR DELAY

问题描述

系统：具有3 GB RAM，2.4 GHz Celeron的Dell PowerEdge服务器

软件：在Windows 2003上运行的Microsoft SQL Server 2000 Enterprise

服务器

软件：在Windows 2000上运行的Microsoft SQL Server 2000 Enterprise

服务器


如果你运行下面的代码，你会发现一些奇怪的事情。在1Millisecond延迟后，

MilliSecond值不会改变。这是一个错误

或我做错了什么？

任何帮助都将不胜感激

--------- -------------------------------------------------- -----------------

-------

/ *

程序员：Des L. Davis

日期：2004年7月4日

目的：测试延迟反应

* /

CREATE PROCEDURE [sp_TestDelay] AS


DECLARE @DELAYPERIOD NCHAR（12）

SET @DELAYPERIOD =''00：00：00： 001''

DECLARE @Retries INT

SET @Retries = 0

DECLARE @MAXTRIES INT

SET @ MAXTRIES = 1000 - 超时前的最大尝试次数

DECLARE @Modified DATETIME


WHILE（（@ Retries< = @MAXTRIES））BEGIN


SET @Modified = GetDate（） - 设置修改日期


PRINT @Retries

PRINT @Modified

PRINT''年=''+ CONVERT（NCHAR（4），DATEPART（年份，@模式） if）））

PRINT''DayOfYear =''+ CONVERT（NCHAR（3），DATEPART（DAYOFYEAR，

@Modified））

打印''小时=''+ CONVERT（NCHAR（2），DATEPART（小时，@修改））

PRINT''Minute =''+ CONVERT（NCHAR（2），DATEPART（MINUTE， @Modified））

打印''秒=''+ CONVERT（NCHAR（2），DATEPART（第二，@修改））

打印''MilliSecond ='' + CONVERT（NCHAR（3），DATEPART（MILLISECOND，

@Modified））


SET @Retries = @Retries + 1 - 递增循环计数器和重试


等待延迟@DELAYPERIOD


结束

GO


------------------------------------------------- ---------------------------

-------

解决方案

SQL Server datetime数据类型，因此WAITFOR DELAY，仅为
，精确到3.33毫秒，可能会出现舍入。您可以通过以下内容查看

发生的事情


DECLARE @DELAYPERIOD datetime

SET @DELAYPERIOD =''00：00 ：00：001''

SELECT @DELAYPERIOD


这在SQL Server 2000联机丛书中有记录：


< Excerpt href =" tsqlref.chm :: / ts_da-db_9xut.htm">


从1753年1月1日到9999年12月31日的日期和时间数据，

精度为三百分之一秒（相当于3.33毫秒

或0.00333秒）。值将四舍五入为.000，.003或.007

秒的增量，如表中所示。


示例圆角示例

01/01/98 23：59：59.999 1998-01-02 00：00：00.000


01/01/98 23：59：59.995,1998-01 -01 23：59：59.997

01/01/98 23：59：59.996，

01/01/98 23：59：59.997，或

01/01/98 23:59:59.998

01/01/98 23：59：59.992,1998-01-01 23：59：59.993
01/01/98 23：59：59.993，

01/01/98 23：59：59.994


01/01 / 98 23：59：59.990或1998-01-01 23：59：59.990

01/01/98 23：59：59.991


< /摘录>


-

希望这会有所帮助。


Dan Guzman

SQL Server MVP


" Des L. Davis" <德******* @ cogeco.ca>在消息中写道

新闻：yq ​​******************** @ read2.cgocable.net ...

系统：具有3 GB RAM，2.4 GHz Celeron的Dell PowerEdge服务器软件：在Windows 2003上运行的Microsoft SQL Server 2000 Enterprise服务器
软件：在Windows 2000上运行的Microsoft SQL Server 2000 Enterprise
服务器

如果你运行下面的代码，你会发现一些奇怪的事情。在1Millisecond延迟后，MilliSecond值不会改变。这是一个
的错误还是我做错了什么？
任何帮助都将不胜感激
--------------------- -------------------------------------------------- ---
- -------
/ *
程序员：Des L. Davis
日期：2004年7月4日
目的：测试延迟反应
* /

创建程序[sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR（12）
SET @DELAYPERIOD =''00：00： 00：001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 - 超时之前的最大尝试次数
DECLARE @Modified DATETIME

WHILE（（@ Retries< = @MAXTRIES））BEGIN

SET @Modified = GetDate（） - 设置修改日期

PRINT @Retries
打印@Modified
打印''年=''+ CONVERT（NCHAR（4），DATEPART（年份，@修改））
PRINT''DayOfYear =''+ CONVERT（NCHAR（3），DATEPART（DAYOFYEAR，
@Modified））
打印''小时=''+ CONVERT（NCHAR（2），DATEPART（小时，@修改））
PRINT''Minute =''+ CONVERT（NCHAR（2）， DATEPART（MINUTE，
@Modified））打印''秒=''+ CONVERT（NCHAR（2），DATEPART（第二，@修改））
打印''MilliSecond =''+ CONVERT（NCHAR） （3），DATEPART（MILLISECOND，
@Modified））

SET @Retries = @Retries + 1 - 递增循环计数器并重试

WAITFOR DELAY @ DELAYPERIOD

结束
GO

--------------------------- -----------------------------------------------
- -------

在运行一些测试后我也注意到WAITFOR似乎有一个

分辨率为1/100秒。


指定延迟''00：00：00：003'会导致同样的延迟，就像我

指定1/100秒。


WAITFOR DELAY''00：00：00：013 '导致延迟2/100秒（：020或.02），所以

显然总是四舍五入。


行为似乎更容易跟随减去输出。

改变程序[sp_TestDelay] AS

DECLARE @DELAYPERIOD DATETIME

SET @DELAYPERIOD =''00：00：00：013 ''

DECLARE @Retries INT

SET @Retries = 0

WHILE（@Retries< = 1000）BEGIN

PRINT DATEPART（MILLISECOND，getdate（））

SET @Retries = @Retries + 1 - 递增循环计数器并重试

WAITFOR DELAY @DELAYPERIOD
结束

GO


exec sp_testdelay


577

597

617

637

657

....等

Dan Guzman <哒******* @ nospam-earthlink.net>在消息中写道

新闻：rS ***************** @ newsread2.news.pas.earthl ink.net ...

SQL Server datetime数据类型，因此WAITFOR DELAY，仅为
，精确到3.33毫秒，可能会出现舍入。您可以通过以下内容查看

发生的事情


DECLARE @DELAYPERIOD datetime

SET @DELAYPERIOD =''00：00 ：00：001''

SELECT @DELAYPERIOD


这在SQL Server 2000联机丛书中有记录：


< Excerpt href =" tsqlref.chm :: / ts_da-db_9xut.htm">


从1753年1月1日到9999年12月31日的日期和时间数据，

精度为三百分之一秒（相当于3.33毫秒

或0.00333秒）。值将四舍五入为.000，.003或.007

秒的增量，如表中所示。


示例圆角示例

01/01/98 23：59：59.999 1998-01-02 00：00：00.000


01/01/98 23：59：59.995,1998-01 -01 23：59：59.997

01/01/98 23：59：59.996，

01/01/98 23：59：59.997，或

01/01/98 23:59:59.998

01/01/98 23：59：59.992,1998-01-01 23：59：59.993
01/01/98 23：59：59.993，

01/01/98 23：59：59.994


01/01 / 98 23：59：59.990或1998-01-01 23：59：59.990

01/01/98 23：59：59.991


< /摘录>


-

希望这会有所帮助。


Dan Guzman

SQL Server MVP


" Des L. Davis" <德******* @ cogeco.ca>在消息中写道

新闻：yq ​​******************** @ read2.cgocable.net ...

系统：具有3 GB RAM，2.4 GHz Celeron的Dell PowerEdge服务器软件：在Windows 2003上运行的Microsoft SQL Server 2000 Enterprise服务器
软件：在Windows 2000上运行的Microsoft SQL Server 2000 Enterprise
服务器

如果你运行下面的代码，你会发现一些奇怪的事情。在1Millisecond延迟后，MilliSecond值不会改变。这是一个
的错误还是我做错了什么？
任何帮助都将不胜感激
--------------------- -------------------------------------------------- ---
- -------
/ *
程序员：Des L. Davis
日期：2004年7月4日
目的：测试延迟反应
* /

创建程序[sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR（12）
SET @DELAYPERIOD =''00：00： 00：001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 - 超时之前的最大尝试次数
DECLARE @Modified DATETIME

WHILE（（@ Retries< = @MAXTRIES））BEGIN

SET @Modified = GetDate（） - 设置修改日期

PRINT @Retries
打印@Modified
打印''年=''+ CONVERT（NCHAR（4），DATEPART（年份，@修改））
PRINT''DayOfYear =''+ CONVERT（NCHAR（3），DATEPART（DAYOFYEAR，
@Modified））
打印''小时=''+ CONVERT（NCHAR（2），DATEPART（小时，@修改））
PRINT''Minute =''+ CONVERT（NCHAR（2）， DATEPART（MINUTE，
@Modified））打印''秒=''+ CONVERT（NCHAR（2），DATEPART（第二，@修改））
打印''MilliSecond =''+ CONVERT（NCHAR） （3），DATEPART（MILLISECOND，
@Modified））

SET @Retries = @Retries + 1 - 递增循环计数器并重试

WAITFOR DELAY @ DELAYPERIOD

结束
GO

--------------------------- -----------------------------------------------
- -------

标准Windows时间API调用仅精确到10毫秒左右这是

显然SQL Server如何实现WAITFOR DELAY。当我运行Profiler

跟踪时，我看到快速运行的语句报告持续时间为
0,13或16毫秒但两者之间没有任何内容。


下面是我的测试脚本，它显示了WAITFOR DELAY的实际行为。

底线是SQL Server将至少等待指定的时间

但是可以等待更长时间，因为日期时间舍入和计时器组合

间隔分辨率。


设置NOCOUNT ON

如果OBJECT_ID（''tempdb .. #Metrics''）IS NOT NULL DROP TABLE #Metrics

CREATE TABLE #Metrics

（

MillisecondDelay int NOT NULL，

MillisecondDelayTime datetime NOT NULL，

重试int NOT NULL，

StartTime datetime NOT NULL，

EndTime datetime NOT NULL

）

DECLARE @MillisecondDelay int

DECLARE @MillisecondDelayTime datetime

DECLARE @Retries int

DECLARE @StartTime da tetime

DECLARE @EndTime datetime


SET @MillisecondDelay = 0

WHILE @MillisecondDelay< 50

BEGIN

SET @MillisecondDelay = @MillisecondDelay + 1

SET @MillisecondDelayTime = DATEADD（ms，@ MillisecondDelay，

'00：00：00：000''）

SET @Retries = 0

WHILE @Retries< = 100

BEGIN

SET @Retries = @Retries + 1 - 递增循环计数器并重试

SET @StartTime = getdate（）

等待延迟@MillisecondDelayTime

SET @EndTime = getdate（）

INSERT INTO #Metrics VALUES（@MillisecondDelay，

@MillisecondDelayTime，@ Retries，@ StartTime ，@ EndTime）

结束

结束


SELECT

MillisecondDelayTime，

AVG（ActualMilliseconds）AS ActualAverageMilliseconds

FROM（

SELECT

MillisecondDelayTime，

DATEDIFF（ms， StartTime，EndTime）AS ActualMilliseconds

FROM #Metrics a

WHERE重试> 1）AS指标

GROUP BY

MillisecondDelayTime

ORDER BY

MillisecondDelayTime


-

希望这会有所帮助。


Dan Guzman

SQL Server MVP

" Aaron W. West" < TA ****** @ hotmail.NO.SPAM>在留言中写道

新闻：E7 ******************** @ speakeasy.net ...

我在运行一些测试之后还注意到WAITFOR似乎具有1/100秒的分辨率。

指定'00：00：00：003'的延迟会导致相同的延迟好像我会指定1/100秒。

WAITFOR DELAY''00：00：00：013''导致延迟2/100秒（：020或。 02），
所以它显然总是四舍五入。

行为似乎更容易跟随输出更少。

改变程序[sp_TestDelay] AS
DECLARE @DELAYPERIOD DATETIME
SET @DELAYPERIOD =''00：00：00：013''
DECLARE @Retries INT
SET @Retries = 0
WHILE（@Retries< = 1000）BEGIN
PRINT DATEPART（MILLISECOND，getdate（））
SET @Retries = @Retries + 1 - 递增循环计数器并重试
WAITFOR DELAY @DELAYPERIOD
END
GO

exec sp_testdelay

577
5 97
617
637
657


Dan Guzman <哒******* @ nospam-earthlink.net>在消息中写道
新闻：rS ***************** @ newsread2.news.pas.earthl ink.net ...
SQL Server datetime数据类型因此，WAITFOR DELAY只能精确到3.33毫秒，并且可能会出现舍入。你可以看到以下内容发生了什么

DECLARE @DELAYPERIOD datetime
SET @DELAYPERIOD =''00：00：00：001''
SELECT @ DELAYPERIOD

这在SQL Server 2000联机丛书中有记录：

<摘录href =" tsqlref.chm :: / ts_da-db_9xut.htm">

从1753年1月1日到9999年12月31日的日期和时间数据，精确度为三百分之一秒（相当于3.33
毫秒或0.00333秒） 。值将四舍五入为.000，.003或
..007秒的增量，如表中所示。

示例圆角示例
01/01/98 23： 59：59.999 1998-01-02 00：00：00.000

01/01/98 23：59：59.995,1998-01-01 23：59：59.997
01/01 / 98 23：59：59.996，
01/01/98 23：59：59.997，或
01/01/98 23：59：59.998

01/01/98 23：59：59.992,1998-01-01 23：59：59.993
01/01/98 23：59：59.993，
01/01/98 23：59：59.994

01/01/98 23：59：59.990或1998-01-01 23：59：59.990
01/01/98 23：59：59.991

< /摘录> ;

- 希望这会有所帮助。

Dan Guzman
SQL Server MVP

Des L. Davis ; <德******* @ cogeco.ca>在消息中写道
新闻：yq ​​******************** @ read2.cgocable.net ...

系统：具有3 GB RAM，2.4 GHz Celeron的Dell PowerEdge服务器软件：在Windows 2003上运行的Microsoft SQL Server 2000 Enterprise
软件：在Windows 2000上运行的Microsoft SQL Server 2000 Enterprise
服务器

如果你运行下面的代码，你会发现一些奇怪的事情。在1Millisecond延迟后，MilliSecond值不会改变。这是

错误

还是我做错了什么？
我们将非常感谢任何帮助

- -------------------------------------------------- -----------------------
-

-------
/ *
程序员：Des L. Davis
日期：2004年7月4日
目的：测试延迟反应
* /

创建程序[sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR（12）
SET @DELAYPERIOD =''00：00：00：001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 - 超时前的最大尝试次数
DECLARE @Modified DATETIME

WHILE（（@ Retries< = @MAXTRIES））BEGIN

SET @Modified = GetDate（） - 设置修改日期

PRINT @Retries
PRINT @Modified
PRINT''年=''+ CONVERT（NCHAR（4），DATEPART（年，@Modif ied））
打印''DayOfYear =''+ CONVERT（NCHAR（3），DATEPART（DAYOFYEAR，
@Modified））
PRINT''Hour =''+ CONVERT（NCHAR（ 2），DATEPART（HOUR，@ Modified））
PRINT''Minute =''+ CONVERT（NCHAR（2），DATEPART（MINUTE，

@Modified））

PRINT''Second =''+ CONVERT（NCHAR（2），DATEPART（第二，
@Modified））打印''MilliSecond =''+ CONVERT（NCHAR（3），DATEPART（MILLISECOND，
@Modified））

SET @Retries = @Retries + 1 - 递增循环计数器并重试

WAITFOR DELAY @DELAYPERIOD
结束
GO

------------------------------- -------------------------------------------
- < blockquote class =post_quotes> -------

System: Dell PowerEdge Server with 3 GB RAM, 2.4 GHz Celeron
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2003
Server
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2000
Server

If you run the code below, you''ll notice something odd occuring. The
MilliSecond value does not change after a 1Millisecond delay. Is this a bug
or am I doing something wrong?
Any assistance will be greatly appreciated
----------------------------------------------------------------------------
-------
/*
Programmer : Des L. Davis
Date : July 4, 2004
Purpose : Testing Delayed Reaction
*/

CREATE PROCEDURE [sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR(12)
SET @DELAYPERIOD = ''00:00:00:001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 -- Maximum number of tries before timing out
DECLARE @Modified DATETIME

WHILE ( ( @Retries <= @MAXTRIES ) ) BEGIN

SET @Modified = GetDate() -- Set Modification Date

PRINT @Retries
PRINT @Modified
PRINT ''Year = '' + CONVERT( NCHAR(4), DATEPART( YEAR, @Modified ) )
PRINT ''DayOfYear = '' + CONVERT( NCHAR(3), DATEPART( DAYOFYEAR ,
@Modified ) )
PRINT ''Hour = '' + CONVERT( NCHAR(2), DATEPART( HOUR, @Modified ) )
PRINT ''Minute = '' + CONVERT( NCHAR(2), DATEPART( MINUTE, @Modified ) )
PRINT ''Second = '' + CONVERT( NCHAR(2), DATEPART( SECOND, @Modified ) )
PRINT ''MilliSecond = '' + CONVERT( NCHAR(3), DATEPART( MILLISECOND,
@Modified ) )

SET @Retries = @Retries + 1 -- Increment loop counter and retry

WAITFOR DELAY @DELAYPERIOD

END
GO

----------------------------------------------------------------------------
-------

解决方案

The SQL Server datetime datatype, and therefore WAITFOR DELAY, is only
accurate to 3.33 milliseconds and rounding may occur. You can see what is
happening with the following

DECLARE @DELAYPERIOD datetime
SET @DELAYPERIOD = ''00:00:00:001''
SELECT @DELAYPERIOD

This is documented in the SQL Server 2000 Books Online:

<Excerpt href="tsqlref.chm::/ts_da-db_9xut.htm">

Date and time data from January 1, 1753 through December 31, 9999, to an
accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds
or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007
seconds, as shown in the table.

Example Rounded example
01/01/98 23:59:59.999 1998-01-02 00:00:00.000

01/01/98 23:59:59.995, 1998-01-01 23:59:59.997
01/01/98 23:59:59.996,
01/01/98 23:59:59.997, or
01/01/98 23:59:59.998

01/01/98 23:59:59.992, 1998-01-01 23:59:59.993
01/01/98 23:59:59.993,
01/01/98 23:59:59.994

01/01/98 23:59:59.990 or 1998-01-01 23:59:59.990
01/01/98 23:59:59.991

</Excerpt>

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Des L. Davis" <de*******@cogeco.ca> wrote in message
news:yq*********************@read2.cgocable.net...

System: Dell PowerEdge Server with 3 GB RAM, 2.4 GHz Celeron
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2003
Server
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2000
Server

If you run the code below, you''ll notice something odd occuring. The
MilliSecond value does not change after a 1Millisecond delay. Is this a bug or am I doing something wrong?
Any assistance will be greatly appreciated
-------------------------------------------------------------------------- -- -------
/*
Programmer : Des L. Davis
Date : July 4, 2004
Purpose : Testing Delayed Reaction
*/

CREATE PROCEDURE [sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR(12)
SET @DELAYPERIOD = ''00:00:00:001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 -- Maximum number of tries before timing out
DECLARE @Modified DATETIME

WHILE ( ( @Retries <= @MAXTRIES ) ) BEGIN

SET @Modified = GetDate() -- Set Modification Date

PRINT @Retries
PRINT @Modified
PRINT ''Year = '' + CONVERT( NCHAR(4), DATEPART( YEAR, @Modified ) )
PRINT ''DayOfYear = '' + CONVERT( NCHAR(3), DATEPART( DAYOFYEAR ,
@Modified ) )
PRINT ''Hour = '' + CONVERT( NCHAR(2), DATEPART( HOUR, @Modified ) )
PRINT ''Minute = '' + CONVERT( NCHAR(2), DATEPART( MINUTE, @Modified ) ) PRINT ''Second = '' + CONVERT( NCHAR(2), DATEPART( SECOND, @Modified ) )
PRINT ''MilliSecond = '' + CONVERT( NCHAR(3), DATEPART( MILLISECOND,
@Modified ) )

SET @Retries = @Retries + 1 -- Increment loop counter and retry

WAITFOR DELAY @DELAYPERIOD

END
GO

-------------------------------------------------------------------------- -- -------

I also notice after running a few tests that WAITFOR seems to have a
resolution of 1/100th second.

Specifying a delay of ''00:00:00:003'' causes the same delay as if I''d
specified 1/100th second.

WAITFOR DELAY ''00:00:00:013'' causes a 2/100th second delay (:020 or .02), so
it apparently always rounds up.

The behavior seems easier to follow with less output.
alter PROCEDURE [sp_TestDelay] AS
DECLARE @DELAYPERIOD DATETIME
SET @DELAYPERIOD = ''00:00:00:013''
DECLARE @Retries INT
SET @Retries = 0
WHILE ( @Retries <= 1000 ) BEGIN
PRINT DATEPART( MILLISECOND, getdate() )
SET @Retries = @Retries + 1 -- Increment loop counter and retry
WAITFOR DELAY @DELAYPERIOD
END
GO

exec sp_testdelay

577
597
617
637
657
.... etc.
"Dan Guzman" <da*******@nospam-earthlink.net> wrote in message
news:rS*****************@newsread2.news.pas.earthl ink.net...
The SQL Server datetime datatype, and therefore WAITFOR DELAY, is only
accurate to 3.33 milliseconds and rounding may occur. You can see what is
happening with the following

DECLARE @DELAYPERIOD datetime
SET @DELAYPERIOD = ''00:00:00:001''
SELECT @DELAYPERIOD

This is documented in the SQL Server 2000 Books Online:

<Excerpt href="tsqlref.chm::/ts_da-db_9xut.htm">

Date and time data from January 1, 1753 through December 31, 9999, to an
accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds
or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007
seconds, as shown in the table.

Example Rounded example
01/01/98 23:59:59.999 1998-01-02 00:00:00.000

01/01/98 23:59:59.995, 1998-01-01 23:59:59.997
01/01/98 23:59:59.996,
01/01/98 23:59:59.997, or
01/01/98 23:59:59.998

01/01/98 23:59:59.992, 1998-01-01 23:59:59.993
01/01/98 23:59:59.993,
01/01/98 23:59:59.994

01/01/98 23:59:59.990 or 1998-01-01 23:59:59.990
01/01/98 23:59:59.991

</Excerpt>

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Des L. Davis" <de*******@cogeco.ca> wrote in message
news:yq*********************@read2.cgocable.net...

System: Dell PowerEdge Server with 3 GB RAM, 2.4 GHz Celeron
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2003
Server
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2000
Server

If you run the code below, you''ll notice something odd occuring. The
MilliSecond value does not change after a 1Millisecond delay. Is this a bug or am I doing something wrong?
Any assistance will be greatly appreciated
-------------------------------------------------------------------------- -- -------
/*
Programmer : Des L. Davis
Date : July 4, 2004
Purpose : Testing Delayed Reaction
*/

CREATE PROCEDURE [sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR(12)
SET @DELAYPERIOD = ''00:00:00:001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 -- Maximum number of tries before timing out
DECLARE @Modified DATETIME

WHILE ( ( @Retries <= @MAXTRIES ) ) BEGIN

SET @Modified = GetDate() -- Set Modification Date

PRINT @Retries
PRINT @Modified
PRINT ''Year = '' + CONVERT( NCHAR(4), DATEPART( YEAR, @Modified ) )
PRINT ''DayOfYear = '' + CONVERT( NCHAR(3), DATEPART( DAYOFYEAR ,
@Modified ) )
PRINT ''Hour = '' + CONVERT( NCHAR(2), DATEPART( HOUR, @Modified ) )
PRINT ''Minute = '' + CONVERT( NCHAR(2), DATEPART( MINUTE, @Modified ) ) PRINT ''Second = '' + CONVERT( NCHAR(2), DATEPART( SECOND, @Modified ) )
PRINT ''MilliSecond = '' + CONVERT( NCHAR(3), DATEPART( MILLISECOND,
@Modified ) )

SET @Retries = @Retries + 1 -- Increment loop counter and retry

WAITFOR DELAY @DELAYPERIOD

END
GO

-------------------------------------------------------------------------- -- -------

Standard Windows time API calls are only accurate to about 10 ms and this is
apparently how SQL Server implements WAITFOR DELAY. When I run a Profiler
trace, I see statements that run quickly have a reported duration of either
0 , 13 or 16 milliseconds but nothing in between.

Below is my test script that shows the actual behavior of WAITFOR DELAY.
The bottom line is that SQL Server will wait for at least the specified time
but can wait longer due to the combination of datetime rounding and timer
interval resolution.

SET NOCOUNT ON
IF OBJECT_ID(''tempdb..#Metrics'') IS NOT NULL DROP TABLE #Metrics
CREATE TABLE #Metrics
(
MillisecondDelay int NOT NULL,
MillisecondDelayTime datetime NOT NULL,
Retry int NOT NULL,
StartTime datetime NOT NULL,
EndTime datetime NOT NULL
)
DECLARE @MillisecondDelay int
DECLARE @MillisecondDelayTime datetime
DECLARE @Retries int
DECLARE @StartTime datetime
DECLARE @EndTime datetime

SET @MillisecondDelay = 0
WHILE @MillisecondDelay < 50
BEGIN
SET @MillisecondDelay = @MillisecondDelay + 1
SET @MillisecondDelayTime = DATEADD(ms, @MillisecondDelay,
''00:00:00:000'')
SET @Retries = 0
WHILE @Retries <= 100
BEGIN
SET @Retries = @Retries + 1 -- Increment loop counter and retry
SET @StartTime = getdate()
WAITFOR DELAY @MillisecondDelayTime
SET @EndTime = getdate()
INSERT INTO #Metrics VALUES(@MillisecondDelay,
@MillisecondDelayTime, @Retries, @StartTime, @EndTime)
END
END

SELECT
MillisecondDelayTime,
AVG(ActualMilliseconds) AS ActualAverageMilliseconds
FROM (
SELECT
MillisecondDelayTime,
DATEDIFF(ms, StartTime, EndTime) AS ActualMilliseconds
FROM #Metrics a
WHERE Retry > 1) AS Metrics
GROUP BY
MillisecondDelayTime
ORDER BY
MillisecondDelayTime

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Aaron W. West" <ta******@hotmail.NO.SPAM> wrote in message
news:E7********************@speakeasy.net...

I also notice after running a few tests that WAITFOR seems to have a
resolution of 1/100th second.

Specifying a delay of ''00:00:00:003'' causes the same delay as if I''d
specified 1/100th second.

WAITFOR DELAY ''00:00:00:013'' causes a 2/100th second delay (:020 or .02), so it apparently always rounds up.

The behavior seems easier to follow with less output.
alter PROCEDURE [sp_TestDelay] AS
DECLARE @DELAYPERIOD DATETIME
SET @DELAYPERIOD = ''00:00:00:013''
DECLARE @Retries INT
SET @Retries = 0
WHILE ( @Retries <= 1000 ) BEGIN
PRINT DATEPART( MILLISECOND, getdate() )
SET @Retries = @Retries + 1 -- Increment loop counter and retry
WAITFOR DELAY @DELAYPERIOD
END
GO

exec sp_testdelay

577
597
617
637
657
... etc.
"Dan Guzman" <da*******@nospam-earthlink.net> wrote in message
news:rS*****************@newsread2.news.pas.earthl ink.net...
The SQL Server datetime datatype, and therefore WAITFOR DELAY, is only
accurate to 3.33 milliseconds and rounding may occur. You can see what is
happening with the following

DECLARE @DELAYPERIOD datetime
SET @DELAYPERIOD = ''00:00:00:001''
SELECT @DELAYPERIOD

This is documented in the SQL Server 2000 Books Online:

<Excerpt href="tsqlref.chm::/ts_da-db_9xut.htm">

Date and time data from January 1, 1753 through December 31, 9999, to an
accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or ..007 seconds, as shown in the table.

Example Rounded example
01/01/98 23:59:59.999 1998-01-02 00:00:00.000

01/01/98 23:59:59.995, 1998-01-01 23:59:59.997
01/01/98 23:59:59.996,
01/01/98 23:59:59.997, or
01/01/98 23:59:59.998

01/01/98 23:59:59.992, 1998-01-01 23:59:59.993
01/01/98 23:59:59.993,
01/01/98 23:59:59.994

01/01/98 23:59:59.990 or 1998-01-01 23:59:59.990
01/01/98 23:59:59.991

</Excerpt>

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Des L. Davis" <de*******@cogeco.ca> wrote in message
news:yq*********************@read2.cgocable.net...

System: Dell PowerEdge Server with 3 GB RAM, 2.4 GHz Celeron
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2003
Server
Software: Microsoft SQL Server 2000 Enterprise running on Windows 2000
Server

If you run the code below, you''ll notice something odd occuring. The
MilliSecond value does not change after a 1Millisecond delay. Is this a

bug

or am I doing something wrong?
Any assistance will be greatly appreciated

--------------------------------------------------------------------------
--

-------
/*
Programmer : Des L. Davis
Date : July 4, 2004
Purpose : Testing Delayed Reaction
*/

CREATE PROCEDURE [sp_TestDelay] AS

DECLARE @DELAYPERIOD NCHAR(12)
SET @DELAYPERIOD = ''00:00:00:001''
DECLARE @Retries INT
SET @Retries = 0
DECLARE @MAXTRIES INT
SET @MAXTRIES = 1000 -- Maximum number of tries before timing out
DECLARE @Modified DATETIME

WHILE ( ( @Retries <= @MAXTRIES ) ) BEGIN

SET @Modified = GetDate() -- Set Modification Date

PRINT @Retries
PRINT @Modified
PRINT ''Year = '' + CONVERT( NCHAR(4), DATEPART( YEAR, @Modified ) )
PRINT ''DayOfYear = '' + CONVERT( NCHAR(3), DATEPART( DAYOFYEAR ,
@Modified ) )
PRINT ''Hour = '' + CONVERT( NCHAR(2), DATEPART( HOUR, @Modified ) )
PRINT ''Minute = '' + CONVERT( NCHAR(2), DATEPART( MINUTE,

@Modified ) )

PRINT ''Second = '' + CONVERT( NCHAR(2), DATEPART( SECOND, @Modified ) ) PRINT ''MilliSecond = '' + CONVERT( NCHAR(3), DATEPART( MILLISECOND,
@Modified ) )

SET @Retries = @Retries + 1 -- Increment loop counter and retry

WAITFOR DELAY @DELAYPERIOD

END
GO

--------------------------------------------------------------------------
--

-------

这篇关于等待延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！