【讨论】 关于压力大的数据库的同步复制容灾应用
eygle_fan,你咋转不过来呢?无论本地怎么坏，只要redo在都好办。问题是启用远程的时候，基本上就是本地用不了了，那么就可能会有需要恢复的数据没有传过去。而在本地不会有这种情况，无论是在redo里，实在数据文件里，是在回滚段里，只要这些东西都完好，数据库就可以起来
-------------------------------------------------------------------------------- 作者：silverwang 时间：04-11-26 16:32
其实说白了，就是存储级的容灾做不出事务级的存储(比如，我要求N个按顺序传向不阵列或者同阵列不同光纤通道的多个数据块要么同时存储成功，要么同时失败).因此，窃以为将来的趋势还是依赖于数据库自身的事务将容灾集合起来更可靠.(就如Dataguard)
-------------------------------------------------------------------------------- 作者：eagle_fan 时间：04-11-27 23:07
回滚段是在数据文件里面的吧。redo也是在日志文件里面的。远端也是同样有数据文件,redo log的吧？"就可能会有需要恢复的数据没有传过去。"这句话如何理解呢
-------------------------------------------------------------------------------- 作者：biti_rainy 时间：04-11-28 10:42
如果你总是能保证传输的顺序和 oracle 写顺序一致，或者一起，那肯定没有问题的。至少也要保证日志和归档是率先传过去的。根据我了解的情况，在同步传输的时候，本地会冻结存储cache使得无法做任何写入，同步完毕才可以做写入。这样对于文件系统可能就有一个新的问题，那就是 OS 还有cache，这部分数据可能就麻烦了,兴许只有 raw device 才是安全的。
-------------------------------------------------------------------------------- 作者：Kamus 时间：04-11-28 23:47
我曾经对于磁盘cache的问题咨询过veritas的工程师。回答曰：这个是没有办法保证的。
意思就是如果磁盘的block不发生变化，基于存储级别的同步软件都无法保证传输。但是我倒是觉得应对磁盘cache的技术对于veritas等厂商应该还是应该考虑到的
-------------------------------------------------------------------------------- 作者：wolfgroup 时间：04-12-06 23:03
-------------------------------------------------------------------------------- 作者：dx6340 时间：04-12-07 11:01
我现在用shareplex的在数据同步中，1天处理archive log 在 200G，DSG没有用过，但是听客户说还能处理得更多（PS: 只是听说，我没有测试过）
-------------------------------------------------------------------------------- 作者：huanghongjie 时间：04-12-07 11:07
其实现在任何一种灾备都不是零风险的，需要从多个方面考虑的。无论是同步还是异步，无论是用dataguard还是存储级别冗灾，我想都有可能丢数据。所以在讨论灾备的时候，还应该考虑从应用系统完善和灾备技术结合上总体考虑，我想一些灾备的能力就可能提高了。
-------------------------------------------------------------------------------- 作者：Kamus 时间：04-12-08 02:26
我听一个实际测试过shareplex的人说当一天的日志量达到60G以上的时候，shareplex就应付的比较吃力了。你的系统一天归档有200G？
-------------------------------------------------------------------------------- 作者：Kamus 时间：04-12-08 02:31
所以我们的方案会有一个最后1分钟数据的拯救功能，根据我们自己系统的业务log来作。如果使用dataguard，那么就设置归档的lag是1分钟，这样可以保证没有数据丢失。
但是我自己心中也有些打鼓，这个一分钟归档一次是不是有些过于频繁了。
-------------------------------------------------------------------------------- 作者：eagle_fan 时间：04-12-08 10:14
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 时间：04-12-08 11:16
关于这个问题我倒确实不大清楚。以往的现象是当使用文件系统的时候会使用比较多的 file cache，这么说来，难道是读的时候cache了？读的时候cache了要有效的话，写的时候需要那这些file cache里面的block 抹去？或者说我们如何完整地解释这个问题
-------------------------------------------------------------------------------- 作者：dx6340 时间：04-12-08 13:12
我做的一个电信客户，高峰期一天200个G。shareplex在某一段高峰时间有些延迟，但是总体上来看还是能满足客户的需求。
-------------------------------------------------------------------------------- 作者：huanghongjie 时间：04-12-09 11:37
看到大家都提到shareplex这个产品，我想问问:这个产品在国内有成功案例吗？能列举一些吗？大概是个什么样的价格？上面有人提到数据库的日志有200G，好像据我所知这个产品能够定制很细的策略，比如到表的字段，也就是说数据库的日志很大，但是不一定让shareplex传输的数据量很多，这个好像要跟客户的灾备要求有关吧，比如只是需要把详单表的变化传过去，就没必要传帐单表的变化了。我想问问如果是异地灾备（1千公里以上），现在电信能够提供的传输带宽和线路类型是什么？
-------------------------------------------------------------------------------- 作者：dx6340 时间：04-12-09 12:58
在国内有成功案例，具体可致电Quest Software 在中国的分公司。的确，shareplex只把自己需要把定制好要复制表的数据和DDL传递。电信提供的方式很多，具体咨询当地的电信部门。
-------------------------------------------------------------------------------- 作者：biti_rainy 时间：04-12-10 17:30
这个问题，参考http://218.94.123.17/viewthread.php?tid=39750。这里做了进一步探讨。steve 说的没错，但进一步控制权还在os自身上
-------------------------------------------------------------------------------- 作者：eagle_fan 时间：04-12-12 13:46
关于这个还是有点不同的意见，发在上面这篇文章上。
不过关于同步和异步的问题，倒让我联想到了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 时间：04-12-12 15:32
我认为最安全的方式还是在数据库这个级别做到基于事务的容灾
-------------------------------------------------------------------------------- 作者：dx6340 时间：04-12-15 17:08
具体的延迟因素很多1）2边ORACLE的当前负载 2）数据库间的网路带宽 3）复制数据的动作，就是DML动作 4）复制数据的属性，有无唯一INDEX等等。需要整体评估
-------------------------------------------------------------------------------- 作者：fengda 时间：04-12-17 13:29
我们是dsg realsync的用户，感觉他们的产品还不错，特别是在首次同步的时候，不用停业务，实施起来省了很多麻烦，测试下来效率要高一些，另外能提供本地化服务，这是俺们最需要的.... |
gulibin
博客统计信息
热门文章
最新评论
友情链接
