2018년 9월 30일 일요일

[SQL Server] Simple Update Query

Professional SQL Server 2012 Internals and Troubleshooting 내용 정리

Update query의 실행과정은 Select와 유사하다.

Select와 다른 부분부터 설명해본다.

Update Query는 Access Methods 부분부터 확인하면 된다.

Update라는 것은 이미 존재하고 있는 데이터를 변경하는 것이다.
Access Methods에서 I/O Request가 아닌 디스크에 존재하는 데이터의 변경을 요청 해야 한다. 이 작업을 해주는 것이 바로 Transaction Manager이다.

- Transaction Manager
 Transaction Manager는 Lock Manager와 Log Manager로 다시 나뉜다. Lock Manager는 동시성을 책임지며, 해당 부분에서는 다루지 않는다. Log Manager는 Access Methods가 수정을 요청하는 부분을 log로 만든다. 그리고 해당 로그를 Transaction Log에 쓴다. 이러한 과정을 WAL(Write-ahead Logging)이라고 한다.
Transaction Log에 쓰는 것은 디스크에 쓰는 것이다. CPU, 메모리가 아닌 디!스!크! 이유는 바로 장애에 대비해서 휘발성을 띄고 있는 CPU와 메모리에 쓰지 않는 것이다. 
 데이터가 수정이 되는 것은 Transaction Log에 입력 된 것이 확실 시 되었을 경우에만 쓰인다. Transaction Log의 핵심적인 역할이 바로 이것이다. Transaction Log에 변경 데이터가 기록이 되었으면 Transaction Manager는 해당 내용을 Access Methods에 전달해준다. 그리고 Access Methods는 완료된 해당사항을 Buffer Manager에게 전달한다. 

- Buffer Manager
 캐시에 가지고 있는 페이지는 수정된 데이터를 가지고 있어야한다. 그래서 Buffer Manager는 Access Methods에게 UPDATE가 수행 된 페이지를 요청합니다. 페이지는 캐시에서 수정되어 궁극적으로 Access Methods와 클라이언트에게 다시 보여주는 것이다. 
 여기서 중요한 점은 UPDATE로 변경된 DATA를 디스크가 아닌 Data Cache에 가지고 있는 것이다. 이것은 성능상의 이유로 Data Cache에 가지고 있는 것이며, 이러한 페이지는 Dirty Page라고 부른다. 우리가 기억해야 할 부분은 메모리에 있는 Dirty Page의 내용과 디스크가 가지고 있는 페이지의 내용이 불일치한다는 것이다. 만약 갑작스런 전원공급이 끊겼을 때, RAM에 가지고 있던 내용은 트랜잭션 로그에 남아있기 때문에 변경사항을 다시 작성할 수 있다. 이것이 바로 ACID의 속성인 내구성을 보장하는 방법이다.
 Buffer Manager는 데이터 캐시에 변경된 페이지 파일을 만들고 체인을 다시 구성한다. 

이렇듯 정상적으로 변경이 완료되면 SELECT와 마찬가지 프로세스로 다시 클라이언트에게 전달해준다.
UPDATE 내용 끝

Professional SQL Server 2012 Internals and Troubleshooting p.15-18

댓글 없음:

댓글 쓰기