data guard的一些疑问

battleman

容灾是一方面,我觉得physical standby最大的优势还是在于高可用方面，一主多备，读写分离，是一个很好的解决方案

shooterchan

原帖由 kevensun 于 2008-1-27 12:23 发表
我觉得Data guard不能算备份，因为主库变动，备库也跟着变，如果数据被删除，备库也无能为力。备库是当主库异常时，比如硬件异常，可以很快恢复应用。如果丢失数据，也是非常少的，总比全部丢失来的好。再说，有些业务讲求不间断，对数据丢失是可以容忍的，或者丢失一点数据可以手工恢复。

因此做了容灾的数据库也需要备份咯。如果出现灾难性的故障，容灾恢复比利用备份恢复来的快。这就是优势。

space6212

原帖由 小比例尺 于 2008-1-27 07:18 发表
data guard在什么场合下使用啊？物理standby只能以只读打开。但数据库是只读的应用真是太少了。至少我没见过。如果业务是频繁数据变动(插入，更新，删除)那物理stand by 根本就没用。
另外，如果只传送归档的话，假设在线日志是100M，那就有可能有99M的数据变动记录(redo)没有反映到从库中。那还谈什么容灾，连数据库的一致性都没得到保护。如果传送的是在线日志，有是问题多多，性能是一回事。如果主库因为网络问题不能连通从库，那主库也不能使用了。


逻辑standby又有没什么用呢？
配置standby是为了容灾，这里的灾通常是指 primary和logical standby一损俱的灾,比如磁盘损坏，掉电。电都没了，logical standby有什么用？！

所以standby根本就没用！

1、物理standby只能以只读打开。但数据库是只读的应用真是太少了
可以用于报表系统，分担主库压力

2、如果业务是频繁数据变动(插入，更新，删除)那物理stand by 根本就没用
不要把dg理解成rac，dg的主要目的是容灾。

3、如果只传送归档的话，假设在线日志是100M，那就有可能有99M的数据变动记录(redo)没有反映到从库中。那还谈什么容灾，连数据库的一致性都没得到保护
如果数据所在主机出现意外，那么异地的dg可以让你减少数据损失

4、如果传送的是在线日志，有是问题多多，性能是一回事。如果主库因为网络问题不能连通从库，那主库也不能使用了。
还有一种折中的保护模式：最大可用性

[ 本帖最后由 space6212 于 2008-1-28 10:13 编辑 ]

小比例尺

欢迎各位发表高见

我看得文档是<Oracle9i Data Guard Concepts and Administration>
以前看的，可能不是很仔细。

physical standby是可以以 读写 方式打开的，前提是 需要角色切换。即：原来的stand by 变成 primary
损坏的primary在修复好之后，配置成stand by

shooterchan

原帖由 space6212 于 2008-1-28 10:08 发表


1、物理standby只能以只读打开。但数据库是只读的应用真是太少了
可以用于报表系统，分担主库压力

2、如果业务是频繁数据变动(插入，更新，删除)那物理stand by 根本就没用
不要把dg理解成rac，dg的主要目的是容灾。

3、如果只传送归档的话，假设在线日志是100M，那就有可能有99M的数据变动记录(redo)没有反映到从库中。那还谈什么容灾，连数据库的一致性都没得到保护
如果数据所在主机出现意外，那么异地的dg可以让你减少数据损失

4、如果传送的是在线日志，有是问题多多，性能是一回事。如果主库因为网络问题不能连通从库，那主库也不能使用了。
还有一种折中的保护模式：最大可用性

4、使用LGWR、standby redo就能传送在线日志，也可以使用最大性能模式啊？？

junsansi

原帖由 小比例尺 于 2008-1-28 15:41 发表
欢迎各位发表高见

我看得文档是
以前看的，可能不是很仔细。

physical standby是可以以 读写 方式打开的，前提是 需要角色切换。即：原来的stand by 变成 primary
损坏的primary在修复好之后，配置成stand by

standby打开flashback，可以短暂以read write模式打开，不需要角色切换，当然此时standby就失去了容灾的功能~~

junsansi

原帖由 小比例尺 于 2008-1-27 07:18 发表
data guard在什么场合下使用啊？物理standby只能以只读打开。但数据库是只读的应用真是太少了。至少我没见过。如果业务是频繁数据变动(插入，更新，删除)那物理stand by 根本就没用。
另外，如果只传送归档的话，假设在线日志是100M，那就有可能有99M的数据变动记录(redo)没有反映到从库中。那还谈什么容灾，连数据库的一致性都没得到保护。如果传送的是在线日志，有是问题多多，性能是一回事。如果主库因为网络问题不能连通从库，那主库也不能使用了。


逻辑standby又有没什么用呢？
配置standby是为了容灾，这里的灾通常是指 primary和logical standby一损俱的灾,比如磁盘损坏，掉电。电都没了，logical standby有什么用？！

所以standby根本就没用！

不少未实际接触过dg的朋友可能会下意识以为dg是一个备份恢复的工具。我要说的是，这种形容不完全错，dg拥有备份的功能，某些情况下它甚至可以与primary数据库完全一模一样，但是它存在的目的并不仅仅是为了恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复(注意这个字眼，灾难恢复)。dg提供全面的服务包括：创建，维护，管理以及监控standby数据库，确保数据安全，管理员可以通过将一些操作转移到standby数据库执行的方式改善数据库性能。后面这一长串大家可以把它们理解成形容词，千万不要被其花哨的修饰所迷惑，要抓住重点，要拥有透明现象看本质的能力，如果没有那就要努力学习去拥有，下面我来举一个例子，比如我们夸人会说它聪明勇敢善良等等，这些就属于形容词，不重要，重点在于我们究竟想形容这个人是好人还是坏人。然后再回来看看oracle对dg功能上的形容，数据保护和灾难恢复应该都可以归结为高可用性，那么我们可以清晰的定位dg的用途了，就是构建高可用的企业数据库应用环境~~~~~

allway

是一种不断进行恢复操作的热备份操作；

如果物理位置不在一起，就是容灾；

最少要丢失联机日志的数据

小比例尺

9i的dg
maximum protection mode 不能支持 failedover
不知道10g的如何

我觉得switchover或者failedover才是使用dg的意义所在。

小比例尺

我有专门的报表数据库，但不是用dg实现的，是高级复制。因为我并不需要产品库的所有数据，而是它的一个子集，并且报表数据库也有数据变化的。

我发现很多的，在谈及dg时，往往提到类似查询分摊提高性能之类的说法，真的是那样么？
我觉得switchover或者failedover才是使用dg的意义所在。特别是switchover这种有计划有步骤地切换，可以实现无数据丢失。
例如rimary停机修正，硬件更换，打补丁等等。