SQL 2000 - Row Level Locking

Hi,

We have encountered deadlock on a table which is used to generate
sequential numbers for different categories eg typical entries

Category Value

TRADE_NO 1456
JOB_NO 267
.....

The applications reference the relevant category applicable to them
and update
the Value accordingly. This is table is very small, occupying 1 page.
However, it has no index as it was not seen to be appropriate for a
table this size.

However, can someone please advise whether

1. An index is required for row level locking
2. If an index on a table as small as above is likely to reduce the
deadlock rate.

Also, please consider the following but which I am not sure is
relevant for above query.

We noted that when we migrated the database concerned from SQL 6.5 to
SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
format for non clustered indexes (NC) ie the clustered key was not
part of the NC index until the clustered index was rebuilt.

Given this should I just rebuild this table with a fake index and drop
it thereafter.

We are aware of the different techniques used to avoid deadlocks (eg
tables accessed in same order etc) and have , as much as possible,
implemented those practices.

I thank you in advance for any help you may be able to offer.

Thanks

Puvendran

> 1. An index is required for row level locking

Yes. It's always a good idea for all tables to have a primary key
regardless of table size. Not only is this a best practice in database
design, SQL Server will create a unique index to support the primary key
constraint and this allows SQL Server to develop better execution plans for
joins and implement row-level locking.
[color=blue]
> 2. If an index on a table as small as above is likely to reduce the
> deadlock rate.[/color]

Yes but you can still have problems if you update different rows as part of
the same transaction and perform updates in different sequence. You might
consider using IDENTITY since this will improve concurrency.
[color=blue]
> We noted that when we migrated the database concerned from SQL 6.5 to
> SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
> format for non clustered indexes (NC) ie the clustered key was not
> part of the NC index until the clustered index was rebuilt.[/color]

I'm not sure what you mean here. In SQL 2000, the clustered index keys are
always stored in non-clustered index leaf pages. This is done automatically
by SQL Server so you don't need to do anything special to make this happen,
even if clustered index keys are not non-clustered index columns. SQL
Server uses the clustered index values from the non-clustered index for
bookmark lookups and to cover queries when appropriate.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"Puvendran" <puvendran.selvaratnam@btfinancialgroup.com> wrote in message
news:d58d22fa.0402150224.55a1df47@posting.google.c om...[color=blue]
> Hi,
>
> We have encountered deadlock on a table which is used to generate
> sequential numbers for different categories eg typical entries
>
> Category Value
>
> TRADE_NO 1456
> JOB_NO 267
> ....
>
> The applications reference the relevant category applicable to them
> and update
> the Value accordingly. This is table is very small, occupying 1 page.
> However, it has no index as it was not seen to be appropriate for a
> table this size.
>
> However, can someone please advise whether
>
> 1. An index is required for row level locking
> 2. If an index on a table as small as above is likely to reduce the
> deadlock rate.
>
> Also, please consider the following but which I am not sure is
> relevant for above query.
>
> We noted that when we migrated the database concerned from SQL 6.5 to
> SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
> format for non clustered indexes (NC) ie the clustered key was not
> part of the NC index until the clustered index was rebuilt.
>
> Given this should I just rebuild this table with a fake index and drop
> it thereafter.
>
> We are aware of the different techniques used to avoid deadlocks (eg
> tables accessed in same order etc) and have , as much as possible,
> implemented those practices.
>
> I thank you in advance for any help you may be able to offer.
>
> Thanks
>
> Puvendran[/color]

