SQL数据库太大。导致应用系统越来越慢。

Question

大家好：
    我在一家服装公司做。公司里面有一个进销存的软件。服务器是XEON3.0的，2G内存，3块160G SATA2硬盘。WIN2003系统，安装的是SQL2000 打的SP4的补丁。
    这个进销存软件是个C/S系统，公司有15个客户端。外埠也有20多个客户端。数据交换量非常大（具体多少也没有统计过）。数据库增长的也非常迅速。现在大约有27 GB吧。系统也是越来越慢，客户端也反映打开一个界面也很慢。
    我马上用大家经常用的一些方法进行收缩，压缩，减肥。可是效果不大。
    请大家给帮帮忙。出出主意，有什么方法能使数据库减减肥。
    我用WINRAR压缩备份的时候，压了整整一个小时。压完了以后发现才有800MB左右。
    下面是我用的一些方法。可是不管用。大家看看，是不是还有更好的方法。
      [1。凡事弄数据你都先备份，你别管它是嘛~~(备份你会的吧。)　　2。打开你的[查询分析器]--选择好你要减肥的数据库名称　　3。运行代码：DUMP TRANSACTION [你要减肥的数据库名字] WITH NO_LOG(作用：清空日志)　　4。运行代码：BACKUP LOG [你要减肥的数据库名字] WITH NO_LOG(作用：截断事务日志)　　5。运行代码：DBCC SHRINKDATABASE([你要减肥的数据库名字])(作用：收缩数据库文件(如果不压缩,数据库的文件不会减小))　　6。运行代码：DBCC UPDATEUSAGE (你要减肥的数据库名字) (作用：报告和更正 sysindexes 表的不正确内容) ]    1、清空日志DUMP  TRANSACTION  库名  WITH NO_LOG 
