달력

5

« 2024/5 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2009. 1. 13. 12:22

nolock 사용시 주의점 Work/SQL Server2009. 1. 13. 12:22

Oracle에 익숙한 사용자가 느끼는 MSSQL 의 황당한 점은 Commit 없이 DML이 적용되는 점과 잠금 이슈 입니다.
지금 언급하려는 것은 잠금 이슈에 대한 것입니다.

데이터 조회시 기초적인 부분은 건너 뛰고, Oracle에서의 SELECT와 비슷한 효과를 내려면 MSSQL에서는 with (nolock) 힌트를 사용하거나
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 절을 사용하여 잠금 수준을 지정해야 합니다.
여기까지는 대부분 알고 있는 내용입니다.

얼마전 (2007년인지 2008년인지 기억이 나지 않습니다.) xxx DB에 문제가 발생해서 제가 내린 1차적인 판단은 Table lock으로 인한 조회 쿼리의 차단일 것으로 추정했습니다. 
다행히 nolock 힌트의 사용으로 문제를 비켜갈 수 있었습니다만, 그 당시 개발자가 정렬이 원하는 대로 되지 않는다고 하여 ORDER BY 절을 사용토록 했습니다.
그렇게 문제는 해결되었는지 피해갔는지 알 수 없이 xxx DB는 관리 대상에서 사라졌습니다.

이 때 당시 저의 기본적인 생각은 ORDER BY 절을 사용하지 않는 한 인덱스를 사용하던 그렇지 않던 간에 데이터 정렬을 보장할 수 없다는 것이었습니다. 
하지만, 그렇지 않다는 것을 이해한 시점은 이 사건이 일어나고 한참 뒤였습니다.

MSSQL에서 유명한 정xx씨와 더불어 상당히 유명하신 김xx라는 분이 있습니다.
이분 블로그에 저와 유사한 경험을 한 것이 있어서 소개 하려고 합니다.



:
Posted by Elick