SQLServer事务事务⽇志
事务 (SQL Server)
⼀、事务概念
事务是⼀种机制、是⼀种操作序列，它包含了⼀组数据库操作命令，这组命令要么全部执⾏，要么全部不执⾏。因此事务是⼀个不可分割的⼯作逻辑单元。在数据库系统上执⾏并发操作时事务是作为最⼩的控制单元来使⽤的。这特别适⽤于多⽤户同时操作的数据通信系统。例如：订票、银⾏、保险公司以及证券交易系统等。
⼆、事务属性
事务4⼤属性：
1  原⼦性(Atomicity)：事务是⼀个完整的操作。
2  ⼀致性（Consistency）：当事务完成时，数据必须处于⼀致状态。
3  隔离性(Isolation)：对数据进⾏修改的所有并发事务是彼此隔离的。
4  持久性(Durability)：事务完成后，它对于系统的影响是永久性的。
三、创建事务
T-SQL中管理事务的语句：
1 开始事务: begin transaction
2 提交事务：commit transaction
3 回滚事务: rollback transaction
事务分类:
1 显式事务:⽤begin transaction明确指定事务的开始。
2 隐性事务：打开隐性事务：set implicit_transactions on，当以隐性事务模式操作时，SQL Servler将在提交或回滚事务后⾃动启动新事务。⽆法描述事务的开始，只需要提交或回滚事务。
3 ⾃动提交事务：SQL Server的默认模式，它将每条单独的T-SQL语句视为⼀个事务。如果成功执⾏，则⾃动提交，否则回滚。
事务⽇志 (SQL Server)
Tue Oct 03 2017
每个 SQL Server 数据库都有事务⽇志，⽤于记录所有事务以及每个事务所做的数据库修改。
事务⽇志是数据库的⼀个关键组件。如果系统出现故障，你将需要依靠该⽇志将数据库恢复到⼀致的状态。
重要
永远不要删除或移动此⽇志，除⾮你完全了解执⾏此操作的后果。
提⽰
检查点会创建⼀些正常点，在数据库恢复期间将从这些正常点开始应⽤事务⽇志。有关详细信息，请参阅。
事务⽇志⽀持的操作
事务⽇志⽀持以下操作：
恢复个别的事务。
在 SQL Server 启动时恢复所有未完成的事务。
将还原的数据库、⽂件、⽂件组或页前滚⾄故障点。
⽀持事务复制。
⽀持⾼可⽤性和灾难恢复解决⽅案： AlwaysOn 可⽤性组、数据库镜像和⽇志传送。
恢复个别的事务
如果应⽤程序发出 ROLLBACK 语句，或者数据库引擎检测到错误（例如失去与客户端的通信），使⽤⽇志记录回退未完成的事务所做的修改。
在 SQL Server 启动时恢复所有未完成的事务
当服务器发⽣故障时，数据库可能处于这样的状态：还没有将某些修改从缓存写⼊数据⽂件，在数据⽂件内有未完成的事务所做的修改。启动 SQL Server 实例时，它将对每个数据库执⾏恢复操作。前滚⽇志中记录的、可能尚未写⼊数据⽂件的每个修改。在事务⽇志中到的每个未完成的事务都将回滚，以确保数据库的完整性。
将还原的数据库、⽂件、⽂件组或页前滚⾄故障点
在硬件丢失或磁盘故障影响到数据库⽂件后，可以将数据库还原到故障点。先还原上次完整数据库备份和上次差异数据库备份，然后将后续的事务⽇志备份序列还原到故障点。
还原每个⽇志备份时，数据库引擎将重新应⽤⽇志中记录的所有修改，前滚所有事务。最后的⽇志备份还原后，数据库引擎将使⽤⽇志信息回退到该点上未完成的所有事务。
⽀持事务复制
⽇志读取器代理程序监视已为事务复制配置的每个数据库的事务⽇志，并将已设复制标记的事务从事务⽇志复制到分发数据库中。有关详细信息，请参阅。
⽀持⾼可⽤性和灾难恢复解决⽅案
备⽤服务器解决⽅案、AlwaysOn 可⽤性组、数据库镜像和⽇志传送极⼤程度上依赖于事务⽇志。
在 AlwaysOn 可⽤性组⽅案中，数据库的每个更新（主要副本）在数据库的完整且独⽴的副本（次要副本）中直接再现。主要副本直接将每个⽇志记录发送到次要副本，这可将传⼊⽇志记录应⽤到可⽤性组数据库，并不断前滚。有关详细信息，请参阅
在⽇志传送⽅案中，主服务器将主数据库的活动事务⽇志发送到⼀个或多个⽬标服务器。每个辅助服务器将该⽇志还原为其本地的辅助数据库。有关详细信息，请参阅。
在数据库镜像⽅案中，数据库（主体数据库）的每次更新都在独⽴的、完整的数据库（镜像数据库）副本中⽴即重新⽣成。主体服务器实例⽴即将每个⽇志记录发送到镜像服务器实例，镜像服务器实例将传⼊的⽇志记录应⽤于镜像数据库，从⽽将其继续前滚。有关详细信息，请参阅。
Transaction Log characteristics
SQL Server 数据库引擎事务⽇志的特征：
事务⽇志是作为数据库中的单独的⽂件或⼀组⽂件实现的。⽇志缓存与数据页的缓冲区⾼速缓存是分开管理的，因此可在数据库引擎中⽣成简单、快速和功能强⼤的代码。有关详细信息，请参阅。
⽇志记录和页的格式不必遵守数据页的格式。
事务⽇志可以在⼏个⽂件上实现。通过设置⽇志的 FILEGROWTH 值可以将这些⽂件定义为⾃动扩展。这样可减少事务⽇志内空间不⾜的可能性，同时减少管理开销。有关详细信息，请参阅。
重⽤⽇志⽂件中空间的机制速度快且对事务吞吐量影响最⼩。
事务⽇志截断
⽇志截断将释放⽇志⽂件的空间，以便由事务⽇志重新使⽤。必须定期截断事务⽇志，防⽌其占满分配的空间（绝对会！）。⼏个因素可能延迟⽇志截断，因此监视⽇志⼤⼩很重要。某些操作可以最⼩⽇志量进⾏记录以减少其对事务⽇志⼤⼩的影响。
⽇志截断可从 SQL Server 数据库的逻辑事务⽇志中删除不活动的虚拟⽇志⽂件，释放逻辑⽇志中的空间以便物理事务⽇志重⽤这些空间。如果事务⽇志从不截断，它最终将填满分配给物理⽇志⽂件的所有磁盘空间。
为了避免空间不⾜，除⾮由于某些原因延迟⽇志截断，否则将在以下事件后⾃动进⾏截断：
简单恢复模式下，在检查点之后发⽣。
在完整恢复模式或⼤容量⽇志恢复模式下，如果⾃上⼀次备份后⽣成检查点，则在⽇志备份后进⾏截断（除⾮是仅复制⽇志备份）。
有关详细信息，请参阅本主题后⾯的。
备注
⽇志截断并不减⼩物理⽇志⽂件的⼤⼩。若要减少物理⽇志⽂件的物理⼤⼩，则必须收缩⽇志⽂件。有关收缩物理⽇志⽂件⼤⼩的信息，请参阅。
Factors that can delay log truncation
在⽇志记录长时间处于活动状态时，事务⽇志截断将延迟，事务⽇志可能填满，这⼀点我们在本主题（很长）前⾯提到过。
[!IMPORTANT} 有关如何响应已满事务⽇志的信息，请参阅。
实际上，⽇志截断会由于多种原因发⽣延迟。查询⽬录视图的 log_reuse_wait 和 log_reuse_wait_desc 列，了解哪些因素（如果存在）阻⽌⽇志截断。下表对这些列的值进⾏了说明。
log_reuse_wait
值
log_reuse_wait_desc 值说明
0NOTHING当前有⼀个或多个可重复使⽤的虚拟⽇志⽂件。
1CHECKPOINT ⾃上次⽇志截断之后，尚未⽣成检查点，或者⽇志头尚未跨⼀个虚拟⽇志⽂件移动。（所有恢复模式）
这是⽇志截断延迟的常见原因。有关详细信息，请参阅。
2LOG_BACKUP 在截断事务⽇志前，需要进⾏⽇志备份。（仅限完整恢复模式或⼤容量⽇志恢复模式）
完成下⼀个⽇志备份后，⼀些⽇志空间可能变为可重复使⽤。
3ACTIVE_BACKUP_OR_RESTORE 数据备份或还原正在进⾏（所有恢复模式）。
如果数据备份阻⽌了⽇志截断，则取消备份操作可能有助于解决备份直接导致的此问题。
4ACTIVE_TRANSACTION 事务处于活动状态（所有恢复模式）：
⼀个长时间运⾏的事务可能存在于⽇志备份的开头。在这种情况下，可能需要进⾏另⼀个⽇志备份才能释放空间。请注意，长时间运⾏的事务将阻⽌所有恢复模式下的⽇志截断，包括简单恢复模式，在该模式下事务⽇志⼀般在每个⾃动检查点截断。
sqlserver备份表语句
延迟事务。 “延迟的事务 ”是有效的活动事务，因为某些资源不可⽤，其回滚受阻。有关导致事务延迟的原因以及如何使它们摆脱延迟状态的信息，请参阅。
长时间运⾏的事务也可能会填满 tempdb 的事务⽇志。 Tempdb 由⽤户事务隐式⽤于内部对象，例如⽤于排序的⼯作表、⽤于哈希的⼯作⽂件、游标⼯作表，以及⾏版本控制。即使⽤户事务只包括读取数据（SELECT查询），也可能会以⽤户事务的名义创建和使⽤内部对象，然后就会填充 tempdb 事务⽇志。
5DATABASE_MIRRORING 数据库镜像暂停，或者在⾼性能模式下，镜像数据库明显滞后于主体数据库。（仅限完整恢复模式）
有关详细信息，请参阅。
6REPLICATION 在事务复制过程中，与发布相关的事务仍未传递到分发数据库。（仅限完整恢复模式）
有关事务复制的信息，请参阅。
7DATABASE_SNAPSHOT_CREATION
正在创建数据库快照。（所有恢复模式）
这是⽇志截断延迟的常见原因，通常也是主要原因。8LOG_SCAN
发⽣⽇志扫描。（所有恢复模式）
这是⽇志截断延迟的常见原因，通常也是主要原因。
9AVAILABILITY_REPLICA 可⽤性组的辅助副本正将此数据库的事务⽇志记录应⽤到相应的辅助数据库。（完整恢复模式）
有关详细信息，请参阅：。
10—仅供内部使⽤11—仅供内部使⽤12—仅供内部使⽤
13OLDEST_PAGE 如果将数据库配置为使⽤间接检查点，数据库中最早的页可能⽐检查点 LSN 早。在这种情况下，最早的页可以延迟⽇志截断。（所有恢复模式）
有关间接检查点的信息，请参阅。
14OTHER_TRANSIENT当前未使⽤此值。
可尽量减少⽇志量的操作
最⼩⽇志记录是指只记录在不⽀持时间点恢复的情况下恢复事务所需的信息。本主题介绍在⼤容量⽇志下（以及简单恢复模式下）按最⼩⽅式记录、但在运⾏备份时例外的操作。
备注
内存优化表不⽀持最⼩⽇志记录。
备注
在完整下，所有⼤容量操作都将被完整地记录下来。但是，可以通过将数据库暂时切换到⽤于⼤容量操作的⼤容量⽇志恢复模式，最⼩化⼀组⼤容量操作的⽇志记录。最⼩⽇志记录⽐完整⽇志记录更为有效，并在⼤容量事务期间，降低了⼤规模⼤容量操作填满可⽤的事务⽇志空间的可能性。不过，如果在最⼩⽇志记录⽣效时数据库损坏或丢失，则⽆法将数据库恢复到故障点。
下列操作在完整恢复模式下执⾏完整⽇志记录，⽽在简单和⼤容量⽇志恢复模式下按最⼩⽅式记录⽇志：
批量导⼊操作（、和）。有关在何时对⼤容量导⼊表按最⼩⽅式进⾏记录的详细信息，请参阅。
启⽤事务复制时，将完全记录 BULK INSERT 操作，即使处于⼤容量⽇志恢复模式下。
SELECT  操作。
启⽤事务复制时，将完全记录 SELECT INTO 操作，即使处于⼤容量⽇志恢复模式下。
插⼊或追加新数据时，使⽤语句中的 .WRITE ⼦句部分更新到⼤型值数据类型。注意，在更新现有值时没有使⽤最⼩⽇志记录。有关⼤型值数据类型的详细信息，请参阅。
在、和 UPDATETEXT, nUPDATETEXT, 、 UPDATETEXT 语句。注意，在更新现有值时没有使⽤最⼩⽇志记录。
重要
不推荐使⽤ WRITETEXT 语句和 UPDATETEXT 语句，应该避免在新的应⽤程序中使⽤这些语句。
如果数据库设置为简单或⼤容量⽇志恢复模式，则⽆论是脱机还是联机执⾏操作，都会按最⼩⽅式记录⼀些索引 DDL 操作。按最⼩⽅式记录的索引操作如下：
操作（包括索引视图）。
REBUILD 或 DBCC DBREINDEX 操作。
重要
不推荐使⽤“DBCC DBREINDEX 语句”；请不要在新的应⽤程序中使⽤该语句。
DROP INDEX 新堆重新⽣成（如果适⽤）。（操作期间将始终完整记录索引页的释放操作。）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。