[IT168 서버 아카데미] 트랜잭션 로그는 매우 중요하지만 데이터베이스 구조에서 종종 무시되는 부분입니다. 데이터베이스의 스키마만큼 활발하지 않기 때문에 트랜잭션 로그에 주의를 기울이는 사람은 거의 없습니다.
트랜잭션 로그는 데이터베이스 변경 사항에 대한 기록으로, 데이터베이스에 대한 모든 작업을 기록하고 기록 결과를 별도의 파일에 저장할 수 있습니다. 모든 트랜잭션 프로세스에 대해 트랜잭션 로그에는 매우 포괄적인 기록이 있으며, 이러한 기록을 기반으로 데이터 파일을 트랜잭션 전 상태로 복원할 수 있습니다. 트랜잭션 작업 시작부터 트랜잭션 로그는 기록 상태입니다. 트랜잭션 중 데이터베이스에 대한 모든 작업은 사용자가 제출 또는 뒤로를 클릭할 때까지 기록이 완료되지 않습니다. 각 데이터베이스에는 최소한 하나의 트랜잭션 로그와 하나의 데이터 파일이 있습니다.
성능상의 이유로 SQL Server는 사용자 변경 사항을 캐시에 저장합니다. 이러한 변경 사항은 트랜잭션 로그에 즉시 기록되지만 데이터 파일에는 기록되지 않습니다. 트랜잭션 로그는 표시 지점을 사용하여 트랜잭션이 캐시의 데이터를 데이터 파일에 기록했는지 여부를 확인합니다. SQL Server가 다시 시작되면 로그의 최신 표시 지점을 확인하고 이 표시 지점 이후의 트랜잭션 레코드를 지웁니다. 왜냐하면 이러한 트랜잭션 레코드는 실제로 캐시의 데이터를 데이터 파일에 쓰지 않기 때문입니다. 이렇게 하면 중단된 트랜잭션이 데이터 파일을 수정하는 것을 방지할 수 있습니다.
트랜잭션 로그 유지
많은 사람들이 트랜잭션 로그를 잊어버리는 경우가 많기 때문에 시스템에 일부 문제가 발생할 수도 있습니다. 시스템이 계속 실행됨에 따라 점점 더 많은 로그 기록이 기록되고 로그 파일의 크기도 점점 커지므로 결국 사용 가능한 디스크 공간이 부족해집니다. 일상 작업에서 로그를 자주 정리하지 않으면 결국 로그 파일이 파티션에서 사용 가능한 모든 공간을 차지하게 됩니다. 로그의 기본 구성은 무제한 용량입니다. 이 구성에서 작업하면 로그가 계속 확장되어 결국 사용 가능한 모든 공간을 차지하게 됩니다. 두 상황 모두 데이터베이스 작동이 중지될 수 있습니다.
트랜잭션 로그를 정기적으로 백업하면 로그 파일이 과도한 디스크 공간을 소비하는 것을 효과적으로 방지할 수 있습니다. 백업 프로세스에서는 더 이상 필요하지 않은 로그 부분을 자릅니다. 잘라내는 방법은 먼저 이전 레코드를 비활성으로 표시한 다음 이전 로그 위치에 새 로그를 덮어써서 트랜잭션 로그의 크기가 커지는 것을 방지하는 것입니다. 정기적인 로그 백업을 수행할 수 없는 경우 데이터베이스를 "단순 복구 모델"로 설정하는 것이 가장 좋습니다. 이 모드에서 시스템은 표시 지점이 기록될 때마다 트랜잭션 로그를 자동으로 잘라내어 기존 로그를 새 로그로 덮어씁니다.
잘림 프로세스는 이전 포인트를 백업하거나 비활성으로 표시할 때 발생합니다. 이를 통해 이전 트랜잭션 레코드를 덮어쓸 수 있지만 트랜잭션 로그가 차지하는 실제 디스크 공간은 줄어들지 않습니다. 로그가 더 이상 사용되지 않더라도 여전히 일정량의 공간을 차지합니다. 따라서 유지 관리 중에 트랜잭션 로그도 압축해야 합니다. 비활성 레코드를 삭제하여 트랜잭션 로그를 압축하므로 로그 파일이 차지하는 물리적 하드 드라이브 공간이 줄어듭니다.
DBCC SHRINKDATABASE 문을 사용하여 현재 데이터베이스의 트랜잭션 로그 파일을 압축할 수 있습니다. DBCC SHRINKFILE 문을 사용하여 지정된 트랜잭션 로그 파일을 압축할 수도 있습니다. 또한 데이터베이스에서 자동 압축 작업을 활성화할 수도 있습니다. 로그가 압축되면 오래된 레코드가 먼저 비활성으로 표시된 다음 비활성으로 표시된 레코드가 완전히 삭제됩니다. 사용된 압축 방법에 따라 결과가 즉시 표시되지 않을 수도 있습니다. 이상적으로는 시스템 사용량이 많지 않은 기간에 압축 작업을 수행해야 합니다. 그렇지 않으면 데이터베이스 성능에 영향을 미칠 수 있습니다.
데이터베이스 복원
트랜잭션 레코드 백업을 사용하여 데이터베이스를 지정된 상태로 복원할 수 있지만 트랜잭션 레코드 백업 자체만으로는 데이터베이스 복원 작업을 완료하기에 충분하지 않으며 백업된 데이터 파일도 복구 작업에 참여해야 합니다. 데이터베이스를 복원할 때 첫 번째 단계는 데이터 파일을 복원하는 것입니다. 전체 데이터 파일이 복원될 때까지 전체 데이터 파일을 완료 상태로 설정하지 마십시오. 그렇지 않으면 트랜잭션 로그가 복원되지 않습니다. 데이터 파일 복구가 완료되면 시스템은 트랜잭션 로그 백업을 통해 데이터베이스를 사용자가 원하는 상태로 복원한다. 데이터베이스의 마지막 백업 이후 여러 로그 파일의 백업이 있는 경우 백업 프로그램은 해당 파일을 생성된 시간에 따라 순서대로 복원합니다.
로그 전달이라는 또 다른 프로세스는 더 강력한 데이터베이스 백업 기능을 제공할 수 있습니다. 로그 전달이 구성되면 전체 데이터베이스를 다른 서버에 복사할 수 있습니다. 이 경우 데이터 복구를 위해 트랜잭션 로그도 정기적으로 백업 서버로 전송됩니다. 이렇게 하면 서버가 핫 백업 상태로 유지되어 데이터가 변경되면 업데이트됩니다. 다른 서버는 모니터 서버라고 하며 지정된 간격으로 전송되는 배송 신호를 모니터링하는 데 사용할 수 있습니다. 지정된 시간 내에 신호가 수신되지 않으면 모니터링 서버는 이 이벤트를 이벤트 로그에 기록합니다. 이 메커니즘을 사용하면 재해 복구 계획에서 로그 전달이 자주 사용됩니다.
성능 최적화
트랜잭션 로그는 데이터베이스에서 중요한 역할을 하며 시스템의 전반적인 성능에도 일정한 영향을 미칩니다. 여러 옵션을 통해 트랜잭션 로그의 성능을 최적화할 수 있습니다. 트랜잭션 로그는 지속적인 디스크 쓰기 프로세스이므로 이 프로세스 중에는 읽기가 발생하지 않습니다. 따라서 로그 파일을 독립 디스크에 배치하면 성능 최적화에 일정한 역할을 합니다.
또 다른 최적화 방법은 로그 파일 크기와 관련이 있습니다. 로그 파일의 크기를 하드 디스크 공간의 몇 퍼센트를 초과하지 않도록 설정하거나 크기를 결정할 수 있습니다. 너무 높게 설정하면 디스크 공간이 낭비되고, 너무 작게 설정하면 로그 파일이 계속해서 확장을 시도하게 되어 데이터베이스 성능이 저하된다.
트랜잭션 로그 파일 트랜잭션 로그 파일은 데이터베이스 업데이트를 기록하는 파일로, 확장자는 ldf이다.
SQL Server 7.0 및 SQL Server 2000에서 자동 증가 기능이 설정되면 트랜잭션 로그 파일이 자동으로 확장됩니다.
일반적으로 트랜잭션 로그의 크기는 검사점이나 트랜잭션 로그 백업에 의해 트리거되는 트랜잭션 로그 잘림 사이에 발생하는 최대 트랜잭션 수를 수용할 수 있을 때 안정적입니다.
그러나 경우에 따라 트랜잭션 로그가 너무 커져서 공간이 부족하거나 가득 찰 수도 있습니다. 일반적으로 트랜잭션 로그 파일이 사용 가능한 디스크 공간을 가득 채우고 더 이상 확장할 수 없으면 다음과 같은 오류 메시지가 표시됩니다.
오류:9002, 심각도:17, 상태:2
데이터베이스 '%.*ls'의 로그 파일이 꽉 찼습니다.
이 오류 메시지 외에도 SQL Server는 트랜잭션 로그 확장 공간 부족으로 인해 데이터베이스를 SUSPECT로 표시할 수 있습니다. 이 상황에서 복구하는 방법에 대한 자세한 내용은 SQL Server 온라인 도움말의 "디스크 공간 부족" 항목을 참조하세요.
또한 트랜잭션 로그 확장으로 인해 다음과 같은 상황이 발생할 수 있습니다.
· 매우 큰 트랜잭션 로그 파일.
· 트랜잭션이 실패하고 롤백이 시작될 수 있습니다.
· 거래를 완료하는 데 시간이 오래 걸릴 수 있습니다.
· 성능 문제가 발생할 수 있습니다.
· 막힘이 발생할 수 있습니다.
원인 다음과 같은 이유 또는 상황으로 인해 트랜잭션 로그 확장이 발생할 수 있습니다.
· 커밋되지 않은 트랜잭션 · 매우 큰 트랜잭션 · 작업: DBCC DBREINDEX 및 CREATE INDEX
· 트랜잭션 로그 백업에서 복원하는 경우 · 클라이언트 응용 프로그램이 모든 결과를 처리하지 않습니다. · 트랜잭션 로그 확장이 완료되기 전에 쿼리 시간이 초과되고 잘못된 "로그 가득 참" 오류 메시지가 표시됩니다. · 로그 파일 확장으로 인해 복제되지 않은 트랜잭션 해결이 발생합니다. full SQL 데이터베이스가 파일에 쓸 수 없는 경우 다음 두 가지 방법을 사용할 수 있습니다.
한 가지 방법은 로그를 지우는 것입니다.
1. 쿼리 분석기를 열고 DUMP TRANSACTION 데이터베이스 이름 WITH NO_LOG 명령을 입력합니다.
2. Enterprise Manager를 다시 엽니다. 압축하려는 데이터베이스를 마우스 오른쪽 버튼으로 클릭합니다. 모든 작업-데이터베이스 축소-파일 축소-로그 파일 선택-축소 모드에서 XXM으로 축소를 선택하고 여기에 축소 권한이 부여됩니다. 최소 개수 M에 도달하려면 이 숫자를 직접 입력하고 확인하세요.
다른 방법은 SQL SERVER의 로그 파일이 기본 데이터베이스 파일에 즉시 기록되지 않기 때문에 특정 위험이 있습니다. 제대로 처리되지 않으면 데이터가 손실됩니다.
1: 로그 삭제
데이터베이스 분리 Enterprise Manager -> 서버 -> 데이터베이스 -> 마우스 오른쪽 버튼 클릭 -> 데이터베이스 분리 2: 로그 파일 삭제 데이터베이스 첨부 Enterprise Manager -> 서버 -> 데이터베이스 -> 마우스 오른쪽 버튼 클릭 -> 데이터베이스 연결 이 방법은 새로운 로그를 생성합니다. 500K가 넘습니다.
참고: 첫 번째 방법을 사용하는 것이 좋습니다.
앞으로는 더 커지는 걸 원하지 않는다면요.
SQL2000에서 사용됨:
데이터베이스->속성->옵션->실패 복구-모델-선택-단순 모델을 마우스 오른쪽 버튼으로 클릭합니다.
또는 SQL 문을 사용하십시오.
데이터베이스 데이터베이스 이름 설정 복구 단순 변경
또한 위 그림에 표시된 것처럼 데이터베이스 속성에는 트랜잭션 로그 증가와 관련된 두 가지 옵션이 있습니다.
체크포인트에서 로그 자르기
(이 옵션은 SQL7.0에서 사용된다. SQL 2000에서는 단순 모델로 장애 복구 모델이 선택된다.)
CHECKPOINT 명령을 실행하면 트랜잭션 로그 파일의 내용이 크기의 70%를 초과하면 지워집니다. 데이터베이스를 개발할 때 이 옵션을 항상 True로 설정하세요.
자동 축소
데이터베이스를 정기적으로 확인하십시오. 데이터베이스 파일 또는 로그 파일의 사용되지 않은 공간이 해당 크기의 25%를 초과하면 시스템은 파일 크기가 초기 크기를 초과하지 않을 때 사용되지 않은 공간을 25%로 자동으로 줄입니다. 축소된 파일은 원래 크기보다 크거나 같아야 합니다. 트랜잭션 로그 파일 축소는 백업할 때나 검사점에서 로그 잘라내기 옵션이 True로 설정된 경우에만 수행할 수 있습니다.
참고: 일반적으로 Li Cheng이 생성한 데이터베이스의 기본 속성이 설정되어 있지만 예상치 못한 상황이 발생할 경우 데이터베이스 속성이 변경됩니다. 트랜잭션 로그가 발생하지 않도록 로그를 지운 다음 위의 데이터베이스 속성을 확인하세요. 다시 채워요.