送分啦，走过路过不要错过啊，远程数据库数据同步问题

[习惯性蹭分]

现在有需求需要同步几个远程数据库的数据，实时要求不高，现在是通过JOB，定时同步数据。
一种是 推数据：各个数据库往中央服务器插入数据。这个要求各个数据库都加JOB（比较麻烦不好统一管理）
第二种：直接在中央服务器添加JOB从各个数据库拉数据。
问题是要JOIN多个表数据，JOIN远程表速度的速度会不会比较慢。
请问那种效率会快一点？

[--小F--]

链接服务器可能存在不稳定的状况。可以考虑用JOB调用。

[习惯性蹭分]

引用 3 楼 fredrickhu 的回复:

链接服务器可能存在不稳定的状况。可以考虑用JOB调用。

现在已经添加链接服务器，在JOB的存储过程中通过 链接服务器 访问远程数据库的。用到远程的多个表（有JOIN多个表）。 这样速度会不会很慢？

[习惯性蹭分]

引用 1 楼 x_wy46 的回复:

dblink访问远程数据库的话，不会用到统计信息，可能会产生比较差的执行计划，建议加hash join hint提示，

MSSQLSERVER怎么用hash join

[专注or全面]

引用 5 楼 tangguangqiang 的回复:

[quote=引用 1 楼 x_wy46 的回复:] dblink访问远程数据库的话，不会用到统计信息，可能会产生比较差的执行计划，建议加hash join hint提示，

MSSQLSERVER怎么用hash join[/quote] 就select * from A inner hash join B on A.id=B,id where ……这种

[还在加载中灬]

如果需要远程JOIN 组织架构类似的数据，建议在本地存一份，定期同步即可，常用又不易更新

[zhrongr]

各有利弊，像你说得第一种不好统一管理，第二种连接多个表，效率是会有影响得，而且不稳定。

[习惯性蹭分]

引用 7 楼 ky_min 的回复:

如果需要远程JOIN 组织架构类似的数据，建议在本地存一份，定期同步即可，常用又不易更新

分公司的数据不一样，需同步到中央服务器，如果是推数据的话，可以先将本地数据作join处理及相关条件过滤， 然后再插入中央服务器。 如果拉数据的话，在中央服务器会JOIN处理及过滤远端数据库数据，这样速度比较慢。

[习惯性蹭分]

引用 10 楼 Tiger_Zhao 的回复:

应该是推数据比拉数据效率高。 有过对比测试，是英文文档，还有人做了翻译。 不过Push、Pull关键字实在太大众了，文档一时间搜不到。（无奈摊手）

远程Join的话，sqlserver会不会是把语句发送给远程，然后直接返回结果就可以，就像调用存储过程一样。 这样的话速度就应该不会慢了。 乱想的。

[还在加载中灬]

感觉第一种要好点 可以只有总部一个固定IP 另外，从各分部可以结合各自情况进行数据分析推送，也能起到压力分摊

[浪淘沙1997]

定時同步吧 坐等高人出現

[KeepSayingNo]

建议用第一种方式，第一种方式比较灵活，每个服务器都可以定义不同的周期

[Tiger_Zhao]

应该是推数据比拉数据效率高。
有过对比测试，是英文文档，还有人做了翻译。
不过Push、Pull关键字实在太大众了，文档一时间搜不到。（无奈摊手）

[Yole]

异地查，本地插。（建议第二种） 第一种权限、环境都不好配。

[卖水果的net]

使用第二种，每次只在同一台机器上操作就可以了，要是说效率，两种方法应该差不多。

[霜寒月冷]

话说，写成程序同步，可追溯日志好些吧。调试也方便

[LongRui888]

建议做数据库的同步吧，这种 通过数据库连接的操作，的sql语句，性能会非常差。

[LongRui888]

应该是做数据库复制 ，把数据复制到一个中央数据库中

[Tiger_Zhao]

先把不同服务器的数据同步到一起，再做JOIN操作。

[悬崖跳舞被人砍]

听说送分我才进来的~！

[程序员鼓励师]

第二种