得不到正确答鞍打死我也不走!!! (200分)

  • 主题发起人 一剑封喉
  • 开始时间
YCK 兄 :谢谢不吝教诲,不过,象您说的那样,可能是因为网线突然断了或其他重大事故
,那有可能教用户等待,不过一般情况下,如果写数据错误,系统会很快反馈的,而不是
象您说的那样要等很长时间,而且每天我们都会把认为正确的机器上的数据都要重新覆盖一下
另外的两台机器,这样,就会保证每台服务器在正常的情况下都和其他机器上的数据相同

其实我不是想和您较真,您千万不要介意,我只是有些不太明白,国内外那么多大型网站
尤其是一些重要的比如记费或者牵涉到一些重要数据交换的网站,他们不可能没有这种
同步备份吧,否则一旦在某一时间一套系统崩溃。他们该怎么做,就要陪人家钱吗?
 
我的想法:使用触发器,然后再在触发器里面执行“分布式查询”。
这样,一但别个有Update或Insert或Delete就触发了触发器工作。
分布式但询你可以查一下SQLServer的帮助。可以实现远程的查询、插入、更新、删除。
而且这些工作是在SQL Server完成的。


这里有一个分布式查询的小例子:
declare @sql VARCHAR(2000)
declare @sTabelName varchar(255), --要同步的表名
declare @sServer varchar(255), --服务器名称或IP
declare @sUserName varchar(255), --登录到服务器的用户名,一般为sa
declare @sPassWord varchar(32) --用户登录到服务器的密码

/*把表@sTabelName[本地]的数据拷贝到临时表*/

