트랜잭션 로그의 기록과 복구

출처 : Inside Microsoft SQL Server 2000
Windows Internals 와 비교해서 꽤 해석이 월활하게 되어 있습니다. 강추 드립니다...^______^!
SQL 2005버젼에서 변경된 내용을 동시에 이야기해 드릴 생각입니다.

DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까? (Checkpoint) (http://maystyle.tistory.com/221)
3. 로그는 어떻게 쓰여질까? (http://maystyle.tistory.com/223)
4. 트랜잭션 로그의 기록과 복구

트랜잭션 로그는 데이터베이스의 모든 변경 사항들을 기록하고, 시스템이 고장났을 경우 또는 App가 특별히 명령을 내렸을 때 변경된 내용들이 Roll back 되거나 Roll forward 될 수 있도록 변경된 정보를 저장한다. 데이터베이스 업데이트를 수행하는 모듈들은 변경 사항들을 정확히 기술하는 로그 항목들을 기록한다. 각 로그 항목들에는 고유한 값을 갖는 로그 시퀀스 번호(LSN) 라벨이 붙는다. 시스템 복구 동안에 트랜잭션의 모든 부분들이 Roll back가 Roll forward를 위해 쉽게 검색 될 수 있도록 동일한 트랜잭션의 일부가 되는 항목들은 서로 연결되어 있다.

버퍼 관리자는 변경된 데이터베이스가 기록되기 전에 트랜잭션 로그가 기록되게 한다. 이것이 가능한 것은 SQL Server가 LSN을 통해 로그에 현재 위치를 유지하기 때문이다. 페이지가 변경될 때마다 이 변경에 대한 로그 항목에 대응하는 LSN이 데이터 페이지의 해더에 기록된다. 페이지에 있는 LSN이 로그에 기록된 마지막 페이지의 LSN보다 작을 때만 변경된 페이지가 디스크에 기록될 수 있다. 버퍼 관리자는 로그 페이지들이 특정 순서로 기록되게 한다. 이것은 시스템이 고장났을 때 언제 고장 났는지 상관없이 어느 로그 페이지들이 처리되어야 하는지를 분명하게 알 수 있게 해준다. 트랜잭션을 위한 로그 레코드들은 커밋 통보가 클라리언트 프로세스에게 전달되기 전에 디스크에 기록되지만, 변경된 실제 데이터는 물리적으로 테이터 페이지에 기록되지 않았을 것이다. 따라서 로그에 기록하는 것은 동기적으로 이루어져야 하지만 (SQL Server는 로그가 디스크에 안전하게 있다는 것을 알 수 있도록 로그 기록이 완료되기를 기다려야한다.), 데이터 페이지에 기록하는 것은 비 동기적으로 이루어질 수 있다. 즉 데이터 페이지에 기록하는 것은 운영체제에게 게시될 필요만 있고, SQL Server는 나중에이 작업이 완료 되었는지 확인 할 수 있다. 로그가 작업을 취소하기 위해 필요한 모든 정보를 갖고 있기 때문에 데이터 페이지에 기록하는 작업은 즉시 완료될 필요가 없다. 이것은 쓰기 작업이 완료되기 전에 시스템이 고장날 경우에도 마찬가지이다. 시스템이 다음 작업을 하기전에 모든 I/O 요청들이 완료되기를 기다려야 한다면 시스템은 지금 보다 훨씬 더 느려질 것이다.

로그에는 각 트랜잭션의 시작과 끝을 구분하는 정보가 들어간다. 트랜잭션이 저장점을 사용할 경우에는 저장점 정보도 들어간다. 시작 정보와 끝 정보 중간에 데이터 변경에 관한 정보가 있다. 이정보는 실제 "before" 데이터와 "after" 데이터 값 형태로 되어 있을 수도 있다. 또는, 이 값들이 유추될 수 있도록 수행된 동작을 참조할 수도 있다. 일반적인 트랜잭션의 끝에는 Commit 레코드가 표시되는데 이것은 트랜잭션이 데이터베이스에 반영되어야 하거나, 필요할 경우에는 다시 수행되어야 한다는 것을 나타낸다. 사용자의 롤백(roll back)이나 리소스에러 등의 문제 때문에 일반 런타임 중에 취소된 트랜잭션은 처음 데이터 변경을 되돌리는 변경작업을 적용함으로써 실제로 동작을 취소한다. 이변경들에 대한 레코드는 로그에 기록되고 "compensation log records"로 표시된다. 트랜잭션이 커밋했지만 데이터가 데이터 페이지에 기록되기 전에 시스템이 고장나면 트랜잭션이 복구되어야 한다. 복구 과정은 시스템 시작시에 자동으로 실행된다. 복구는 시스탬 시작 시의 기능이다. 그러나 복구는 백업된 데이터배이스를 불러들이는 마지막 단계 동안에도 실행되고, 수동으로 강제적으로 실행될 수 있다.

복구는 재실행 동작과 취소 동작 모두를 수행한다. 재 실행 동작에서 로그는 조사되고 변경된 것들은 이미 데이터베이스에 반영되었는지 검사한다. 변경된 내용이 데이터베이스에 없으면 로그에 있는 정보를 사용하여 적용 동작이 다시 수행된다. 트랜잭션이 완전하게 완료되지 않았다면 취소할 때 트랜잭션에 의해 부분적으로 변경된 것들이 제거되어야 한다.

복구 과정 동안에 마지막 검사점 이후에 일어났거나 진행중인 변경사항들만이 재실행되거나 취소된다. 복구 알고리즘에는 세 단계가 있고, 이단계들은 트랜잭션 로그에 있는 마지막 검사점 레코드를 중심으로 하여 있다.

복구 계획
1 단계 : 분석
첫번째 단계는 트랜잭션 로그에 있는 마지막 검사점 레코드에서 시작하여 앞으로 진행하는 것이다. 이 단계는 시스템 정지 시에 변경되어 있었을 수도 있는 페이지들로 구성된 DPT(dirty page table)을 알아내고 구성한다. 시스템 정지 시에 커밋되지 않은 트랜잭션들로 구성된 활성 트랜잭션 테이블이 만들어진다.
2 단계 : 재실행
이 단계는 데이터베이스를 시스템 정지 시의 상태로 되돌린다. 이 포워드 진행의 시작 지점은 DPT에 있는 모든 LSN들의 최소값이다. 복구될 필요가 없는 페이지들을 읽는 것을 피하고 로그에 기록되기 않은 변경 사항들을 덮어쓴느 것을 피하기 위해 DPT가 사용된다.
3 단계 : 취소
이 단계는 각 트랜잭션 마다 트랜잭션 로그에 있는 항목들간의 연결을 따라가면서 로그의 끝에서부터 뒤쪽 방향으로 움직인다. 시스템 정지 시에 커밋되지 않은 트랜잭션은 취소된다. 이것은 변경된 내용들이 실제로 데이터베이스에 반영되지 않도록 하기 위한 것이다.