sql server实现热备用可用性中日志传送以及同步复制的方式

sql server下实现热备用可用性中日志传送以及同步复制的方式：
1.   使用企业版的“日志传送向导”(被集成在“数据库维护向导”之中)
2.   通过编写脚本，并将其作为普通的SQL Server代理作业来进行调度而实现
3.   使用同步复制

　集群是一种实现高可用性的有效解决方案，有时它会适得其反。而且，它还非常昂贵。因此，数据库管理员可使用日志转移代替集群来提供较高的可用性。 

　　日志转移是这样一种处理过程，它能将某一数据库中的事务日志文件依次转存到备份的数据库中，进而为这一数据库创建一个“近乎”热备份。SQL Server 2000的数据库引擎中设置了日志转移功能，并在其中进行处理。所以它会自动完成复原到备份服务器的进程，而不需要数据库管理员手动操作。只有你的产品服务器操作失败，你才需手动完成到备份服务器的复原进程。(注释：尽管SQL Server 7.0和2005中均有日志转移功能，但本文主要针对SQL Server 2000。) 

　　◆为什么要使用日志转移? 
　　日志转移是一种解决高可用性的措施，并且十分有效。同样作为高可用性的措施方案，日志转移相对集群来说，最大的好处是它要便宜许多。这是因为，使用集群功能有硬件要求，而日志转移则不需要。 
　　日志转移在数据库与数据库而非服务器与服务器之间进行；因此才有可能将备份数据库存储在你已用作其他用途的服务器上。但如果转移失败则有可能会出现问题，这时你可换用备份数据库，这种选择是可用的。 
　　日志转移相对比较容易安装。SQL Server提供了非常完善的向导帮助你安装这个进程。 
　　日志转移允许你保存分布在不同地理位置中的冗余数据，SQL Server的集群功能则很难做到这一点。这一特点十分出众，因为，当你的数据中心遭到灾难时，你仍能在备份服务器中将其恢复过来。而在相同的数据中心，如果你使用的是集群功能，你就会陷入麻烦。 
　　日志转移的另一优点是你能将备份数据库作为报告数据库使用，这对许多公司来说是很不错的选择。但如果你决定了用这个备份数据库作报告使用，就必须注意它的局限性。使用原始数据库中的日志时，SQL Server 要求指定唯一的通道，所以，当日志文件正在被应用时，报告则不能同时进行。 

　　◆使用日志转移要考虑的相关因素 
　　在将日志转移作为高可用性的方案来使用时，我们必须考虑以下几点因素。由于从原始数据库到备份数据库有一个潜伏期，对你的公司而言，它并非一定是可行的实现高可用性的一种解决方案。潜伏期由数据库管理员设置，时间也因需要而缩短,但永远不能避免。 
　　日志转移中没有设置恢复功能，这就意味着在将日志转移到备份服务器上时，这些日志都暂时不可用。因此，数据库管理员必须在将备份数据库放到网上前完成一系列的操作，这些步骤包括: 
　　将已存储在备份数据服务器上原始数据库里的备份标签存储起来。一旦所有的标签被存储后，数据库就必须得到恢复，然后放到网上。 
　　一旦所有的数据库都已放在网上，所有需要访问数据库的应用程序就需要改变自身的链接。如果你不能将应用程序尽快指向刚刚恢复的数据库，你就前功尽弃了。 
　　一个SQL Server的实例能用于监控日志转移。这个实例可以在原始数据库、备份数据库或单独的数据库中。任何一种版本的SQL Server都能用于SQL Server监控。 
　　注释：数据库登录必须在原始数据库与备份数据库之间同时进行 

操作步骤：
Log Shipping
Operations Guide
Version: 1.0
Index
Create Log Shipping.. 3
Monitor.. 9
Delete Log shipping.. 10
Role Alter.. 11
Role Change.. 13

Create Log Shipping
1.SQL Server 节点1 Tonym 和 Tonym02必须位于同一域中，并且SQL1 和SQL2都要使用域账户启动SQL Server服务和SQLServerAgent服务。
2.在企业管理器中删掉local连接，应用Server Name注册本地服务器 Tonym，辅助服务器Tonym02
3. 在SQL1 服务器上新建共享文件夹NorthwindBackupShare01，赋予启动SQL Server账户的Full 权限。在SQL1服务器上新建文件夹 ReceiveSQL2Logs，用来在进行数据库角色转换时接收从SQL2上传送过来的日志。
 在SQL2 服务器上新建共享文件夹NorthwindBackupShare02，赋予启动SQL Server账户的Full 权限。在SQL2服务器上新建文件夹 ReceiveSQL1Logs，用来接收数据库SQL1上传送过来的日志。
4.设置想要应用Log Shipping的服务器为完全恢复模式。
5.在Database Maintenance Plans上右键 New maintenance Plan，选择进行LogShipping 的数据库，每次只允许选择一个数据库。
6．去掉Back up the database as part of the maintenance plan,保证维护计划唯一性（推荐）
7．指定数据库日志备份路径。
8．指定存放日志文件的共享文件夹。
8.添加目的数据库。

  Server Name 为目的名称
  Transaction Log Destination Directory 填写从SQL1上传送到SQL2上日志文件的接收路径.
  Destination Database 选择新建数据库（指定数据文件，日志文件存放路径）或者应用已存在的数据库
  Database Load State
  No recovery mode：使用者将无法进行资料查询，只供备份使用.
  Standby mode ：设置成只读模式，只要不是进行日志回存的时候，都可以进行查询。
  Terminate users in database(Recommended) ：在回存数据库或是交易日志文件时，回存程序将是数据库唯一的使用者。
  Allow database to assume primary role：允许主要服务器与次要服务器之间进行角色转换。

  选择进行角色转换后新主要服务器的共享目录路径。
