建材销售网站手机模板,门头沟青岛网站建设,怎么推广网站,自助建站如转载#xff0c;请注明出处#xff1a;http://blog.csdn.net/robinson_0612/archive/2009/10/31/4751070.aspx SQL server 2005高可用性之日志传送是在SQL server 2000 日志传送基础之上的延续#xff0c;两者其本质上并没有太大的差异。日志传送能够同步位于不同服务器或…如转载请注明出处http://blog.csdn.net/robinson_0612/archive/2009/10/31/4751070.aspx           SQL server 2005高可用性之日志传送是在SQL server 2000 日志传送基础之上的延续两者其本质上并没有太大的差异。日志传送能够同步位于不同服务器或同一服务器不同实例之间的数据库通过将主服务器上备份出来的一系列日志自动传送到辅助服务器上并进行恢复。当主服务器宕机的时候日志传送功能并不能实现从主服务器到辅助服务器的自动故障转移功能需要手动将辅助服务器切换到联机状态使得辅助服务器上数据库来提供服务从而实现数据库的高可用性。      一、实验目的配置SQL server 2005日志传送、监控日志传送状态及故障转移。      二、日志传送使用的场景         1. 可用于支持Reporting server通过指定standby模式来实现相应的查询功能并保持与主体数据库同步。         2. 可用于初始化镜像数据库使得镜像中主体数据库与镜像中的镜像数据库在时间上时点延迟上更接近加快镜像会话的实现。         3. 实现数据库的版本更新或迁移到新平台有利于最小化应用程序的宕机时间。         4. 实现多个将多个主数据库的数据备份到一个辅助数据库节省资源和开支。        三、实现日志传送的组成部分         1. Primary server(Primary database):  主服务器中用于实现日志传送的主体数据库         2. Secondary server(Secondary database):   辅助服务器中恢复日志文件的数据库可以为多个主服务器提供日志备份。         3. Monitor Server: 可选的监视服务器用于记录日志传送过程中出现的异常情况失败时给出警告存储在msdb数据库中。        四、实现日志传送所需的环境         1. 至少两台SQL server 2005服务器或同一服务器的两个实例。         2. SQL server 2005的版本要求为Standard, Workgroup, Enterprise, or Developer Edition之一。         3. 主体服务器的主体数据库使用完全恢复模式(FULL)或大容量日志恢复模式(Bulk-Logged)。         4. 主体服务器中SQL server Agent服务启动帐户拥有对存放备份日志文件目录读写的权限辅助服务器中SQL server Agent启动帐户一是要有对主服务器上存放备份日志文件目录读的权限用于从主服务器复制日志文件二是要拥有辅助服务器上存放用于恢复日志文件目录读写的权限。用于将复制过来的日志文件写入恢复日志文件目录。不建议将备份出来的日志文件存放到主服务器可以考虑放到文件服务器上减少主服务器的I/O。         5. 若主服务器备份出的日志文件要存放到其他服务器或文件服务器请使用Windows域用户帐户启动主服务器的SQL server Agent服务。         6. 启动主体服务器和辅助服务器的SQL server Agent服务若有监视服务器也应当启动监视服务器的SQL server Agent服务。        五、实现日志传送所需要用到的几个作业        1.  备份作业(backup job): 运行在主服务器上为每个实现日志传送数据库创建一个备份作业备份主体数据库日志删除旧的日志文件或历史记录信息并将其记录到主服务器和监视服务器上。        2.  复制作业(copy job):  运行在辅助服务器上将备份文件从主服务器复制到辅助服务器并记录信息到辅助服务器和监视服务器上。        3.  还原作业(restore job):  运行在辅助服务器上为每个日志传送配置创建一个还原作业恢复从主体数据库传送过来的日志删除旧的日志文件或历史记录信息并将其记录到辅助服务器和监视服务器上。         4.  警报作业(alter job): 运行于监视服务器上警报作业由使用监视器服务器实例的所有日志传送配置中的主数据库和辅助数据库所共享。        六、本次实验的环境        1. windows xp pro (英文版) sp2        2. SQL server 2005 Developer sp3        3. 同一主机的三个实例 ROBINSON ROBINSON/MIRRORROBINSON/WITNESS        4. 用于日志传送的数据库为Ecustom_qah        5. 因在同一服务器上实现日志传送本实验没有增加SQL server Agent 服务帐户用的是Local system帐户启动SQL server Agent 服务。       七、具体实验步骤如下        1. 设定共享目录在主服务器上设定Backuplog并共享使主服务器上的SQL server Agent 服务帐户拥有读写的权限使辅助服务器上的SQL server Agent 服务帐户拥有读的权限。Backuplog用于存放主服务器备份出来的日志文件。        2. 辅助服务器上设定Resotrelog使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Resotrelog用于存放从主服务器复制过来的日志文件用于恢复。        3. 在辅助服务器上设定一个初始化数据库的文件夹Databckup并共享使辅助服务器上的SQL server Agent 服务帐户拥有读写的权限。Databckup用于存放Ecustom_qah的mdf文件和ldf文件。        4. 测试以上的设置可以正常使用因本实验在同一台服务器上执行故仅仅是在D盘下设定了Backuplog、Resotrelog、Databackup并设定相应权限。        5. 启动相关服务。在SQL Server Configuration Manager中查看各个实例的MSSQLSERVE 和SQL server Agent是否启动如下图                            6. 查看用于日志传送的主数据是否处于FULL或Bulk-Logged恢复模式如不是请修改其为FULL或Bulk-Logged恢复模式。             也可以使用如下语句来修改恢复模式 Alter database Ecustom_qah  set recovery FULL。         7. 启动SSMS并连接到主服务器展开databases文件夹右单击Ecustom_qah选择Properties,选择Transaction Log Shipping选择Enable This As A Primary Database In A Log Shipping Configuration后单击Backup Settings设置。         8. 输入备份文件夹网络路径当备份文件夹位于主服务器上时输入主服务器上的文件夹。         9. 设定超6分钟后删除日志文件并设定3分钟没有备份则提示报警。                          10.单击Schedule设定日志的备份频率为每2分钟备份一次日志文件。         11. 单击 Add 按钮添加Secondary server.         12. 单击connect连接Secondary server输入帐户和密码选择secondary database为Ecustom_qah在Initialize Secondary Database中因我们没有对初始数据库进行备份故在此处选择generate a full backup并设定其Restore options设定数据文件和日志文件的位置在辅助服务器上的所在的文件夹 。         13. 如果在设定日志传送之前已经备份了数据库或已对辅助数据库初始化可以选择restore an existing backup或the secondary database is initialized.                     14. 在copy files选项卡设定复制文件的目的文件夹设定删除已复制的文件的时间间隔为6分钟复制频率为每2分钟复制一次日志文件。                            15. 在Restore Transaction Log选项卡中设定No recovery模式并设定延迟为1分钟恢复每2分钟发生一次超过4分钟日志没有恢复则报警。                         16. 设定完Restore Transaction Log后回到log shipping 主界面勾选use a monitor server instance选择settings选择ROBINSON/WITNESS并设定15分钟后删除历史记录。                      17. 按以上设定完毕后点击ok系统开始按所设定配置日志传送如果有错误发生系统会给出警告按警告提示更正相关错误。         18. 如设定无误后连接到MIRROR实例和WITNESS实例则在各个实例之间的jobs会出现相关作业在MIRROR实例中出现数据库Ecustom_qah(Restoring)如下图所示                               19. 打开设定的文件夹检查主服务器的备份情况和辅助服务器上复制过来的日志文件。                            至此SQL server 2005日志传送配置完毕。      八、监控日志的传送        1. 通过存储过程查看日志传送的情况              如在主服务器上执行sp_help_log_shipping_primary_database Ecustom_qah                 在辅助服务器上执行sp_help_log_shipping_secondary_database Ecustom_qah              也可以在监视服务器上执行脚本来跟踪日志的传送情况如下图                     2. 通过摘要中报表模块下的事物日志传送状态来动态查看和跟踪事务日志的情况。             因本机所使用SQL server 2005的版本为Developer sp3 所以无报表模块功能什么原因待考证。笔者曾在SQL server标准版(中文)中看到有报表且有事物日志传送状态功能但安装了sp3中文补丁后则不再有此功能。如有知其原因者可以给我留言。         3. 通过警报作业将故障通知道相关人员。             在监视服务器上我们可以看到有两个警报作业即Alters下我们可以看到Log shipping Primary Server Alert和Log shipping Secondary Server Alert。.默认的情况如果监视到错误并不会做任何通知我们可以通过新建操作员(Operators)来接受相关报警信息。同样我们也可以在主服务器和辅助服务器上设定操作员来接受相关报警信息可以通过消息邮件等形式前提是需要配置数据库邮件或启动操作系统中的Messenger信使服务等如本试验中设定的启动了Messenge服务后则得到如下图的提示                4. 对于常见的SQL server故障我们可以通过查看操作系统的事件查看器或SQL server日志来发现问题。      九、事务日志模式            在设置辅助数据库时对于恢复事务日志Restore Transaction Log选项卡我们设定了为No recovery mode还有一个可供选择的则为Standby mode。在事物日志的传送过程中恢复事务日志Restore Transaction Log与我们普通的恢复不同一般情况下的恢复是回滚所有未提交的事务前滚所有已提交但未写入磁盘的事务。事务日志中如果一个事务回滚所有改变的数据将会被丢失因为在这个时候你并不知道下一事物究竟是回滚还是提交。故在事务日志传送中提供了No recovery mode和Standby mode两者的介绍如下         1. 无恢复模式(No recovery mode):既不前滚也不回滚未提交的事务数据不可读。         2. 备用模式(Standby mode):在恢复日志期间回滚所有未提交的事务并且将所有未提交的事务保存为一个单独的Transaction Undo File(TUF)文件恢复过程通过该文件来维护事务的完整性当恢复下一个事物的时候则恢复所有已提交的事务。Standby mode中的复选框勾选则当日志恢复的时候断开所有用户的连接如果有一个用户没有断开则还原无法进行。          十、演示Standby mode查看日志传送及故障转移         1. 将No recovery mode切换到Standby mode 。此操作在主服务器上打开Ecustom_qah 的 properties选择Transaction Log shipping点击辅助数据库后的… 号打开Restore Transaction Log直接点击Standby mode即可可以勾选当日志恢复的时候断开所有用户的连接。如果设定的复制和恢复间隔时间很短则当主服务器上所有在Restoring模式下的备份出来的日志文件在辅助服务器上恢复完毕后会自动在复制到的目录中产生一个tuf文件。且辅助服务中Ecustom_qah 数据库由restoring显示为standby/read-only模式。如果设定的复制和恢复间隔时间很长可以手动执行辅助服务其中的copy 作业和restore作业将主服务器上所有未复制的日志文件复制到设定的恢复目录(restorelog)中然后恢复到辅助服务器中。同样也可以将Standby mode切换回No recovery mode。图略。         2. 可以通过在原始数据库中创建新的表或表中插入记录在到辅助数据库中检查该变化是否亦同步前提是使用Standby mode此演示省略。         3. 故障转移 在主服务器Ecustom_qah数据库中删除complex表中字段code_ts中以04开头的记录,delete from complex where code_ts like 04%。 停止主服务器的MSSQLSERVER服务然后删除主服务器中的Ecustom_qah数据库的mdf文件来模拟主服务器故障。 重新启动主服务器的MSSQLSERVER服务服务在主服务器master中执行备份尾部日志。              backup log Ecustom_qah to disk D:/Restorelog/last.bak with no_truncate 将主、辅助、监视服务器上日志传送的几个作业禁用(Disable) 。 在辅助服务器上执行copy作业和resotre作业将未复制过来的日志复制到恢复目录并全部恢复完毕。 将尾部日志恢复到辅助服务器辅助数据库中并使辅助数据库Ecustom处理联机状态。在辅助服务器master数据库中执行如下脚本:               restore log Ecustom_qah from disk D:/Restorelog/last.bak with norecovery;               go               restore database Ecustom_qah with recovery;               go  改变应用程序的连接字符串使应用程序连接到辅助服务器的辅助数据库此时辅助服务器的辅助数据库已变成为主服务器主数据库。  当原始主服务器修复后再重新配置日志传送即可。 转载于:https://www.cnblogs.com/zlja/archive/2009/10/31/2449443.html