GetDate in Standardbeschränkungen in einigen Tabellen in SQL Server 2012

Question

Wie Sie erwarten, habe ich ein Problem mit GetDate in Standardeinschränkungen in einigen Tabellen in SQL Server 2012.

Ich habe zwei Tische wie unten (a und b):

CREATE TABLE [dbo].[TABLE_A_OR_B] (
[TABLE_A_OR_B_PK]   BIGINT          IDENTITY (1, 1) NOT NULL,
[CREATE_DATETIME]   DATETIME2 (7)   CONSTRAINT [DF_TABLE_A_OR_B_CREATE_DATETIME] DEFAULT (getdate()) NOT NULL,
[CREATE_USER]       VARCHAR (100)   CONSTRAINT [DF_TABLE_A_OR_B_CREATE_USER] DEFAULT (suser_sname()) NOT NULL,
...
CONSTRAINT [PK_TABLE_A_OR_B] PRIMARY KEY CLUSTERED ([TABLE_A_OR_B_PK] ASC)
);

Und ich habe eine Prozedur, bei der ich zwei Einsätze mache - zuerst zu Tabelle A und zweitens B ohne Spalte create_datetime. Zwischen ihnen ist eine Menge Sachen.

Ratet mal, was in der Spalte create_datetime in den Tabellen A und B ist?

Zweimal - vielleicht nach 1 000 000 Datensätzen, noch nie zuvor - befindet sich in Tabelle A DATETIME DIMER IN TABELLE B FÜR DRAFTEN AUS DER DEM SP -Ausführung (verifiziert) wie folgt:

row in A: 2013-11-07 00:02:22.7000000 
row in B: 2013-11-07 00:02:22.6970000

Kannst du mir ein paar Hinweise geben, warum?

Antworten für Kommentare:
1. Keine Auslöser.
2. Nr. 1 000 000 Datensätze gleichzeitig sind die Gesamtzahl der Datensätze in der Tabelle im ersten Fehler im Moment. Diese Informationen sind für die statistische Analyse - heute ist ein Fehler nach xx Tausenden von Datensätzen nach dem letzten Fehler aufgetreten - daher ist dies sehr zufällig.
3. Ja, Aussagen werden zu 100% in dieser Reihenfolge ausgeführt.
4. Keine Transaktion oder einzelne - zwei verschiedene Prozesse - gleicher Fehler.
5. Sicher dateTime2.

Wichtig! Jemand hat mir gesagt, dass GetDate eine Genauigkeit auf 3 Millisekunden hat. Vielleicht rundet GetDate Millisekunden mit einer runden Robin -Methode so zweimal zum gleichen oder nahezu selben Zeit (Diff <3 ms).

Answer 1

Getdate zu sysdatetime Änderung der Einschränkungen scheint ein Problem zu lösen.

Answer 2

Wenn Sie den ersten Einfügen in Tabelle A einfügen und begehen und dann den zweiten Einfügen in Tabelle B einfügen und begehen, ist es sehr möglich, um dieses Ergebnis zu erzielen, da dieser Unterschied mit dem Einfügen der beiden Datensätze eingesetzt wird. Auch wenn Sie den Einsatz in separaten Transaktionen nicht begehen.

Wenn der Tisch wächst, dauert der Einsatz aus vielen Gründen mehr Zeit. Wenn die Tabelle in jedem Insert in den Index enthält, muss der Index zur Kenntnis nehmen, wo der Datensatz gespeichert oder organisiert wurde. Zweitens wird die Fragmentierung auf den Seiten im SQL -Server die Einfügung mehr Zeit in Anspruch nehmen. Überprüfen Sie Ihre Indexstruktur, wenn schnellere Einsätze den Füllfaktor niedrig halten möchten.

Wenn Sie immer die gleiche Zeit wünschen, erstellen Sie eine Variable. Erstellen Sie die Zeit und erstellen Sie dann den Einfügen in beiden Tabellen mit dieser Variablen.

Ich hoffe es hilft.

Answer 3

GETDATE() wird aus der Uhr des Betriebssystems abgeleitet - Wenn etwas dazu geführt hat, dass die Uhr auf dem Server (zu einem früheren Zeitpunkt) geändert wird, erreichen Sie Ihre (offensichtliche) Zeitreise.

Was könnte solche Änderungen verursachen? Das Offensichtliche ist eine manuelle Einstellung oder wenn der Server so eingestellt ist, dass er seine Uhr automatisch mit einer externen Quelle synchronisiert, wie z. B. eine andere Maschine auf Ihrer Domäne oder über NTP. Es kann auch andere mögliche Ursachen geben.