puvendran.selvaratnam@btfinancialgroup.com (Puvendran) wrote in message news:<d58d22fa.0402150224.55a1df47@posting.google. com>...[color=blue]
> Hi,
>
> We have encountered deadlock on a table which is used to generate
> sequential numbers for different categories eg typical entries
>
> Category Value
>
> TRADE_NO 1456
> JOB_NO 267
> ....
>
> The applications reference the relevant category applicable to them
> and update
> the Value accordingly. This is table is very small, occupying 1 page.
> However, it has no index as it was not seen to be appropriate for a
> table this size.
>
> However, can someone please advise whether
>
> 1. An index is required for row level locking
> 2. If an index on a table as small as above is likely to reduce the
> deadlock rate.
>
> Also, please consider the following but which I am not sure is
> relevant for above query.
>
> We noted that when we migrated the database concerned from SQL 6.5 to
> SQL 2000, using DTS, that the database was NOT strictly in SQL 2000
> format for non clustered indexes (NC) ie the clustered key was not
> part of the NC index until the clustered index was rebuilt.
>
> Given this should I just rebuild this table with a fake index and drop
> it thereafter.
>
> We are aware of the different techniques used to avoid deadlocks (eg
> tables accessed in same order etc) and have , as much as possible,
> implemented those practices.
>
> I thank you in advance for any help you may be able to offer.
>
> Thanks
>
> Puvendran[/color]

Puvendran,

As far as I am aware an index is not required to implement row-level
locking, and as you are clearly aware an index on a table this size is
pointless (I doubt the optimizer would ever choose to use it).

The presence of any index would probably increase any tendency towards
deadlocking, since it will lengthen the transaction time (the index
pointers need to be updated as well as the data), and one of the
deadlock avoidance techniques is to keep transactions as short as
possible.

Surely, though, it would be simple to test all this out? Just
implement row-level locking, with and without an index, and see what
happens.

I'm not sure I understand your second observation - the clustered key
was not part of the NC index? Maybe someone else with more experience
of SQL Server than myself can answer this one.

Philip Yale (philipyale@btopenworld.com) writes:[color=blue]
> As far as I am aware an index is not required to implement row-level
> locking, and as you are clearly aware an index on a table this size is
> pointless (I doubt the optimizer would ever choose to use it).[/color]

