你们说的都没错。呵呵。 -camryv6(busy!!!) @佛州华人论坛:佛州枫下论坛 The Rolia Forum of Florida

你们说的都没错。呵呵。

camryv6(busy!!!)

可是跟问题不太相关也回答不了问题，是不是？：）

我用大白话说吧。数据同步和trigger之间的协调问题，是数据同步的基本常识，我相信任何商业数据库系统或同步工具都不会没有solution。至少我接触过的多种数据库系统或数据同步软件都解决地很好。任何人在开发或设置数据同步之前不了解这个基本常识，不客气的说是不称职的。我们公司的数据同步并不发生在sql server 之间。但是由于我明白这个道理，所以很快在msdn上找到了答案，并回复了楼主。

我不是XB，而是看到楼主真的挺着急，所以花了几分钟看了他的问题，并帮助解决了。我还在等他说谢谢呢。

(#2171909@0)
Last Updated: 2005-3-11
This post has been archived. It cannot be replied.

我把我的问题贴在experts-exchange上了，SQL Server 高手请看看吧。 http://www.experts-exchange.com/Databases/Microsoft_SQL_Server/Q_21347088.html -holdon(try again); 2005-3-11 (#2171724@0)

the simple and easy way is to use the log shipping as your DRP solution. -yangn(Raymond); 2005-3-11 (#2171734@0)

多谢提示。我怎么以前从未听说过log shipping。查了一下，http://www.sql-server-performance.com/sql_server_log_shipping.asp，好像不是实时的，需要定期复制，会造成数据丢失阿。 -holdon(try again); 2005-3-11 (#2171770@0)

replication and log shipping are two different DRP solutions. Each has its own pros and cons. But no solution is real time unless you apply the cluster one. -yangn(Raymond); 2005-3-11 (#2171817@0)

我感觉replication 能基本满足我的需要，cluster 没做过，感觉就是双机容错的概念，两台机器物理上要在一起吧。 -holdon(try again); 2005-3-11 (#2172025@0)

不必. -yangn(Raymond); 2005-3-11 (#2172155@0)

http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx#EKAA http://www.sql-server-performance.com/rn_sql_server_clustering_2000_to_2005_1.asp 都说要共享磁盘阵列阿。 -holdon(try again); 2005-3-11 (#2172221@0)

你说的是标准CLUSTER,已经落后了,用的是所谓的"share nothing",NODE之间公用 STORAGE,一般NODE之间有效距离不超过10 KM,但这个技术只能做HIGH AVAILABILITY不能作DRP,因为SHARED STARAGE 很容易成为the single point of failure. -yangn(Raymond); 2005-3-11 {88} (#2172243@0)
GEO CLUSTER 是NODE 自己带QUORUM DISK, 彼此之间的同步是通过HARDWARE 而非SOFTWARE来实现的.

1. Never use replication( this is what micorsoft suggested for us in my preious project) If any small problem happen your database will be in trouble. -nealzhao(neal); 2005-3-11 {71} (#2171809@0)

2. If your boss really wants make the database 100% online. use cluster

MS 从来没说不应该用REPLICATION. REPLICATION 有它自己的条件和限制.比如要用TRANS REP,你必须确定所有的ARTICLE TABLE 都有PRIMARY KEY DEFINED.而且当你每次改变那些replicaed table structure, 你必须重新建立REPLICATION. -yangn(Raymond); 2005-3-11 {203} (#2171828@0)
这是它的麻烦部分.并且对于大型DB来说,每次作SNAPSHOT REPLICATION的时候,,primary db有可能会被LOCK住.但是在某些情况下 REPLICATION 还是很好的SOLUTION的,比如你如果要把SECONDARY SERVER 作REPORT SERVER 用的时候.

是一个内部的工程师，在我们再三追问下，不得已告诉我们的。尽量不要用它，特别您有IDENTITY 字段的时候。当然这与不同应用有很大的关系。我说的也许有点夸张。:-) -nealzhao(neal); 2005-3-11 (#2171844@0)

hoho，别争了，回答问题要在点子上，能回答就回答，说这些虚的有什么用？面试时你要是这么回答，120% fail。得罪 -camryv6(busy!!!); 2005-3-11 (#2171852@0)

还是多说2句吧. -yangn(Raymond); 2005-3-11 {214} (#2171867@0)
相对于其它SOLUTION, REPLICATION相对复杂一些.但不代表它不能用.但很多情况下,不少人用的不是地方. REPLICATION 是非常好的OFF LOADING SOLUTION, 但如果你要把他当作HIGH AVAILABILITY 或者是 DRP SOLUTION, 它的局限性就出来了.

同意。多数在于使用一些技术时没有考虑他的局限性。不过还是帮楼主想想办法吧。 -nealzhao(neal); 2005-3-11 (#2171891@0)
你们说的都没错。呵呵。 -camryv6(busy!!!); 2005-3-11 {514} (#2171909@0)
可是跟问题不太相关也回答不了问题，是不是？：）

我用大白话说吧。数据同步和trigger之间的协调问题，是数据同步的基本常识，我相信任何商业数据库系统或同步工具都不会没有solution。至少我接触过的多种数据库系统或数据同步软件都解决地很好。任何人在开发或设置数据同步之前不了解这个基本常识，不客气的说是不称职的。我们公司的数据同步并不发生在sql server 之间。但是由于我明白这个道理，所以很快在msdn上找到了答案，并回复了楼主。

我不是XB，而是看到楼主真的挺着急，所以花了几分钟看了他的问题，并帮助解决了。我还在等他说谢谢呢。

对，这点是很讨厌，做完replication,改了一个store procedure, 发现还要手工去改另一个server的。另外加了一大堆超长名字的trigger，看了让人头晕。 -holdon(try again); 2005-3-11 (#2172038@0)

first of all, SQL server sucks. But your problem can be resolved anyway. -camryv6(busy!!!); 2005-3-11 {153} (#2171821@0)

apply "NOT FOR REPLACATION" option for your triggers. Read doc carefully b4 you take any action this time. :) Don't screw thing up anymore. Good luck.

呵呵，哪个数据库不suck阿，oracle? 我在 Linux 8, 9 上装过，安装过程本身就能让人疯掉，这里一个补丁，那里一个错误，怪不得Oracle DBA挣那么多:-) -holdon(try again); 2005-3-11 (#2172083@0)

我个人的感觉，replication如果用的好，还是有很多好处的。比如我目前这个项目，log shipping 恐怕就不行。 -holdon(try again); 2005-3-11 {447} (#2172003@0)

看了一下，感觉log shipping 就是自动的backup/restore. 但是我的项目第一要求尽量少数据丢失，实际上我们每天晚上已经作了backup。这个客户的production server 实际情况是数据库大(1G), 带宽小（Sympatio Business DSL+VPN, 上传也就40K左右吧。standby server 在我们公司。如果backup, ftp 要7个小时。replication的好处是可以不停的传数据，中断/重联后也只需要传更新的数据，速度相对快的多。Camryv6 的建议很对，应该用NOT FOR REPLACATION，不过我得小心小心再小心这次:-(

1 G 的数据库绝对不算大. TD EASY WEB 的WEBFUNDS 部分有20个GB, 我一样可以用LOG SHIPPING. 你所说的带宽问题自然会影响到两SERVER 之间的传递,但不会只影响LOG SHIPPING ,也会同样影响 REPLICATION 的吧. -yangn(Raymond); 2005-3-11 {327} (#2172122@0)
在正常情况下,你的REPLICATION受影响不大,因为传递的只是TRANSACTION.可是如果REPLICATION 必须重新SET UP了,你就知道那个SNAPSHOT是多慢了.可能你的PRIMARY DB 很少结构上的改变,否则每一次你都要把REPLICATION中止,改变以后REPLICATION就要重新开始.

个人的感觉,如果STANDBY SERVER 只是在SWITCH OVER的时候才会被用,REPLICATION 绝不是最佳方案.

你说的很对。我说1G大是相对带宽而言。 -holdon(try again); 2005-3-11 {180} (#2172153@0)
这个数据库是别人开发好了的，我们只负责维护，数据结构基本不会动了，store procedure 我可以手改。我建snap shot 大概用了几个小时，还可以接受。当让如果是20G的Snap shot, 那就另当别论了。

如果不记成本的话,你的这种情况最好的解决方案是GEO-CLUSTER. -yangn(Raymond); 2005-3-11 (#2172168@0)

成本当然要计拉，否则用得着我一个程序员冒充DBA吗:-( -holdon(try again); 2005-3-11 (#2172187@0)

接受Camryv6的批评。仔细阅读了楼主的帖子。 -nealzhao(neal); 2005-3-11 {399} (#2172137@0)

1。使用internet 来做Replication是不可靠的。我不知道你有多少个节点。我们以前做过类似的项目，那简直是nightmare。一切没有问题肯定好好的。一旦服务器，网络，identity字段出现问题，订阅/发布会停止，很难恢复。SQL Server 还没有聪明到DBA的程度。

2。Identity 对于大型的数据库，不是十分好用，见机自己编写store procedure管理这些字段。

3。我们客户时使用的第三方软件实现这个功能的。你可以网上看看相关的产品。

1. 这个确实比较让人担心。目前只有两个节点，以前测试时确实有中断的。 -holdon(try again); 2005-3-11 {144} (#2172185@0)
2。大型数据库都用ID啊，自己写很难达到同样的效果吧。我感觉SQL Server 2000在Identity方面还是有很大改进的，

3。客户是小公司，才不会花这个钱呢。
不客气，批评不敢当。我也是看到楼主说搞坏了客户数据才出手，不想有同胞因此而失去工作而已。 -camryv6(busy!!!); 2005-3-11 (#2172207@0)

多谢：-) 我和老板比较铁，还不至于丢掉工作。数据昨天晚上已经恢复了。现在怎么样下次做更可靠。 -holdon(try again); 2005-3-11 (#2172227@0)

No problem. Just take it easy... -camryv6(busy!!!); 2005-3-11 (#2172756@0)

this is exactly why sql 2005 introduces database mirroring for standard edition or above. -speed(如风); 2005-3-11 (#2172226@0)

本质上来说,SQL 2005 MIRRORING 和LOG SHIPPING 的原理相似,自然也会受到NETWORK BANDWIDTH的影响的. -yangn(Raymond); 2005-3-11 (#2172258@0)

我现在用三种放法 1.短距离 SQL2000 n-nodes cluster 2. 中距离用SAN STORAGE自带的工具如mirror view通过光纤从存储底层同步.3. 远距离LOG SHIPPING -chinatiger(能曾金刚的生神); 2005-3-12 {119} (#2174252@0)

my 2 cents: SQL replication is not really for high availability it is pretty good for high traffic remote data consumer

完全同意楼上的意见，讨论了半天，最有效的办法就是Cluster，最不可取就是replication中的Merge，互相影响，最后那边都不稳定。 -houseless(糊涂); 2005-3-12 (#2175581@0)

@Florida

你们说的都没错。呵呵。

Replies, comments and Discussions:

More Topics