日期：2011-05-02 15:22:00 来源：本站整理

SQL Server 2000之日记传送功效 - 描写（2）[MSSQL防范]

赞助商链接

分享到： QQ空间新浪微博腾讯微博人人网

　　本文“SQL Server 2000之日记传送功效 - 描写（2）[MSSQL防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
角色变更、角色交换、以及监控服务器所在位置

??? Step 4: 告诉监控服务器角色已变更 sql server 2000 的日记传送会在监控服务器上安装监控工具程序;最好是在第三台服务器.为了告诉监控服务器日记传送的角色已经过变更,您必须在监控服务器上履行 sp_change_monitor_role 预存程序,如程序代码列表3所示.固然名称内含有 change 字眼,但它并不会变更监控服务器的角色.相反地,此预存程序会变更主要/次要服务器内档案分享所参照(reference)的位置.意思是说:监控服务器 log_shipping_secondaries 资料表内原先参依旧次要服务器的资料会被删除.而在 log_shipping_primaries 资料表内则是将旧主要服务器名称更改成新主要服务器名称.此预存程序并不会将资料新增到 log_shipping_secondaries 资料表,因为新的配对服务器目前还没有建置.
?
?????? 程序代码列表 3: 将角色交换后果告诉监控服务器之预存程序.

USE master
GO
EXEC msdb.dbo.sp_change_monitor_role
????? @primary_server = 'oahu\sql2k_1' ,
???? ?@secondary_server = 'oahu\sql2k_2',
????? @database = 'Pubscopy',
????? @new_source = 'oahu\sql2k_2'

????? 步骤 5: 在次要服务器上解析登入帐号 您必须先在新主要服务器上解析旧主要服务器登入帐号,利用者才可以存取新主要服务器;方法是利用步骤1所汇出之登入帐号档案.此汇出档案可被 sp_resolve_logins 预存程序所读取,然后解析各服务器间 SID 的差别.举例来说,程序代码列表4示范如安在新答复的 Pubscopy 数据库上履行 sp_resolve_logins 预存程序,去解析本来的登入帐号.BOL文章曾教导您必须在目的数据库内才能履行该预存程序.事实上,sp_resolve_logins 利用了非完好式参照(unqualified reference)指向 syslogins 视观表,所以您必须在 master 数据库内才能履行此预存程序!
?
??????? 程序代码列表4: 在次要服务器上解析登入帐号的预存程序.

USE master
GO
EXEC sp_resolve_logins
????? @dest_db = 'Pubscopy',
????? @dest_path = 'd:\',
????? @filename = 'syslogins.dat'

?????? 步骤 6: 连结数据库存取与权限 BOL 关于角色变更的相关谈论仅止于步骤5,但是它忽视一个重要步骤:在 "数据库存取权限" 与 "转移后登入帐号" 之间举行协变更作.为了在新主要服务器内线上数据库,将移转后已解析的登入帐号连结至相对应的数据库利用者及其权限,您必须履行针对每个登入帐号履行一次 sp_change_users_login 预存程序.

USE pubscopy
GO
EXEC sp_change_users_login 'Update_One', 'UserName', 'LoginName'

??????? 履行该预存程序可确保 SQL Server 登入帐号可以精确地连结相对应的数据库利用者名称.
?
??????? 到此为止,您已经成功地将次要服务器进级为新的角色,而旧主要服务器也早已变成次要服务器.但是,您仍旧还没有建置新的日记传送关系.您完成的只是角色变更,而不是角色交换.
?
角色交换

??????? 为了达成完好的日记传送角色交换,您只需在新主要服务器与新次要服务器之间重新设定一第二天志传送便可.因为新主要服务器已内含崭新的数据库保护筹划,您将会偏向在保护筹划内直接加入新次要服务器,做为目的服务器.但是经过多次尝试之后,我发现新主要服务器的 "交易日记备份工作" 老是会失利,并且日记也不会重新主要服务器传送到新次要服务器.
?
??????? 所以,您需求别的一种办法.您在履行过日记传送角色变更的预存程序,以及先前我具体阐明的步骤后,便可以直接达成完好的角色交换 - 在新主要服务器与新次要服务器之间建置一份新的日记传送筹划.为了建置该筹划,您需遵守下列步骤:
1.??????? 在新主要服务器的数据库保护筹划内移除日记传送功效.
2.??????? 在主要服务器上删除数据库保护筹划.
3.??????? 在次要服务器上删除数据库保护筹划.
4.??????? 保持全部交易日记文件.
5.??????? 在新主要服务器上成立一个新的数据库保护筹划,指定新次要服务器所在、目的数据库位置、以及交易日记文件之得当存放位置,好像我在 Part 1所介绍的内容.
6.??????? 重新开始新主要服务器的全部活动.
?
??????? 在您成功设定角色交换且建置新日记传送配对服务器之后,Enterprise Manager 的日记传送监督器大概会奉告您新次要服务器数据库并未与新主要服务器数据库获得同步(out of sync).假如 "近来一次加载的交易日记" 与 "近来一次备份的交易日记" 之间的时间差超越了 out-of-sync 设定值,您就会收到此报告.直到近来一次的备份资料被加载之后,日记传送监督器就会回到普通无错误状况.
?
日记传送监督器所在位置

????? Microsoft 激烈倡议将日记传送监督器置放于独立服务器上.如此一来,无论主要服务器或是次要服务器履行工作失利时,该监督器城市送出警示(alert).假如监督器位于主要或次要服务器此中之一,报告后果将取决于监督器所在服务器.假如监督器所在服务器因故停摆,它将无法持续回报大概的错误情形.所以,要让监督器独立回报日记传送系统内主要或次要服务器上大概发生的问题,赐与监督器一台独立服务器是较佳的实作方法.此外,也可以利用这台独立的监控服务器去监控别的日记传送配对服务器.
?
??????? 假如没有别的服务器可安装监控程序,而需求放在主要或次要服务器此中之一.毕竟应当把日记传送监督器放在哪台服务器呢?因为重点是想侦测主要服务器上大概发生的日记传送问题,所以放在次要服务器对比妥当.假如将日记传送监督器放在主要服务器上,当主要服务器停摆时,您就无法利用该监督器,监督器也无法在日记传送发生问题时送出警示.所以呢,假如只有两台服务器可以利用,次要服务器为置放日记传送监督器较佳的位置.某些时刻,为避免灾难发生时影响次要服务器,必须将交易日记从某一实体位置传送到另一个地方(大概有一段距离).在此情形下,日记传送监督器最好放在别的地方的独立服务器,让灾难发生时不至于影响主要与次要服务器. 　　以上是“SQL Server 2000之日记传送功效 - 描写（2）[MSSQL防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：

Windows 搭配 IIS7 PHP MySQL 环境

sqlserver索引的原理及索引成立的注意事项小结

SQL Join的一些总结(实例)

SQL的Join利用图解教程

SQL中JOIN和UNION辨别、用法及示例介绍

关于SQL中CTE（公用表表达式）（Common Table Expression）的总结

mysql Out of memory (Needed 16777224 bytes)的错误办理

mysql提醒[Warning] Invalid (old?) table or database name问题的办理办法

mysql启用skip-name-resolve情势时呈现Warning的处理办法

MySQL Order By语法介绍

<b>MySQL ORDER BY 的实现解析</b>

本文地址：