배경 및 조사 내용

ID값의 리셋을 프로덕션 환경에서 온라인으로 실시하는 것이 가끔 있기 때문에, 거동에 대해 조사해 보았습니다.

테이블 만들기

create table t1 (col1 int identity(1,1), col2 int)

트랜잭션 로그 확인

checkpoint
select * from sys.fn_dblog(null, null) --トランザクションログ確認
DBCC CHECKIDENT (t1, RESEED, 100)
select * from sys.fn_dblog(null, null) --トランザクションログ確認

잠금 정보에서 오브젝트 이름을 식별합니다.


하나는 t1 테이블에 Sch-M 잠금이었다.


또 하나는 syscolpars라는 내부 시스템 테이블이었습니다.
문서 에도 게재되고 있습니다.

SELECT 
    sc.name as schema_name, 
    so.name as object_name, 
    si.name as index_name
FROM sys.partitions AS p
JOIN sys.objects as so on 
    p.object_id=so.object_id
JOIN sys.indexes as si on 
    p.index_id=si.index_id and 
    p.object_id=si.object_id
JOIN sys.schemas AS sc on 
    so.schema_id=sc.schema_id
WHERE hobt_id = 281474979397632;
GO

syscolpars의 내용을 보려면 DAC 연결이 필요합니다.
DAC 연결 후 다음 쿼리를 실행하면 업데이트된 레코드까지 확인할 수 있습니다.

SELECT
    *
FROM sys.syscolpars (NOLOCK)
WHERE %%lockres%% = '(eb60ca9093af)';
GO

ID 값이 변경되면 syscolpars의 해당 레코드의 idtval 열이 업데이트되는 거동이 되었습니다.
※idtval에 대해서는 이 기사 가 보다 상세합니다.

조사를 바탕으로 ID 값을 재설정 할 때 조심하십시오.

트랜잭션 로그의 내용을 보는 한, 락을 취득할 수 있어 버리면, 레코드수에 관계없이 순간적으로 끝나는 처리라고 할 수 있습니다.

다만, Sch-M 락을 취득할 필요가 있기 때문에, 블로킹에 주의가 필요합니다.
DBCC CHECKIDENT 실행→1초 경과해도 끝나지 않으면 중단→다시 실행
를 반복하면 좋을까 생각합니다.

좀처럼 Sch-M 락을 획득할 수 없는 환경하에서는 이 기사 에서 소개하고 있는 방법을 사용하는 것도 있다고 생각합니다.