deadlock errors 1204 and 1205 differences

I believe there are 2 error numbers related to deadlocks 1204 and 1205. What
are the differences and when may i see one over another ? Using SQL 2000Hi
Error 1204 is issued when there is a process can not take out a lock rather
than the process being deadlocked. This is a resource problem and the number
of locks can be increased using sp_configure.
See Books Online:
mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\trb
lsql.chm::/tr_reslsyserr_1_6gxg.htm
Error 1205 is issued when a deadlock is detected. Check out "Inside SQL
Server 2000" by Kalen Delany ISBN 0-7356-0998-5 on how to detect and solve
deadlock problems.
John
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:utZq8LR%23DHA.1632@.TK2MSFTNGP12.phx.gbl...
> I believe there are 2 error numbers related to deadlocks 1204 and 1205.
What
> are the differences and when may i see one over another ? Using SQL 2000
>

deadlock errors 1204 and 1205 differences

I believe there are 2 error numbers related to deadlocks 1204 and 1205. What
are the differences and when may i see one over another ? Using SQL 2000Hi
Error 1204 is issued when there is a process can not take out a lock rather
than the process being deadlocked. This is a resource problem and the number
of locks can be increased using sp_configure.
See Books Online:
mk:@.MSITStore:C:\Program%20Files\Microso
ft%20SQL%20Server\80\Tools\Books\trb
lsql.chm::/tr_reslsyserr_1_6gxg.htm
Error 1205 is issued when a deadlock is detected. Check out "Inside SQL
Server 2000" by Kalen Delany ISBN 0-7356-0998-5 on how to detect and solve
deadlock problems.
John
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:utZq8LR%23DHA.1632@.TK2MSFTNGP12.phx.gbl...
> I believe there are 2 error numbers related to deadlocks 1204 and 1205.
What
> are the differences and when may i see one over another ? Using SQL 2000
>

DBREINDEX/INDEXDEFRAG a few questions

I pretty much understand the differences between DBCC DBREINDEX and DBCC INDEXDEFRAG. However, I need the forums help to understand a few specific issues relating to clustered/non-clustered indexes and the advantages/disadvantages of running the DBCC DBREINDEX/INDEXDEFRAG against the table or against each specific index...

"If a table has a clustered index, it's only necessary to re-index the clustered index because any non-clustered indexes on that table will be automatically re-indexed as well."

I think the above statement is true for DBCC DBREINDEX but is the following statement true for DBCC INDEXDEFRAG:-

"If a table has a clustered index, it's only necessary to Index Defrag the clustered index because any non-clustered indexes on that table will be automatically defragged as well."

Following on from the above, is there any advantage with an index maintenance strategy to individually running DBCC DBREINDEX against each specific index as opposed to running it against the table and letting SQL sort out the underlying indexes? Does the same apply to DBCC INDEXDEFRAG?

Regards,

Clive"If a table has a clustered index, it's only necessary to Index Defrag the clustered index because any non-clustered indexes on that table will be automatically defragged as well."

I just did a test of this, and the answer is no, the non-clustered indexes will not be defragged as well. This works out as a slight benefit to indexdefrag, as it saves you the time of rebuilding the non-clustered indexes at the same time as the clustered index.

If you have all non-clustered indexes, then there would be a slight benefit in space-savings by running dbcc dbreindex on each index separately. If there is a clustered index, then running dbreindex on the clustered index rebuilds all of the indexes. This would be a waste of any time spent on each index being rebuilt individually. Does this help?|||Yes, that helps. Thank you. In fact, I just put together a test myself and found the same result. Not unsurprisingly, the DBREINDEX produced 100% scan density on the clustered index and the same or close to it on the non-clustered indexes. However, I was surprised that INDEXDEFRAG on the clustered index actually lowered scan-density by a few percent!

Regards,

Clive|||What was the scan density when you started?

The main problem with indexdefrag is that it is only moving pages from and to page locations that are already allocated to the index being defragmented. It may coalesce some unused space among these allocations, but it does not touch anything that is already allocated to another index page or data page of the table. Since it has to work around all of these prior allocations, you almost never get a nice 100% result from indexdefrag, unless all you had to start with was the clustered index.