An index is definitely helpful in a table as Puvendran's, since if there
is no index, SQL Server will have to put a shared table lock on the table
to be able to find the row to update. Once the row(s) is located, that lock
can possibly be released (although I don't know if that really happens),
but as long as as the exclusive lock is held on the updated row, the
next guy that wants a sequence number for a different item wil be block,
because he can't get the table lock.
[color=blue]
> The presence of any index would probably increase any tendency towards
> deadlocking, since it will lengthen the transaction time (the index
> pointers need to be updated as well as the data), and one of the
> deadlock avoidance techniques is to keep transactions as short as
> possible.[/color]

I would expect that the index keys to be stable and not be updated, so
this would not be issue.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns9490D258B8752Yazorman@127.0.0.1>...[color=blue]
> Philip Yale (philipyale@btopenworld.com) writes:[color=green]
> > As far as I am aware an index is not required to implement row-level
> > locking, and as you are clearly aware an index on a table this size is
> > pointless (I doubt the optimizer would ever choose to use it).[/color]
>
> An index is definitely helpful in a table as Puvendran's, since if there
> is no index, SQL Server will have to put a shared table lock on the table
> to be able to find the row to update. Once the row(s) is located, that lock
> can possibly be released (although I don't know if that really happens),
> but as long as as the exclusive lock is held on the updated row, the
> next guy that wants a sequence number for a different item wil be block,
> because he can't get the table lock.[/color]

But it's a 1-page table. I remain to be convinced that the optimizer
would do an index lookup on this, since this would require a minimum
of 2 I/Os (one for the index page, one for the leaf node). I'll test
this out myself, but I would expect a single-page table scan
(technically a clustered index scan, but it's scanning the leaf pages,
not doing an index seek), which will lead to a shared PAGE lock during
a read operation (which will in reality be equivalent to a table-level
lock, although no lock escalation to table-level will be required),
and an exclusive PAGE lock or ROW lock (depending on the lock strategy
employed) during an update (again, a page lock would be equivalent to
a table-level lock in this particular example).

The question seems to be about how to implement row-level locking
(since this would undoubtedly improve concurrency), and unless someone
knows why it can't be done I'd suggest simply using the WITH ROWLOCK
clause as part of any select or update statement.[color=blue]
>[color=green]
> > The presence of any index would probably increase any tendency towards
> > deadlocking, since it will lengthen the transaction time (the index
> > pointers need to be updated as well as the data), and one of the
> > deadlock avoidance techniques is to keep transactions as short as
> > possible.[/color]
>
> I would expect that the index keys to be stable and not be updated, so
> this would not be issue.[/color]

Fair point, since the index would probably be keyed on Category, and
these will not change. I still don't see what benefit an index would
offer, though, other than referential integrity by acting as a primary
key constraint.

philipyale@btopenworld.com (Philip Yale) wrote in message news:<e9c86dcc.0402160230.419a360@posting.google.c om>...[color=blue]
> Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns9490D258B8752Yazorman@127.0.0.1>...[color=green]
> > Philip Yale (philipyale@btopenworld.com) writes:[color=darkred]
> > > As far as I am aware an index is not required to implement row-level
> > > locking, and as you are clearly aware an index on a table this size is
> > > pointless (I doubt the optimizer would ever choose to use it).[/color]
> >
> > An index is definitely helpful in a table as Puvendran's, since if there
> > is no index, SQL Server will have to put a shared table lock on the table
> > to be able to find the row to update. Once the row(s) is located, that lock
> > can possibly be released (although I don't know if that really happens),
> > but as long as as the exclusive lock is held on the updated row, the
> > next guy that wants a sequence number for a different item wil be block,
> > because he can't get the table lock.[/color]
>
> But it's a 1-page table. I remain to be convinced that the optimizer
> would do an index lookup on this, since this would require a minimum
> of 2 I/Os (one for the index page, one for the leaf node). I'll test
> this out myself, but I would expect a single-page table scan
> (technically a clustered index scan, but it's scanning the leaf pages,
> not doing an index seek), which will lead to a shared PAGE lock during
> a read operation (which will in reality be equivalent to a table-level
> lock, although no lock escalation to table-level will be required),
> and an exclusive PAGE lock or ROW lock (depending on the lock strategy
> employed) during an update (again, a page lock would be equivalent to
> a table-level lock in this particular example).
>
> The question seems to be about how to implement row-level locking
> (since this would undoubtedly improve concurrency), and unless someone
> knows why it can't be done I'd suggest simply using the WITH ROWLOCK
> clause as part of any select or update statement.[color=green]
> >[color=darkred]
> > > The presence of any index would probably increase any tendency towards
> > > deadlocking, since it will lengthen the transaction time (the index
> > > pointers need to be updated as well as the data), and one of the
> > > deadlock avoidance techniques is to keep transactions as short as
> > > possible.[/color]
> >
> > I would expect that the index keys to be stable and not be updated, so
> > this would not be issue.[/color]
>
> Fair point, since the index would probably be keyed on Category, and
> these will not change. I still don't see what benefit an index would
> offer, though, other than referential integrity by acting as a primary
> key constraint.[/color]

Okay, humble pie time. Still, I don't understand what I'm seeing,
though, and coming from a Sybase background it wasn't what I expected
to see at all.

Having run a few simple tests, I found the following:

CREATE TABLE [GroupTable] (
[GroupName] [char] (10) COLLATE Latin1_General_CI_AS NOT NULL ,
[GroupID] [int] NOT NULL ,
CONSTRAINT [PK_GroupTable] PRIMARY KEY CLUSTERED
(
[GroupName]
) ON [PRIMARY]
) ON [PRIMARY]

insert grouptable values ('Admin',334)
insert grouptable values ('User', 2314)
insert grouptable values ('Web', 714)

This gives us a single-page table (well, 8-page if you want to be
strict about extent allocation), with a primary key on GroupName.

The following query uses the clustered index (no surprise, since it's
there), but I was surprised to see it SEEKing rather than SCANning:

select groupid from grouptable where groupname = 'user'

|-Clustered Index Seek(OBJECT:([Northwind].[dbo].[GroupTable].PK_GroupTable]),
SEEK:([GroupTable].[GroupName]=[@1]) ORDERED FORWARD)

As expected, there are 2 logical page reads (one for the index page,
one for the leaf page):

Table 'GroupTable'. Scan count 1, logical reads 2, physical reads 0,
read-ahead reads 0.

Dropping the primary key and then re-running the query gives the
expected table scan:

|--Table Scan(OBJECT:([Northwind].[dbo].[GroupTable]),
WHERE:([GroupTable].[GroupName]=[@1]))

and the number of logical page reads has dropped to 1 (scan of a
single page):

Table 'GroupTable'. Scan count 1, logical reads 1, physical reads 0,
read-ahead reads 0.

This is all more or less what I expected to see, but I couldn't
understand why the optimizer would choose a clustered index seek over
a tablescan simply because the index happened to be there. I compared
the showplan cost estimates and was surprised by the following:

With Clustered Index With No Index
Est Rowcount 1 1
Est Rowsize 11 21
Est I/O Cost 0.00632 0.0187
Est CPU Cost 0.000080 0.000041
Est Cost 0.006408 (100%) 0.037660 (100%)
Est Subtree Cost 0.00640 0.0376

Clearly the estimated total cost with the clustered index is less than
without it, but on a table of this size I'm afraid I just don't
understand why. Any offers?

Philip Yale (philipyale@btopenworld.com) writes:[color=blue]
> Okay, humble pie time. Still, I don't understand what I'm seeing,
> though, and coming from a Sybase background it wasn't what I expected
> to see at all.[/color]

If Sybase is still sticks to page locks as its lowest level of granularity,
then I can understand that it does not make sense in that context.

However, since version 7, MS SQL Server has row locks, and this is all
about concurrency.

Run this in one query window:

CREATE TABLE [grouptable] (
[GroupName] [char] (10) ,
[GroupID] [int] NOT NULL ,
-- CONSTRAINT [PK_GroupTable] PRIMARY KEY (GroupName)
)
insert grouptable values ('Admin',334)
insert grouptable values ('User', 2314)
insert grouptable values ('Web', 714)
go
begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'Admin'

waitfor delay '00:00:10'
select "next" = @next
commit transaction
go

The WAITFOR here stands in for some other time-consuming processing.
While the second batch is running, run this from another window:

begin transaction
declare @next int

update grouptable
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'User'

select "next" = @next
commit transaction

Note that this second batch does not complete until the first completes.

Now, drop the table and uncomment the PK constraint, and rerun the two
queries. Notice now that the second query window returns instantly.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns9491F3CC26982Yazorman@127.0.0.1>...[color=blue]
> Philip Yale (philipyale@btopenworld.com) writes:[color=green]
> > Okay, humble pie time. Still, I don't understand what I'm seeing,
> > though, and coming from a Sybase background it wasn't what I expected
> > to see at all.[/color]
>
> If Sybase is still sticks to page locks as its lowest level of granularity,
> then I can understand that it does not make sense in that context.
>
> However, since version 7, MS SQL Server has row locks, and this is all
> about concurrency.
>
> Run this in one query window:
>
> CREATE TABLE [grouptable] (
> [GroupName] [char] (10) ,
> [GroupID] [int] NOT NULL ,
> -- CONSTRAINT [PK_GroupTable] PRIMARY KEY (GroupName)
> )
> insert grouptable values ('Admin',334)
> insert grouptable values ('User', 2314)
> insert grouptable values ('Web', 714)
> go
> begin transaction
> declare @next int
>
> update grouptable
> set @next = GroupID + 1,
> GroupID = GroupID + 1
> where GroupName = 'Admin'
>
> waitfor delay '00:00:10'
> select "next" = @next
> commit transaction
> go
>
> The WAITFOR here stands in for some other time-consuming processing.
> While the second batch is running, run this from another window:
>
> begin transaction
> declare @next int
>
> update grouptable
> set @next = GroupID + 1,
> GroupID = GroupID + 1
> where GroupName = 'User'
>
> select "next" = @next
> commit transaction
>
> Note that this second batch does not complete until the first completes.
>
> Now, drop the table and uncomment the PK constraint, and rerun the two
> queries. Notice now that the second query window returns instantly.[/color]

This doesn't surprise me at all, and Sybase would do the same (yes, it
does have row-level locking if chosen). Are we saying that SQLServer
will only (can only?) use row-level locking if the is a primary key
constraint on the table?

What was really surprising me before was that the optimizer was
choosing a more expensive solution (index lookup costing 2 logical
reads, instead of a table scan costing 1 logical read). The Query
Plan estimates show that it expected the index lookup to be cheaper,
but I believe the actual results confirm that this expectation was
wrong. I can see that at this scale the differences are negligible,
and if the row-level locking option is only available with a PK in
place then the index lookup is clearly preferrable. However, the
optimizer is a "machine" (of sorts), and I would expect it to apply
costing rules consistently. Couldn't the best solution be achieved,
though, without a PK (forcing a tablescan) and modifying the update
to:

update grouptable WITH (ROWLOCK)
set @next = GroupID + 1,
GroupID = GroupID + 1
where GroupName = 'User'

I realise all this may be of little or no consequence, but it would
help with my understanding of the SQLServer optimizer versus that of
Sybase.

Philip Yale (philipyale@btopenworld.com) writes:[color=blue]
> This doesn't surprise me at all, and Sybase would do the same (yes, it
> does have row-level locking if chosen). Are we saying that SQLServer
> will only (can only?) use row-level locking if the is a primary key
> constraint on the table?[/color]