set @sql='select * into tempTbl from '
set @sql=@sql + ' OPENDATASOURCE( '
set @sql=@sql + '''SQLOLEDB.1'','
set @sql=@sql + '''Persist Security Info=True;User ID=' + @sUserName
set @sql=@sql + ';Password=' + @sPassWord
set @sql=@sql + ';Initial Catalog=toys;Data Source=' + @sServer
set @sql=@sql + ''').toys.dbo.'+@sTabelName
EXEC(@sql)

不过,像你那种情况,要用[连接服务器]的方法建立连接而不是用OPENDATASOURCE。

SQL Server里面有连接服务器的说明和例子
 
呵呵, 我们公司早先有这样的系统, 不过我不了解实现机制!
是台湾一家公司写的!
 
当然是用双机热备份,从硬件上实现
 
有人已经解决了你的问题啊,就是通过磁盘阵列。
使用RAID5,除非几块硬盘同时出问题。
 
双机热备份到底是一个什么原理,一个SQLSERVER服务器的数据能够同时保存到多块硬盘上吗?
而不用软件支持?
 
查一本书《SQL Server 2000 开发指南》---清华大学出版社
第761页
 
使用服务器集群的技术,
两台计算机共同使用同一个磁盘阵列(RAID5即可)
对外是同一个网络接口,
当其中一台计算机出现故障时,可以马上切换到另一个服务器
加载数据库也不会需要很长的时间

但是,如果数据库软件引起的错误,
破坏了数据库文件(近来总听有人说SQL Server会这样,不认自己的文件了)
那么磁盘阵列也无济于事,因为破坏也是同步的呀

按照你的说法,可以做成多层的系统,
由中间层负责对多个服务器进行同步更新,
并协调访问的效率,譬如,只要有一个服务器先完成操作,就可以返回成功
访问每个服务器均用独立的线程,

在可靠性和性能之间找到一个理想的位置
 
正如楼上LiChaoHui所说的,双机热备份是两台机器,数据放在同一个磁盘阵列中。
若一台机器出问题,则另一台自动承担起所有的责任,对于客户端没有任何影响,
程序也不用中断。
这种方式的缺点在于:
1、对机器要求高,磁盘阵列也不便宜(相对于PC机),而且必须带UPS。否则,
一掉电,肯定玩完。
2、磁盘阵列若配UPS,可靠性是很高。但是若不幸出事,数据就没了。机器出事倒没
问题。
 
也不像yck说的那样一点都不影响工作,
另一台计算机加载数据库可能需要半分钟的时间
客户端的访问必然不能成功,客户端还会发生数据库连接中断的情况
不过很短时间就可以恢复
 
可是这两台机器是怎么样处理的呢?是不是一台机器暂时不工作,能不能具体的讲一下,
双机热备份的详细操作!多谢!
 
IBM的PPRC或EMC的SRDF异地容灾能否满足您的要求?
 
双机热备份需要两台服务器,一个磁盘阵列(最好RAID5),实际上两台服务器使用的是一个
磁盘阵列,由容错软件监控主服务器和备份服气器。当主服务器发生故障时,容错软件自动
切换到备用服务器,这个过程终端用户基本感觉不到。
这个时候,你就要抢修好主服务器,然后恢复先前工作模式。

但是磁盘出问题就不好办了,所以要使用RAID5,几块硬盘同时坏掉的可能性很小。
另外还得每晚自动备份,即使几块硬盘同时坏掉损失的数据最多是半天到一天的。
然后,每周还要把数据备份到光盘上,异地保存。
 
iamfish兄,你的观点我觉得可行,可是能不能做一个通用的触发器,因为被编辑或修改的
表太多了,在一个数据库的不管每一个表被编辑或增加删除之后都会利用这样的通用触发器
把被修改的部分自动送入备份服务器,使两个服务器数据相同。

不知道有没有高手知道!
 
故障转移群集
在 Microsoft® SQL Server™ 2000 企业版中,SQL Server 2000 故障转移群集支持高度可用性。例如,在操作系统发生故障或执行计划的升级时,可配置故障转移群集以转移到故障转移群集配置中的任何其它节点。这样,可以将系统停机时间减到最少,从而提供高度的服务器可用性。

若要安装、配置和维护故障转移群集,请使用 SQL Server 安装程序。有关升级到 SQL Server 2000 故障转移群集的信息,请参见升级到 SQL Server 2000 故障转移群集。

使用故障转移群集进行以下操作:

在故障转移群集内的多个节点上安装 SQL Server。此操作只受操作系统支持的节点数的限制。
在安装故障转移群集之前,必须安装 Microsoft Windows NT® 4.0 企业版、Microsoft Windows® 2000 Advanced Server 或 Windows 2000 Datacenter Server 以及 Microsoft 群集服务 (MSCS)。

使用故障转移群集必须遵从特定的安装步骤。有关更多信息,请参见安装故障转移群集和处理故障转移群集安装。

为各虚拟服务器指定多个 IP 地址。
SOL Server 2000 允许使用所有可用的网络 IP 子网,以便在一个子网出现故障时可以通过另外的方法连接,并且提高了网络的可伸缩性。例如,如果使用单个网卡,当网络出现故障时会使通讯中断。但是,如果在服务器中有多个网卡,而每个网卡都可以在不同的 IP 子网上。即使一个子网出现故障,至少还有一个连接可以继续工作。如果一个路由器出现故障,而 MSCS 继续运行,则所有 IP 地址仍然有效。然而,如果本地计算机上的网卡出现故障,则通讯仍将中断。有关更多信息,请参见创建故障转移群集。

从群集 SQL Server 配置的任何节点上管理故障转移群集。若要执行安装任务,必须从群集磁盘资源控制下的节点上进行安装。有关更多信息,请参见创建故障转移群集。


允许一台虚拟服务器将故障转移到故障转移群集配置上的任何其它节点。有关更多信息,请参见创建故障转移群集。


使用安装程序在故障转移群集配置中添加或删除节点。有关更多信息,请参见维护故障转移群集。


在不影响其它节点的情况下,在故障转移群集内的任意节点上重新安装或重建虚拟服务器。有关更多信息,请参见维护故障转移群集。


使用 Microsoft 搜索服务与故障转移群集执行全文查询。有关更多信息,请参见在故障转移群集中使用 SQL Server 工具。
支持多个实例
故障转移群集还支持多个实例。多实例支持使其更便于在故障转移群集环境中生成、安装和配置虚拟服务器。应用程序可以连接单个计算机上的每个实例,其方法与连接运行在不同计算机上的 SQL Server 实例基本相同。有关虚拟服务器的更多信息,请参见创建故障转移群集。

使用多实例支持可以隔离工作环境(例如,将测试同生产隔离)或易变的应用程序环境,并为同一台计算机中的各 SQL Server 实例设置不同的系统管理员。有关更多信息,请参见多个 SQL Server 实例。

 
大型 Web 站点或内部联机事务处理 (OLTP) 系统的数据必须高度可靠。数据必须是一年 52 星期、一星期 7 天、一天 24 小时可用。在群集应用程序层中,丢失一个服务器可能会降低系统性能,但不会使整个系统停止运行。群集中剩下的服务器将重新平衡负荷,直到可以将替换服务器插入群集中。

虽然 Microsoft® SQL Server™ 2000 不支持这类负荷平衡群集,但支持 Microsoft 群集服务故障转移群集。故障转移群集支持每个群集有一到四个服务器,具体取决于操作系统。群集在应用程序看来就象是单个虚拟服务器。如果主服务器节点出现故障,另一节点将检测出主服务器节点丢失,并自动开始为所有发送到虚拟服务器的请求提供服务。群集在备用节点下保持运行,直到修复或替换主服务器。故障转移群集有助于提供高度可用性,但不执行任何负荷平衡。

 
顶部