首先，IP SAN组网尤其是用在数据库环境，不是首选不推荐。
其次假如使用IP SAN前提下，双机热备部署也得根据实际操作系统版本，检查Oracle版本与操作系统兼容性，最好根据Oracle最佳实践部署，实际此场景用在生产环境下较少。
部署和管理维护难度根据实际采用的版本有关。
RAC技术目前生产上应用最为广泛，但是也是跟实际数据库版本有关，11g最为成熟稳定，12c/19c应用相对较少，对比11g，有区别，管理和部署没啥特别大的区别。
DG也是Oracle原生实际生产应用很广的技术，一般部署方式有生产机房和同城异地机房。
生产机房优势有链路传输优势，而且一般用于查询读库，同城异地部署一般容灾需求，应用场景也可以作为查询读库使用。管理和部署相对简单。
@asdf-asdf cloudstone 研究学者：
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的要求，适合自己的才是最好的。
@wangzk0206 scrcu 数据库管理员：
首先通过您使用IP-SAN存储模式，说明你们的系统重要程度不是非常高。鉴于此，个人建议选择第三种模式。
第三种模式存在几方面的优势。（1）数据可以保留双份，防止IP-SAN存储出现坏块或者弥补其不可靠的风险。（2）大部分情况下，单实例数据库相比RAC效率更高（除非你数据库设计非常的优秀，已经将单台服务器的性能压到瓶颈）。
下面谈下为什么不选择第一种和二种。
第一种其实如果是小机的话，双机热备是非常成熟的，也是以前非常优秀的架构模式，只是针对X86以及现有架构来说，已经不是非常的推荐了。
第三种架构，是ORACLE非常推荐的架构，也是数据库的高可用保障，防止单机故障的场景采用，但是 针对 你们选择的IP-SAN存储来说（主要是可能系统对可用性要求没有那么严格），这是不太成熟的，一方面是IP-SAN存储的性能、可靠性还有待加强，市场案例并不成熟。如果在这个基础上在采用复杂的集群架构，可能会带来更多的未知风险和性能不高。
个人建议第三种方案。
@王巧雷 sino-bridge 系统工程师：
这个还是看实际情况和使用场景吧。
1. 如果业务负载不高，对数据安全也没那么苛刻，用个普通双机就行，管理方便。备机还可以再放个应用，和数据库做成互备还节省资源。
2. 如果性能要求比较高，可以做rac，两个节点可以负载压力。但是你的ip-san存储需要考量一下，性能是否跟得上，会不会成为瓶颈。
3. 如果对数据安全特别看重，可以做ODG，这样的话数据会有两份，一边出了故障切换到另一边也比较快，性能上和1差不多，比不上2。
总结，管理上1方便，性能上2好，数据安全和容灾上3好。
@nanjing_2013 北京卓望 系统架构师：
使用操作系统自带或者第三方 HA 软件：
优点：部署方便。维护成本低。
缺点：资源利用率只有50%，备节点闲置。切换过程中，业务不可用。部分配置文件变更后需要手动同步到备机。数据单份存放，存在风险。
使用 Oracle Clusterware 集群软件：
优点：高可用。节点宕机不影响业务连续性。高并发，所有节点都可以对外提供业务。可以在2个以上节点部署。
缺点：实施及维护成本高。SQL语句写法可能影响集群性能。存储存在单点故障。
Oracle DATAGUARD：
优点：支持一主多备，支持级联。架构灵活，源端和目标端可以组合选择单机、HA、RAC等架构。支持备库只读开启，用于报表查询或者批处理。可以自动修复物理坏块。备库可选延迟应用日志，或开启闪回，备库误删数据库可快速恢复。备库支持临时以读写模式开启用于压力测试或功能验证。支持多种保护模式，最大性能模式下，对主库影响较小。l可选配置ObServer，业务出现问题时自动FailOver拉起备库。
缺点：只能做库级别同步，无法做到对象级同步。通过全量归档日志同步，网络传送压力较大，可选开启日志压缩。主备库之间没有浮动IP，切换是否需要修改应用IP或者DNS配置。
Oracle GoldenGate：
优点：支持跨平台、跨版本或者跨数据库产品进行同步。架构灵活，支持一对一、一对多、多对一、多对多模式，支持级联。架构灵活，源端和目标端可以组合选择单机、HA、RAC等架构。可定制需要同步的方案、表、列等。同步过程中，支持对数据加工处理l 生成自带的Trail File格式文件，支持压缩，体积小。支持将数据输出到平面文件，供数据库仓库使用。
缺点：所有数据库都是读写模式，可能导致数据冲突。实施和维护成本高。灾备切换过程中，需要先配置备库的触发器和外键。
@liaobin429 北京农商银行 系统工程师：
IP-SAN，生产确实不建议rac吧，毕竟心跳数据通信要求还是比较高的。
1跟3方案，各有优缺点吧。容灾考虑3，实时要求比较高的系统，考虑1吧。毕竟1切起来还是挺快的，也不用改什么配置。3的要求可能稍微高点。
@午夜幽魂 系统运维工程师：
使用哪种方式，也要考虑成本和自身的维护能力。自身维护能力 一般的情况下，双机热备比较容易。RAC的方式要考虑IP SAN存储的稳定性，以及授权和维护能力。对业务连续性要求不是特别高的场景，ODG也可以选择。
@韩成亮 KE 数据库管理员：
首先请详细列出物理机的配置，共享存储的配置。
其次是成本，购买License的预算，RAC 还是DG或者ADG费用是不一样的。
采取什么样的方案，这个是一个性价比的问题，这里面还会涉及到RPO/RTO。
对于模棱两可的背景，就不要谈什么部署难度、日常管理，运维、稳定性、容灾程度。
最后综合考虑，RAC>DG> 双机热备软件。
@annoymous：
具体问题具体分析了，不同的模式用于不同场景，不能一概而论。
1、双机热备：可以应用和数据库分开部署，成互备模式，节约资源；
2、RAC：可以提供高性能，两台机器同时提供服务，提高性能；
3、ADG：可以提供第二份数据，提供readonly。
而且不同的模式容灾方式不一样，具体考虑吧。
@张文正 dcits 系统工程师：
这个情况我建议根据数据库的重要来程度区分吧；第一种模式，主备模式，部署方便简单，快捷，维护也很方便，可以满足日常数据库应用需求，可以和sap结合，允许短暂业务切换需求，容灾也比较方便，成本较低；第二三种应用在业务连续性较高场景，部署维护起来相对复杂些，对技术要求较高，容灾成本较高。可以根据以上情况选择相应的部署方式。
@飞奔的T 德卡科技 软件开发工程师：
如果访问业务量很大，交易量小，可以采用主备读写分离部署方式。备端可以实现容灾的同时，还可以提供读操作，减轻生产库的压力。