NOLOCK (Sql Server 힌트)이 나쁜 습관입니까?

NOLOCK (Sql Server 힌트)이 나쁜 습관입니까?

---

나는 미션 크리티컬 하지 않은 웹 사이트 및 응용 프로그램을 만드는 사업을하고 있습니다 . 뱅킹 소프트웨어, 우주 비행, 집중 치료 모니터링 응용 프로그램 등 아이디어를 얻습니다.

따라서 그 엄청난 면책 조항으로 인해 일부 SQL 문에서 NOLOCK 힌트를 사용하는 것이 좋지 않습니까? 몇 년 전, 동료 SQL 관리자는 "더러운 읽기"에 만족하면 NOLOCK을 사용해야한다고 제안했습니다.이 읽기는 각 읽기가 잠기지 않기 때문에 시스템에서 약간 더 많은 성능을 제공합니다. 테이블 / 행 / 무엇이든.

또한 교착 상태가 발생하면 훌륭한 솔루션이라고 들었습니다. 그래서 Sql 전문가가 임의의 코드로 나를 도와주고 SQL 코드의 모든 NOLOCKS를 알 때까지 몇 년 동안 그 생각을 따르기 시작했습니다. 나는 정중하게 꾸짖었고 그는 나에게 설명하려고 노력했지만 (왜 좋지 않은지) 나는 길을 잃었습니다. 나는 그의 설명의 본질이 '더 심각한 문제에 대한 반창고 해결책'이라고 느꼈다. 특히 교착 상태에 처한 경우. 따라서 문제의 근원을 고치십시오 '.

나는 최근에 그것에 대해 인터넷 검색을 하고이 게시물을 가로 질러왔다 .

그렇다면 일부 SQL DB 전문가 선생님이 저를 깨우칠 수 있습니까?

---

NOLOCK 힌트를 사용하면 SELECT명령문 의 트랜잭션 분리 레벨 은 READ UNCOMMITTED입니다. 이는 쿼리가 더럽고 일관되지 않은 데이터를 볼 수 있음을 의미합니다.

일반적으로 적용하는 것은 좋지 않습니다. 미션 크리티컬 웹 기반 애플리케이션에서이 더티 읽기 동작이 정상인 경우에도 NOLOCK 스캔은 601 오류를 발생시켜 잠금 보호 기능이 부족하여 데이터 이동으로 인해 쿼리를 종료 할 수 있습니다.

Snapshot Isolation이 도움이되고 아플 때 읽을 것을 권장합니다. MSDN은 대부분의 상황에서 SNAPSHOT 대신 READ COMMITTED SNAPSHOT을 사용하는 것이 좋습니다.

---

스택 오버플로 작업을하기 전에, 나는 반대했다 NOLOCK당신이 잠재적를 수행 할 수있는 원금 SELECT과 NOLOCK날짜 또는 일관성이 밖으로 할 수있는 데이터와 결과를 다시 얻을. 고려해야 할 요소는 다른 프로세스가 동일한 테이블에서 데이터를 선택할 때 동시에 삽입 / 업데이트 할 수있는 레코드 수입니다. 이런 일이 많이 발생하면과 같은 데이터베이스 모드를 사용하지 않으면 교착 상태가 발생할 가능성이 높습니다 READ COMMITED SNAPSHOT.

그 NOLOCK후 SELECT성능 이 향상 되고 대량로드 된 SQL Server에서 교착 상태를 제거 할 수있는 방법을 목격 한 후 사용에 대한 관점을 변경 했습니다 . 데이터가 정확히 100 % 커밋되지 않았으며 오래된 결과 일지라도 신속하게 결과를 다시 요구해야하는 경우가 있습니다.

다음을 사용할 때 스스로에게 질문하십시오 NOLOCK.

쿼리에 많은 수의 INSERT/ UPDATE명령 이 포함 된 테이블이 포함 되어 있고 쿼리에서 반환 된 데이터에 특정 시점에 이러한 변경 내용이 누락되어 있는지 확인해야합니까?

대답이 아니오 인 경우 NOLOCK성능을 향상시키는 데 사용하십시오 .

---

방금 NOLOCK스택 오버플로에 대한 코드베이스 내 에서 키워드를 신속하게 검색 하고 138 개의 인스턴스를 찾았으므로이를 몇 군데에서 사용합니다.

---

더티 읽기 (즉, READ 상황)에 신경 쓰지 않는다면 NOLOCK괜찮습니다.

그러나 대부분의 잠금 문제는 하드웨어가 작업에 달려 있다고 가정하여 쿼리 워크로드에 대해 '정확한'인덱스가 없기 때문에 발생합니다.

그리고 전문가의 설명은 정확했습니다. 일반적으로 더 심각한 문제에 대한 반창고 솔루션입니다.

편집 : 나는 NOLOCK을 사용해야한다고 분명히 말하지 않습니다. 분명히 분명히 했어야한다고 생각합니다. (나는 그것이 정상이라고 분석 한 극단적 인 상황에서만 그것을 사용할 것입니다). 예를 들어, 얼마 전 나는 NOLOCK으로 뿌려진 TSQL에서 잠금 문제를 해결하기 위해 노력했습니다. 나는 그것들을 모두 제거하고 올바른 색인을 구현했으며 모든 교착 상태가 사라졌습니다.

---

의심 할 여지없이 교통량이 많은 사람은 "전문가"였습니다 ...

웹 사이트는 일반적으로 사용자가 완전히로드 된 페이지를 볼 때 "더러워"집니다. 데이터베이스에서로드 한 다음 편집 된 데이터를 저장하는 양식을 고려하십시오 ?? 사람들이 더티 읽기에 대해 계속하는 방식은 바보가 아닙니다.