2、截断事务日志BACKUP LOG 数据库名 WITH NO_LOG  
3、收缩数据库文件(如果不压缩，数据库的文件不会减小）企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM，这里会给出一个允许收缩到的最小M数，直接输入这个数，确定就可以了。 --选择数据文件--在收缩方式里选择收缩至XXM，这里会给出一个允许收缩到的最小M数，直接输入这个数，确定就可以了。 也可以用SQL语句来完成：--收缩数据库DBCC SHRINKDATABASE(客户资料) 
--收缩指定数据文件，1是文件号，可以通过这个语句查询到：select * from sysfiles DBCC SHRINKFILE(1) 
4、为了最大化的缩小日志文件(如果是sql 7.0，这步只能在查询分析器中进行) a.分离数据库： 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库：企业管理器--服务器--数据库--右键--附加数据库 此法将生成新的LOG，大小只有500多K 或用代码： 下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。a.分离EXEC sp_detach_db @dbname = 'pubs' 
b.删除日志文件 c.再附加：EXEC sp_attach_single_file_db @dbname = 'pubs', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf' 
5、为了以后能自动收缩，做如下设置： 企业管理器--服务器--右键数据库--属性--选项--选择“自动收缩”--SQL语句设置方式：EXEC sp_dboption '数据库名', 'autoshrink', 'TRUE' 
6、如果想以后不让它日志增长得太大。企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式：alter database 数据库名 modify file(name=逻辑文件名,maxsize=20)    以上就是我用的一些方法，也不乏网上一些能人高手给提供的，可就是不行。希望这次大家帮帮我。谢谢大家。

Answer 1

查看一下表的索引：
优化一下:
http://topic.csdn.net/u/20070329/17/38398e78-adac-4d7e-a8b6-f2d319d283e8.html

Answer 2

以上是重建/整理，不是新建索引,日志大说明，数据库频繁insert/update,造成索引碎片，影响系统select的性能

Answer 3

你看下CPU的性能监控，内存使用率，网卡吞吐率，服务器可以考虑再加1个GB的内存，

Answer 4

谢谢大家给了这么多的意见，
首先内存使用在40%多吧。看意思还是够使，CPU跳得让人惊魂，有时候能连续100%，看了一下使用CPU 的进程一个就是SQL另外一个就是进销存的应用服务程序，两个进程。
日志倒不是很大，也就是1MB多点吧。
主要是主数据库大。现在又是27GB了吧。
不知道大家还有谁遇到过这种情况。

Answer 5

CPU占用挺大的，建议换服务器，看看程序代码方面能不能再作些优化不知道LZ公司的系统运行了多久，27G的数据库，业务数据应该在千万数量级吧，这种情况下可以考虑数据库集群+存储了日志最好不要清空，比较好的方法是日志转储，SQL SERVER有这项功能 LOG SHIPPING

Answer 6

看来大家是让俺不要在怎么给SQL数据库减肥上下功夫了呀。我的数据库呀。太大了。5555555555

Answer 7

谢谢8、9、11楼的哥几个，这也是一个不错的方法，我再试试吧，不过数据库过大，我拷都得拷1个多小时，移动硬盘还得要求是NTFS的，受不了。大家遇到过这样子的问题吗。

Answer 8

创建一个作业job，定时的将数据库数据更新到其它磁盘上，确定成功后，在自动删除数据，需要的时候，恢复回来
这样每隔一段时间就备份一次，可以在晚上无人作业的时候做这个操作
就不会涉及数据库转移时间太长问题了

Answer 9

随着数据量的增加，索引的重要性就会显现出来。
首先，profiler出来duration最长的几个sql语句。
然后，看一下execution plan，是不是有大表的table scan。
如果是index seek，可以看下一索引碎片，如果碎片较多，可以重建一下相关索引。

Answer 10

数据库大和速度慢之间没有必然的联系，进销存系统有很多都是写的很差的
我看这个可能和block，IO有关。
楼主应该监控一下block和read很多的语句，提出来分析优化。
CPU跳可能是大规模统计或者block，IO等待造成的。

Answer 11

服务器是XEON3.0的，2G内存，3块160G   SATA2硬盘。
WIN2003系统，安装的是SQL2000   打的SP4的补丁。 
公司有15个客户端。外埠也有20多个客户端。
现在大约有27GB吧。
先内存使用在40%多吧。看意思还是够使，CPU跳得让人惊魂，有时候能连续100%
----------------------------------------------------
从你的用户连接数来看，硬件配置基本够用。
内存使用如果持续在60%一下的，瓶颈不在内存
CPU连续在90%以上的话，或者是CPU有瓶颈，或者是I/O的瓶颈造成CPU忙。你可以看一下I/O的情况，如果I/O也很忙，并且是读操作大大高于写操作的话（多半是这种情况）
那就需要重建索引，以清除索引碎片。（这一步你可以自己做）
另外就是把一些很老的历史数据从当前数据库中移出去。（这一步可能要开发商协助）另外，在这种很慢/忙的系统上面不要随便收缩数据库，还会很快长回去，而且反而造成数据库获得的磁盘空间分布在磁盘不同的位置上，不是连续的一段，反而更慢。你反而应该备份一个数据库，做磁盘碎片整理，还原数据库，并把数据库空间扩大到50G左右，以避免系统忙的时候还去自动扩大。

Answer 12

20楼的哥哥说的也很有见地。谢谢呀，这就按方法去试试。
-----------------------------------
不用谢。因为我们也有和你差不多大的数据库，但是放在SAN上面，所以没必要做磁盘碎片整理这一步。
除了把数据库放在磁盘上一个连续段上之外，然后就是下面两步：那就需要重建索引，以清除索引碎片。（这一步你可以自己做） 
另外就是把一些很老的历史数据从当前数据库中移出去。（这一步可能要开发商协助） 如何你们和开发商合作比较密切的话，再看看能不能优化索引和优化一些效率太低查询。

Answer 13

你可以尝试在建立一个sql 2000环境将读操作分离出来，做个mirror就可以，这样会提高很多。（如果你们公司有钱的话）
如果你们公司不出钱的话，你也可以这样做新建一个同样的表，将现有表中的信息全部导入到新表中，然后将旧表中的信息保留到允许的时间范围里，把不用的数据全部删除，提高查询效率。然后做个JOB每天将新插入的数据导入到新表中，这个在晚上做就可以。如果他们要是需要以前的数据你就可以手工的跑sql就可以了。