SQL Server 2000에서 SQL Server 2008로 데이터베이스 집합을 업그레이드했는데 이제는 큰 읽기가 쓰기를 차단합니다. 반면 SQL Server 2000에서는 문제가 없었습니다 (동일한 데이터베이스와 동일한 응용 프로그램 &보고) 왜? 2008 년의 다른 설정은 무엇입니까? 커밋되지 않은 트랜잭션을 읽으려면 기본적으로 2000이 기본값입니까?SQL Server 2008 쓰기 차단 쓰기
(업데이트) 문제의 보고서보기에 (nolock)을 추가하면 단기적으로 문제가 해결됩니다. 장기적으로 볼 때 스냅 샷 또는 손으로보고 할 데이터의 복사본을 만들어야합니다. [sigh] 나는 여전히 SQL Server 2008이 무엇을 필요로하는지 알고 싶습니다.
(업데이트 2) 문제의보기가 보고서에 사용되기 때문에 '미승인 읽기'가 지금은 괜찮습니다.
SQL Server 2000은 기본적으로 READ UNCOMMITTED을 사용하지 않았습니다.
실행 계획의 최적화가 변경되었을 수 있습니다. 일부 인덱스는 SQL Server 2000의 인덱스와 다른 순서로 잠길 수 있습니다. 또는 SQL Server 2008에서는 SQL Server 2000이 해당 쿼리에 대해 모두 무시하고있는 인덱스를 사용하고 있습니다.
자세한 정보없이 진행되는 작업은 정확히 말하기 어렵지만 잠금 유형을 읽고 두 충돌하는 쿼리의 실행 계획을 확인하십시오. 상황이 교착 상태에 빠질 수있는 또 다른 예를 설명하는 멋진 short article이 있습니다.
읽기 커밋은 읽기 전용이 아닌 SQL Server 2000의 기본 격리 수준입니다. 아마도 연결 개체의 속성 중 하나를 통해 -
http://msdn.microsoft.com/en-us/library/aa259216(SQL.80).aspx
나는 앱에서 뭔가 격리 수준을 설정하는 것을 상상한다. ADO, ODBC 및 OLE DB를 통해 트랜잭션 격리 수준을 설정하는 데 사용되는 방법은 here입니다.
SQL Server 2008에서도 동일한 작업을 수행 할 수 있지만 응용 프로그램이 커밋되지 않은 상태에서 실행되어야합니까? 앱이 데이터 이동 및 팬텀 읽기를 처리하도록 특별히 설계 되었습니까?
SQL Server 2000에서 문제가 발생하지 않은 것은 사실 놀랍습니다. 매주 잠금을 해제하는 저장 프로 시저가 수정 된 것 같습니다. 누가 잠금을 잊었 기 때문입니다.
그래서 우리는 단지 운이 좋았습니까? –
내 생각 엔 당신이 무엇을 실행 하던지간에 너무 오래 걸리지 않았거나 결코 트랜잭션 레벨 격리 수준을 설정하지 않았다는 것입니다. SQL Server 2000의 쿼리에 본능적으로 nolocks를 추가하기 때문에 이러한 오류가 자주 발생합니다. – Jon
스냅 샷 격리를 살펴보면 쓰기 스레드가 여전히 행을 업데이트하는 동안 앱이 이전 버전의 행을 읽을 수 있습니다.
* 좋은 기사입니다. Thx –