실행 시간이 조금 걸리는 쿼리가 있으므로 읽기 전용으로 설정된 격리 수준으로 실행하면 데이터가 더러울 수 있습니다. 곁눈질.Read Uncommitted를 사용할 때 잠금
좋은 하루 (아침 일찍)에 대한 쿼리는 실행하는 데 약 3-15 초가 걸립니다. (날짜 정렬은 정렬하지 않고 순간적으로 느려집니다.)
하루는 시작하기에 길어지기 때문에 실행하는 데 2 분 이상 걸립니다.
내가 알아챈 것은 쿼리가 실행될 때 많은 OBJECT/PAGE 잠금을 얻는 것 같습니다.
내가 이해할 수없는 것은 Uniquitted Read로 설정된 동안 획득이 잠금되는 이유입니다.
쿼리에서 사용하는 인덱스 중 하나가 행/페이지 잠금을 사용하도록 설정되어 있습니다.
내 Q :
합니까 액세스하는 경우 쿼리가 커밋되지 않은 읽기 경우에도 고정 할 행/페이지 잠금을 사용하는 데이터의 원인이 설정되어 인덱스?
READ UNCOMMITTED 격리 수준은 독자의 행동을 변경합니다. READ COMMITTED 이상의 격리 수준에서 작업이 행에서 읽으려고 할 때 forst는 잠금 관리자에게 공유 잠금을 요청합니다. 이 요청은 다른 세션에서 독점 잠금이없는 경우에만 적용됩니다. 그렇지 않으면 대기해야합니다.
READ UNCOMMITTED에서 독자는 공유 잠금을 요청하지 않으므로 가능한 단독 잠금이 해제 될 때까지 기다릴 가능성이 없습니다.
그러나 업데이트시 잠금 동작은 사용 된 격리 수준에 관계없이 동일합니다. 다른 비관적 인 격리 수준에서와 같이 독점 잠금은 여전히 READ UNCOMMITTED에 있고 (트랜잭션이 끝날 때까지 유지됩니다).
쿼리가 완료되는 데 필요한 시간이 길어지면이 문제가 발생하거나 일부 리소스 경합이 발생할 수 있습니다. 간단히 말하면 쿼리는 동시에 실행되는 다른 쿼리와 데이터 캐시를 놓고 경쟁합니다.
것은 하루의 다양한 시간에 page life expectancy 카운터를 적어 보자
SELECT OBJECT_NAME(p.[object_id]) AS [Object Name], p.index_id,
CAST(COUNT(*)/128.0 AS DECIMAL(10, 2)) AS [Buffer size(MB)],
COUNT(*) AS [BufferCount], p.Rows AS [Row Count],
p.data_compression_desc AS [Compression Type]
FROM sys.allocation_units AS a WITH (NOLOCK)
INNER JOIN sys.dm_os_buffer_descriptors AS b WITH (NOLOCK)
ON a.allocation_unit_id = b.allocation_unit_id
INNER JOIN sys.partitions AS p WITH (NOLOCK)
ON a.container_id = p.hobt_id
WHERE b.database_id = CONVERT(int,DB_ID())
AND p.[object_id] > 100
GROUP BY p.[object_id], p.index_id, p.data_compression_desc, p.[Rows]
ORDER BY [BufferCount] DESC OPTION (RECOMPILE);
[이 : 또한
SELECT @@SERVERNAME AS [Server Name], [object_name], instance_name, cntr_value AS [Page Life Expectancy]
FROM sys.dm_os_performance_counters WITH (NOLOCK)
WHERE [object_name] LIKE N'%Buffer Node%' -- Handles named instances
AND counter_name = N'Page life expectancy' OPTION (RECOMPILE);
을, 가장 많은 공간을 차지되는 데이터보고,이 쿼리를 사용하여 기타 진단 검색어는 여기에서 확인할 수 있습니다. http://sqlserverperformance.wordpress.com/]