SQL Getdate의 정밀도?

높은 속도로 SQL 2005 Server 데이터베이스 (XP SP3)에 데이터를 삽입하는 프로그램을 실험하고 있습니다. (이것은 타이밍 데이터를 수집하기위한 것이기 때문에 디자인의 여러 측면을 평가할 수 있습니다).SQL Getdate의 정밀도?

내 기본적인 셋업은 같은 테이블에 데이터를 삽입 관련된 다음 (그냥 페이로드 필드를 지정하는 SP 사용) : 두 날짜 필드뿐만 아니라 그들에 UNIQUE 제약 조건을 가지고

create table data 
(
Id int PRIMARY KEY Identity, 
payload datatime not null, 
inserted datetime default (getdate()) not null 
)

주 .

클라이언트 프로그램에서 필자는 .Net DateTime.Now 값의 정밀도에 문제가 있었고 (따라서 스레드도 잠자기 상태 였기 때문에) 페이로드의 고유 한 제약 조건을 위반하는 등의 엄격한 루프에서 SP를 호출했습니다. 나는 스톱워치 변수, Thread.Sleep()의 비트와 "페이로드"데이터를 수동으로 생성하여 SQL DateTime 필드 (3.3 mS)의 해상도를 위반하지 않도록했습니다.

그러나 삽입물은 5mS에서 10mS 사이의 속도로 생성됩니다. 고유 한 키 위반에 대해 행이 정기적으로 거부되는 SQL 쪽의 "삽입 됨"필드에 문제가 발생하기 시작했습니다. 이 문제가 사라지는 것은 15 번이나 그 이상으로 삽입 속도를 늦추는 경우에만 해당됩니다. 이 속도는 .Net DateTime.Now (내가 어딘가에 게시물에 16mS를 읽었습니다)와 같은 정밀도 문제와 유사하므로 SQL Getdate() 함수의 실제 정밀도가 무엇인지 궁금합니다.

그래서 누군가 GetDate()를 뒷받침하는 것을 말해 줄 수 있으며 .Net DateTime.Now 값과 동일한 소스에 묶여 있을까요? 그리고 그것으로부터 어떤 종류의 정밀도를 기대해야합니까?

SQL 2008 서버의 DATETIME2 형식에 대해 알고 있으므로 해당 시스템의 GetDate()에 대한 정밀도가 무엇인지에 대한 질문이 제기됩니다.

출처

2010-07-31 Peter M

왜 삽입 된 열에 고유 제한 조건이 필요합니까? 식별 열에는 삽입 된 순서가 표시됩니다.나는 데이터베이스 생성 시간이 동시 활동으로 인해 삽입 요청을 처리 할 수있는 빈도의 자연적 변화에 취약 할 것이라고 추측합니다. 이전 삽입이 페이지 분할을 야기했는지 여부와 상관없이 어쨌든 그렇게 의미를 가질 수는 없습니다. 그런 제약을 보증하라. –

@martin .. 유일성과 질서가 같은 것은 아닙니다. 같은 시간에 두 개의 행을 삽입 할 수 없다는 생각에 빠져있었습니다. 그러나 getdate의 정밀도가 잘못되었습니다. 그러나 나는 내가하고있는 일이 세상에서 가장 똑똑한 일이라고 제안하지는 않습니다! –

DATETIME은 2 개의 정수로 저장됩니다. 하나는 날짜 부분을 나타내고 다른 하나는 시간 부분 (자정 이후의 틱 수)을 나타내며 각각 is 1/300 of a second 틱이므로 최소한 이론적 인 정밀도는 3.3 밀리 초입니다.

난 그냥 내 컴퓨터

declare @d varchar(24) 

while 1=1 
begin 
set @d=CONVERT(VARCHAR(24), GETDATE(), 113) 
raiserror('%s',0,1, @d) with nowait 
end

에서이 작업을 실행 그리고 그것은 내가 할 수없는 어떤 고유 제한이있을 수 있다고 생각하지 않습니다 한 번에 하나의 틱을 이동했다 상당히 긴 실행을 가지고 시도 달성.

01 Aug 2010 00:56:53:913 
... 
01 Aug 2010 00:56:53:913 
01 Aug 2010 00:56:53:917 
... 
01 Aug 2010 00:56:53:917 
01 Aug 2010 00:56:53:920 
... 
01 Aug 2010 00:56:53:920 
01 Aug 2010 00:56:53:923

