摘要：使用RCSI可以使普通的数据库读取操作不再善用Share Lock，但不是所有的读操作都不会被阻塞。 我一开始就把这个“读取操作”无限放大，认为从此不再有读/写操作相互阻塞的事情了。下面是不久之前系统里的一个例子，用来说明更新操作中，当SQL SERVER引擎用来确认更新范围的时候并不会读取快照，而是会使用和X锁不兼容的U锁。因此，即使一个语句的最终结果不会更新任何记录，他还是有可能会被阻塞。[代码] 开两个会话分别执行SegmentA和SegmentB，会发现，SegmentB被阻塞。查看会话和锁情况： 解决办法比较笨，将Where条件更换为使用临时表：[代码] 因为我们没有想到更好的强迫S 阅读全文

摘要：自己写来玩的，只做测试用。使用sys.dm_tran_locks表Resource_description列值。完全不排除不准确的可能 只适用Clustered Index，Non-Clustered Index使用DBCC PAGE更快一些。[代码] 用法: usp_PKHash N'TableName', N'PKColumnName', N'Filter' 阅读全文

摘要：今天改一处效率问题，对一个临时表进行分段累加计算，累加方式为累积(Cumulative Aggregations),大约9万条记录的表，时间超过三分钟。执行环境：SQL SERVER 2005 ENTERPRISE EDITION8 CPU CORES16G MAXSERVERMEMORY累加算法如下：代码 执行计划可以想象，内连接驱动假脱机(Inner Join Drived Eager Spool)。其中假脱机运算符占据了多数的CPU时间。 一开始打算使用开窗聚合函数(Window Aggregations)，查资料发现SQL SERVER 2005只为聚合函数实现了带Partion语句的 阅读全文

摘要：今天修改一处并发问题，小记如下。 程序的核心代码包括以下存储过程(示例代码，未包含索引及TRY..CATCH逻辑)。持锁存储过程 程序的基本逻辑是这样的： 程序在并发条件下经常出现超时情况，Profiler截取GenerateLSH执行时间没有发现明显规律。 转而一想，由于启用了RCSI，是否跟存储过程中唯一的一句Update语句有关。因为只有这一句会持有KEY锁。这个存储过程只能是线性执行，其持有的KEY锁生命周期为: @time = TimePoint(Commit Tran) - TimePoint(Exec Proc) 以程序30秒的超时间隔计算，允许的并发数可粗略计算为： @coun 阅读全文