SQL Server 오류 30 일 상담 19 일 째 Truncate 표 작업 은 로그 에 기록 되 지 않 습 니 다.

오류\#19:Truncate 표 의 동작 은 로그 에 기록 되 지 않 습 니 다.오류 가 사용자 표 에 있 는 동작 은 로그 에 기 록 됩 니 다.SQL Server 에서 로그 에 기록 되 지 않 는 유일한 동작 은 TempDB 의 줄 버 전 관리 입 니 다.Truncate Table 문 구 는 표 의 모든 데 이 터 를 삭제 합 니 다.그러나 삭제 하 는 방식 은 한 줄 한 줄 삭제 가 아니 라 표 로 구 성 된 데이터 페이지 를 방출 하고 표 로 구 성 된 관련 페이지 를 방출 하 는 작업 을 배경 스 레 드 에 맡 겨 대기 열 처 리 를 하 는 과정 을 deferred-drop 이 라 고 합 니 다.배경 스 레 드 를 사용 하여 deferred-drop 를 처리 하 는 장점 은 이 작업 이 있 는 업 무 를 오래 수행 하지 않 기 때문에 대량의 자물쇠 가 필요 하지 않다 는 것 이다.SQL Server 2000 SP3 이전 버 전(이 버 전 은 deferred-drop 을 도 입 했 습 니 다)이 Truncate Table 에서 너무 많은 잠 금 이 발생 하여 메모리 가 소 진 되 는 일이 다반사 입 니 다.다음은 테스트 코드 입 니 다.

 
CREATE DATABASE TruncateTest; 
GO 
USE TruncateTest; 
GO 
ALTER DATABASE TruncateTest SET RECOVERY SIMPLE; 
GO 
CREATE TABLE t1 (c1 INT IDENTITY, c2 CHAR (8000) DEFAULT 'a'); 
CREATE CLUSTERED INDEX t1c1 on t1 (c1); 
GO 

SET NOCOUNT ON; 
GO 

INSERT INTO t1 DEFAULT VALUES; 
GO 1280 

CHECKPOINT; 
GO 

위의 테스트 데이터 베이스 복구 모델 은 간단 하기 때문에 모든 Checkpoint 는 로 그 를 차단 합 니 다(간단 하기 위해 서 입 니 다.하하).1 분 후에 일지 에 몇 개의 기록 이 있 는 지 봅 시다.

 
SELECT COUNT (*) FROM fn_dblog (NULL, NULL); 
GO 

을 보면 현재 로그 항목 의 숫자 는 2 입 니 다.만약 당신 이 얻 은 숫자 가 2 가 아니라면,데이터 가 2 일 때 까지 Checkpoint 를 한 번 더 하 세 요.현재 로 그 를 알 고 있 습 니 다.로그 의 증 가 는 뒤의 작업 으로 인 한 것 입 니 다.다음은 다음 코드 를 실행 합 니 다.

 
TRUNCATE TABLE t1; 
GO 

SELECT COUNT (*) FROM fn_dblog (NULL, NULL); 
GO 

은 현재 541 개의 로그 기록 이 있 음 을 볼 수 있 습 니 다.Truncate 작업 은 로그 에 기록 해 야 한 다 는 것 이 분명 합 니 다.그러나 이 541 개의 로그 기록 이 1280 개의 데 이 터 를 삭 제 했 기 때문에 Truncate 는 한 줄 한 줄 삭제 하지 않 는 다 는 것 을 알 수 있다.다음 문장 을 실행 하여 로 그 를 보십시오:

 
SELECT 
[Current LSN], [Operation], [Context], 
[Transaction ID], [AllocUnitName], [Transaction Name] 
FROM fn_dblog (NULL, NULL); 

다음은 결과 입 니 다.    
    그림 1.Truncate 후의 로그(부분)를 보면 로 그 를 통 해 첫 번 째 디 스 플레이 로 Truncate Table 사 무 를 시작 하고 마지막 으로 Deferred Alloc 를 시작 합 니 다.보시 다시 피 Truncate 작업 은 표 의 페이지 와 구역 을 구성 하 는 것 에 불과 합 니 다.다음 코드 는 로그 의 구체 적 인 동작 에 대한 설명 을 볼 수 있 습 니 다.

 
SELECT 
[Current LSN], [Operation], [Lock Information], [Description] 
FROM fn_dblog (NULL, NULL); 
GO 

결 과 는 그림 2: 참조.
    그림 2.로그 작업 설명(선택)
당신 은 빠 른 회복 의 목적 을 위해 관련 자 물 쇠 를 추가 한 것 을 알 수 있 습 니 다.
    위의 로그 에서 보 듯 이 이 동작 은 8 페이지 에 관련 자 물 쇠 를 추가 한 다음 에 전체 구역 을 한꺼번에 방출 합 니 다.방출 후 관련 구역 에 IX 자 물 쇠 를 추가 합 니 다.즉,더 이상 사용 할 수 없습니다.트 랜 잭 션 이 제출 되 어야 deferred-drop 이 진행 되 기 때문에 Truncate table 작업 이 다시 굴 러 갈 수 있 습 니 다.
    또한 표 에 비 집합 색인 이 존재 한다 면 조작 방식 도 비슷 합 니 다.모두 배경 스 레 드 에 건 네 주 고 표 와 색인 을 방출 하 는 페이지 입 니 다.방출 된 최소 단 위 는 모든 분배 단원 이다.위 단계 에 따라 네가 직접 시도 해 보면 내 뜻 을 알 수 있 을 것 이다.
PS:Truncate Table 작업 이 스크롤 백 할 수 없 는 잘못된 부분 이 있 습 니 다.저 는 Lock logging and fast recovery 이라는 글 에서 상세 하 게 설명 하 였 습 니 다.