쿼리 SQL Server 2008의 대한 GetDate() 정밀도와 관련이 SQL2005과 동일합니다. sysdatetime은 더 높은 정밀도를 의미합니다. 나는 단지 다음을 실행하려고 시도하고 두 결과 사이의 불일치에 놀랐다.

SET NOCOUNT ON 

CREATE TABLE #DT2(
[D1] [datetime2](7) DEFAULT (getdate()),  
[D2] [datetime2](7) DEFAULT (sysdatetime()) 
) 
GO 

INSERT INTO #DT2 
      DEFAULT VALUES 
GO 100 

SELECT DISTINCT [D1],[D2],DATEDIFF(MICROSECOND, [D1], [D2]) AS MS 
FROM #DT2

는

D1       D2        MS 
---------------------------- -----------------------  ------ 
2010-08-01 18:45:26.0570000 2010-08-01 18:45:26.0625000  5500 
2010-08-01 18:45:26.0600000 2010-08-01 18:45:26.0625000  2500 
2010-08-01 18:45:26.0630000 2010-08-01 18:45:26.0625000  -500 
2010-08-01 18:45:26.0630000 2010-08-01 18:45:26.0781250  15125 
2010-08-01 18:45:26.0670000 2010-08-01 18:45:26.0781250  11125 
2010-08-01 18:45:26.0700000 2010-08-01 18:45:26.0781250  8125

출처

2010-07-31 23:09:44

데이터가 테이블에 삽입되는 동안 타이머가 멈추지 않으므로 불일치가 발생하지 않습니다. 이 http://msdn.microsoft.com/en-us/library/ms188383.aspx MS 페이지에서 "select Getdate(), sysdatetime()"을 시연 할 때 언급 한 것을 보았습니다. 그러나 내 문제는 약 15 mS의 입도로 datetime 값을 반환하는 내 컴퓨터에서 getdate() 주위를 돌리는 것 같습니다. 나중에 쿼리를 실행하고 내 컴퓨터에서 무엇이 튀어 나오는지 확인합니다. 무슨 하드웨어와 운영 체제를 실행하고 있습니까? –

방금 결과를 다시 한 번 살펴 봤는데 하나의 행에 D1! = D2를 처리 할 수있는 삽입 과정에서 이상한 일이 일어나야 만하는 것처럼 보였습니다. 그러나 여러 D2 값이 여러 다른 D1 값보다 큽니다. 행이 실제로 흥미 롭습니다 (또는 무서운 것). 이상한 스레딩 문제 일 수도 있습니다. –

@Peter - RE : 내 데스크톱 컴퓨터에만 있던 사양이므로 XP, 2GB RAM은 다른 응용 프로그램에서 동시에 발생하는 동시 작업을로드하지만 GetDate 버전이 그렇지 않은 방식을 이해하지 못했습니다. sysdatetime이 26.078을보고 한 후 '26.07'에 도달했습니다. 각 삽입은 자체 트랜잭션에 있으므로 다음 트랜잭션을 시작하기 전에 커밋해야합니다. –

DATETIME는 3.3ms의 정밀도를 가지고 결과,하지만 당신이 발견 한 것처럼 GETDATE()이에 정확한 시간을 반환하지 않습니다. 새로운 유형/기능의 작동 방식에 대한 자세한 내용은 MSDN page for date/time types/functions을 확인하십시오.

출처

2010-07-31 23:13:34

용어에 동의하지 않습니다. 해상도는 3.3mS이지만 정밀도는 아닙니다! 그리고 "모든 시스템 날짜 및 시간 값은 SQL Server 인스턴스가 실행되는 컴퓨터의 운영 체제에서 파생되었습니다."라는 핵심 문장이있는 페이지를 보았습니다. 그들이 파생 된 방법을 말하지 않습니다! –

DATETIME은 3.3ms (또는 그 근원)의 정밀도를가집니다. 원자 시계로 설정하면 3.3ms로 정확합니다. :) GETDATE()는 DATETIME이 아니라 여기서 문제입니다. 해상도가 더 좋은 용어입니다. ' –

. Getdate가 datetime을 반환한다고 가정 할 때 그들은 일종의 고리로 묶여 있습니다. 그렇습니다. GetDate가 여기있는 문제입니다. http://www.tutelman.com/golf/measure/precision.php도 확인하십시오. –

답변

관련 문제