none
SQL Server2000 数据库之间存储同步延迟问题~~急需解决 RRS feed

  • 问题

  • 3个数据库服务器,分别是原始库,应用库,产品库。工作原理:全省大约1600个基站的信息汇总于原始库,因为原始库服务器性能比较差,所以只存放不超过3天的数据,原始库通过存储过程,定期向应用库插入数据,原始库和应用库的表结构完全一样。应用库存放3个月的数据。应用库开放给很多部门查询检索的权限。原始库设定每几分钟通过触发器向产品库写入数据。

    现在问题是:原始库中的数据和产品库中的数据不同步,但不是完全导入不到产品库内,延时长达几个小时,因为之前是根据条件,把要插入的数据先存放在一个TEMP临时表中,然后产品库通过存储过程去TEMP表中抓取,这样导致TEMP中的数据越积越多,不能及时的导入到产品库中去。
    所有的过程都是在存储过程中完成,为什么从原始库到应用库同步没什么问题,但从原始库到产品库会有问题?
    请各位高手给予解答,谢谢大家!

    • 已编辑 chris.li 2009年12月21日 5:41
    2009年12月21日 2:29

答案

  • 对于楼主的先写temp表, 再同步的方法导致的延时, 这个只能去分析延时的原因, 是处理慢, 网络慢, 还是处理过程中有block, 根据原因才能出解决办法.

    另外, 一般的数据同步, 直接使用 replication 会比自定义的触发器容易实现和管理. 建议楼主考虑一下.
    2009年12月21日 4:20
  • Hi,

    通过你的描述,觉得事实上你们自己开发了一个简易的replication系统,当然如果是这样的话,用微软的会更稳定高效。

    但是如果要继续查找出你们的问题,你可以从以下方面入手:

    当你把数据搬到应用库的时候,只是简单的insert, delete and update,还有其他的转换处理吗?
    当你把数据搬到产品库的时候呢?

    建议监视一下瓶颈出现在哪? 数据放入temp table的时候(temp database performance)?从temp取数据的时候?还是当数据倒入产品库的时候?
    当找到问题症结了以后,才好下药。
    2009年12月21日 14:19

全部回复

  • 我先说说我的想法,
    1.如果某一笔数据在插入时发生锁表的情况,然而又不能正常解表,直到一个周期才会自动释放,这样可能会导致后面的数据都堆积在那里,不能及时同步。
    2.利用触发器同步到产品库的时候,应用程序中做的例如SUMMARY或者其他的一些逻辑处理如果发生错误是不是没有捕捉到异常,有些运行时异常也有可能导致不能及时同步。
    大家有什么好的意见呀?

     

    2009年12月21日 2:35
  • Why don't use replication? To solve performance issue from root, you are better to redesign database.
    2009年12月21日 2:37
  • 当时设计DB之间同步数据就没有使用应用程序,因为存储过程和触发机制是可以做到数据同步的,而且我们在两个DB表结构都相同的情况下,同步没有问题,但是两个DB表结构不同的情况下,同步出现延时情况
    2009年12月21日 2:55
  • Trigger is expensive, try replication. Also take look at table partition.
    2009年12月21日 3:09
  • 没太看明白, 触发器是数据变更时自动触发的, 怎么会存在"原始库设定每几分钟通过触发器向产品库写入数据"的情况? 通道你每几分钟去update一下原始库?

    2009年12月21日 4:16
  • 对于楼主的先写temp表, 再同步的方法导致的延时, 这个只能去分析延时的原因, 是处理慢, 网络慢, 还是处理过程中有block, 根据原因才能出解决办法.

    另外, 一般的数据同步, 直接使用 replication 会比自定义的触发器容易实现和管理. 建议楼主考虑一下.
    2009年12月21日 4:20
  • 首先谢谢你的回复,我可能描述的不是那么清楚,
    从原始表到应用表数据库同步没有问题,这两个数据库的表结构是相同的
    但从原始库到产品库同步明显出现几个小时的延时,通过存储过程会有一些简单的计算然后写入到产品库中,所以两个数据库表结构会有一些不一样,
    使用temp表是因为直接用触发器比较慢,对机器性能有影响
    2009年12月21日 7:30
  • Hi,

    通过你的描述,觉得事实上你们自己开发了一个简易的replication系统,当然如果是这样的话,用微软的会更稳定高效。

    但是如果要继续查找出你们的问题,你可以从以下方面入手:

    当你把数据搬到应用库的时候,只是简单的insert, delete and update,还有其他的转换处理吗?
    当你把数据搬到产品库的时候呢?

    建议监视一下瓶颈出现在哪? 数据放入temp table的时候(temp database performance)?从temp取数据的时候?还是当数据倒入产品库的时候?
    当找到问题症结了以后,才好下药。
    2009年12月21日 14:19
  • 我自己给出的建议操作

    1、  原始库服务器的临时表中堆积了很多本应该导入到产品库中的数据,但产品库中却没有获得,建议在产品库服务器的SQL Server代理中定制警报,当作业操作调度失败时,发出警报。如果获得警报,可以确定是原始库响应延时导致调度失败,如果没有获得警报,就需要进一步分析产品库服务器的系统及SQL性能日志。

    2、  建议在产品库的数据存储过程语句里面增加针对删除、更新操作的判断语句,并能将失败的操作发送到Windows日志。

    3、  产品库服务器的同步频率是否可以做微调,如从5分钟调到8分钟,这个需要看业务逻辑是否允许。

    4、  在原始库服务器上面新增一套RAID1,在这个新的RAID1上面单独创建一个用于存放临时表的数据库,然后通过修改触发器将新的增删改数据存储到新的数据库的临时表中,以解决磁盘I/O争用的现象。

    5、  对三台服务器做碎片整理,并卸载不相关软件。调整Windows 2000 Server Boot.ini文件的3G内存参数。

    谢谢大家,结了。

    2009年12月25日 9:46