请数据库高手帮忙（第４页ｕｐｄａｔｅｄ）

招财猫

我每天需要把一些TABLE从一个SERVER传到另一个SERVER,在SQL SERVER 2005 BI中使用从OLE DB SOURCE和OLE DB DESTINATION,一共70个TABLE,1G左右，用时约6小时，请问这样的速度正常吗？如果速度过慢，主要会是什么原因？网络没有问题。

[ 本帖最后由 招财猫 于 2007-2-24 09:35 编辑 ]

招财猫

jl162401

你的本地硬盘大不大，1G应该有的，你试验一下本机的变成文本，再上传到一个新库的时间，如果小于两个小时，建议你这种方法实现，只不过网络部分需要压缩和解压来实现

招财猫

你是说变成FLAT FILE DESTINATION

jl162401

对的，能不能测试呢，速度慢可能有三个原因：
1、本机数据库慢
2、网络传输问题
3、目的数据库慢
我觉得要分解来看

招财猫

谢谢，另外我传输的TABLE不是整个TABLE,而是里面的某些COLOMN,有没有可能是搜索这些COLUMN慢？

jl162401

你的cloumn是index吗，把SQL发出来看看，如果不是在where条件上做选择，是不影响性能的

袋鼠

直接用sql的import/export function就可以了嘛. 6小时好像夸张了点, 如果两个server在同一个physical location的话.

招财猫

原帖由 jl162401 于 2007-2-12 14:09 发表
你的cloumn是index吗，把SQL发出来看看，如果不是在where条件上做选择，是不影响性能的

这些TABLE& COLUMN用于DATA WAREHOUSE，所以数据较多，没有INDEX,相当于
SELECT FIRSTNAME,LASTNAME，PHONE, DOB.....
FROM EMPLOYEE
这样的语句，所以基本上是SCAN整个TABLE的。

招财猫

原帖由 袋鼠 于 2007-2-12 14:14 发表
直接用sql的import/export function就可以了嘛. 6小时好像夸张了点, 如果两个server在同一个physical location的话.

2005里IS代替了DTS，6小时确实长葛店

jl162401

我是做Data warehouse的，你没有使用index，也没有用where子句，就是选了部分字段，那不会有什么性能上的提高或者影响，如果直接导出成文件比较快的话，不妨一试，全表导出，然后drop字段也是种选择，关键要看慢在哪里了

招财猫

从SERVER A把1G的数据传到SERVER B的FILE上，只用了5分钟，那看起来是在SERVER B插入的时候慢了

jl162401

那找到原因就好办了，呵呵，不会是写了日志，然后一条一条的插入吧，这样肯定特别慢，要分析一下慢的原因

招财猫

log file并不大，除此之外还可能有别的什么原因，一般传1g的东西大概多少时间应该就够了？

典

you may consider partitioned tables (not sure),
you may don't need to transfer 1G per day. Unless your business create new data for 1G per day

袋鼠

原帖由 goldensun 于 2007-2-12 16:15 发表
you may consider partitioned tables (not sure),
you may don't need to transfer 1G per day. Unless your business create new data for 1G per day

yeah. should do delta transfer only.
Don't think there is 1G new data each day.

jl162401

同意，但如何取增量往往是很麻烦的问题，如果1G全量加载的时间很短，可以考虑

招财猫

原帖由 goldensun 于 2007-2-12 16:15 发表
you may consider partitioned tables (not sure),
you may don't need to transfer 1G per day. Unless your business create new data for 1G per day

这正是我解决不了的问题，比如一个employee table,怎么知道谁的电话或地址今天被改动了？有什么好建议？

jl162401

1 数据库日志，可以记录改变的轨迹
2 触发器
3 自己比较两天的数据

个人觉得1G数据没有必要

mileswei2006

”这正是我解决不了的问题，比如一个employee table,怎么知道谁的电话或地址今天被改动了？有什么好建议？ “

jl162401 的方案可行，加trigger。

jl162401

我觉得还是回到原来的问题，关于数据库复制效率低的方面好，解决效率这个问题的思路应该比较简单

袋鼠

