通过事务日志解决SQL Server常见4大故障

核心提示：当系统出现故障时，只要存在数据日志那末便可以够利用它来恢复数据解决数据库故障。作为SQL Server数据库治理员，了解数据日志文件的作用，和如何利用它来解决1些数据库的常见故障，这非常重要。

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

故障1：服务器意外封闭酿成的损失

俗语说，天又不测风云。数据库服务器假设由于忽然断电或其他1些缘由意外当机时，再重新启动服务器后会出现1些数据的损失。这主要是由于数据库中的数据产生更改后，其实不会在第1时间就把数据写进到硬盘中。为了进步数据库的运行效率，常常是先把数据写进到数据高速缓存中;同时把更改的情况写进到事务日志中。等到1定的情况数据库系统才会把数据写进到硬盘文件中。

此时，假设数据库服务器系统忽然产生故障，数据库系统就有可能还没有把缓存中的修改后的数据写进到硬盘中，即数据文件内有未完成事务所做的修改。假设确切有这类情况，则当启动SQL Server实例时，假设没有事务日志或事务日志破坏时，修改后的数据就没法恢复过来了。但是，假设当事务日志可用的话，则当实例启动时，系统会丢每个数据库履行恢复操纵。前滚日至中记录的、可能还没有写进数据文件的每个修改。在事务日志中找到的每个未完成的事务都将回滚，以确保数据库数据的完全性。

所以当数据库服务器意外故障时，数据库治理员最好能够确认1下事务日志是否是可用。假设事务日志已破坏，那末就需要先恢复事务日志然后再重新启动数据库实例。否则的话，数据库实例在重新启动时不能够正常恢复数据。这1点在碰到服务器突发行的故障时1定要留意。否则的话，很可能破坏数据库数据的完全性。

故障2：解决备份数据库的数据同步题目

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

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

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

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

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

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

故障3：解决数据1致性题目

假定现在有这么1种情况。在1个银行系统中，某个用户需要转帐。这个转帐作业主要是通过两个步骤来完成。第1个步骤就是扣减用户帐户中的金额;第2个步骤是把钱转进到另外1个用户那里。现在假设在转帐的进程中，第1步成功了，但是第2个步骤由于某种缘由出错了。如用户提供的帐户名字与实际转帐的帐户名字不符，则第2个操纵就会失败。此时全部转帐操纵就会以失败而告终。但是现在的题目是，第1个扣减的动作在数据库zhon给已完成了。而实际却是没有转帐成功，就救造成了数据1致性的题目。

实际进程中假设利用程序发出 ROLLBACK 语句，或数据库引擎检测到毛病，就使用日志记录回滚未完成的事务所做的修改。也就是说，当第2个操纵失败的话，利用程序要发出1个ROLLBACK 语句，利用事务日志回滚功能，恢复第1步的操纵。也就是说，把扣减金额的操纵进行恢复，从而实现数据的1致性。类似的利用，在数据库开发进程中很频繁。

故障4：数据库时点恢复的题目

如现在碰到这么1种故障。数据库系统在上午11点忽然发现故障，启动不起来了。而数据库系统是在昨天晚上12点刚做完1个完全备份。在这类情况下，假设只是从完全备份中恢复数据的话，只能够恢复到昨天晚上12点的数据。那从昨天晚上12点到今天上午11点的数据就不能够恢复了吗?

实在不然。由于用户在对数据库做的任何1个修改都会保存在事务日志当中。为此只要事务日志不破坏的情况下，数据库治理员可以把数据恢复到上午11点那个时刻的数据。具体的操纵方法很简单，就好先利用完全备份文件恢复数据库系统，此时数据库中的数据位昨天晚上12点的数据。然后再利用日志恢复功能把数据恢复到今天上午11点的数据。可见事务日志可以帮助治理员把数据恢复到某1个具体的时点。

唐山网站建设www.fw8.net
TAG:数据库,数据,服务器,日志,事务

评论加载中... 内容： 评论者： 验证码：