来讨论一个recovery的问题

学习一下！收起

我的想法是这样的：

对于数据库来讲，写操作最终应该是通过write()这样的系统调用进行的，在数据库的一次
完整性的写，应该是有多个write()操作，而对操作系统来讲，它每收到一次write系统调用的请求，
它就会向存储发送一次写命令，而存储也就会执行一次写操作（这里假设没有使用raw device，如果用file，可能
先写在file cache里，然后再定期sync到disk上），
所以说数据库的写完整性是只能由数据库来保证，存储是不会保证的，
假设一次数据库写操作需要调用10次write() 系统调用，当调用到第五次时，
server crash了，我认为前五次的写操作应该已经apply到disk上了，存储
应该不会知道这只是数据库一次写请求的一部分。
但是存储能保证这5次写请求能够按照原顺序写入，这个应该没有问题。

当然，很有可能数据库不是简单通过write（）来实现的，我记得在unix里有聚集写（writev）这样的系统调用，
可以一次写多个非连续缓存。

数据库是个非常复杂的系统，可能还有其他一些技术能保证写完整性，仅凭我的这点水平，
其实还远不足以解释这么深入的问题，这块还需要wang给我们多多指点，
让我们能够更深入的了解数据库的底层机制。收起

are you talking about this part "这个不同于server crash。在server crash得时候，如果一个写请求已经完整地发送到SAN，那么SAN肯定会把完整的数据写进去。如果请求发送到一半数据库server就down了，那么这个tcpip得连接就会中断而SAN也不会去写那个发送到一半的请求。所以对于server crash来说，crash recovery是可以保证数据库页级别的一致性的……但是如果SAN断电了，那就自求多福吧……"?

can you elaborate more of your point? i can't fully understand what exact point you were talking about收起

老帖被翻出来了，
不过感觉王的第二点理解有点不对啊，照这么说，如果是数据库建在local disk上就不能crash recovery了？
存储好像是不会保证数据库的写完整性的，只能保证写顺序是正确的。。。收起

好帖收起

恩，有见解收起

我觉得是在对数据库一致性的控制上。收起

高手的理解，学习了收起

...... cmon guys, there's even haven't been an answer to the question :lol

anyway let me post MY answer here, other people may have different opinion and any comments are welcome

根据俺的理解，point-in-time得FS image有一个很大的问题，也就是它可以在文件系统的页级别保证一致性，但是无法保证数据库的页级别一致性。
一个数据库的data page可以是4k,8k,16k,32k得，但是文件系统的页大小基本都是4k得。也就是在某一个point-in-time，有可能一个数据库的页只有一部分被刷新到磁盘上（比如只是前两个4k页），然后FS得consistency-group就会在文件系统级别一致，但是在数据库级别不一致……而且这种东西不能用crash recovery来恢复，因为从数据库页的header看来该页已经被写入了，但是实际上真实写入的只有前面的几个page……

这个不同于server crash。在server crash得时候，如果一个写请求已经完整地发送到SAN，那么SAN肯定会把完整的数据写进去。如果请求发送到一半数据库server就down了，那么这个tcpip得连接就会中断而SAN也不会去写那个发送到一半的请求。所以对于server crash来说，crash recovery是可以保证数据库页级别的一致性的……但是如果SAN断电了，那就自求多福吧……

这个是俺的理解，不知道有没有什么地方不大妥当，欢迎指出收起

是的，所以oracle里用rman备份时，也是把控制文件做个快照，这样备份时就使用这个快照控制文件，以防止在备份时前后的SCN不一致收起