전체 백업에도 불구하고 트랜잭션 로그 (2008 R2)가 매우 빠르게 증가하는 데 문제가 있습니다. SQL 프로파일 러에서 rowcount를 사용하여 모든 Insert, Delete 및 Update 문을 캡처하는 추적을 실행했으며 모두 매우 낮았습니다.t-sql 트랜잭션 로그 열기. SP로 인한 발견 원인
서버에서 실행되는 앱 중 많은 수가 SP를 사용하고 행 개수가 꺼져있어 어느 것이 대규모 업데이트, 삽입, 삭제 작업을하는지 볼 수 없습니다 (몇 가지가 있지만 몇 가지가 있음을 알고 있습니다. SP의 대부분은 타사 응용 프로그램의 일부입니다). 이걸 추적하는 가장 좋은 방법은 뭔가? 나는 다른 문제는 삽입, 업데이트 제외가 실현
, 즉립니다 로그 성장 여부를 발생할 수 있습니다 삭제,하지만 난
어떤 제안 (내가 할 수있는 경우) 다음을 배제하고 싶습니다?
TIA
마크 (전체 백업에도 불구하고) 매우 빠르게 성장
트랜잭션 로그 (2008 R2) 전체 백업 로그를 자르지 을하기 때문에 것
. 로그 백업 만 로그를 자릅니다. 이 Myth 30-05로 알려져있다 :
30-05) 전체 또는 차등 백업은
번호는 로그 백업은 마지막 로그 백업 이후의 모든 로그를 포함 로그를 지 웁니다 - 아무것도 그것을 변경할 수 있습니다 - 로그가 전체 또는 차등 백업으로 백업되었는지 여부에 관계없이 작년에 트위터에 대한 유명한 논쟁이 있었고이 블로그 게시물을 증거로 썼습니다 : Misconceptions around the log and log backups: how to convince yourself. FULL 또는 BULK_LOGGED 복구 모델에서 만 로그를 지우는 것은 로그 백업입니다.
로그 증가를 조사하기 위해 일반적인 장소를 먼저 확인해야합니다 : log_reuse_wait.
그래, 언급 한 것처럼, 롤. 전체 백업이 사용자의 tlog를 지우지 않습니다. tlog의 크기를 줄이려면 tlog 백업을 수행해야합니다.
첫 번째로, 얼마나 자주 tlogs를 백업합니까? 아니면 전혀 돌려 주겠습니까? tlog 크기를 확인하는 유일한 방법은 tlog가 단순 복구 모드에 있는지 확인하는 것입니다 (권장되지 않음, 재해 발생시 특정 시점으로 데이터베이스를 복원 할 수 없음)
또는
정기적으로 유지 관리의 일환으로 tlog를 백업하고 멋지고 깔끔하게 유지하십시오. 여전히 응용 프로그램이 대량 트랜잭션을 수행하는 경우가 있습니다. 이로 인해 tlog가 큰 크기로 커질 수는 있지만, 80 % 또는 85 %와 같이 도달하면 tlog를 백업하는 일종의 유지 관리 작업을 갖는 것이 중요한 이유입니다. 현재 크기의.
죄송합니다. 전체 백업이 아닌 로그 백업을 작성하려고합니다. – mark1234
'log_reuse_wait '에 무엇이 있습니까? –