No. If you submit the version without the clustered index, you will see
that it has an exclusive lock for RID resource. RID is a row id, and
occurs only in heaps. There are also intent-exclusive locks on table
and page level. In the version with the clustered index in place, the
RID resource is changed to KEY, but the intent locks are still there.

In fact, you would have the same result if row locks was all there
was. When the second update comes along, it must read all rows in the
table, to find if the row matches the WHERE condition. But there is
one row in the table it cannot read, because this row is locked, and
therefore the second update is held up here.

When you have an index in place, the second update does not have to
read all rows to find matching rows.

Exactly how the optimizer avoids this pitfall, I don't know, but it
may be as simple that the optimizer stops looking for plans once
it has found one which is good enough.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns9492ECBD7F5E0Yazorman@127.0.0.1>...[color=blue]
> Philip Yale (philipyale@btopenworld.com) writes:[color=green]
> > This doesn't surprise me at all, and Sybase would do the same (yes, it
> > does have row-level locking if chosen). Are we saying that SQLServer
> > will only (can only?) use row-level locking if the is a primary key
> > constraint on the table?[/color]
>
> No. If you submit the version without the clustered index, you will see
> that it has an exclusive lock for RID resource. RID is a row id, and
> occurs only in heaps. There are also intent-exclusive locks on table
> and page level. In the version with the clustered index in place, the
> RID resource is changed to KEY, but the intent locks are still there.
>
> In fact, you would have the same result if row locks was all there
> was. When the second update comes along, it must read all rows in the
> table, to find if the row matches the WHERE condition. But there is
> one row in the table it cannot read, because this row is locked, and
> therefore the second update is held up here.
>
> When you have an index in place, the second update does not have to
> read all rows to find matching rows.
>
> Exactly how the optimizer avoids this pitfall, I don't know, but it
> may be as simple that the optimizer stops looking for plans once
> it has found one which is good enough.[/color]

