冬瓜头

引用:

原帖由 clarcli 于 2007-9-10 15:45 发表
我想日志更新了,控制文件也会跟着更新,down了之后,重新启动,mount控制文件,在mount数据文件的时候会检查文件scn号是否一直,由于数据文件没有更新,会使用日志做数据文件的恢复的;

能否详细说说，oracle每个数据文件都有一个scn，还是每个块都有一个最后落实的scn？

killy1980

我很受伤.......大家看数据库真的只靠日志就能绝对保证一致性么 题目，越赖越偏到那里去了！

fengwy

行，那么你得意思是log写入的时候是write through了。就算这样，你也说了，比如dirty data block writer，这个进程，如果他是异步的，某时刻，他向数据文件flush的一次，将dirty data写入文件，并得到success的提示，那么dbms会将lsn提高到当前未提交或者未flush的最小lsn号处，以前的lsn他认为已经得到落实了，但是此时dirty data还在fs的cache中，down机，这些数据将丢失，但是dbms认为这些事务已经落实到了磁盘上，这不就是不一致么。
还需要怎么解释呢？麻烦仔细想想，这是我最后一次解释了。
-------------------------------------------------------------------------
log写同步方式和write through有什么关系？
不太明白你描述的意思。
写脏数据一定要触发检查点，而且你说脏数据已经写入数据文件了，怎么还在cache中？不好意思我理解能力不强。

fengwy

引用:

原帖由 冬瓜头 于 2007-9-10 14:51 发表


呵呵，说了一大堆，还是白说了。

就算白说吧。
能否解释一下数据库中用到的裸设备，这连文件系统都没。

冬瓜头

罗设备不用解释，我这个论题前提就是使用了fs的cache。

冬瓜头

引用:

原帖由 clarcli 于 2007-9-10 15:45 发表
我想日志更新了,控制文件也会跟着更新,down了之后,重新启动,mount控制文件,在mount数据文件的时候会检查文件scn号是否一直,由于数据文件没有更新,会使用日志做数据文件的恢复的;

这位哥们让我茅塞顿开了。
一切都是oracle和db2实现机制不同造成的。oracle这种机制可以保证端到端的一致性。
db2的实现机制是，将崩溃恢复需要repaly的lsn存放到SQLOGCTL.LFH中，这就注定了db2在使用fs的cache的时候，非常容易丢失数据并造成不一致。

呵呵，感谢各位。

fengwy

引用:

原帖由 冬瓜头 于 2007-9-10 15:12 发表
是么，那能否见识一下，以前一直认为ntfs不能恢复丢失的数据。官方网页有么？给个看看说明ntfs能自动重做丢失的数据。

windows操作系统原理第252页；或者google一下

fengwy

引用:

原帖由 冬瓜头 于 2007-9-10 19:17 发表
罗设备不用解释，我这个论题前提就是使用了fs的cache。

你的论断就是非日志文件系统上的数据库没有日志文件系统上安全，不是吗？

冬瓜头

引用:

原帖由 fengwy 于 2007-9-10 19:39 发表


你的论断就是非日志文件系统上的数据库没有日志文件系统上安全，不是吗？

是的，针对某些数据库。根据实现原理的不同。

冬瓜头

引用:

原帖由 fengwy 于 2007-9-10 19:35 发表

windows操作系统原理第252页；或者google一下

我查了，ntfs是元数据日志，实际数据不做日志。只保证fs本身一致性，不保证上层的一致性。
而ext3有三种类型日志，可以元数据日志，可以元数据和实际数据都日志，可以元数据日志并且flush脏块后再flush日志。