总结及未来的路-线性代数及其应用中文版下载

9.3 文件部分地删除 SQLite 假设从用户进程角度来看是一个原子操作。当删除过程中发生掉电，当电源恢复之后，SQLite 希望看到文件 要么完整的存在，要么根本找不到了。如果操作系统不能做到这一点，那事务就可能不是原子性的了。 9.4 写入到文件中的垃圾 SQLite 的数据文件是一种普通的磁盘文件，可以由普通用户进行读写。一些流氓进程可能会打开一个 SQLite 文件， 并在其中写入一些混乱的数据。混乱的数据也可能由于操作系统的 BUG 而写入到一个 SQLite 的数据文件中。对于 这些情况，SQLite 无能为力。 9.5 删除掉或更名了“hot”日志文件 如果掉电或系统崩溃导致留下了一个”hot”日志文件在磁盘上。实际上，原来的数据文件再加上留下来的“hot“日 志文件， 是 SQLite 下回打开时发生回滚使用的，这可以恢复 SQLite 数据的正常状态（节 4.2）。SQLite 会在数据 库所在同一目录下用打开的文件名来寻找可能存在的”hot”日志文件。如果数据文件或者日志文件被移动或者改名， 或者删除掉了，那么这些日志文件将不会被回滚，数据库也就可能损坏，无法使用了。 我们常怀疑 SQLite 发生的恢复失败的例子是这样的：停电了，之后电又恢复了。一个好心的用户或者系统管理管 理员开始查看磁盘损坏。他们看到名为"important.data"数据库文件，或许类似的文件。但由于停电，这里也同样有 一个日志文件名为"important.data-journal".这个用户删除了这个“hot”日志文件，认为他是清理系统。那于这种情 况，除了进行用户培训，没有其他办法。 如果有多个联接（硬或者符号联接）指向一个数据文件，这个日志文件会以被打开的联接文件名相关来创建的。如 果系统崩溃之后，数据库以一个新的联接重新打开，这个“hot”日志文件就不会被找到，数据也不会发生回滚。 有时，电源问题会导致文件系统出现毛病，如最新修改的文件名被丢失了，并会转移至类似于"/lost+found"这样的 目录中。当这种情况发生的时候，这个 hot 日志文件就不会被找到，同样恢复也不会发生。SQLite 在同步一个日志 文件时通过打开并同步日志文件所在目录来尝试阻止这类事件发生。然后，转移文件到"/lost+found"可能会由不相 关的其他进程在相同的目录中产生与主数据库文件名相同的不相关文件。既然这都是 SQLite 所无法控制，所以 SQLite 没有什么好办法。如果你运行在一种易导致名称空间冲突的文件系统上，那么你最好把每一个 SQLite 的数 据文件放在你私有的子目录中。 10.0 总结及未来的路 即使到了现在，还是有人发现了一些关于原子提交机制失败模式，开发者不得不为此做一些补丁。这样的事情发生 得越来越少了，失败模型也变得越来越模糊了。但如果就认为 SQLite 的原子提交逻辑是没有任何 bug，那是相当愚 昧的。开发者承诺将尽可能快的修复被发现的 bug。 开发者同时在考虑新的优化提交机制的办法。当前的 linux,macOSX,win32 的 VFS 实 现使用这些系统之上的一些悲 观设定。或许在与一些了解这些系统如何工作的专家交流之后，我们或许可能放松一些这些系统上的设定，使其跑