Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
WITH no locks
- Thread starter Ladyazh
- Start date
- Thread starter
- #2
I found this article and trying to see if it is correctly put:
MOST OF THE TIME
the "with (nolock)" should not be used.
often when they are used it is a sign of a poor db design or that the table needs an index or other optimsing such as use of a clustered index.
in a few cases you may need them to get that last bit of perf.
an example was a db I did some work on that had them all over and they deleted rows every month as that kept it working.
I did a new system for them and I have one table that we trim and never have the problems the former db had.
some examples were: no PK on a table, no related key's on some tables, using datetime when an int id would work ....
genberaly the tables and relations were crapp and as a result they had many problems.
I have large numbers of rows in a new db that does the same 'functions' as the old system w/o the bugs they had as an everyday thing.
I did have to do some fun stuff with some tables, we put a clustered index on some columns to help with inserts.
they dump orders in at a fast rate sometimes and the locks for adding new rows were jaming up the server.
the clusterd index plus re-indexing at night opens up new space in the tables and indexs so that we nolonger have a bottle neck when they dump orders at peak work load.
MOST OF THE TIME
the "with (nolock)" should not be used.
often when they are used it is a sign of a poor db design or that the table needs an index or other optimsing such as use of a clustered index.
in a few cases you may need them to get that last bit of perf.
an example was a db I did some work on that had them all over and they deleted rows every month as that kept it working.
I did a new system for them and I have one table that we trim and never have the problems the former db had.
some examples were: no PK on a table, no related key's on some tables, using datetime when an int id would work ....
genberaly the tables and relations were crapp and as a result they had many problems.
I have large numbers of rows in a new db that does the same 'functions' as the old system w/o the bugs they had as an everyday thing.
I did have to do some fun stuff with some tables, we put a clustered index on some columns to help with inserts.
they dump orders in at a fast rate sometimes and the locks for adding new rows were jaming up the server.
the clusterd index plus re-indexing at night opens up new space in the tables and indexs so that we nolonger have a bottle neck when they dump orders at peak work load.
- Status
Similar threads
- Locked
- Question
- Locked
- Question