Sql Server事务日志
Sql Server事务日志一、SQLSERVER事务日志查看
利用下面SQL语句来查看所在数据库的事务日志记录
USE [GPOSDB] --要查看事务日志记录的数据库
GO
SELECT * FROM [sys].[fn_dblog](NULL,NULL)
一些重要字段的说明
CurrentLSN：当前LSN号，事务日志中的每个记录都由一个唯一的日志序列号 (LSN) 标识。LSN 是这样排序的：如果 LSN2 大于 LSN1，则 LSN2 所标识的日志记录描述的更改发生在日志记录 LSN1 描述的更改之后
Operation：当前LSN所做的操作
Context：操作的上下文
TransactoinID：事务ID号
Log Record Fixed Length：LSN记录的所占虚拟日志文件的固定长度
Previous LSN：前一个LSN号
AllocUnitID：修改的那条数据所属分配单元ID
AllocUnitName：修改了数据的表名
Page ID：0001:00000121 转换成十进制：289 所以查看pageid为289页 DBCC PAGE([pratice],1,289,3)
Slot ID：数据所在数据页面的第几条记录
PartitionID：数据所在数据页面的所在分区ID
二、Sql Server事务日志满的解决方法
因为磁盘空间已满，SqlServer服务有可能无法正常启动。先不要让应用程序连接数据库。
试着启动SqlServer服务。看看能否启动起来。如果不能，需要腾出来一点空间来。删除一些暂时不要的软件。总之要让SqlServer服务启动起来。如果SqlServer服务能起来，就做下面的。
1、执行如下语句
backup log tempdb with no_log --清除事务日志
go
backup log SharePoint_Config with no_log --清除事务日志
go
use tempdb
go
dbcc shrinkfile (tempdev, 10240) --调整tempdb的主数据文件大小为10240 MB, 可根据需要调整, 这个命令不是必须执行的。
go
三、事务在不断增大的时候如何缩小日志
当数据如在频繁修改或者删除的同时，事务的日志就会不断的增加，甚至超过了碰盘的大小，这时候就不能因此而直接删除了事务日志的LDF文件，否则可能会带来很大的麻烦。为了避免这种情况，我们需要有如下的操作：
1) 、尽量避免tempdb 日志与用户数据库日志放在同一磁盘上，tempdb 数据库和事务日志具有足够的空间来处理索引操作。不能在索引操作完成之前截断 tempdb 事务日志。
2) 、通过执行下列命令来缩小事务日志
DBCC SHRINKDATABASE
DBCC SHRINKFILE
操作会立即尝试将物理日志文件收缩为所要求的大小。
如果虚拟日志文件中的逻辑日志未超出 target_size 标记，则释放 target_size 标记之后的虚拟日志文件，并成功完成 DBCC 语句，不显示任何信息。
如果虚拟日志中的逻辑日志超出了 target_size 标记，SQL Server Database Engine 将释放尽可能多的空间并显示一个信息性消息。该消息告诉您必须执行什么操作来从文件尾部的虚拟日志中删除逻辑日志。执行完该操作后，可以重新发出 DBCC 语句以释放剩余的空间。
DBCC SHRINKFILE 语句还显示一个信息性消息，指出它不能释放所要求的全部空间，并告诉您可以执行 BACKUP LOG 语句来释放剩余的空间。
四、事务日志的还原
事务日志在还原的时候可以选择三种恢复模式：简单模式、完整模式和大容量日志模式。
1、简单恢复模式
此模式简略地记录大多数事务，所记录的信息只是为了确保在系统崩溃或还原数据备份之后数据库的一致性。
由于旧的事务已提交，已不再需要其日志，因而日志将被截断。截断日志将删除备份和还原事务日志。但是，这种简化是有代价的，在灾难事件中有丢失数据的可能。没有日志备份，数据库只可恢复到最近的数据备份时间。如果您使用的是 SQL Server Enterprise Edition，需要考虑此问题。此外，该模式不支持还原单个数据页。
2、完整恢复模式
此模式完整地记录了所有的事务，并保留所有的事务日志记录，直到将它们备份。在 SQL Server Enterprise Edition 中，完整恢复模式能使数据库恢复到故障时间点。
3、大容量日志恢复模式
此模式简略地记录大多数大容量操作(例如，索引创建)，完整地记录其他事务。
大容量日志恢复提高大容量操作的性能，常用作完整恢复模式的补充。大容量日志恢复模式支持所有的恢复形式，但是有一些限制，备份包含大容量日志记录操作的日志时，需要访问数据库内的所有数据文件。如果数据文件不可访问，则无法备份最后的事务日志，而且该日志中所有已提交的操作都将丢失。
五、SqlServer事务日志常用来解决的问题
1、服务器意外关闭造成的损失
数据库服务器如果因为突然断电或者其他一些原因意外当机时，再重新启动服务器后会出现一些数据的损失。这主要是因为数据库中的数据发生更改后，并不会在第一时间就把数据写入到硬盘中。为了提高数据库的运行效率，往往是先把数据写入到数据高速缓存中;同时把更改的情况写入到事务日志中。等到一定的情况数据库系统才会把数据写入到硬盘文件中。
此时，如果数据库服务器系统突然发生故障，数据库系统就有可能还没有把缓存中的修改后的数据写入到硬盘中，即数据文件内有未完成事务所做的修改。如果确实有这种情况，则当启动SQL Server实例时，如果没有事务日志或者事务日志损坏时，修改后的数据就无法恢复过来了。但是，如果当事务日志可用的话，则当实例启动时，系统会丢每个数据库执行恢复操作。前滚日至中记录的、可能尚未写入数据文件的每个修改。在事务日志中找到的每个未完成的事务都将回滚，以确保数据库数据的完整性。
所以当数据库服务器意外故障时，数据库管理员最好能够确认一下事务日志是否可用。如果事务日志已经损坏，那么就需要先恢复事务日志然后再重新启动数据库实例。否则的话，数据库实例在重新启动时不能够正常恢复数据。这一点在遇到服务器突发行的故障时一定要注意。否则的话，很可能破坏数据库数据的完整性。
2、解决备份数据库的数据同步问题
有时候出于数据库高可用性的目的，需要在生产服务器之外的地方再部署一台数据库服务器。当生产服务器出现故障不可用时，则可以马上启用这个备用的服务器。故就需要保证生产服务器与备用服务器之间数据的同步。那么SQL Server数据库是通过什么技术来达到这个生产服务器与备份服务器之间的数据同步的呢?简单的说，就是通过这个事务日志的复制来实现数据同步的。具体的来说，SQL Server数据库提供了两种解决方案，分别为数据镜像与日志传送。这两个方案都是在事务日志复制的基础上来实现的。
在日志传送方案中，生产服务器将生产数据库的活动事务日志发送到一个或多个目标服务器。每个辅助服务器将该日志还原为其本地的辅助数据库，从而实现备用服务器与生产服务器之间数据的一致性。使用日志传送，您可以自动将“主服务器”实例上“主数据库”内的事务日志备份发送到单独“辅助服务器”实例上的一个或多个“辅助数据库”。事务日志备份分别应用于每个辅助数据库。可选的第三个服务器实例(称为“监shi服务器”)记录备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。日志传送配置中的主服务器是作为生产服务器的 SQL Server 数据库引擎实例。主数据库是主服务器上希望备份到其他服务器的数据库。通过数据库进行的所有日志传送配置管理都是在主数据库中执行的。另外需要注意的是，如果采用日志传送方案对于生产服务器的工作模式有限制。生产数据库必须使用完整恢复模式或大容量日志恢复模式。如果将数据库切换为简单恢复模式会导致日志传送停止工作。
一台备用服务器可以包含多台不同生产服务器中数据库的备份副本。例如，某个集团公司可能有三台数据库服务器，每台服务器都运行关键数据库系统。在这种情况下，可以只使用一台辅助服务器，而不必使用三台单独的辅助服务器。三个主系统上的备份都可以加载到这个备份系统中，从而减少所需的资源数量并节省开支，也可以数据库管理员的工作量。
另外也可以通过数据库镜像方案中来解决生产服务器与备用服务器之间的数据同步问题。生产数据库的每次更新都在独立的、完整的备份数据库中立即重新生成。主体服务器实例立即将每个日志记录发送到镜像服务器实例，镜像服务器实例将传入的日志记录应用于镜像数据库，从而将其继续前滚。“数据库镜像”是用于提高数据库可用性的首选软件解决方案。镜像基于每个数据库实现，并且只适用于使用完整恢复模式的数据库。简单恢复模式和大容量日志恢复模式不支持数据库镜像。因此，所有大容量操作始终被完整地记入日志。数据库镜像可使用任意支持的数据库兼容级别。在“数据库镜像模式”中，主体服务器和镜像服务器作为伙伴进行通信和协作。两个伙伴在会话中扮演互补的角色：主体角色(生产服务器)和镜像角色(备份服务器)。在任何给定的时间，都是一个伙伴扮演生产服务器角色，另一个伙伴扮演备用服务器角色。如果生产服务器角色出现故障时，则备份服务器角色马上会顶替出现故障的生产服务器角色，转变为生产服务器角色。从而实现数据库的高可用性。
数据库镜像方案有两种镜像运行模式
一种是“高安全性模式”，它支持同步操作。在高安全性模式下，当会话开始时，镜像服务器将使镜像数据库尽快与主体数据库同步，一旦同步了数据库，事务将在伙伴双方处提交，这会延长事务滞后时间。
第二种运行模式，即高性能模式，它与第一种模式的主要差异就在于异步运行。镜像服务器尝试与主体服务器发送的日志记录保持同步。镜像数据库可能稍微滞后于主体数据库。但是，数据库之间的时间间隔通常很小。但是，如果主体服务器的工作负荷过高或镜像服务器系统的负荷过高，则时间间隔会增大。在高性能模式中，主体服务器向镜像服务器发送日志记录之后，会立即再向客户端发送一条确认消息。它不会等待镜像服务器的确认。这意味着事务不需要等待镜像服务器将日志写入磁盘便可提交。此异步操作允许主体服务器在事务滞后时间最小的条件下运行，但可能会丢失某些数据。具体采用哪种模式，则需要数据库管理员根据企业对待数据损失的态度与工作负荷等来确定。
可见现在可用的备份服务器与生产服务器之间的数据同步解决方案都是基于事务日志来实现的。
3、解决数据一致性问题
假设现在有这么一种情况。在一个银行系统中，某个用户需要转帐。这个转帐作业主要是通过两个步骤来完成。第一个步骤就是扣减用户帐户中的金额;第二个步骤是把钱转入到另外一个用户那里。现在如果在转帐的过程中，第一步成功了，但是第二个步骤因为某种原因出错了。如用户提供的帐户名字与实际转帐的帐户名字不符，则第二个操作就会失败。此时整个转帐操作就会以失败而告终。但是现在的问题是，第一个扣减的动作在数据库zhon给已经完成了。而实际却是没有转帐成功，就救造成了数据一致性的问题。
实际过程中如果应用程序发出 ROLLBACK 语句，或者数据库引擎检测到错误，就使用日志记录回滚未完成的事务所做的修改。也就是说，当第二个操作失败的话，应用程序要发出一个ROLLBACK 语句，利用事务日志回滚功能，恢复第一步的操作。也就是说，把扣减金额的操作进行恢复，从而实现数据的一致性。类似的应用，在数据库开发过程中很频繁。
4、数据库时点恢复的问题
如现在遇到这么一种故障。数据库系统在上午11点突然发现故障，启动不起来了。而数据库系统是在昨天晚上12点刚做完一个完全备份。在这种情况下，如果只是从完全备份中恢复数据的话，只能够恢复到昨天晚上12点的数据。那从昨天晚上12点到今天上午11点的数据就不能够恢复了吗?
其实不然。因为用户在对数据库做的任何一个修改都会保存在事务日志当中。为此只要事务日志不损坏的情况下，数据库管理员可以把数据恢复到上午11点那个时刻的数据。具体的操作方法很简单，就好先利用完全备份文件恢复数据库系统，此时数据库中的数据位昨天晚上12点的数据。然后再利用日志恢复功能把数据恢复到今天上午11点的数据。可见事务日志可以帮助管理员把数据恢复到某一个具体的时点。