使用事务日志解决SQL Server的4个常见故障

当系统出现故障时,只要存在数据日志那么就可以利用它来恢复数据解决数据库故障。作为SQL Server数据库管理员,了解数据日志文件的作用,以及如何利用它来解决一些数据库的常见故障,这非常重要。既然事务日志这么重要,那么他到底可以用来做什么事情呢?口说无凭,笔者这里就跟大家说说事务日志到底可以用来解决什么故障。

故障一:服务器意外关闭造成的损失

俗话说,天又不测风云。数据库服务器如果因为突然断电或者其他一些原因意外当机时,再重新启动服务器后会出现一些数据的损失。这主要是因为数据库中的数据发生更改后,并不会在第一时间就把数据写入到硬盘中。为了提高数据库的运行效率,往往是先把数据写入到数据高速缓存中;同时把更改的情况写入到事务日志中。等到一定的情况数据库系统才会把数据写入到硬盘文件中。

此时,如果数据库服务器系统突然发生故障,数据库系统就有可能还没有把缓存中的修改后的数据写入到硬盘中,即数据文件内有未完成事务所做的修改。如果确实有这种情况,则当启动SQL Server实例时,如果没有事务日志或者事务日志损坏时,修改后的数据就无法恢复过来了。但是,如果当事务日志可用的话,则当实例启动时,系统会丢每个数据库执行恢复操作。前滚日至中记录的、可能尚未写入数据文件的每个修改。在事务日志中找到的每个未完成的事务都将回滚,以确保数据库数据的完整性。

所以当数据库服务器意外故障时,数据库管理员最好能够确认一下事务日志是否可用。如果事务日志已经损坏,那么就需要先恢复事务日志然后再重新启动数据库实例。否则的话,数据库实例在重新启动时不能够正常恢复数据。这一点在遇到服务器突发行的故障时一定要注意。否则的话,很可能破坏数据库数据的完整性。

故障二:解决备份数据库的数据同步问题

有时候出于数据库高可用性的目的,需要在生产服务器之外的地方再部署一台数据库服务器。当生产服务器出现故障不可用时,则可以马上启用这个备用的服务器。故就需要保证生产服务器与备用服务器之间数据的同步。那么SQL Server数据库是通过什么技术来达到这个生产服务器与备份服务器之间的数据同步的呢?简单的说,就是通过这个事务日志的复制来实现数据同步的。具体的来说,SQL Server数据库提供了两种解决方案,分别为数据镜像与日志传送。这两个方案都是在事务日志复制的基础上来实现的。

在日志传送方案中,生产服务器将生产数据库的活动事务日志发送到一个或多个目标服务器。每个辅助服务器将该日志还原为其本地的辅助数据库,从而实现备用服务器与生产服务器之间数据的一致性。使用日志传送,您可以自动将“主服务器”实例上“主数据库”内的事务日志备份发送到单独“辅助服务器”实例上的一个或多个“辅助数据库”。事务日志备份分别应用于每个辅助数据库。可选的第三个服务器实例(称为“监shi服务器”)记录备份和还原操作的历史记录及状态,还可以在无法按计划执行这些操作时引发警报。日志传送配置中的主服务器是作为生产服务器的 SQL Server 数据库引擎实例。主数据库是主服务器上希望备份到其他服务器的数据库。通过数据库进行的所有日志传送配置管理都是在主数据库中执行的。另外需要注意的是,如果采用日志传送方案对于生产服务器的工作模式有限制。生产数据库必须使用完整恢复模式或大容量日志恢复模式。如果将数据库切换为简单恢复模式会导致日志传送停止工作。

一台备用服务器可以包含多台不同生产服务器中数据库的备份副本。例如,某个集团公司可能有三台数据库服务器,每台服务器都运行关键数据库系统。在这种情况下,可以只使用一台辅助服务器,而不必使用三台单独的辅助服务器。三个主系统上的备份都可以加载到这个备份系统中,从而减少所需的资源数量并节省开支,也可以数据库管理员的工作量。

另外也可以通过数据库镜像方案中来解决生产服务器与备用服务器之间的数据同步问题。生产数据库的每次更新都在独立的、完整的备份数据库中立即重新生成。主体服务器实例立即将每个日志记录发送到镜像服务器实例,镜像服务器实例将传入的日志记录应用于镜像数据库,从而将其继续前滚。“数据库镜像”是用于提高数据库可用性的首选软件解决方案。镜像基于每个数据库实现,并且只适用于使用完整恢复模式的数据库。简单恢复模式和大容量日志恢复模式不支持数据库镜像。因此,所有大容量操作始终被完整地记入日志。数据库镜像可使用任意支持的数据库兼容级别。在“数据库镜像模式”中,主体服务器和镜像服务器作为伙伴进行通信和协作。两个伙伴在会话中扮演互补的角色:主体角色(生产服务器)和镜像角色(备份服务器)。在任何给定的时间,都是一个伙伴扮演生产服务器角色,另一个伙伴扮演备用服务器角色。如果生产服务器角色出现故障时,则备份服务器角色马上会顶替出现故障的生产服务器角色,转变为生产服务器角色。从而实现数据库的高可用性。