[color=blue]
> When you have an index in place, the second update does not have to
> read all rows to find matching rows.[/color]

Not strictly true. The clustered index only directs the optimizer to
the *PAGE* on which the row is located, since the index node rows in a
clustered index only contain the first key value of the target page at
the leaf level. (This is not the same as a non-clustered index, which
would direct the search to the individual record). Thus, with a
clustered index seek you will still have to read all rows on the
target page to find those which match / don't match. Because of this,
I still maintain that the clustered index lookup is more expensive
than a single-page tablescan, even with row-level locking, since you
have to read both the index node page and the entire leaf page (at
least 2 logical reads), as opposed to just a single logical read by
scanning the 1-page table.
[color=blue]
> Exactly how the optimizer avoids this pitfall, I don't know, but it
> may be as simple that the optimizer stops looking for plans once
> it has found one which is good enough.[/color]

This isn't (shouldn't be) the way optimizers work. They consider ALL
possible plans, then slect the "cheapest". It's the definition of
"cheapest" which is probably the stumbling block here. As the Query
Plan stats showed a few posts back now, the optimizer truly believed
that the clustered index lookup would be cheaper. It was the
STATISTICS IO output that resulted from actually running the query
which showed that, in I/O terms at least (which is usually what the
optimizer would place most emphasis on), the clustered index lookup
was twice as expensive as the tablescan.

