답변:
""쿼리 실행에 실패했습니다. "페이지 수준 잠금이 비활성화되어" "" "테이블의" "(파티션 1) 인덱스를 재구성 할 수 없습니다."
유지 보수 계획은 온라인 작업 인 ALTER INDEX REORGANIZE를 시도해야합니다. 조각화 (페이지 순서가 아님)를 제거하려면 페이지를 잠그고 이동해야합니다. 이는 페이지 잠금이 비활성화 된 경우에는 불가능합니다. 페이지 잠금없이 조각 모음을 수행하는 유일한 방법은 전체 파티션을 잠그는 것입니다. 온라인에서만 REORGANIZE를 사용할 수 없습니다.
두 잠금 방식의 차이점은 무엇이며 실제 (생산 중) 결과는 무엇입니까?
특정 잠금 유형을 허용하지 않을 때의 영향을 평가하려면 레코드 및 페이지가 무엇인지 파악해야합니다. SQL Server 스토리지 내부에 익숙하지 않은 경우 레코드 분석 및 페이지 분석으로 시작하십시오 . 간단히 말해서 :
허용 된 잠금 유형을 변경하려는 경우 :
잠금 유형을 허용하지 않는 것이 유리한 위치를 알고있는 두 가지 시나리오가 있습니다. 타인이 없다는 것을 의미하지는 않지만 다른 사람들이 모범을 보이기를 바랍니다.
자주 변경되지 않는 자주 찾는 조회 테이블 -페이지 및 행 레벨 잠금을 모두 사용 안함으로 설정하면 모든 독자가 공유 테이블 잠금을 사용합니다. 이것은 테이블에서 일반적인 인 텐트 공유보다는 페이지에서 인 텐트 공유 및 마지막으로 특정 행에서 공유 잠금보다 빠르거나 저렴합니다.
특정 교착 상태 시나리오 방지 -동일한 페이지에 자주있는 잠금을 획득하는 동시 프로세스로 인해 교착 상태가 발생하면 행 잠금을 허용하지 않고 대신 페이지 잠금이 수행됩니다. 한 번에 한 프로세스 만 페이지에 액세스 할 수 있으며 다른 프로세스는 기다려야합니다.
첫 번째 예는 미세 최적화이며 일반적인 시스템에서 측정 가능한 이점을 얻지 못할 것입니다. 두 번째는 특정 교착 상태 시나리오를 해결하지만 다른 코드 섹션에서 동시성 종료와 같은 예기치 않은 부작용이 발생할 수 있습니다. 영향을 완전히 평가하기 어렵고 조심스럽게 접근하십시오!
기본값은 둘 다 사용하도록 설정되어 있으며 적절한 원인없이 변경 하면 안됩니다 .
아마 아무것도 아닙니다. 나는 MS가 당신이나 나보다 더 잘 알고 있다고 확신한다
대용량 OLTP 시스템에서 작업 한 적이 있으며 설정을 변경할 필요가 없습니다. 교착 상태는 어쨌든 발생할 수 있으므로 재 시도해야합니다.
SQL Server Storage Engine 블로그 에서 인용 한 " SQL 2005의 잠금 에스컬레이션" n은 어쨌든 완전히 읽을 가치가 있습니다.
기본적으로 ROW 및 PAGE 잠금이 모두 활성화되어 있습니다. SQL Server는 대부분의 경우 ROW 잠금 단위를 선택하지만 적절한 경우 PAGE 잠금을 선택할 수 있습니다. 따라서 지정한 경우 ROW 잠금이 가능합니다. 데이터베이스 또는 인스턴스 레벨에서 PAGE 잠금을 해제 할 방법이 없습니다. PAGE 잠금으로 인해 차단이 발생합니까?
나는 당신이 행락을 강요한다면 다른 곳에서 더 효과적으로 사용될 수있는 자원을 소비 할 것이라고 생각한다. 부하가 중요 할 정도로 높으면 왜 메모리를 소비합니까? 블로그 기사는 이것에 들어갑니다
나는 이것처럼 뒤에 미신이 있다고 생각합니다.