9．Initialize the Destination Database: 挑选最近一次的资料或是建立一份新的备份资料。对大型数据库，使用即有备份比较有效率。但是要保证从备份之后的日志都存在于主服务器上的日志共享目录中。
10．设定主服务器上日志备份频率。
11．设置辅助服务器复制备份日志和加载备份日志的频率，以及日志文件在辅助服务器上的留存时间。
12．针对日志备份及日志回存工作，设定合理的延迟时间，当超过临界时间时，日志传送监控程序对话框会相应一个警告信息。
13．指定监控服务器，应该指定独立于主服务器，辅助服务器的第三台服务器作为监控服务器，或者指定辅助服务器为监控服务器。
14．点击Next，指定维护计划的名称。Finish，开始进行Log shipping 的创建。

Monitor
1.
Log Shipping 创建好后，和Log Shipping 相关的信息存储在msdb的7个表中：

Log_shipping_plans
Log_shipping_plan_databases
Log_shipping_databases
Log_shipping_plan_history
Log_shipping_monitor
Log_shipping_primaries
Log_shipping_secondaries

2.可以在监控服务器的management 下看到Log shipping 备份，复制，加载等动作的状态信息。

Delete Log shipping
1. 选择主要服务器上的log shipping 维护计划,打开属性，选择【Log shipping】设定页，然后点选【Remove Log Shipping】。此动作将从次要服务器上移除SQL Server Agent的备份与回存工作，并清除日志传送资料表内的所有相关资料。此外，日志传送监控程序的相关信息也会一并被清除。然而此动作将会适当地保留主要服务器上SQL Server Agent的交易日志备份工作。只有在删除数据库维护计划时，该工作才会被移除。假如您想从监控服务器内移除掉日志传送监控程序，请用手动方式将log_shipping_primaries与log_shipping_secondarie 这两个资料表(位于监控服务器的msdb数据库)的资料删除即可。
如果您在数据库维护计划内设定日志传送时，就已允许目的数据库可以做为新的日志传送来源数据库。当您删除主要服务器的维护计划时，次要服务器上仍然会保留其数据库维护计划，以及交易日志文件备份工作。删除这些项目的方式是将次要服务器上与日志传送相关的数据库维护计划直接删除。

Role Alter 
1.在主服务器上创建登陆同步DTS包。
2.打开企业管理器并连接到主服务器。展开企业管理器树至“Data Transformation Services” 组，选择“Local Packages”。右击“Local Packages”并选择 “New Package”。从“Task”菜单选择“16 Transfer Logins Task”。在源选择 主服务器，目的选项卡 选择 辅助服务器。在“Logins”选项卡，选择传输与特定数据库关联的登陆，或者传输该服务器的所有登陆。（对于我们的环境推荐使用传输该服务器的所有登陆）
3．将DTS包保存在主服务器。
3．指定DTS同步时间（至少每周一次）。

同步登陆账户SID
1. bcp master..syslogins out localpath\syslogins.dat  /N /S current_primary_server /U sa /P sa_password.
稍后会用到导出的syslogins信息.
2.  降级主要服务器.在主服务器运行以下存储过程。
Use master

Exec msdb..sp_change_primary_role
        @db_name = ‘current_primary_dbname’
        @backup_log = 1,
        @terminate = 1,
        @final_state = 3,
        @access_level = 1

3.升级辅助服务器.在辅助服务器运行以下存储过程。
Use master

Exec msdb..sp_change_secondary_role
        @db_name = ‘current_secondary_dbname’
        @do_load = 1,
        @force_load = 1,
        @final_state = 1,
        @access_level = 1,
        @terminame = 1,
        @keep_replication = 0,
        @stopat = null

该存储过程会将数据库质为单用户模式。明明没有任何使用者正在存取数据库，它却告诉我数据库目前为使用中，解决的方式为重新执行一次该存储过程。
4.通知监控服务器角色已变更，在监控服务器上运行以下存储过程。
Use master

Exec msdb..sp_change_monitor_role
        @primary_server = ‘current_primary_server_name’,
        @secondary_server = ‘current_secondary_server_name’,
        @database = ‘current_secondary_dbname’,
        @new_source = ‘new_source_directory’

5.在次要服务器上解析登入帐号
Use master

Exec sp_resolve_logins
        @dest_db = ‘dbname’,
        @dest_path = ‘destination_path’,
        @filename = ‘filename’ (from step 1 export)

6.连接数据库存取与权限。将转移后已解析的登入帐号连结至相对应的数据库使用者及其权限. (SQL BOOK Online 缺少此步)
Use sourcename

Exec sp_change_users_login ‘update_one’,‘username’,‘LoginName’

Role Change
1. 在新主要服务器的数据库维护计划内移除日志传送功能。
2. 在主要服务器上删除数据库维护计划。
3. 在次要服务器上删除数据库维护计划。
4. 维护所有交易日志。
5. 在新主要服务器上建立一个新的数据库维护计划，指定新次要服务器所在，目的数据库位置，以及交易日志之适当存放位置。
6. 重新开始新主要服务器的所有活动。

在您成功设定角色互换且建置新日志传送配对服务器后，Enterprise Manager 的日志传送监视器可能会告诉您新次要服务器数据库并未与新主要服务器数据库取得同步（out of sync）。如果“最近一次加载的交易日志”与“最近一次备份的交易日志”之间的时间差超过了 out-of-sync设定值，您就会收到此报告。你需要把新主服务器的备份日志拷贝到新次服务器的同步备份路径下。到最近一次的备份资料被加载之后，日志传送监视器会回到平常无错误状态。