想请教 大家是怎么解决.客户每天的业务量越来越大.历史数据越来越多,速度越来越慢的问题的?

Question

本人现接触到SQL SERVER 2005 进销存数据库
由于业务量越来越大,现在想弄一个库来做正式前端增删改用,一个来做查询用.来缓解速度慢的作用.
想到下面策略:
1. 用同步复制.     但是不仅会改变数据库本身得结构,同时也增加本身数据库文件的大小.还影响性能.
2. 自己写脚本同步. 由于客户本身业务仅仅允许修改7天内的数据,所以将查询库里面的东西7天内全部删除,然后再从前端库重新同步一次.缺点,只能在临晨无人的时候操作.数据同步延迟最高达一天.同步数据的时候同样占用大量资源.
3.将历史数据移出.但是无法满足客户的部分需求.而且这样同样会影响到大量代码的修改.
4.用BI来实现.BI是一个庞大的系统.不仅得投入大量的资金,还得有大量得维护陈本.
我现在的状况是,
1.希望能有实现同步复制功能.但是又不希望改变它本身的数据结构.也不想影响性能.当然一小点点性能牺牲是可以忍受的.
  晚上很少人使用,影响性能的同步动作可以晚上操作.数据稍微有些延迟没关系,比如15分钟或者半个小时.2.不知道 SQL Server 2005 的Service Broker 的功能能不能实现.想请教 大家是怎么解决.客户每天的业务量越来越大.历史数据越来越多,速度越来越慢的问题的?

Answer 1

这说明你的数据库设计的不合理.
拆分数据库为当前库A(保留7天数据)和历史库B.
7天后的数据转储到历史库B,历史库只供给查询.
如果一定不能改变数据库结构.那么就是用sqlserver自带的复制功能,新添一台发布服务器和订阅服务器,基本可以做到实时同步.
订阅服务器同时作为查询服务器.不想花钱又想稳定快速是很难做到的.

Answer 2

1、历史数据肯定是要移出的。
2、写一个JOB,每天凌晨的时候，把本机前一天的数据更新到备份服务器上。

Answer 3

其实问题就出在这里,如果把历史数据放到备份库中,为了OLTP的实现同样得去改现有的程序,或者是存储过程.
因为客户在销售或者进货的时候,是需要参考到过去到当前为止的销售或者进货情况甚至是明细,来判断是否应该进货或者销售的.如果当前数据库仅仅保留一个月,客户端查询就得同时关联两个数据库,最后来一个合并展现.似乎还得改大量的代码

Answer 4

如果SQL服务器够强大，光纤连接的话
1.做读写分离，建议用SQL2005的复制，同步没什么问题，写就一台机器，然后订阅服务器多台，例子：
一台发布，3台订阅，然后.NET在做缓存处理，这样差不多能行了。
2.表在做分区，按周来做。
3.最好拖一个磁盘阵列柜，STATII的硬盘，做RAID10，IO达到最好状态。
4.索引优化和SQL优化这样下来估计差不多，这当然要投钱的。

Answer 5

貌似SQL SERVER  日志传送 可以实现，就是不知道是否对性能影响严重否？

Answer 6

这个问题很现实。关注ing。。

Answer 7

再顶下下，其实数据量不是很大，总共就20G左右，已经运行2年了。就想知道用那种方式合适些。现在我能想到的选择的方案有：
把历史数据移走
同步复制
镜像后快照
日志传送
Service Broker