auto-increment int 기본 키가있는 테이블이 있는데 최대 값은 이제 T-SQL int 유형의 제한값입니다. 우리가 테이블을 다시 시드하려고 할 때 (키에 큰 갭이 있기 때문에 최대 int 값만큼 충분한 행을 찾을 수 없음) 최대 값 int 값으로 계속 재설정됩니다.기본 키가 오버플로되면 어떻게합니까?
분명히 심각한 문제를 야기합니다. PK는 결코이 가치를 얻지 못했고 데이터 유형을 변경하는 것은 큰 일이 될 것입니다. 재 시딩은 충분해야하지만 작동하지 않습니다!
어떻게 계속 재설정 될 수 있습니까?
편집 : 상황을 명확히하기 위해이 쿼리 SELECT MIN(CategoryID), MAX(CategoryID) FROM dbo.tblCategories은 -2147483647, 2147483647을 반환합니다. int 유형의 최소 및 최대 값에 실제 PK 값이 있음을 의미합니다.
다음에 할당 된 ID 열이 테이블의 현재 최대 값보다 작아 지도록 테이블을 "다시 시드"할 수 있습니다. 그러나 어떤 하위 기호 인 DBCC CHECKIDENT은 내부 카운터를 현재 열에있는 최대 값으로 다시 설정합니다. 리셋이 나오는 곳이 아마도 그럴까요? 그리고 물론 인서트는 결과적으로 중복 값을 기록하여 제작 지원 담당자에게 재미있는 시간을 갖게됩니다.
전반적으로 문제가 있습니다. uber-high ID 값을 제거/재설정하려면 일회성 스크립트를 작성하는 것이 좋습니다. 행 (및 모든 관련 외래 키 값)을 업데이트하는 것은 외래 키 제약 조건을 비활성화해야한다는 것을 포함하지만 다른 모든 항목을 알지 못하기 때문에 하나의 옵션이므로 권장하지 않습니다. 다른 하나는 의 정확한 복사본을 만들고 더 많은 실제 ID 값을 사용하여 "high-id"항목에 대한 데이터를 모두으로 만든 다음 원래 항목을 삭제하는 것입니다. 이것은 해킹이지만 훨씬 더 유지 관리가 쉬운 데이터베이스가됩니다.
아, 그 높은 ID 값을 넣은 사람들을 추적하고 최소한 데이터베이스에 대한 액세스 권한을 철회하십시오.
테이블을 다시 색인하면 다른 유지 관리 유형 활동처럼 ID 카운터도 재설정 될 수 있습니다.실제로 리셋을 일으키는 원인을 식별하기 위해 많은 테스트가 필요할 수 있습니다. –
누군가가 우연히'NORESEED'없이'CHECKIDENT'를 실행했다고 생각하지만, 우리가 가지고있는 오류 로그의 타임 스탬프에 따라 그 방식으로 보이지 않습니다. –
우리는 행운을 빕니다. 테이블의 PK는 어디서나 외래 키로 사용되지 않습니다. 사실 덕분에 PK 카운트를 1로 다시 시작할 수 있습니다. –
저는 비슷한 문제가있는 프로젝트에 참여했습니다. 우리의 경우 누군가 4 자리 숫자를 기본 키로 선택한 필드를 선택했는데, 9999 개의 레코드에 접근 할 때 작동하지 않았습니다.
우리의 경우 테이블에 새 열을 만들고 그 열을 채우고 기본 키를 해당 열로 변경 한 다음 모든 외부 키 관계를 새 키에 다시 물었습니다.
매우 지저분하지만 작동했습니다.
사용중인 최대 값은 무엇입니까? 내 생각 엔 그것은'int'에 저장 가능한 최대 값이라는 것입니다. –
나는 이것을 포함하는 게시물을 명확히하고있다. –
열을 다시 시드하는 방법, DBCC CHECKIDENT (TABLE_NAME, RESEED, NEW_SEED_VALUE)를 실행하고 있습니까? 신원 증분 값이 높을 수도 있습니다. 데이터의 틈에 눈치 채 셨던 패턴이 있습니까? –