트랜잭션 로그의 크기를 50GB로 미리 할당 한 여러 대의 컴퓨터가 있습니다. 재구성하려고하는 테이블의 크기는 55-60GB이지만 계속 증가 할 것입니다. 내가 재구성하고 싶은 주된 이유는 공간을 확보하고 그로 인해 성능상의 이점이 추가 보너스이기 때문입니다.
테이블의 조각화 수준은 30-35 %입니다. 이 컴퓨터 중 일부에서 "트랜잭션 로그 가득 참"오류가 발생하고 재구성이 실패합니다. 트랜잭션 로그 크기는 최대 48gb에 이릅니다. 이것에 반하는 좋은 방법은 무엇입니까? 자동 증분이 설정되어 있지 않으며 사용을 꺼려합니다.
로그 크기를 더 큰 값으로 늘릴 수 있지만 나중에 테이블 크기가 커지면 값이 충분하지 않을 수 있습니다. 또한 로그 크기를 동일하게 늘리면 공간을 확보하기 위해 재구성을 수행하는 목적을 상실합니다. 어떻게 효과적으로 대응할 수 있습니까? 데이터 손실이 허용되지 않으므로 벌크 모드를 사용하는 것은 옵션이 아닙니다.
답변:
모범 사례 는 REORGANIZE약 30 % 미만의 단편화와 그 REBUILD이상입니다. 간단히, REBUILD깨끗한 사본을 만들고 REORGANIZE현장에서 수행합니다.
실제로하고있는 일을 확인하십시오. 유지 보수 계획이 없으십니까?
더 큰 테이블 (50GB 테이블이 도착 함) REORGANIZE에서이 규칙을 따르면 모든 트랜잭션 로그 공간을 사용하는 것을 보았습니다 . 자주 발생하지 않음 : 특정로드 패턴을 가진 시스템 하나만 REORGANIZE로그까지 단지 RAN은 확장 된 모든 디스크 공간을 소비했다.
우리는 REBUILD더 이상 문제없이 대신 전환 했지만 25 % 미만의 조각화는 무시했습니다. 이것은 우리를 위해 더 잘 작동했습니다 : 그것이 당신에게 효과가 있는지 확인해야합니다.
REBUILDREORGANIZE프로덕션 환경 보다 성능에 더 많은 영향을 미칠 수 있지만 때로는 ONLINE옵션 (엔터프라이즈 판 필요)을 사용하여 완화 할 수 있습니다 .
REORGANIZE (ALTER INDEX ... REORGANIZE에서와 같이)는 매우 빠른 작업 (주로 대부분은 ...)으로, 적은 양의 로그가 필요하며 언제든지 중단하고 나중에 다시 시작할 수 있으며 소규모 배치 트랜잭션 에서 내부적으로 작동 합니다 .
조각 모음은 일련의 짧은 트랜잭션으로 수행되므로 로그 백업을 자주 수행하거나 복구 모델 설정이 SIMPLE 인 경우 큰 로그가 필요하지 않습니다.
재건 에 대해 이야기하고 있지 않습니까? 인덱스 REBUILD는 느리고 비싸며 엄청난 양의 로그를 사용합니다 (오프라인이 아니고 최소로 기록 할 수없는 경우 온라인 재 구축을 최소로 기록 할 수없는 경우).
당신이 재건을하고있는 것처럼 보입니다. 이것은 당신이 매우 잘 생각한 이유가 없다면하지 말아야 할 정말로 예외적 인 작업입니다. 어떤 종류의 공간 회수를 원하십니까? 아무것도 DBCC CLEANTABLE처리하지 않습니다? 테이블 물리적 구조를 점검 했습니까? 논리적 구조에서 벗어 났 습니까 (자세한 내용 은 후드 아래의 SQL Server 테이블 열 참조)?
실제로 테이블을 다시 작성 해야하는 경우 총알을 물고 필요한 로그를 할당하는 것 외에는 선택의 여지가 없습니다. 자동으로 자라게하지 마십시오. 프로세스 속도가 느려집니다. 테이블 크기의 2.5 배로 미리 자릅니다.
테이블이 파티션 된 경우 한 번에 하나의 파티션을 오프라인으로 재구성 (및 재구성) 할 수 있습니다. 온라인 재 구축은 전체 테이블 수준에서만 수행 할 수 있습니다.
나는 전에이 문제를 겪었다.
재구성을 중단하면 중단 된 부분부터 계속할 수 있다는 것을 알기 때문에 중단은 롤백이 아니라 트랜잭션을 커밋한다는 것입니다.
여기 당신이하는 일이 있습니다. 조금 길지만 간단합니다.
성능 조건에서 에이전트 WMI 경보 ( '릴리프 밸브 재구성')를 작성하십시오.
작업 만들기 ( '재구성 검사')
개발 샌드 박스를 포함한 모든 곳에서 테스트하여 프로덕션 서버에 고정하기 전에 제대로 수행되는지 확인하십시오.
'재구성'작업이 시작되고 로그가 채워지기 시작합니다. 로그가 꽉 찼을 때 다른 작업을 실행하는 WMI 경고 (약 30 초 이내)를 트리거하여 '재구성'작업이 실행 중이고 오류가 발생했을 가능성이 있음을 확인합니다. 그런 다음 '재구성'을 중지하고 백업을 수행 한 후 로그 여유 공간이 적절한 값으로 돌아 왔는지 확인한 다음 '재구성'작업을 다시 시작하여 중단 된 부분을 선택합니다.
따라서이 시나리오에서 로그 크기를 합리적인 크기로 미리 조정하는 이유는 증가 / 트리거 / 작업 / 중지 / 다시 시작 횟수를 줄여서보다 효율적이고 공간을 충분히 확보 할 수 있기 때문입니다. 때때로 잡히지 않는 성장.
이것은 이상한 시나리오입니다. 나는 몇 년 전에이 문제에 봉착했을 것이라고 확신하며 여기에는 근본적인 근본적인 문제가 있습니다. 그러나 수백 대의 서버를 처리하는 경우 MacGyvering이 작업을 수행하는 임시 솔루션을 제외하고 어떤 이유로 든 처리 할 수없는 이와 같은 몇 가지 경우가 발생할 수 있습니다.
안전하고, 논리적이며, 테스트되고, 잘 문서화되어 있으면 문제가 없습니다.
이것은 인덱스 reorg에 대해 일반적으로 한 일입니다 (인덱스 reorg는 이전 reorg 작업을 잃지 않고 언제든지 중지 할 수 있기 때문에).
인덱스 유지 관리 프레임 워크에서 인덱스를 두 그룹으로 분류합니다. 하나는 인덱스 재구성을위한 것이고 다른 하나는 인덱스 재구성을위한 것입니다. 인덱스 다시 작성의 경우 인덱스 다시 작성 세션을 중지하지 않기 때문에 다소 다른 방법을 사용합니다 (롤백이 발생하고 이전의 모든 작업이 손실 됨). 인덱스를 다시 작성하는 동안 모니터링 세션에 사용 된 tlog 파일 여유 공간이 시나리오에 표시되면 모니터링 세션이 tlog 파일을 자동으로 증가 시키며 최악의 시나리오 (예 : 디스크가 가득 참)에서는 모니터링 세션이 다른 로그 파일을 생성합니다 ( 나중에 다른 드라이브 (백업 드라이브)에 드롭합니다.
질문 작성자와 같은 문제가 있었으며 그의 의견을 보면 동일한 설정이 있다고 말할 수 있습니다. 을 시도하는 동안 REORGANIZE로그는 크기에 관계없이 전체 테이블 크기의 여러 배까지 전체 크기로 커집니다.
트랜잭션 복제 로 인해 문제가 발생했습니다 . 분명히 REORGANIZE작업이 완료 될 때까지 로그를 백업 할 수 없습니다 . Microsoft에서 알려진 문제인 곳을 읽었지만 어디에 있는지 잘 모르겠습니다.
트랜잭션 복제를 비활성화하면 로그 백업이 다시 정상적으로 작동하고 30 초마다 로그 백업을 수행하는 동안 재구성이 효과적이었습니다.
나는 당신이 다음 라인을 따라 무언가를 실행하고 있다고 가정합니다 :
재구성에 대한 색인 변경
불행히도 부분 구성을 실행할 수있는 방법은 없습니다 (예를 들어 로그 파일을 부분적으로 축소 할 수있는 방법). 이 문제를 해결할 수있는 방법은 다음과 같습니다.
1) 재구성을 실행하는 동안 데이터베이스를 단순 복구 모드로 설정하십시오.
2) 인덱스 분할-대략 같은 크기의 파티션을 얻기 위해 인덱스를 분할하는 방법을 생각할 수 있으면 각 파티션을 독립적으로 재구성 (또는 온라인 옵션으로 다시 작성)하여 로그 파일 증가를 제한 할 수 있습니다.
이 작업을 수행하고 있다고 확신하지만 그렇지 않은 경우 인덱스 최적화를 수행하기 전후에 로그 파일 백업을 시작하여 사용 된 공간을 회수 할 수 있습니다.