모든 트랜잭션을 랩핑하는 일부 저장 프로 시저를 보았습니다.SQL Server 트랜잭션 로그 잘림/축소
begin transaction
update
table
set
column c = (column a * column b)
commit
트랜잭션 로그를 관리하는 것이 올바른 방법입니까? 몇 가지 저장 프로 시저를 사용해 보았지만 로그가 손에 닿지 않는 것처럼 보입니다. 여러 개의 업데이트/삽입/변경 문이 포함 된 저장 프로 시저를 실행할 때 트랜잭션 로그를 관리하는 가장 좋은 방법은 무엇입니까?
도움을 주시면 대단히 감사하겠습니다.
트랜잭션 문의 또는 복구 모델에서 쿼리가 암시 적으로 래핑되는지 여부에 관계없이 SQL 트랜잭션이 로깅됩니다. 복구 모델에 따라 트랜잭션은 로그에 남아 있거나 (전체 복구 모드) 또는 잘립니다 (단순 복구 모드). 로그를 자르는 모드에 관계없이 파일 크기가 줄어들지 않습니다.
로그 관리는 일반적으로 응용 프로그램 내에서 SQL 쿼리에서 처리되는 것이 아니라 DBA 작업입니다.
트랜잭션은 실패시 복구가 가능하도록 저장됩니다. 마지막 백업 이후에 트랜잭션을 단계별로 실행하여 해당 시점의 데이터를 다시 작성할 수 있습니다. 단순 복구 모드는 트랜잭션이 성공적인 실행 (COMMIT)시 즉시 절단되므로이를 허용하지 않습니다.
로그는 일반적으로 백업시 잘리고 줄어 듭니다. SQL 유지 보수 작업을 작성하여이를 관리 할 수 있습니다.
로그는 쿼리에 명시된 TRANSACTION 개의 숫자와 직접적인 관련이 없습니다. It's related to your recovery model. 명시적인 TRANSACTION 문은 요청시 롤백 또는 커밋하기 위해 로그를 사용합니다.
또한 COMMIT 또는 ROLLBACK이없는 BEGIN TRANSACTION이 있기 때문에 코드에 오류가 발생합니다.
트랜잭션에서 이것을 감쌀 필요가 없습니다. 하나의 명령.을 실행하여 성공하거나 실패합니다.
두 번째 테이블을 업데이트 할 때 데이터를 일관성있게 유지하려면 두 테이블 모두를 필요로하는 경우이 방법을 고려할 수 있습니다.
그러나 .. 트랜잭션 로그 파일의 크기는 백업 될 때까지 커집니다. 데이터베이스가 작 으면 데이터베이스 복구 옵션을 단순으로 설정하고 매일 밤 전체 데이터베이스를 백업하려는 경우 트랜잭션 로그 파일을 자릅니다.
복구를 단순으로 설정하는 것을 제외하고는 실패한 데이터가 손실 될 수 있습니다. 대부분의 응용 프로그램이 트랜잭션 로그 백업을 시작하는 것이 좋습니다. 우리는 15 분마다 데이터를 잃을 수있는 회사가 될 수 없기 때문에이를 수행합니다. – HLGEM
@divided, 데이터베이스를 백업하는 것이 트랜잭션 로그를 백업하지 않는다는 것을 명확히하기 위해 별도의 트랜잭션 로그 백업이 필요합니다. – HLGEM
물론 당신 말이 맞습니다. 나는 계속해서 설명 할 것이지만 빠른 타이피스트들의 압박감을 느끼고 있었다. 위의 Dustin의 답변이 아마도 내가 배운 이유 중 가장 완벽 할 것입니다. 그러나 모든 개발자가 데이터베이스 관리를위한 DBA의 명성을 누리고있는 것은 아닙니다. –
감사합니다. 방금 '커밋'대신 '끝'을 입력 한 것으로 나타났습니다. – divided