在ORACLE系统搭建的时候，一般来说，对于系统的拓扑很多时候会混淆。老板希望的是要高可用，老板觉得我投资了这么多，你得给我保证百分百可用，得保证这个，保证那个，其实，每个系统在搭建的时候，能做到啥程度，应该是和应用有关系的。

    依据偶的经验，偶一般会首先将应用系统粗暴的分级为三个等级，然后再在这三个等级之上去选择适合每个等级的拓扑结构来搭建，我一般分级为：

    核心系统：承载核心业务，极高的性能要求，极高的7×24在线要求，极端情况下极短的恢复时间，例如电信的BOSS系统，在线交易网站的交易系统；

    关键系统：承载关键业务，较高的性能要求，较高的7×24在线要求，极端情况下较短的恢复时间，例如一些提供个客户查询等的系统；

    其他系统：承载其他业务，较低的性能要求，较低的或者无7×24在线要求，对恢复时间无特别要求，仅仅要求可恢复，例如一些供内部使用的数据仓库系统；

    下面给出对于三个系统级别上的简单的拓扑：

    核心系统：

    从拓扑可以看到，对于核心系统，首先，生产系统搭建为RAC方式，容灾系统配置为和生产系统相同的RAC环境，并进行实时的同步(存储级别或者是其他方式)，同时配置一套硬件环境稍差的应急系统，以保证生产系统和容灾系统同时崩溃时核心系统的最为核心的业务可以持续，再加上一个高度冗余的备份系统，整个系统的高可用可以得到一定程度的保障。如有条件，以上四个系统，应分布在四个不同的机房，即生产系统一个机房，容灾系统一个机房，应急系统一个机房，高度冗余的备份应至少有一个在和上述三个机房不同的机房；当然，这个投资也是非常巨大的。

    关键系统:

    从图上可以看出，关键系统会取消掉容灾系统，因为一般来说，容灾系统的投资是非常巨大的，同时，其备份也不再是高冗余的备份；建议备份，生产系统和应急系统在不同的机房；

    其他系统：

    其他系统的配置就比较简单，生产系统不再配置为RAC，而备份也是低冗余的备份，建议将生产系统和备份分布在不同的机房；

    当然以上只是简单的一个示例，在实际情况中，可能会复杂很多，具体情况具体对待的了。

    从图上就可以看出来，如果一套系统真的被定义为核心系统，那么他的搭建，特别是在高可用上，投入是非常巨大的，当然了，对于一个企业来说，真正能被定义为核心系统的系统，也就那么几套，而又恰恰是这么几套系统消耗了DBA大部分的心血去优化，去维护。当然，从图上可以看出，真正的核心系统，其高可用是可以得到保证的，投资也是巨大的。如果我们自己都不能和老板说清楚，达到什么样的高可用，需要什么样的架构，什么样的投资，老板一定会把所有系统定义为核心系统，并且要求达到4个9或者是5个9甚至更高的可用。如果我们和老板说说清楚，告诉老板，如果真的被定义为核心系统，达到要求的高可用标准，需要的投资是如何如何的，我相信，每个老板都是可以沟通的，老板也一定会考虑投入产出的，然后，降低系统的级别，为公司节省资源。