原帖由 招财猫 于 2007-2-12 16:33 发表

这正是我解决不了的问题，比如一个employee table,怎么知道谁的电话或地址今天被改动了？有什么好建议？

Quite simple acutally provided you have rights to make the needed changes.

Create an additional field, named "UpdateDate" or something. When a record is updated or created, update this field with current system time.

Alternative, create a trigger to record changes into audit trail table with updating time. From audit trail table, get updated records daily and load into the other server.

江苏小伙子

原帖由 招财猫 于 2007-2-12 15:40 发表
从SERVER A把1G的数据传到SERVER B的FILE上，只用了5分钟，那看起来是在SERVER B插入的时候慢了

Not an SQL Server man. Just try to give some idea.

(1) Physical transfer is always faster, if source db can be brought down, bring it down and transfer the files to server B where
     the files can be attached to database.

(2) If source fetch is no problem. Then the problem will be data insertion/updating on server B if network is OK.

(3) While job is running, check system performance on server B, especially CPU and I/O.

(4) I cannot believe you guys do not have indexes in tables. Double check server B if those tables have indexes, if they do have,
     drop them before the job and recreate them after the job. Or make them temporarily useless during the job execution.
     Try ways to increase DOP. That's the key.

典

原帖由 袋鼠 于 2007-2-12 17:24 发表


Quite simple acutally provided you have rights to make the needed changes.

Create an additional field, named "UpdateDate" or something. When a record is updated or created, update  ...

For updating data, it should be a good idea. I may suggest to use indexed views or normal views, not triggers. (of course, use trigger is a good idea)

Some data may be just new data, not updated data.(For example, Orders). You only need to transfer new records. To this scenario, you may consider to use partitioned tables.

典

原帖由 江苏小伙子 于 2007-2-12 17:36 发表


Not an SQL Server man. Just try to give some idea.

(1) Physical transfer is always faster, if source db can be brought down, bring it down and transfer the files to server B where
     the  ...

Agree

招财猫

1，加trigger我也考虑过，但是怕影响performance，因为公司的数据库比较大，有100多个db，基本上同时有300多人在线，传输到dw的70个table,基本上时时都在更新，如果使用trigger，会大大损害performance.

2，22楼的建议很好，但是所有的application都是第三方开发的，我没有代码，更无法添加代码，如果要第三方添加，他们的consultant来一次就要1000刀，我估计我经理不会愿意付这个钱的。

3，job 运行的时候，我check过server b得performance,一切都很好，cpu很低，page life expectancy大于1000。

所以我不知道问题到底出在那里，或者有什么更好的办法。

jungle

我很奇怪，楼主为什么没有考虑使用Replication Services？是否两个数据库的结构有所不同，在做数据同步时，还有数据转换的操作？

如果不是还要做数据转换，仅仅需要数据同步的话，使用SQL SERVER自带的Replication Services，应该是解决这个问题最简单、方便和快捷的方法啊。你都不用考虑什么自己设TRIGGER取增量，它自己就做了啊。

招财猫

不需要数据同步，只是需要一个dw来做report，每天晚上更新一次即可

jungle

原帖由 招财猫 于 2007-2-13 09:36 发表
不需要数据同步，只是需要一个dw来做report，每天晚上更新一次即可

那么说，楼主你只是需要将几个table的数据从一个数据库，完整地原样传递到另一个数据库？使用Replication Service可以非常容易的解决这个问题。

你应当只需要简单配置一下，使用最简单的Transactional Publication就可以了。Replication Service的好处，就是他可以自动实现增量传递。

文档请参看：
http://msdn2.microsoft.com/en-us/library/ms152485.aspx

我所维护的一个数据库，大小约600M，数据表约100个，每小时与另一数据库完全同步一次，用时不足10秒。

[ 本帖最后由 jungle 于 2007-2-13 09:57 编辑 ]

jl162401

原帖由 江苏小伙子 于 2007-2-12 17:36 发表


Not an SQL Server man. Just try to give some idea.

(1) Physical transfer is always faster, if source db can be brought down, bring it down and transfer the files to server B where
     the  ...

专业！