Précision de SQL Getdate?

Question

J'expérimente avec un programme qui insère des données dans une base de données SQL 2005 Server (sur XP SP3) à haut débit. (Ceci est pour collecter des données de synchronisation afin que je puisse évaluer différents aspects de ma conception).

Mon configuration de base consiste à insérer une donnée dans un tableau comme suit (et en utilisant un SP qui spécifie que le champ de charge utile):

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

Notez que les deux champs datetime ont UNIQUE sur eux aussi .

Sur le programme client, j'appelais le SP dans une boucle tellement serrée que j'avais des problèmes avec la précision de la valeur .Net DateTime.Now (et éventuellement du thread dormant) et donc violant la contrainte unique de la charge utile. Je ai adressé par une combinaison d'une variable chronomètre, un peu de Thread.Sleep() et la construction manuelle des données "payload" de sorte qu'il n'a pas violé la résolution du champ SQL DateTime (3.3 mS)

Cependant avec les inserts étant générés à une vitesse comprise entre 5mS et 10mS J'ai commencé à voir des problèmes avec le champ "Inséré" du côté SQL où une ligne est régulièrement rejetée pour une violation de clé unique. Ce n'est que lorsque je ralentis mon taux d'insertion à plus de 15 mS que ces problèmes disparaissent. Ce taux ressemble étrangement au problème de précision que j'avais avec le .Net DateTime.Now (j'ai lu 16mS sur un post quelque part) donc je me demande quelle est la précision réelle de la fonction SQL Getdate().

Alors, quelqu'un peut-il me dire ce qui soutient GetDate(), et serait-il lié à la même source que la valeur .Net DateTime.Now? Et quelle précision dois-je en attendre? En outre, je connais le type DATETIME2 dans le serveur SQL 2008, ce qui soulève la question de savoir quelle est la précision de GetDate() dans ce système également.

Answer 1

DATETIME est stocké sous forme de 2 entiers. L'une représentant la partie date et l'autre la partie temps (nombre de graduations après minuit) cochent chacune is 1/300 of a second pour avoir au moins une précision théorique de 3,3 millisecondes.

Je viens d'essayer d'exécuter ce sur ma machine

declare @d varchar(24) 

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

Et a obtenu une course assez longue où il a fait monter d'un tic à la fois, donc je ne pense pas qu'il y ait une limitation inhérente qui empêche réaliser cela.

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 

En ce qui concerne votre question au sujet GetDate() précision dans SQL Server 2008, c'est le même que pour SQL2005. sysdatetime est destiné à avoir une plus grande précision. J'ai juste essayé de courir le suivant et ai été surpris par l'écart entre les deux résultats.

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 

Résultats

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 

Answer 2

DATETIME a une précision de 3,3ms, mais GETDATE() ne retourne pas à ce moment précis que vous avez découvert. Consultez le MSDN page for date/time types/functions pour plus d'informations sur le fonctionnement des nouveaux types/fonctions.