It may be that the SQLServer optimizer is biased towards using a
clustered index if one is available, since in most tables a clustered
index SCAN is at least as good as a tablescan, and a clustered index
SEEK is almost always better. Perhaps it's just the 1-page table
scenario that's the exception to the rule?

Philip Yale (philipyale@btopenworld.com) writes:[color=blue]
> Not strictly true. The clustered index only directs the optimizer to
> the *PAGE* on which the row is located, since the index node rows in a
> clustered index only contain the first key value of the target page at
> the leaf level. (This is not the same as a non-clustered index, which
> would direct the search to the individual record).[/color]

Wait here. This may be true in Sybase, but the row locator in MS SQL
Server for a non-clustered index in a table with a clustered index is
the key value of the clustered index.

So I would assume that the index structure in MS SQL Server extends down
the page as well. The gory details of this are described in Kalen Delaney's
"Inside SQL Server 2000", although I have to admit that I have not
read that chapter myself.
[color=blue]
> Thus, with a clustered index seek you will still have to read all rows
> on the target page to find those which match / don't match. Because of
> this, I still maintain that the clustered index lookup is more expensive
> than a single-page tablescan, even with row-level locking, since you
> have to read both the index node page and the entire leaf page (at least
> 2 logical reads), as opposed to just a single logical read by scanning
> the 1-page table.[/color]

Maybe it is more expensive for the individual query, but not for overall
performance.
[color=blue][color=green]
>> Exactly how the optimizer avoids this pitfall, I don't know, but it
>> may be as simple that the optimizer stops looking for plans once
>> it has found one which is good enough.[/color]
>
> This isn't (shouldn't be) the way optimizers work. They consider ALL
> possible plans, then slect the "cheapest".[/color]

No, that's not the way an optimizer should work! Because for a complex
query with 12 tables, the optimizer could spend minutes to determine
which of a several sub-second plans to use.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

Erland Sommarskog <sommar@algonet.se> wrote in message news:<Xns94942A5ED283Yazorman@127.0.0.1>...[color=blue]
> Philip Yale (philipyale@btopenworld.com) writes:[color=green]
> > Not strictly true. The clustered index only directs the optimizer to
> > the *PAGE* on which the row is located, since the index node rows in a
> > clustered index only contain the first key value of the target page at
> > the leaf level. (This is not the same as a non-clustered index, which
> > would direct the search to the individual record).[/color]
>
> Wait here. This may be true in Sybase, but the row locator in MS SQL
> Server for a non-clustered index in a table with a clustered index is
> the key value of the clustered index.
>
> So I would assume that the index structure in MS SQL Server extends down
> the page as well. The gory details of this are described in Kalen Delaney's
> "Inside SQL Server 2000", although I have to admit that I have not
> read that chapter myself.
>[color=green]
> > Thus, with a clustered index seek you will still have to read all rows
> > on the target page to find those which match / don't match. Because of
> > this, I still maintain that the clustered index lookup is more expensive
> > than a single-page tablescan, even with row-level locking, since you
> > have to read both the index node page and the entire leaf page (at least
> > 2 logical reads), as opposed to just a single logical read by scanning
> > the 1-page table.[/color]
>
> Maybe it is more expensive for the individual query, but not for overall
> performance.
>[color=green][color=darkred]
> >> Exactly how the optimizer avoids this pitfall, I don't know, but it
> >> may be as simple that the optimizer stops looking for plans once
> >> it has found one which is good enough.[/color]
> >
> > This isn't (shouldn't be) the way optimizers work. They consider ALL
> > possible plans, then slect the "cheapest".[/color]
>
> No, that's not the way an optimizer should work! Because for a complex
> query with 12 tables, the optimizer could spend minutes to determine
> which of a several sub-second plans to use.[/color]

