SQL Server日志的的作用

在关系数据库系统中，我们需要数据库可靠，所谓的可靠就是当遇见如下两种情况之一时保证数据库的一致性:

在系统崩溃/故障等情况下，保证数据库的一致性

数据不能在多个DML语句同时修改数据的情况下，导致不一致或数据损坏

实际上，上述第二种情况就是并发性所需要解决的问题，传统关系数据库中，我们用锁来解决这个问题，而对于内存 数据库或带有乐观并发控制的数据库系统，通过多版本并发控制（MVCC）来解决这个问题。因为本篇文章的主旨是讨论 日志而不是并发，因此对于上述第二种情况不会详细解释。

我们上面还多次提到了一致性（Consistence），在开始了解日志如何维持一致性之前，我们首先要明白什么是一致 性。一致性在数据库系统中所指的内容比较广，一致性不仅仅需要数据库中的数据满足各种约束，比如说唯一约束，主 键约束等，还需要满足数据库设计者心中的隐式约束，简单的业务约束比如说性别这列只允许男或女，这类隐式约束通 常使用触发器或约束来实现，或是在数据库所服务的应用程序中进行约束。

下面我们把一致性的范围缩减到事务一致性，事务一致性的概念学术上的解释为：

如果事务执行期间没有出现系统错误或其他事务错误，并且数据库在事务开始期间是数据一致的，那么在该事务结束 时，我们认为数据库仍然保证了一致性。

因此，引申出来事务必须满足原子性，也就是事务不允许部分执行。事务的部分执行等同于将数据库置于不一致的 境地之下。此外多事务并发执行也可能导致数据库不一致，除非数据库系统对并发进行控制。

关于上面的显式约束，由数据库系统来实现，比如说违反了一致性约束的语句会导致数据库系统报错并拒绝执行。但 一些隐式的事务约束，比如说写语句的开发人员对系统设计者所设计的规则并不了解，导致了违反业务规则的数据修改 ，这种情况在数据库端很难探查。但是这种问题通常可以规则到权限控制的领域，我们认为授予某个用户修改特定数据 的权限，就认为这个用户应该了解数据库中隐式和显式的规则。

除去这些业务上的数据不一致之外，我们需要在系统崩溃等情况下保证数据的一致性，而可能导致这类数据不一致的 情况包括但不限于下面这些情况：

存储系统损坏，比如说磁盘上字节级别的损坏，这类问题通常可以通过磁盘上的奇偶校验发现，另外还有一些大一些 的问题，比如说整个存储系统崩溃。这类问题的修复手段取决于前期工作，比如说备份策略，高可用性架构，SAN Replication等技术。

机房整体损坏，这类问题比较极端，只有异地机房容灾可以解决。

系统故障，修改数据的进程都需要事务作为上下文，和其他概念一样，事务也是有状态的。而事务状态通常存储在易 丢失的主存中，因此，当出现系统故障、进程崩溃等系统失败时，可能导致事务状态的丢失，此时，我们就无法得知事 务中的哪部分已经执行而哪部分还未执行，重新运行事务并不会解决这类问题，因为有可能导致事务中某部分的重复执 行。因此解决这类问题的方式就是将事务的状态以及对数据库修改的详细步骤与内存中的数据分开存放，并存储于磁盘 等稳定的介质中，当系统故障等情况下，我们可以通过这些记录来将系统恢复到一致性的状态之下，我们对这类存储， 称之为日志。

SQLServer中的日志

SQL Server中靠日志来维护一致性（当然，日志的作用非常多，但一致性是日志的基本功能，其他功能可以看作是额 外的功能）。通常我们创建数据库的时候，会附带一个扩展名为ldf的日志文件。日志文件其实本质上就是日志记录的集 合。在SQL Server中，我们可以通过DBCC LOGINFO来看这个日志的信息，如图1所示。

图1.DBCC LOGINFO

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!