1、RAC(or OPS in oracle 8i)
RAC是盛传很久了的一个神话了，因为RAC对硬件的要求高，特别在9i版本以前，几乎都是跑在小型机上，因而，很多人就把RAC想成了稳定快速的代名词。实际上如此吗？其实我们应当先看看RAC的设计目的是什么：为了解决高可用性与高并发性，因此而不是整体性能的提升。在一定程度上来说，RAC比单个节点是要慢的，因为它比单节点多了节点之间的通信与管理。但是，正因为它的高可用性与大量并发连接的支持，所以，RAC应用才如此广泛，在多个性能比较差的机器上可以平均的分布负载，在一个节点故障的时候，其它的节点可以进行接管。但是RAC带来的却是管理的复杂，性能的降低（这个在OPS的OLTP系统中尤其明显，而在RAC中则好多了）。
2、分区(partition)
有的时候，会有人问我：“我把我的一个大表分区了，应用的速度怎么慢了呢，我认为应当变快啊”，我则会问他的索引是本地索引吗？应用大部分是以分区关键字为查询条件吗？回答往往是：“对了，为了管理的方便，我们用了分区索引，我们只有一小部分查询是有分区条件的，大部分没有”。对了，到这里，就是原因所在了，分区不是fast=true参数，实际上，也根本没有这个参数。我们再看看分区的目的，为了DSS等数据仓库系统大型对象管理的方便性。分区最主要的两个作用就是高可管理性与可扩展性，并没有说性能的提升。因为大表的分区，我们可以方便的管理一个分区而不至于是整张表，但是，如果不是按照分区条件进行的查询，而索引又是本地索引，查询需要分开到多个本地索引树去扫描而不是一个索引树。
3、并行(parallel)
今天随便翻了翻一本Oracle书，居然把这个词翻译为线索，当时查点没有晕背过去。并行也是广泛流传的一个神话。在说并行之前，我们先说一个工作分配的问题，有一个部门领导，下面有12个小兵（先这么说吧），有一天，来了一个小任务，其实他一个人一个小时就做完了，但是他非要分给下面12个人同时做，结果，开会->分工->分别行动->整合，整个过程下来，他们居然发现花了1个半小时，为什么？原因就是盲目的分工。并行查询就是这样，适合在数据仓库环境下，少量的并发连接用户，执行大的查询。如上面的例子，如果一个很大的工作，分配给12个人是好的。所以，在决定使用并行查询前需要考虑的问题是：会不会因为并行度占用资源较多，对其它用户造成影响，是不是一个大的，并行能提高查询速度的语句。除了并行查询，并行DDL则是对管理来说一个比较常用的减少维护时间的手段了。
发表于 @ 2004年10月27日 09:16:00|评论(loading...)|编辑