즉, 선택한 레이어에 여러 레이어를 구축하면 위험한 중복성을 구축 할 수 있습니다. 돈이나 상태 시나리오를 다루는 경우 트랜잭션 데이터 읽기 / 쓰기뿐만 아니라 적절한 동시성 솔루션 (대부분의 "전문가"가 신경 쓰지 않는 것)이 필요합니다.

반면에 웹 사이트에 대한 고급 제품 검색 (예 : 캐시되지 않고 약간 집중적 일 수있는 것)이 있고 동시 사용자가 몇 명 이상인 사이트 (대수 "전문가"는하지 않았다), 그 뒤에 모든 다른 과정에서 목을 병에 넣는 것은 비참하다.

그것이 의미하는 바를 알고 필요할 때 사용하십시오. 요즘 데이터베이스는 거의 항상 주요 병목이 될 것이며 NOLOCK을 사용하는 것이 현명하다면 인프라에서 수천을 절약 할 수 있습니다.

편집 : 그것은 도움이되는 교착 상태 일뿐 만 아니라 다른 사람들이 당신이 끝날 때까지 기다리게하거나 그 반대도 마찬가지입니다.

EF4에서 NOLOCK 힌트를 사용하십니까?

---

대답은 틀리지 않지만 약간 혼란 스러울 수 있습니다.

• When querying single values/rows it's always bad practise to use NOLOCK -- you probably never want to display incorrect information or maybe even take any action on incorrect data.
• When displaying rough statistical information, NOLOCK can be very useful. Take SO as an example: It would be nonsense to take locks to read the exact number of views of a question, or the exact number of questions for a tag. Nobody cares if you incorrectly state 3360 questions tagged with "sql-server" now, and because of a transaction rollback, 3359 questions one second later.

---

As a professional Developer I'd say it depends. But I definitely follow GATS and OMG Ponies advice. Know What You are doing, know when it helps and when it hurts and

read hints and other poor ideas

what might make You understand the sql server deeper. I generally follow the rule that SQL Hints are EVIL, but unfortunately I use them every now and then when I get fed up with forcing SQL server do things... But these are rare cases.

luke

---

When app-support wanted to answer ad-hock queries from the production-server using SSMS (that weren't catered for via reporting) I requested they use nolock. That way the 'main' business is not affected.

---

I agree with some comments about NOLOCK hint and especially with those saying "use it when it's appropriate". If the application written poorly and is using concurrency inappropriate way – that may cause the lock escalation. Highly transactional table also are getting locked all the time due to their nature. Having good index coverage won't help with retrieving the data, but setting ISOLATION LEVEL to READ UNCOMMITTED does. Also I believe that using NOLOCK hint is safe in many cases when the nature of changes is predictable. For example – in manufacturing when jobs with travellers are going through different processes with lots of inserts of measurements, you can safely execute query against the finished job with NOLOCK hint and this way avoid collision with other sessions that put PROMOTED or EXCLUSIVE locks on the table/page. The data you access in this case is static, but it may reside in a very transactional table with hundreds of millions of records and thousands updates/inserts per minute. Cheers

---

I believe that it is virtually never correct to use nolock.

If you are reading a single row, then the correct index means that you won't need NOLOCK as individual row actions are completed quickly.

If you are reading many rows for anything other than temporary display, and care about being able repeat the result, or defend by the number produced, then NOLOCK is not appropriate.

NOLOCK is a surrogate tag for "i don't care if this answer contains duplicate rows, rows which are deleted, or rows which were never inserted to begin with because of rollback"

Errors which are possible under NOLOCK:

• Rows which match are not returned at all.
• single rows are returned multiple times (including multiple instances of the same primary key)
• Rows which do not match are returned.

Any action which can cause a page split while the noLock select is running can cause these things to occur. Almost any action (even a delete) can cause a page split.

Therefore: if you "know" that the row won't be changed while you are running, don't use nolock, as an index will allow efficient retrieval.

If you suspect the row can change while the query is running, and you care about accuracy, don't use nolock.

If you are considering NOLOCK because of deadlocks, examine the query plan structure for unexpected table scans, trace the deadlocks and see why they occur. NOLOCK around writes can mean that queries which previously deadlocked will potentially both write the wrong answer.

---

The better solutions, when possible are:

• Replicate your data (using log-replication) to a reporting database.
• Use SAN snapshots and mount a consistent version of the DB
• Use a database which has a better fundamental transaction isolation level

The SNAPSHOT transaction isolation level was created because MS was losing sales to Oracle. Oracle uses undo/redo logs to avoid this problem. Postgres uses MVCC. In the future MS's Heckaton will use MVCC, but that's years away from being production ready.

---

NOLOCK is often exploited as a magic way to speed up database reads, but I try to avoid using it whever possible.

The result set can contain rows that have not yet been committed, that are often later rolled back.

An error or Result set can be empty, be missing rows or display the same row multiple times.

This is because other transactions are moving data at the same time you're reading it.

READ COMMITTED adds an additional issue where data is corrupted within a single column where multiple users change the same cell simultaneously.

---

In real life where you encounter systems already written and adding indexes to tables then drastically slows down the data loading of a 14gig data table, you are sometime forced to used WITH NOLOCK on your reports and end of month proessing so that the aggregate funtions (sum, count etc) do not do row, page, table locking and deteriate the overall performance. Easy to say in a new system never use WITH NOLOCK and use indexes - but adding indexes severly downgrades data loading, and when I'm then told, well, alter the code base to delete indexes, then bulk load then recreate the indexes - which is all well and good, if you are developing a new system. But Not when you have a system already in place.

참고URL : https://stackoverflow.com/questions/1452996/is-the-nolock-sql-server-hint-bad-practice