[color=blue]
> Wait here. This may be true in Sybase, but the row locator in MS SQL
> Server for a non-clustered index in a table with a clustered index is
> the key value of the clustered index.
>
> So I would assume that the index structure in MS SQL Server extends down
> the page as well. The gory details of this are described in Kalen Delaney's
> "Inside SQL Server 2000", although I have to admit that I have not
> read that chapter myself.[/color]

In our discussion, though, we aren't considering NC indexes, just
clustered. My description of clustered index access is almost a
verbatim quote of the "gory details" in Kalen's book, where she states
explicitly that a clustered index seek only gets as far as the first
record in a data page, not the individual records within that page
(page 420, section headed Nonclustered Index Leaf Rows).
[color=blue]
> No, that's not the way an optimizer should work! Because for a complex
> query with 12 tables, the optimizer could spend minutes to determine
> which of a several sub-second plans to use.[/color]

For a complex query with 12 joins I would agree with you entirely, and
I believe that that is what it does do (for queries exceeding 4 tables
in the join). However, that's not what we are considering here, so
when I said that it should consider ALL joins, I meant it! :-)

I think we're probably reaching the point of diminishing returns in
this discussion now, and that we broadly agree on the explanation -
the single-page example is a special case where the optimizer doesn't
necessarily take the theoretically most efficient path, but since the
overhead is negligible who cares? The approach taken gets
progressively more efficient as table size increases.

My initial surprise at this stems from the fact that Sybase would NOT
choose to use an index (of any sort) over a table scan of a singlepage
table. Since I've moved from Sybase into the SQLServer arena, I'm
still on a learning curve about the intricacies of the SQLServer
optimizer; the temptation is very great to apply many years of Sybase
P&T experience to similar scenarios in SQLServer, but I've quickly
discovered that this simply won't work! Despite their shared history,
they're now two very different animals.

Thanks for the discussion, though - it's good to be forced to think
these things through more fully.

Philip Yale (philipyale@btopenworld.com) writes:[color=blue]
> In our discussion, though, we aren't considering NC indexes, just
> clustered. My description of clustered index access is almost a
> verbatim quote of the "gory details" in Kalen's book, where she states
> explicitly that a clustered index seek only gets as far as the first
> record in a data page, not the individual records within that page
> (page 420, section headed Nonclustered Index Leaf Rows).[/color]

OK, if Kalen says so, it is so. I still suppose it has some smart way to
avoid the keys that are looked.
[color=blue]
> For a complex query with 12 joins I would agree with you entirely, and
> I believe that that is what it does do (for queries exceeding 4 tables
> in the join). However, that's not what we are considering here, so
> when I said that it should consider ALL joins, I meant it! :-)[/color]

That four-table thing is also an oldie. In SQL 6.5, as well as in older
Sybase versions, SQL Server would only consider groups of four, so if
you had

SELECT * FROM a, b, c, d, e WHERE ...

the optimizer would examine all iterations of abcd and bcde.

But this is not true anymore.

--
Erland Sommarskog, SQL Server MVP, sommar@algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp