June 27, 2014 at 2:22 am
i have a database which get refreshed every day from client's data . and we need to pull heavy data from them every day as reports . so only selects happens on that database.
we do daily population of some table in some other databases from this daily refreshed DB.
will read uncommitted or NOLOCK with select queries help to retrieve data faster.
there will be no dirty read as there are NO DML operation in that database so for SELECT which happens concurrently on these tables , will NOLOCK helps ?
-------Bhuvnesh----------
I work only to learn Sql Server...though my company pays me for getting their stuff done;-)
June 27, 2014 at 2:26 am
Probably not. If the very small overhead of requesting locks is noticeable, you probably have other problems.
If you really want, mark the DB read only in its entirety, then SQL shouldn't take locks at all since it knows that nothing can change
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 27, 2014 at 8:58 am
Yes, it does help, and is measurable.
However - you could look at writing indexes specifically for your queries. With no updates, you can go wild on indexes, and create covering indexes - in reality almost a mini table, as well as sorting your data on disk with a clustered index to suit your queries best.
I have previously duplicated a table three times with 3 separate names and each with a different clustered index to help the queries fly.
Covering and clustered indexes are very very good as speeding up a query only database.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply