两台主机部署oracle采用何种模式为好？

两台相同的物理主机，IP-SAN模式的共享存储。
如果由你来搭建数据库，采用oracle使用何种模式部署；
1、双机热备：通过双机热备软件进行部署，主机-备机模式。
（购买第三方软件，如国产DSG等，有厂家专人维护，如果是重要核心系统，最好配置个厂家专人驻场服务）
2、RAC：通过oracle RAC模式进行部署。
（部署难度不大，日常管理做好相关备份和应急恢复演练，需要DBA进行专人维护，生产核心系统需要RAC来避免单点故障，但还不是真正意思上的灾备环境（存储没有冗余）需要配合ADG或OGG）
3、ODG：采用oracle dataguard进行部署。
（ADG是真正意思上的容灾方案，部署相对容易，日常管理较少，比较稳定，检查好日志的传输与应用，磁盘空间的使用情况即可。）

个人观点：最终还是要看各公司的要求，以及领导的的大方向（资金方面）现在很多国产化软件都非常不错，所以选择国产数据同步软件的公司越来越多。RAC方面，如果有3台主机的话，建议RAC+ADG环境，这也是大家经常使用的方案。当然只给2台的话，只购买了ORACLE的话，就直接ADG好了。

这个还是看实际情况和使用场景吧
1，如果业务负载不高，对数据安全也没那么苛刻，用个普通双机就行，管理方便。备机还可以再放个应用，和数据库做成互备还节省资源。
2. 如果性能要求比较高，可以做rac，两个节点可以负载压力。但是你的ip-san存储需要考量一下，性能是否跟得上，会不会成为瓶颈
3. 如果对数据安全特别看重，可以做ODG，这样的话数据会有两份，一边出了故障切换到另一边也比较快，性能上和1差不多，比不上2.

总结，管理上1方便，性能上2好，数据安全和容灾上3好。

如果访问业务量很大，交易量小，可以采用主备读写分离部署方式。备端可以实现容灾的同时，还可以提供读操作，减轻生产库的压力。

IP-SAN模式的共享存储 ，用于  oracle rac测试可以  上产线是不建议的
何种模式需要看你的产线需求， 

测试环境的话，建议都试一次

两台物理机+共享存储，在搭建ORACLE数据库服务器时，数据库一般采用SAN网络访问存储，IP-SAN网络很少在生产环境看到（至少我没遇到过）。基于ORACLE高可用架构常用模式有：双击热备模式、RAC集群、ODG（11GR2版本后支持ADG）、OGG等。

1、双击热备模式，以前在RAC模式还未成熟时常用的模式， 采用第三方HA软件 ，技术比较成熟、架构简单，稳定性高。其缺点为备机为空闲状态，造成资源浪费；切换时间比较长，通常在分钟级别。

2、RAC模式，现常用的架构模式，目前RAC技术成熟、稳定，安装也越来越简单，RAC充分利用了两台机器的计算能力，做到了计算节点的双活，切换比较快。缺点是对运维人员的技术要求较高，对某些应用单事务处理时间肯能会变长。

3、DG模式（支持物理备库和逻辑备库），目前灾备常用的架构，支持一主多备，也是比较成熟的技术，配置简单，运行稳定，备用节点通过事务日志同步数据，ADG备用节点支持读操作，可以做到读写分离，承担主库只读应用的计算压力。DG可以做到计算节点和存储节点的双冗余，缺点是磁盘要求是数据的两倍。

4、采用OGG等数据复制软件同步数据，配置灵活，可以一对多，多对一，目标库支持读写，不受复制的影响，复制过程可以选择性复制，过滤数据，对数据进行加工等。缺点是管理配置比较麻烦，维护成本高。

当然，架构没有完美的，各有优缺点，要基于自己对RTO、RPO的要求，适合自己的才是最好的。

