shahand

引用:

原帖由 冬瓜头 于 2007-9-12 11:27 发表
oracle从来都是用同步io？那延迟可很大了吧。根据这段话来看，异步IO是比较折中的方法，oracle为何不用异步io呢？

Oracle一直强烈建议用aio的。

冬瓜头

嗯，fs会丢失数据，这是一定的，但是丢失了，可以找回来，这就是log的作用了，oracle可以从崩溃之后，通过日志将数据redo回来。这就和fs没什么关系了。

冬瓜头

引用:

原帖由 shahand 于 2007-9-12 11:33 发表


redo如果被cache(无论是fs cache 还是 array的cache)了，

然后随着系统crash丢失了部分redo数据(记录)呢？

再次redo啊，如果被cache了，磁盘上就没有，没有，再次redo的时候就从磁盘上的号码开始接着do，不怕crash。

clarcli

redolog被cache了,系统down了,数据库oracle有可能就打不开了;
比如数据库更新了记录A,数据库发出了更新controlfile和写入了redolog的命令,此时会产生一个scn号随这个记录一起写入,controlfile也会记录这个scn号,,假设controlefile的更新已经写入磁盘,而redolog还是在cache了,datafile的更新也没有写入磁盘,系统crash之后,重新启动数据库的时候,由于控制文件比较新,而redolog也没有相关记录用于恢复,数据库就会产生一致性问题;

冬瓜头

redolog和control file必须要求fs写入磁盘才返回成功。

fengwy

不是很少，而是根本就不会。
>>>这个倒不敢苟同，你去下个Linux较新版本的src code，看看Documentation\filesystems\ext3.txt，里面确实有这一选项；
>>>实现这个技术，很简单(特别是加上jbd之后)；当然其必要性，有待商榷；
>>>文件系统种类太多，可能会有不同的应用，也许有的环境就需要把data也进行log！

日志文件系统只对文件系统的元数据作日志
------------------------------------------------------------
you are right!
确实可以对数据作日志！默认是对元数据作日志


There are 3 different data modes:

* writeback mode
In data=writeback mode, ext3 does not journal data at all.  This mode provides
a similar level of journaling as that of XFS, JFS, and ReiserFS in its default
mode - metadata journaling.  A crash+recovery can cause incorrect data to
appear in files which were written shortly before the crash.  This mode will
typically provide the best ext3 performance.

* ordered mode
In data=ordered mode, ext3 only officially journals metadata, but it logically
groups metadata and data blocks into a single unit called a transaction.  When
it's time to write the new metadata out to disk, the associated data blocks
are written first.  In general, this mode performs slightly slower than
writeback but significantly faster than journal mode.

* journal mode
data=journal mode provides full data and metadata journaling.  All new data is
written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state.  This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes.

forwarding

总而言之，没有被持久化的东西，掉电之后就over了。
buffer只是一个协调高速设备和低速设备的东西，从来就不可能两者兼得。
各种journal啊，包括redo flush机制其实就是针对不同系统的特点优化持久化数据的频率。
如果想深究，做实验就可以了。

为什么redo会恢复呢？就是redo flush的频率比较高，所以从概率上讲减小了数据不一致的可能行。
并不是说避免呀，instance修复的时候是要对一致性进行检查的，如果不一致，可以通过redo修复。
绝对的RPO=0是不可能的。对于oracle来说，RPO最多也是3秒。
不错了，在最差最差的情况下损失了3秒的数据。算上FS可能这个数字会大一点，也是几秒吧。

对于用户来讲已经足够了。这就够了。
等到了哪一天，计算机体系结构中可以不需要内存，硬盘速度足够快的时候，就可以RPO=0了。

冬瓜头

nono, flush redo的时候是保证flush到磁盘才会成功提交的，否则undo。
3秒，一秒钟可能有几千笔交易，你这下好，丢失3秒钟的交易，如果是关键业务，等着哭吧你！

lkptantan

如果是1秒就几千记录的，还会因为死机这种原因而丢数据。。。
3秒已经不错了，感觉大家要去看看数据库再回来

冬瓜头

是吧，哈哈，这不就见识过了么？兄弟没白来啊