Locking Problem: SQL Server

[Ritesh]

Hi All,

According to my observation using SP_WHO2 in my database, some INSERT
statements are getting blocked by SELECT statements. Though the
blocking
SELECT statement is having ReadPast hint, i think, it will only read
past
locked resources but will not guarantee the select statement itself not
blocking other statements(in my case Insert). According to my knowledge

and
information, select statements take shared locks but why then these
statements are blocking insert statements?

Can there be any other solution other than using NoLock hint as this
hint
make sure no shared locks are issued but it can read uncommited data.

Need help urgently.

Thanks
Ritesh

[Ray]

Re: Locking Problem: SQL Server

Ritesh,

ReadPast only skips row level locks. sp_who2 will not show you the
granularity of the lock for that use sp_lock. You are correct that only
NoLock will read without blocking but it comes with a price of potentially
reading dirty pages. In SQL 2005 a new isolation level will be added called
SnapShot that will give you what you are looking for.

Ray

"Ritesh" <riteshkhanna20 01@yahoo.com> wrote in message
news:1112673804 .428002.52360@g 14g2000cwa.goog legroups.com...[color=blue]
> Hi All,
>
> According to my observation using SP_WHO2 in my database, some INSERT
> statements are getting blocked by SELECT statements. Though the
> blocking
> SELECT statement is having ReadPast hint, i think, it will only read
> past
> locked resources but will not guarantee the select statement itself not
> blocking other statements(in my case Insert). According to my knowledge
>
> and
> information, select statements take shared locks but why then these
> statements are blocking insert statements?
>
> Can there be any other solution other than using NoLock hint as this
> hint
> make sure no shared locks are issued but it can read uncommited data.
>
> Need help urgently.
>
> Thanks
> Ritesh
>[/color]

[Ritesh]

Re: Locking Problem: SQL Server

Thanks Ray,

Can there be any solutions to SELECT statements not blocking Insert statements?

Regards,
Ritesh



"Ray" <someone@nowher e.com> wrote in message news:<Nsu4e.293 65$hU7.26820@ne wssvr33.news.pr odigy.com>...[color=blue]
> Ritesh,
>
> ReadPast only skips row level locks. sp_who2 will not show you the
> granularity of the lock for that use sp_lock. You are correct that only
> NoLock will read without blocking but it comes with a price of potentially
> reading dirty pages. In SQL 2005 a new isolation level will be added called
> SnapShot that will give you what you are looking for.
>
> Ray
>
> "Ritesh" <riteshkhanna20 01@yahoo.com> wrote in message
> news:1112673804 .428002.52360@g 14g2000cwa.goog legroups.com...[color=green]
> > Hi All,
> >
> > According to my observation using SP_WHO2 in my database, some INSERT
> > statements are getting blocked by SELECT statements. Though the
> > blocking
> > SELECT statement is having ReadPast hint, i think, it will only read
> > past
> > locked resources but will not guarantee the select statement itself not
> > blocking other statements(in my case Insert). According to my knowledge
> >
> > and
> > information, select statements take shared locks but why then these
> > statements are blocking insert statements?
> >
> > Can there be any other solution other than using NoLock hint as this
> > hint
> > make sure no shared locks are issued but it can read uncommited data.
> >
> > Need help urgently.
> >
> > Thanks
> > Ritesh
> >[/color][/color]

[julian_muir]

Re: Locking Problem: SQL Server

Pehaps you are asking the wrong question. I would be asking why the select
queries are running long enough to block the update queries. If applications
are written correctly then select queries should run quickly enough that
updates are not blocked for long.

Specifically in 2000 you can only use nolock or set the the isoation level
to dirty read for the query (does the same), you cannot guarantee to get
clean data if you do this. It will depend on what the users need if this is
acceptable.

Shared locks will block update locks this is correct and expected. Also SQL
2000 will only allow exclusive locks to be blocked 4 times (from memory) by
shared locks before it lets the exclusive locks through (this gives further
weight to the question as to why the select queries are taking so long)

Help this helps
Julian


