oracle性能, 复杂就是好的吗?

原文:

DML性能低下，其中最严重的原因之一是无用索引的存在。所有SQL的插入，更新和删除操作在它们需要在每一行数据被改变时修改大量索引的时候会变得更慢。

许多Oracle 管理人员只要看见在一个SQL 查询的WHERE语句出现了一列的话就会为它分配索引。虽然这个方法能够让SQL运行得更快速，但是基于功能的Oracle 索引使得数据库管理人员有可能在数据表的行上过度分配索引。过度分配索引会严重影响关键Oracle 数据表的性能。

在Oracle9i出现以前，没有办法确定SQL查询没有使用的索引。让我们看看Oracle9i提供了什么样的方法让你找到这些索引并删除它们。

过程是相当简单的。Oracle9i有一个工具能够让你使用ALTER INDEX命令监视索引的使用。然后你可以查找这些没有使用的索引并从数据库里删除它们。

个人以为:

oacle的性能, 基本分为查询性能, 和事务性能, 这是两种不同的算法机制,...

实际上, oracle的性能是个性化的, 换句话说, 对相关业务的类型有关的, 是比较有讲究的, 这个10年前, 在看oracle7的随机EN文资料就有描述, 其性能是同数据库安装时候的配置有关的,这是大的环境, 其次, 每个表的数据增长(insert)和变化(UPDATE和delete)直接影响了其性能, 这个效果是随着时间和数据量的增长有很大关系的, 同时, 也同session的数目有很大关系, 所以, 数据库的性能优化是灵活的, 需要有一个工具, 跟踪数据库的运行响应时间和其状态, p=f(状态, 数据指标), 曾经使用过一个很特别的数据库健康/性能监控工具, 非常详细描述了数据库的运行状态和评估健康指标, 当然, 健康是如何定义的呢? :-) 这个工具本人在广东电信安装配置过很多, 将数据库调整到非常好的运行状态, 需要对应用类型宏观, 和数据库驻留/配置的微观环境有比较深刻的认识, 不是考个OCP就能玩的转的东东...需要情景/场景/事件的考验...包括故障发生时, 如何使oracle start...

宏观: 指业务的交易类型

微观: 指数据库的安装配置, 物理配置和逻辑配置, 特别是对oracle数据文件族, 这里有很多技 巧.甚至细到, 表的column, row级别... 一个好的sql语句可以大幅度提高业务响应时间, 而相反, 一个差的sql语句, 甚至可以使数据库block在那里...

实际上, 说来说去, 就是如何使ORACLE响应一个session的资源最少, 响应时间最短, 是一种动态的平衡, 是一种方法论的表现...
另外, 最好是程序, 数据分离. 这是一个很讲究的东西, 曾经在见过一个从来不用update语句的厉害家伙, 思路很独特, 真正是高手. 其次, 数据库的业务存储结构要不断调整, 这个需要个环境, 调整数据库的存储配置, 抽出数据, 使数据同存储结构分离, 这个考验你真正的功夫, 书本是不会写的, 每次调整/rebuild, 都可以避免碎片, 大幅度提高数据库的性能...不是随便写个sql语句的事情...