问如何保证数据的一致性和完整性？

EN

要回答这个问题，让我们看看当事务提交到数据库时会发生什么。

在SQL Server上执行DML语句时，必须发生一些事件。

1. 事务被写入磁盘上的事务日志。
2. 下一次将事务写入内存中的相应数据页，然后将数据页标记为脏(即不再匹配磁盘上的内容)。
3. 在下一个CHECKPOINT或LAZY WRITE中，脏页将被写回磁盘。由于这些操作的频率，在将整个页面写回磁盘之前，单个数据页实际上可以接收多个更改。

一旦事务在事务日志中，它本质上就被提交了。这是过程中的关键点。如果Server在更改事务日志之前崩溃，Server就不会向客户端确认事务成功。

如果SQL Server在更新事务日志后崩溃，并且在内存中或磁盘上更新页面之前，仍然可以从事务日志中恢复事务。一旦Server服务在新的主节点上启动，数据库将经历恢复，并通过将尚未写入数据文件的事务日志中的事务应用到数据库前滚。

这取决于，因为有多个点可以发生崩溃。

• Server -进程可能崩溃
• Windows操作系统可能会崩溃
• VM主机可能崩溃
• SAN/磁盘控制器可能崩溃

现在，如果Server崩溃，Brendan的回答将详细描述这个过程。

如果是Windows本身呢？Windows的NTFS是一个日志文件系统，所以它应该以一致的状态编写SQL Server告诉它的任何数据，对吗？不，它不能保证用户数据(哪些数据库文件和事务日志是完整的)是完整的。它保证NTFS 内部数据结构是健壮的。因此，即使NTFS告诉Server事务是写入的，如果同时发生崩溃，也可能不是。

如果VM主机崩溃怎么办？这就更棘手了。从Windows的角度来看，这有点像有人拉电源线。这里最大的“但是”是VM系统隐藏IO，因此Windows认为它已经成功地执行了写操作，但是它仍然被缓存在VM主机上。现在主机崩溃了，我以为是书面的东西就消失了。(虚拟)磁盘上的实际状态是什么？没人能看出来。这并不罕见，比如10年前虚拟化技术还不那么成熟的时候。

如果磁盘控制器崩溃怎么办？所有赌注都取消了。没有办法知道控制器到底在磁盘上写了什么，如果有的话。没有任何保证，这是有意义的。我在HP上见过一些这样的案例，但这些都是罕见的。

例如，操作系统在处理sql数据和日志文件时崩溃，从而导致损坏。

您在这里讨论的是SQL和OS在数据一致性方面几乎没有作用，因为数据和日志文件驻留在共享驱动器上。因此，基本上，如果OS崩溃和故障转移发生，所有对战事务都将回滚，提交的事务将被前滚，当DB在其他节点上联机时，您将看到这一点。