收到一个命题，2TB容量的数据，1000并发，7*24的系统，如果就可维护性，可扩展性和系统性能几方面考虑，该如何进行系统设计。

    这是一个很大的题目，牵涉到从硬件到软件，从应用设计到数据库设计的方方面面，足够写一本厚厚的书，其实，我们的梦想不就是有一个维护简单，扩展性良好，性能优秀的系统吗?

    7*24意味着对于高可用性的要求严格，那么Oracle数据库在高可用性方面的选项包括哪些呢?

    1. RAC

    也许很多人仍然对于RAC抱有怀疑，就跟很多人对于RAC抱有迷信一样，持有RAC的性能还不如单节点这样论调的人跟持有性能不好实施RAC就能解决这样论调的人恐怕人数不相伯仲。

    其实RAC在性能因素上对于应用的提升仅仅是一个方面，RAC对于高可用性的贡献才是真正无可替代的，目前我还不知道有任何其它一种技术可以当Oracle数据库的一个实例损坏的时候(比如主机的网卡出现故障或者主机根文件系统被充满导致机器没有响应等等)另外一个实例可以立刻顶上并提供服务。普通的HA做不到，Data Guard做不到，Streams也同样做不到。

    RAC多节点能够提供数据库软件滚动升级，对于Oracle11g之前的数据库来说这个功能大大减少了系统down机时间，当然实际上Data Guard也可以做到这点，不过即使是Data Guard也仍然有一个Switchover的过程，这仍然需要更多一些的down机时间。

    2. Data Guard

    RAC的所有节点持有同样一份数据文件，那么对于RAC来说，致命的故障可能发生在盘阵的损坏或者连接盘阵的光纤交换机损坏，这种情况下有多少个节点也无济于事，因为数据文件出问题了。而Data Guard弥补的是这方面的需求，两个或者多个实例，两份或者多份存储，在一个实例一份存储坏掉的情况下，可以通过Failover或者Switchover命令来进行主备角色的互换。同时延时Apply功能在Oracle还没有大大增强Flashback的前几个版本中也同样有很大的实用价值。

    3. Streams

    个人认为Streams终将取代Advanced Replication，即使不提及Streams使用AQ技术而AR使用数据字典表来做延迟队列这两种技术的孰优孰劣，仅仅从最近几个版本的Oracle数据库对AR没有做任何加强这一点上也可以求得佐证。当然，物化视图的刷新由于其操作的简单性以及技术的成熟性在今后很长一段时间内应该还会继续成为多个数据库实例之间同步数据的有效手段。
 
    4. Partition

    为什么这里要提到分区?因为大多数人认为分区带来的是性能提升，但是实际上我们认为分区带来的最大好处是高可用性的提升，诚然，正确地使用分区以及分区索引会带来性能上的提升，带来扩展性的提升，但是即使这些不是我们考虑的问题，为了一个系统能够有优越的高可用性，仍然强烈建议使用分区技术来规划数据库。举一个最简单的例子，当我们要卸载历史数据的时候，分区的DDL操作比起对于整表数据的DML操作而言带来的高可用性的提升无疑是巨大的。

    那么对于上面那样一个系统，我的建议数据库架构是双节点RAC + Physical Standby + Partition，也许应用只会使用到RAC中的一个节点，但是仍然需要RAC;也许这份健壮的存储永远不会坏，我们仍然需要Data Guard，至少RMAN备份不用占据产品数据库的资源;也许单表数据只有几G，即使索引全扫描也仍然可以接受，我们仍然要分区。

    更加Detail的一些设计和维护准则：

    1. 并发度1000，这并不代表会有1000进程同时操作同一个data block，所以对于表和索引的inittrans设计可以参考V$SEGMENT_STATISTICS视图中的ITL waits值，V$SEGMENT_STATISTICS是Oracle9i之后很有用的但是经常被大家忽略掉的性能视图。

    2. Segment使用LMT且uniform size，避免system automatic size可能产生的空间碎片，这要求我们能够对于Segment的可能大小在设计阶段就又预估，大小相差悬殊的Segment分配到uniform size不同的表空间中去。

    3. 对于高并发的操作在应用层面予以控制，详细的文章可以参见Piner的这篇 - 并发容易出现的问题和并发的控制。

    4. 注意约束和索引之间的互相影响，对于一个业务繁忙，任何维护操作都可能是在业务繁忙期进行的系统，尽量避免约束和索引之间的相互影响。比如创建唯一性约束，我们可以先创建普通索引，再创建唯一性约束using index，这样操作的好处在于删除约束的时候不会影响索引，这里的关键思想是，约束用于控制商业逻辑，索引用于控制系统性能，逻辑和性能是要分开的，商业逻辑可能发生变化，然后性能不能因为商业逻辑的变化而受到影响。这小小的一点考虑却涵盖了可维护性，可扩展性和系统性能三个方面。

    5. 如果分区表Local Index能够满足性能需求，那么首选Local Index，即使Global Index可能带来更少的Consistent Gets。因为Global Index最大的问题是分区操作时候必须rebuild index，通常这在性能和可维护性上都无法接受。

    6. 使用Oracle 10g吧，从Oracle 10g到Oracle 11g，高可用性的提升有目共睹，各种online操作增强，各种阻塞的影响面减少，各种性能诊断工具的易用性，不是说9i不好，而是10g更强(这句话说的太像Oracle员工了，抱歉)。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。