数据库镜像方案有两种镜像运行模式。一种是“高安全性模式”,它支持同步操作。在高安全性模式下,当会话开始时,镜像服务器将使镜像数据库尽快与主体数据库同步,一旦同步了数据库,事务将在伙伴双方处提交,这会延长事务滞后时间。第二种运行模式,即高性能模式,它与第一种模式的主要差异就在于异步运行。镜像服务器尝试与主体服务器发送的日志记录保持同步。镜像数据库可能稍微滞后于主体数据库。但是,数据库之间的时间间隔通常很小。但是,如果主体服务器的工作负荷过高或镜像服务器系统的负荷过高,则时间间隔会增大。在高性能模式中,主体服务器向镜像服务器发送日志记录之后,会立即再向客户端发送一条确认消息。它不会等待镜像服务器的确认。这意味着事务不需要等待镜像服务器将日志写入磁盘便可提交。此异步操作允许主体服务器在事务滞后时间最小的条件下运行,但可能会丢失某些数据。具体采用哪种模式,则需要数据库管理员根据企业对待数据损失的态度与工作负荷等来确定。

可见现在可用的备份服务器与生产服务器之间的数据同步解决方案都是基于事务日志来实现的。

时间: 2016-10-30

使用事务日志解决SQL Server的4个常见故障的相关文章

通过事务日志解决SQL Server常见四大故障(一)

同Oracle数据库一样,SQL Server数据库中也有事务日志.事务日志主要用来记录所有事务以及每个事务对数据库进行了哪些更改.事务日志可以说是数据库中最重要的数据文件之一. 当系统出现故障时,只要存在数据日志那么就可以利用它来恢复数据解决数据库故障.作为SQL Server数据库管理员,了解数据日志文件的作用,以及如何利用它来解决一些数据库的常见故障,这非常重要.既然事务日志这么重要,那么他到底可以用来做什么事情呢?口说无凭,笔者这里就跟大家说说事务日志到底可以用来解决什么故障. 故障一:

通过事务日志解决SQL Server常见四大故障(二)

数据库镜像方案有两种镜像运行模式.一种是"高安全性模式",它支持同步操作.在高安全性模式下,当会话开始时,镜像服务器将使镜像数据库尽快与主体数据库同步,一旦同步了数据库,事务将在伙伴双方处提交,这会延长事务滞后时间.第二种运行模式,即高性能模式,它与第一种模式的主要差异就在于异步运行.镜像服务器尝试与主体服务器发送的日志记录保持同步.镜像数据库可能稍微滞后于主体数据库.但是,数据库之间的时间间隔通常很小.但是,如果主体服务器的工作负荷过高或镜像服务器系统的负荷过高,则时间间隔会增大.在

Sql server数据库不能启动常见故障

server|数据|数据库 SQL Server不能启动的常见故障 --是否修改了操作系统密码? --修改操作系统密码,导致SQL不能启动的解决办法: 1.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"本地系统帐户" 或: 2.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"此帐户"--密码和确认密码中输入你修改后的administrator密码

SQL Server不能启动的常见故障[1][1]

SQL Server不能启动的常见故障 --是否修改了操作系统密码? --修改操作系统密码,导致SQL不能启动的解决办法: 1.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"本地系统帐户" 或: 2.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"此帐户"--密码和确认密码中输入你修改后的administrator密码. 两者的区别: 选择第一种

SQL Server不能启动的常见故障

server SQL Server不能启动的常见故障 --是否修改了操作系统密码? --修改操作系统密码,导致SQL不能启动的解决办法: 1.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"本地系统帐户" 或:2.我的电脑--控制面板--管理工具--服务--右键MSSQLSERVER--属性--登陆--登陆身份--选择"此帐户"--密码和确认密码中输入你修改后的administrator密码. 两者的区别:

如何解决 SQL Server 2000 中的连接问题

server|解决|问题 如何解决 SQL Server 2000 中的连接问题适用于 重要说明:本文包含有关修改注册表的信息.修改注册表之前,一定要备份注册表,并且一定要知道在发生问题时如何还原注册表.有关如何备份.还原和编辑注册表的信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章: 256986 Microsoft Windows 注册表说明 本任务的内容概要 解决连接问题 验证 DNS 设置 验证启用的协议和别名 验证 SQL Server 实例正在正确地侦听 解

解决Sql Server警报的疑难问题

server|解决|问题 1.检查你是否使用了最新的Sql Server service pack 这是因为在最新的Sql Server service pack中已经修补了很多Sql Server使用警告(Alerts)的漏洞.你应该确保在你的系统中已经安装了最新的Sql Server service pack补丁包. 2.检查SqlServerAgent服务的帐户是否作为成员运行在域用户群组(Domain User Group)下 LocalSystem帐户它没有访问网络的权限.所以,如果你

SQL Server误区:在服务器故障转移后,正在运行的事务继续执行

误区 #1:在服务器故障转移后,正在运行的事务继续执行 这当然是错误的! 每次故障转移都伴随着某种形式的恢复.但是如果当正在执行的事务没有Commit时,由于服务器或实例崩溃导致连接断开,SQL Server可没有办法在故障转移后的服务器重新建立事务的上下文并继续执行事务-无论你使用的故障转移方式是集群,镜像,日志传送或是SAN复制. 对于故障转移集群来说,当故障转移发生后,一个SQL Server实例在另一个故障转移集群的节点启动.所有实例上的数据库都要经历Recovery阶段-也就是所有没有

如何解决SQL Server警报的疑难问题

         具体的解决方法请参考下文 : ◆检查你是否使用了最新的Sql Server service pack.因为在最新的Sql Server service pack中已经修补了很多Sql Server使用警告(Alerts)的漏洞.应该确保在你的系统中已经安装了最新的Sql Server service pack补丁包. ◆检查SqlServerAgent服务的帐户是否作为成员运行在域用户群组(Domain User Group)下.LocalSystem帐户没有访问网络的权限,所