有人有兴趣讨论下压力大的数据库的容灾嘛？

huanghongjie

忍不住了，说两句。
其实现在任何一种灾备都不是零风险的，需要从多个方面考虑的。无论是同步还是异步，无论是用dataguard还是存储级别冗灾，我想都有可能丢数据。所以在讨论灾备的时候，还应该考虑从应用系统完善和灾备技术结合上总体考虑，我想一些灾备的能力就可能提高了。
   呵呵，大家一起来讨论。

小新

这么多人关注，呵呵，大家继续啊，讨论出个结果来。

eagle_fan

最初由 biti_rainy 发布
[B]

如果你总是能保证 传输的顺序和 oracle 写顺序一致，或者一起，那肯定没有问题的

至少也要保证日志和归档是率先传过去的


根据偶了解的情况，在同步传输的时候，本地会冻结存储cache使得无法做任何写入，同步完毕才可以做写入。这样对于文件系统可能就有一个新的问题，那就是 OS 还有cache，这部分数据可能就麻烦了,兴许只有 raw  device 才是安全的。 [/B]

hi biti：
oracle使用os的cache吗
oracle是采用synchronous writes的方式立即写入硬盘

下面这篇文章取自ixora
Oracle Internals Notes
Buffered I/O
Most file system I/O is buffered by the operating system in its file system buffer cache. The idea of buffering is that if a process attempts to read data that is already in the cache, then that data can be returned immediately without waiting for a physical I/O operation. This is called a cache hit. The opposite is called a cache miss. When a cache miss occurs, the data is read from disk and placed into the cache. Old data may have to be removed from the cache to make room for the new data. If so, buffers are reused according to a least recently used algorithm in an attempt to maximize the number of cache hits.
The file system buffer cache is also used for write operations. When a process writes data, the modified buffer goes into the cache. If the process has explicitly requested the synchronous completion of writes (synchronous writes) then the data is written to disk immediately and the process waits until the operation has completed. However, by default delayed writes are used. User processes do not wait for delayed writes to complete. The data is just copied into the buffer cache, and the operating system has a background task that periodically flushes delayed write buffers to disk. Delayed writes allow multiple changes to hot blocks to be combined into fewer physical writes, and they allow physical writes to be optimally ordered and grouped.

Delayed writes can be lost if a system failure occurs while some delayed writes are still pending. Some file systems support a write behind mount option that minimizes the delay before the flushing of delayed write buffers begins. This minimizes the risk of data loss, but reduces the benefit of delayed write caching. It also reduces the risk and severity of delayed write backlogs.

Because delayed writes involve a risk of data loss, Oracle never uses them. Oracle insists on the synchronous completion of writes for all buffered I/O to database files. This is done by using the O_DSYNC flag when opening database files. This means that the data itself must be written synchronously, but that delayed writes may be used for updates to the file access and modification times recorded by the file system.

Do not confuse delayed writes with asynchronous writes. User processes do not wait for the completion of either type of writes. But, they are notified or learn when asynchronous writes have been completed, whereas there is no notification of the completion of delayed writes. It is just assumed that delayed writes will be completed. Thus delayed writes involve a risk of data loss, but asynchronous writes do not.

biti_rainy

关于这个问题我倒确实不大清楚

以往的现象是 当使用文件系统的时候会使用比较多的 file cache，这么说来，难道是读的时候cache了？ 读的时候cache了要有效的话，写的时候需要那这些file cache里面的block 抹去？

或者说我们如何完整地解释这个问题

dx6340

我做的一个电信客户，高峰期一天200个G。
shareplex在某一段高峰时间有些延迟，但是总体上来看还是能满足客户的需求。

huanghongjie

看到大家都提到shareplex这个产品，我想问问:这个产品在国内有成功案例吗？能列举一些吗？大概是个什么样的价格？
上面大侠提到数据库的日志有200G，好像据我所知这个产品能够定制很细的策略，比如到表的字段，也就是说数据库的日志很大，但是不一定让shareplex传输的数据量很多，这个好像要跟客户的灾备要求有关吧，比如只是需要把详单表的变化传过去，就没必要传帐单表的变化了。
我想问问如果是异地灾备（1千公里以上），现在电信能够提供的传输带宽和线路类型是什么？

dx6340

在国内有成功案例，具体可致电Quest Software 在中国的分公司。
的确，shareplex只把自己需要把定制好要复制表的数据和DDL传递。
电信提供的方式很多，具体咨询当地的电信部门。

biti_rainy

最初由 eagle_fan 发布
[B]

hi biti：
oracle使用os的cache吗
oracle是采用synchronous writes的方式立即写入硬盘

下面这篇文章取自ixora
Oracle Internals Notes
Buffered I/O
Most file system I/O is buffered by the operating system in its file system buffer cache. The idea of buffering is that if a process attempts to read data that is already in the cache, then that data can be returned immediately without waiting for a physical I/O operation. This is called a cache hit. The opposite is called a cache miss. When a cache miss occurs, the data is read from disk and placed into the cache. Old data may have to be removed from the cache to make room for the new data. If so, buffers are reused according to a least recently used algorithm in an attempt to maximize the number of cache hits.
The file system buffer cache is also used for write operations. When a process writes data, the modified buffer goes into the cache. If the process has explicitly requested the synchronous completion of writes (synchronous writes) then the data is written to disk immediately and the process waits until the operation has completed. However, by default delayed writes are used. User processes do not wait for delayed writes to complete. The data is just copied into the buffer cache, and the operating system has a background task that periodically flushes delayed write buffers to disk. Delayed writes allow multiple changes to hot blocks to be combined into fewer physical writes, and they allow physical writes to be optimally ordered and grouped.

Delayed writes can be lost if a system failure occurs while some delayed writes are still pending. Some file systems support a write behind mount option that minimizes the delay before the flushing of delayed write buffers begins. This minimizes the risk of data loss, but reduces the benefit of delayed write caching. It also reduces the risk and severity of delayed write backlogs.

Because delayed writes involve a risk of data loss, Oracle never uses them. Oracle insists on the synchronous completion of writes for all buffered I/O to database files. This is done by using the O_DSYNC flag when opening database files. This means that the data itself must be written synchronously, but that delayed writes may be used for updates to the file access and modification times recorded by the file system.

Do not confuse delayed writes with asynchronous writes. User processes do not wait for the completion of either type of writes. But, they are notified or learn when asynchronous writes have been completed, whereas there is no notification of the completion of delayed writes. It is just assumed that delayed writes will be completed. Thus delayed writes involve a risk of data loss, but asynchronous writes do not. [/B]

这个问题，参考
http://218.94.123.17/viewthread.php?tid=39750

这里做了进一步探讨
steve 说的没错，但进一步控制权还在os自身上

eagle_fan

关于这个还是有点不同的意见，发在上面这篇文章上

不过关于同步和异步的问题，倒让我联想到了oracle的slave IO虚拟异步的机制
如果操作系统不支持异步IO
oracle采用slave IO实现Asynchronous I/O
因为oracle总是会向系统申请操作，需要等到操作系统说“OK,已经写好了”
如果没有slave IO,DBWR总是处于write/wait/write/wait的状态
所以DBWR会通过slave IO实行IO操作，只需要slave IO回报说“OK，已经写好了，DBWR就继续写
DBWR处于write/write/write...
可以提高性能

和这个主题无关，只是随便想到了

cyr1974

我认为最安全的方式还是在数据库这个级别做到基于事务的容灾