제약 조건에서 SYSDATETIME 변화를 얻는 것은 문제를 해결하는 것으로 보입니다.
SQL Server 2012의 일부 테이블에 대한 기본 제약 조건을 getDate
-
29-07-2022 - |
문제
예상대로 SQL Server 2012의 일부 테이블에서 GetDate에서 기본 제약 조건에 문제가 있습니다.
아래 (A 및 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)
);
그리고 두 개의 삽입물을 수행하는 절차가 있습니다. 먼저 create_dateTime 열이없는 테이블 a와 두 번째에서 b에서 b까지. 그들 사이에는 많은 것들이 있습니다.
이제 테이블 a와 b의 create_dateTime 열에 무엇이 있는지 추측하십시오.
두 번 - 아마도 1,000,000 개의 레코드 후에는 이전에 없었을 것입니다. 테이블에는 동일한 SP 실행 (확인)의 레코드에 대해 표 B보다 더 큰 시간이 있습니다.
row in A: 2013-11-07 00:02:22.7000000
row in B: 2013-11-07 00:02:22.6970000
왜 나에게 단서를 줄 수 있습니까?
의견에 대한 답변 :
1. 트리거가 없습니다.
2. 한 번에 1,000 000 레코드가 아니 었습니다. 오류가 발생한 순간의 테이블에있는 총 레코드 수입니다. 이 정보는 통계 분석을위한 것입니다 - 오늘 오류는 마지막 오류 후 XX 수천 개의 레코드 후에 발생 했으므로 매우 무작위입니다.
3. 예, 진술은이 순서로 100% 실행됩니다.
4. 트랜잭션이나 단일 - 두 가지 프로세스 - 동일한 오류.
5. 확실한 dateTime2.
중요한! 누군가 GetDate가 3 밀리 초의 정확도를 가지고 있다고 말 했으므로 Round Robin 방법을 사용하여 GetDate Rounds Rounds가 동일하거나 거의 동일하게 두 번 (Diff <3ms) 두 가지 근사치를 줄 수 있다고 말했습니까?
해결책 3
다른 팁
표 A에 첫 번째 삽입물을 삽입하고 커밋 한 다음 표 B에 두 번째 삽입물을 삽입하고 커밋하는 경우 두 레코드를 삽입하기 위해 시간의 차이를 가져 오기 때문에이 결과를 얻을 수 있습니다. 별도의 트랜잭션으로 인서트를 커밋하지 않더라도.
테이블이 커지면 삽입물은 여러 가지 이유로 점점 더 많은 시간이 걸립니다. 테이블에 모든 삽입물에 인덱스가있는 경우 인덱스는 레코드가 저장되거나 구성된 위치를 기록해야합니다. 둘째, SQL Server의 내부 페이지의 조각화는 삽입물을 더 많은 시간을 할애합니다. 더 빠른 인서트를 원한다면 인덱스 구조를 확인하십시오. 충전 계수를 낮게 유지하십시오.
항상 같은 시간을 원한다면 변수를 만들고 시간을 얻은 다음이 변수를 사용하여 두 테이블에서 삽입을 만듭니다.
도움이되기를 바랍니다.
GETDATE()
운영 체제의 시계에서 파생됩니다. 서버의 시계가 (이전까지) 변경 된 경우 (명백한) 시간 여행을 달성 할 수 있습니다.
그러한 변화를 일으킬 수있는 것은 무엇입니까? 명백한 것은 수동 조정 또는 서버가 도메인의 다른 시스템이나 NTP를 통해 외부 소스와 시계를 자동으로 동기화하도록 설정된 경우입니다. 다른 가능한 원인도있을 수 있습니다.