对SQL Server 2008数据库进行收缩时，会遇到死锁现象，如何解决。

楼主 可以试试下面的方法：

清空日志
　 DUMP TRANSACTION 库名
WITH
NO_LOG 
2截断事务日志：
　 BACKUP LOG 数据库名 WITH
NO_LOG
3收缩数据库文件
　 数据库名--右击--任务--收缩--文件
　   --文件类型选择日志--收缩 *** 作选择第二个 将文件收缩到0 ,确定就可以了
4 也可以用SQL语句来完成
　 --收缩数据库
　 DBCC SHRINKDATABASE(客户资料)
　 --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select from
sysfiles
　 DBCC SHRINKFILE(1)

收缩的时候把恢复模式改为简单 否则收缩不了 

希望解决了楼主的问题

数据库表死锁和锁表是数据库并发控制中的两个常见问题，通常是由以下原因导致的：

并发访问：当多个事务同时访问数据库中的同一张表时，就会出现并发访问的情况。如果这些事务在 *** 作时没有正确地使用锁机制，就可能导致死锁或锁表的问题。

锁粒度：锁粒度通常是指锁定的数据范围大小，如果锁的粒度不合理，例如过大或过小，就可能导致死锁或锁表的问题。通常建议在进行并发 *** 作时，使用尽可能小的锁粒度，以避免死锁或锁表的问题。

事务处理：如果事务处理不当，例如事务的隔离级别设置不当，就可能导致死锁或锁表的问题。例如，在并发环境下，如果多个事务同时访问同一张表，而其中一个事务占用了一条记录的锁，另一个事务也需要访问该记录，就可能导致死锁或锁表的问题。

针对死锁和锁表的问题，可以从以下方面来定位问题：

锁定信息：查询数据库中的锁定信息，查看哪些表被锁定，以及锁定的粒度、类型等信息。可以使用SHOW LOCKS或者SELECT FROM INFORMATION_SCHEMAINNODB_LOCKS来查询锁定信息。

连接信息：查询数据库中的连接信息，查看哪些连接占用了锁资源，以及锁资源的具体情况。可以使用SHOW PROCESSLIST或者SELECT FROM INFORMATION_SCHEMAPROCESSLIST来查询连接信息。

SQL语句：检查并发 *** 作中使用的SQL语句，查看是否存在锁定粒度不合理、事务隔离级别设置不当等问题，以及是否存在死循环、递归查询等问题。

系统资源：检查系统资源使用情况，查看是否存在内存、磁盘等资源不足的情况，以及是否存在网络延迟等问题。

第一步，查出已锁的进程

查看正在锁的事务

SELECT FROM INFORMATION_SCHEMAINNODB_LOCKS;

``

查看等待锁的事务

SELECT FROM INFORMATION_SCHEMAINNODB_LOCK_WAITS;

``

INNODB_TRX表主要是包含了正在InnoDB引擎中执行的所有事务的信息，包括waiting for a lock和running的事务

select from information_schemainnodb_trx

``

第二步，kill进程

show engin innodb status; //最后一次死锁信息及sql

show open tables where in_use > 0 //查看锁表

为了查看死锁信息，数据库引擎提供了监视工具，分别为两个跟踪标志以及
SQL
Server
Profiler中的死锁图形事件。
跟踪标志
1204
和跟踪标志
1222
发生死锁时，跟踪标志
1204
和跟踪标志
1222
会返回在
SQL
Server
错误日志中捕获的信息。跟踪标志
1204
会报告由死锁所涉及的每个节点设置格式的死锁信息。跟踪标志
1222
会设置死锁信息的格式，顺序为先按进程，然后按资源。可以同时启用这两个跟踪标志，以获取同一个死锁事件的两种表示形式。
SQL
Server
Profiler
中的
TraceEvent
Class:
LocksEvent
Name:
Deadlock
Graph
提供
一个XML
图表，你可以从中看出发生了什么。

可以用sp_who'active'看一下午blk字段是否为0，如是其它数x，说明这个数可能就是锁，再用sp_who数x看一下它下面的blk是否有数，这样查下去，如果它下面没有数并且是查询状态或是等待状态等（除更新及插入状态）都可以用kill数x

oracle的测试例子，使用它的sqlplus连接，默认为非自动提交。如果是MSSQL，则需要你把它的查询选项中的自动提交改为非自动提交
create table t5(id int,sp varchar(10));
declare
begin
for i in 110 loop
insert into t5 values(i,'test'||i);
end loop;
end;
/
session 1(一个连接):
update t5 set id=99 where id=10;------行加IX锁
session 2(第二个连接):
update t5 set id=id+1;-------------表等候加IX锁
session 1:
update t5 set id=id-1 where id>8;------发生死锁，session 2事务回滚

一个事务对数据加了S锁之后，对数据只能进行读 *** 作，在释放对数据的S锁之前，其他事务可以且只能给该数据加S锁。
在T2请求Xlock
A之前，T2已经请求过了Slock
A，其他事务在T2释放对A的S锁之前只能给A加S锁，所以T1因为加X锁失败而进入等待，而T2因为之前的S锁为释放再加X锁导致加锁失败而进入等待

---