数据库从SQL SERVER 2000升级到2008后插入速度变慢

因为要用到数据库镜像，所以把2000升级到了2008，
还有感觉2008 可能优化了某些查询以为速度回快点


但是升级好后，在业务繁忙的时候，经常死锁，我已经把表的数据移除很多，现在在插入的时候总死锁，或者卡主
延迟严重，
1.后来想想是不是索性建的不对，就把索引全删了再加了一遍
2.利用数据库2008自带的工具“重新生成索引任务”和“更新统计信息任务”，查询我感觉是比以前快了
但是在高峰期的时候还是会卡主，死锁。假如是我程序写的事务不对，那2000也应该会卡主，但是在2000的时候很正常
求大师救命啊!!!

22 个解决方案

#1

是2008没有配置好吧，重新配置下

#2

直接附加上去的话可能存在很多隐患，我个人觉得问题主要有两个：
1、配置问题，毕竟跨越了2代产品，很多配置，特别是对操作系统的利用都不尽相同。建议去找一下2008的配置。重新配置一下。
2、2000使用了大量只有2000才有，但是2008仅仅是兼容而已的语法或功能。使得虽然不报错，但是没发挥出来。如果时间允许，建议全面检查并改进。毕竟这是一次性的动作而已，所以还是建议仔细、并多话点时间。

#3

引用 2 楼  的回复:

直接附加上去的话可能存在很多隐患，我个人觉得问题主要有两个：
1、配置问题，毕竟跨越了2代产品，很多配置，特别是对操作系统的利用都不尽相同。建议去找一下2008的配置。重新配置一下。
2、2000使用了大量只有2000才有，但是2008仅仅是兼容而已的语法或功能。使得虽然不报错，但是没发挥出来。如果时间允许，建议全面检查并改进。毕竟这是一次性的动作而已，所以还是建议仔细、并多话点时间。

昨天我查了半天，发现兼容性还是SQL2000的，后来在测试机器上把兼容性改成了2008，不知道行不行。

#4

引用 1 楼  的回复:

是2008没有配置好吧，重新配置下

能具体说说吗？怎么配置。

#5

昨天忘了说其中一个问题，就是tempdb，新版本对tempdb的使用远远超过过往的版本，所以tempdb如果太小，或频繁增长，将严重影响性能。配置方面我说几个吧，其实这方面太多了，一下子我也记不得那么多，并且要根据业务需要来调试的。下面是我目前想到的：
1、cpu个数，最好保留1个cpu给操作系统，然后其他分给SQLServer；
2、tempdb根据cpu的个数，配置同等数量的tempdb【数据文件】，tempdb的日志文件最好扩大一点，像我现在的生产环境，大概初始化tempdb日志文件是40G。数据文件是10个，初始化2G，限制增长到4G每个。
3、配置SQLServer的最大、最小内存，建议留2G给操作系统。
4、数据库的日志文件和数据文件分开存放到不同的【物理】磁盘。而不是逻辑盘符。
5、如果你的索引重建会短时有效的话，研究一下索引建的是否合理？比如会不会因为一天的数据量而导致索引碎片太多？如果是，那要考虑把索引的填充因子改大（看联机丛书）。
还有一些就是磁盘配置、语法调优了。这些实在太多了

#6

引用 5 楼  的回复:

问你和我没有把兼容性搞成2008有关系吗

#7

最好把兼容级别升级到2008（100），否则后续新功能的开发可能会报错。还有你这句话怎么我看的有点不舒服啊？

引用 6 楼  的回复:

引用 5 楼  的回复:


问你和我没有把兼容性搞成2008有关系吗

#8

引用 7 楼  的回复:

最好把兼容级别升级到2008（100），否则后续新功能的开发可能会报错。还有你这句话怎么我看的有点不舒服啊？引用 6 楼  的回复:

引用 5 楼  的回复:


问你和我没有把兼容性搞成2008有关系吗

呵呵对不起是我打错字了，我没那意思是我字打错了
我原来想问是不是和我没有把兼容性搞成2008有关系吗？
对不起，对不起呵呵

#9

因为兼容级别不仅仅是写法上的区别，可能还包含很多内容。所以既然你升级到2008，那就顺便把兼容模式也跟上去，这样就算报错，也比较容易解决。不然还用2000的兼容级别的话可能用不到2008的特性。

#10

引用 9 楼  的回复:

因为兼容级别不仅仅是写法上的区别，可能还包含很多内容。所以既然你升级到2008，那就顺便把兼容模式也跟上去，这样就算报错，也比较容易解决。不然还用2000的兼容级别的话可能用不到2008的特性。

现在兼容性我也升到2008，想对某些表进行表分区，应该注意什么，网上有些说做了分区反而慢了。有点不确定。

#11

这个主要是升级数据引擎后统计数据没有更新,所以性能开始会变慢.一段时间后就会好了.
也可以有针对性的对瓶颈或常用查询从SSMS多跑几遍,然后 update statistics来提升性能.

#12

exec sp_updatestats

执行一下，全局更新一下索引统计

#13

分区是2005以后非常建议使用的功能，能够降低I/O。对性能的负面影响几乎没有，只要不分得太细就可以了。2008支持999个分区。

#14

昨天我查了半天，发现兼容性还是SQL2000的，后来在测试机器上把兼容性改成了2008，不知道行不行。
---------------------
不行,最好自动生成数据库对象创建文本,在sql 2008中再重新创建对象

#15

楼主先检查死锁的原因吧，是哪里引起死锁，是不是事务中执行先后顺序不一致，事务太长，有没有应用到索引，或者触发器使用不当，这些都有可能引起死锁。

跟踪检查是哪些过程会引发锁的升级，因为锁的升级会很容易导致死锁的出现。

对于不是有关金钱的非重要的业务，Select过程可以考虑使用nolock

Update过程，如当行Update可考虑rowlock

... ... 

#16

Update过程，如当Update一行数据时，可考虑rowlock

#17

引用 11 楼  的回复:

这个主要是升级数据引擎后统计数据没有更新,所以性能开始会变慢.一段时间后就会好了.
也可以有针对性的对瓶颈或常用查询从SSMS多跑几遍,然后 update statistics来提升性能.

已经执行了“重新生成索引任务”和“更新统计信息任务”

#18

引用 14 楼  的回复:

昨天我查了半天，发现兼容性还是SQL2000的，后来在测试机器上把兼容性改成了2008，不知道行不行。
---------------------
不行,最好自动生成数据库对象创建文本,在sql 2008中再重新创建对象

那样还要倒数据过去很漫长的一段

#19

引用 16 楼  的回复:

Update过程，如当Update一行数据时，可考虑rowlock

死锁就是因为插入的时候不知道为什么很慢就卡主了，引起其他程序死锁。
以为是索引加多了引起插入慢，但是检查后，删除索引也很慢

#20

看过等待资源吗？是不是其他有瓶颈？

#21

说一句哦，如果用镜像的话，那么有两种模式，一种会使性能降低点；所以感觉是镜像把事务的时间拉长了，然后再高峰的时候会有很多死锁，镜像有两种方式，同步应用日志和异步应用方式，如果要性能，就用异步应用日志的吧，另外查一查具体死锁的原因，有助于更好的出解决方案，毕竟你现在做的只是小修小改而已。

#22

原来是2000数据库 现在还原到2005上 并发数一高就出错了 死锁
感觉的奇怪的是为什么在2000上是好的，在2005上就出现问题了