Showing posts with label xxx. Show all posts
Showing posts with label xxx. Show all posts

Wednesday, March 7, 2012

NOLOCK on views

Hey guys,

I came across a SQL statement, thought up by a developer, in which two views were joined with the NOLOCK hint:
SELECT v1.xxx, v2.yyy
FROM dbo.vw_SomeView v1 WITH (NOLOCK)
INNER JOIN dbo.vw_SomeOtherView WITH (NOLOCK) ON v1.id = v2.id
The views are not created the NOLOCK hint. So my question is: has the NOLOCK hint any effect here?

I've looked in the BOL and searched on the net but can't find anything on this particular topic.

Lex

PS. Personally I don't like to use views in JOINs. I've seen too many cases in which tables are joined twice just because they are part of both views. Further more I don't like the "random" use of NOLOCK because most people don't seem to understand the implications of it. But this is besides the point of my question ;)Looks like it's time for a little hands on experiment. Take an update lock on one of the tables used in either of the views in one QA window, and try to run the sql in another.|||Looks like it's time for a little hands on experiment. Take an update lock on one of the tables used in either of the views in one QA window, and try to run the sql in another.

I use and recommend (NOLOCK) Optimizer hints on a regular basis. Just know that when a (NOLOCK) hint is used, it performs a "Dirty Read" against the data.

The primary benefit to a (NOLOCK) hint is to prevent the blocking of objects from occurring when users are selecting data. I would recommend using them if you have contention in your environment with users holding exclusive locks on tables.

Hope this helps!