"Ritesh" <riteshkhanna20 01@yahoo.com> wrote in message
news:1112673804 .428002.52360@g 14g2000cwa.goog legroups.com...[color=blue]
> Hi All,
>
> According to my observation using SP_WHO2 in my database, some INSERT
> statements are getting blocked by SELECT statements. Though the
> blocking
> SELECT statement is having ReadPast hint, i think, it will only read
> past
> locked resources but will not guarantee the select statement itself not
> blocking other statements(in my case Insert). According to my knowledge
>
> and
> information, select statements take shared locks but why then these
> statements are blocking insert statements?
>
> Can there be any other solution other than using NoLock hint as this
> hint
> make sure no shared locks are issued but it can read uncommited data.
>
> Need help urgently.
>
> Thanks
> Ritesh
>[/color]

[Gang He [MSFT]]

Re: Locking Problem: SQL Server

Ritesh,

Normally insert statement will not block on select statement. But there are
exceptions. For example, when the lock granularity of the insert is the
page level, then it can block on page lock held by select statement. If
this is the case, the force insert to take row lock using ROWLOCK will
remove the blocking. Or if the select statement is run under read repeatable
or serializable isolation level, then the select takes some kind of key
range lock which prevents insert into the range locked. If this is the
case, changebthe select isolation level to read committed will remove
blocking. Finally you may need to do some homework to find out which lock
the insert is blocked on by the select, which you can query sysprocesses and
syslockinfo to find out.

--
Gang He
Software Design Engineer
Microsoft SQL Server Storage Engine

This posting is provided "AS IS" with no warranties, and confers no rights.
"Ritesh" <riteshkhanna20 01@yahoo.com> wrote in message
news:1112673804 .428002.52360@g 14g2000cwa.goog legroups.com...[color=blue]
> Hi All,
>
> According to my observation using SP_WHO2 in my database, some INSERT
> statements are getting blocked by SELECT statements. Though the
> blocking
> SELECT statement is having ReadPast hint, i think, it will only read
> past
> locked resources but will not guarantee the select statement itself not
> blocking other statements(in my case Insert). According to my knowledge
>
> and
> information, select statements take shared locks but why then these
> statements are blocking insert statements?
>
> Can there be any other solution other than using NoLock hint as this
> hint
> make sure no shared locks are issued but it can read uncommited data.
>
> Need help urgently.
>
> Thanks
> Ritesh
>[/color]

[Ritesh]

Re: Locking Problem: SQL Server

Hi,

You are correct but the problem is my select queries are blocking
insert statements and select statements are running in default
isolation level. The problem is, I inheriated this design, which is
OLTP in nature but the DB is also queried extensively for newly
inserted records.

Can there be any way to completely avoid just inserting records
(showing in the query. It is acceptable for business logic, say
READPAST will do.) and also the query (same select query) not blocking
newly inserting records but not reading any dirty data? or I am asking
to much from SQL Server? :)

What do you say?

Thanks & Regards,
Ritesh Khanna



"Gang He [MSFT]" <gangheREMOVETH IS@microsoft.co m> wrote in message news:<425c750c$ 1@news.microsof t.com>...[color=blue]
> Ritesh,
>
> Normally insert statement will not block on select statement. But there are
> exceptions. For example, when the lock granularity of the insert is the
> page level, then it can block on page lock held by select statement. If
> this is the case, the force insert to take row lock using ROWLOCK will
> remove the blocking. Or if the select statement is run under read repeatable
> or serializable isolation level, then the select takes some kind of key
> range lock which prevents insert into the range locked. If this is the
> case, changebthe select isolation level to read committed will remove
> blocking. Finally you may need to do some homework to find out which lock
> the insert is blocked on by the select, which you can query sysprocesses and
> syslockinfo to find out.
>
> --
> Gang He
> Software Design Engineer
> Microsoft SQL Server Storage Engine
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Ritesh" <riteshkhanna20 01@yahoo.com> wrote in message
> news:1112673804 .428002.52360@g 14g2000cwa.goog legroups.com...[color=green]
> > Hi All,
> >
> > According to my observation using SP_WHO2 in my database, some INSERT
> > statements are getting blocked by SELECT statements. Though the
> > blocking
> > SELECT statement is having ReadPast hint, i think, it will only read
> > past
> > locked resources but will not guarantee the select statement itself not
> > blocking other statements(in my case Insert). According to my knowledge
> >
> > and
> > information, select statements take shared locks but why then these
> > statements are blocking insert statements?
> >
> > Can there be any other solution other than using NoLock hint as this
> > hint
> > make sure no shared locks are issued but it can read uncommited data.
> >
> > Need help urgently.
> >
> > Thanks
> > Ritesh
> >[/color][/color]