首先，IP SAN组网尤其是用在数据库环境，不是首选不推荐。
其次假如使用IP SAN前提下，双机热备部署也得根据实际操作系统版本，检查oracle版本
与操作系统兼容性，最好根据Oracle最贱实践部署，实际此场景用在生产环境下较少。
部署和管理维护难度根据实际采用的版本有关
RAC技术目前生产上应用最为广泛，但是也是跟实际数据库版本有关，11g最为成熟稳定，12c/19c应用相对较少，对比11g，有区别，管理和部署没啥特别大的区别
DG也是ORACLE原生实际生产应用很广的技术，一般部署方式有生产机房和同城异地机房
生产机房优势有链路传输优势，而且一般用于查询读库，同城异地部署一般容灾需求，应用场景也可以作为查询读库使用。管理和部署相对简单。

首先通过您使用IP-SAN存储模式，说明你们的系统重要程度不是非常高。鉴于此，个人建议选择第三种模式。
第三种模式存在几方面的优势。（1）数据可以保留双份，防止IP-SAN存储出现坏块或者弥补其不可靠的风险。（2）大部分情况下，单实例数据库相比RAC效率更高（除非你数据库设计非常的优秀，已经将单台服务器的性能压到瓶颈）。

下面谈下为什么不选择第一种和二种。
第一种其实如果是小机的话，双机热备是非常成熟的，也是以前非常优秀的架构模式，只是针对X86以及现有架构来说，已经不是非常的推荐了。
第三种架构，是ORACLE非常推荐的架构，也是数据库的高可用保障，防止单机故障的场景采用，但是 针对 你们选择的IP-SAN存储来说（主要是可能系统对可用性要求没有那么严格），这是不太成熟的，一方面是IP-SAN存储的性能、可靠性还有待加强，市场案例并不成熟。如果在这个基础上在采用复杂的集群架构，可能会带来更多的未知风险和性能不高。

个人建议第三种方案。

使用操作系统自带或者第三方 HA 软件。
| 优点 | l 部署方便。 l 维护成本低。
| 缺点 | l 资源利用率只有50%，备节点闲置。 l 切换过程中，业务不可用。 l 部分配置文件变更后需要手动同步到备机。 l 数据单份存放，存在风险。

使用 Oracle Clusterware 集群软件。
| 优点 | l 高可用。节点宕机不影响业务连续性。 l 高并发，所有节点都可以对外提供业务。 l 可以在2个以上节点部署。 |
| 缺点 | l 实施及维护成本高。 l SQL语句写法可能影响集群性能。 l 存储存在单点故障 |

ORACLE DATAGUARD

| 优点 | l 支持一主多备，支持级联。 l 架构灵活，源端和目标端可以组合选择单机、HA、RAC等架构。 l 支持备库只读开启，用于报表查询或者批处理。 l 可以自动修复物理坏块(11.2.0+) l 备库可选延迟应用日志，或开启闪回，备库误删数据库可快速恢复。 l 备库支持临时以读写模式开启用于压力测试或功能验证。 l 支持多种保护模式，最大性能模式下，对主库影响较小。 l 可选配置ObServer，业务出现问题时自动FailOver拉起备库。 |
| 缺点 | l 只能做库级别同步，无法做到对象级同步。 l 通过全量归档日志同步，网络传送压力较大，可选开启日志压缩。 l 主备库之间没有浮动IP，切换是否需要修改应用IP或者DNS配置。 |

Oracle GoldenGate

| 优点 | l 支持跨平台、跨版本或者跨数据库产品进行同步。 l 架构灵活，支持一对一、一对多、多对一、多对多模式，支持级联。 l 架构灵活，源端和目标端可以组合选择单机、HA、RAC等架构。 l 可定制需要同步的方案、表、列等。 l 同步过程中，支持对数据加工处理。 l 生成自带的Trail File格式文件，支持压缩，体积小。 l 支持将数据输出到平面文件，供数据库仓库使用。 |
| 缺点 | l 所有数据库都是读写模式，可能导致数据冲突。 l 实施和维护成本高。 l 灾备切换过程中，需要先配置备库的触发器和外键。 |

ip-san，生产确实不建议rac吧，毕竟心跳数据通信要求还是比较高的。
1跟3方案，各有优缺点吧。容灾考虑3，实时要求比较高的系统，考虑1吧。毕竟1切起来还是挺快的，也不用改什么配置。3的要求可能稍微高点。