Oracle性能优化

DBA往往认为SQL调优是必要的、重要的甚至是关键的。现实情况是，SQL调优所消耗的时间和资源，往往会把CPU和运行时间的节省抵消掉。正确的问题是：“我们如何衡量优化?”“由谁负责企业IT的能力规划?”“对于处理新程序/SQL迁移，灾难恢复规划等类似问题，我们有没有现成的最佳实践方案?”注意，这些问题体现的问题是DBA的优先级以及他们的时间成本。

从应用开发到SQL管理，Oracle自带的数据库优化工具提供许多令人印象深刻的功能。但DBA也许已经发现，许多第三方Oracle数据库管理工具比Oracle自带工具还要更加健壮。

在第二天下午的“数据分析与数据架构设计调优”分论坛演讲中，云和恩墨创始人、ITPUB版主盖国强发表主题演讲《Oracle数据库架构演进和性能优化实践》，分享了在云架构、大数据风起云涌的时代，企业在数据架构变革中面对的问题，以及Oracle数据库的未来演进变革。

Oracle数据库有时候出现不能使用索引的现象，出现该现象的原因有很多，该怎么去定位呢?本文我们主要就介绍这一部分内容。

大型关系数据库Oracle已经广泛应用于各行各业，如政府、交通、公安、电信、金融、能源等部门，并已逐渐成为企业信息化建设的重要数据库平台，但随着 Oracle 数据库规模的扩大，数据库用户人数的增加，数据库性能问题越来越突出……

ORACLE提供了安全标记的功能，其模型是建立在BLP安全模型之上，并进行了扩展。BLP模型的元素是安全级别和范围，即可以对主客体进行安全级别和范围的设定，从而达到控制数据流动的目的，即向下读、向上写的规则。即用户可以读低于用户安全级别的数据，写高于用户安全级别的数据

9i也算是很老的Oracle版本了，只是很多系统包括很多大型的核心的系统都在用，因此本文介绍建立在分区键列上的本地索引存在的问题。

有客户遇到SQL性能不稳定，突然变差导致系统性能出现严重问题的情况。对于大型的系统来说，SQL性能不稳定，有时突然变差，这是常常遇到的问题。

曾几何时，网络上流传着给Oracle数据库分配内存的一条法则：把80%的内存分配给Oracle使用，而又将这80%的内存分配80%给SGA，剩下的20%分给PGA。

优化器默认为CBO,OPTIMIZER_MODE默认值为ALL_ROWS。不再使用古老的RBO模式,但RULE、CHOOSE并没有彻底消失,有些时候仍然可以作为我们调试的工具。

经常有人问到oracle中的Where子句的条件书写顺序是否对SQL性能有影响，我的直觉是没有影响，因为如果这个顺序有影响，Oracle应该早就能够做到自动优化，但一直没有关于这方面的确凿证据

我们都知道drop table, truncate table时都会先做一次checkpoint，将被删除对象的脏块写入磁盘。

一条看上去很简单的SQL执行时长比较长，以至于出现ORA-01555错误，由于返回的结果数据行数非常大，取1月之内3天的数据，不太适合于使用索引，同时应用结构上决定了，也不能按天分区。

操作系统优化时应该考虑的因素有：内存的使用;Cpu的使用;IO级别;网络流量。各个因素互相影响，正确的优化次序是内存、IO、CPU。

Oracle9i有两种优化器模式可以选择：Rule-based、Cost-based

1、避免动态分配的缺陷 　　创建本地管理的表空间; 　　合理设置segment的大小; 　　监控将要扩展的segment：

索引的层次越多，效率越低，如果索引中含有许多已删除的行，这个索引也会变得低效，如果索引数据的15%已经被删除，应该考虑重建索引。

DML事务使用row-level locks,查询不会锁定数据。锁有两种模式：exlusive、share。

Transaction以轮循的方式使用rollback segment里的extent，当前所在的extent满时就移动到下一个extent。可能有多个transaction同时向同一个extent写数据，但一个rollback segment block中只能保存一个transaction的数据。

Latch是简单的、低层次的序列化技术，用以保护SGA中的共享数据结构，比如并发用户列表和buffer cache里的blocks信息。一个服务器进程或后台进程在开始操作或寻找一个共享数据结构之前必须获得对应的latch，在完成以后释放latch。不必对latch本身进行优化，如果latch存在竞争，表明SGA的一部分正在经历不正常的资源使用。