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

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

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

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

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

　　故障二：解决服务器意外关闭造成的损失。

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

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

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