1.1、数据库及SQL代码优化方案（1）每周检查统计信息是否及时更新。

（2）每周检查各索引是否有效。

（3）每周检查分区是否正确。

（4）每周检查执行计划是否正确。

（5）每天检查RAC和ASM是否正常运行。

（6）每天检查相关日志是否正常备份。

（7）每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。

（8）在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。

（9）分析上述SQL语句，与软件服务商充分沟通后，提出优化建议。

（10）在每月申报高峰期每隔15分钟检查一次数据库连接数，发现异常及时处理。

1.1.1、系统数据库索引、表分区和对象优化方案数据库对象的优化主要包括：表、索引和sequence等对象，通过优化对象参数、调整对象属性（例如分区表、分区索引、反转索引等等）等方法来实现对数据库对象的优化改造。

1.1.1.1表和索引并行参数优化数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响，表和索引的degree值大于1，执行计划就偏向于使用全表和全索引扫描，另外如果并行参数值过大，短时间内也会对主机和数据库的资源造成很大的压力，因此在oltp的数据库下建议将表和索引的degree值设为1。

1.1.1.2热点大表的分区改造对访问量很大、表的记录数很多、存在热块争用的表，可以考虑对表和索引进行适当的分区改造，分散访问压力，提高数据访问的性能。

对以下表的记录数超过1000万并且记录数持续增长的大表，建议进行分区改造（地区+时间）：1.1.1.3分区索引的清理对最近30天数据库分区索引访问情况进行统计，对访问次数为0的分区索引和应用部门进行确认，若确认为多余的索引，建议进行删除清理。

1.1.1.4Sequence序列优化加大sequence 的 cache，并使用noorder选项。

在RAC中经常会遇到SQ 锁等待，这是因为在RAC环境下，sequence也成为全局性的了，不同节点要生成序列号，就会产生对sequence资源的争用。

而目前大多数系统中，sequence 大多数被作为主键发生器来使用，使用的频率十分高，在RAC环境中，需要设置较大的 sequence cache，否则会造成较为严重的争用，从而影响业务。

1.1.2、SQL硬解析优化方案1.1.2.1相关知识点介绍1.1.2.1.1Oracle的硬解析和软解析Oracle对sql的处理过程：当发出一条sql语句交付Oracle，在执行和获取结果前，Oracle对此sql将进行几个步骤的处理过程：1、语法检查(syntax check)检查此sql的拼写是否语法。

2、语义检查(semantic check)诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。

3、对sql语句进行解析(prase)利用内部算法对sql进行解析，生成解析树(parse tree)及执行计划(execution plan)。

4、执行sql，返回结果(execute and return)其中，软、硬解析就发生在第三个过程里。

Oracle利用内部的hash算法来取得该sql的hash值，然后在library cache里查找是否存在该hash值：●假设存在，则将此sql与cache中的进行比较；●假设"相同"，就将利用已有的解析树与执行计划，而省略了优化器的相关工作。

这也就是软解析的过程如果上面的2个假设中任有一个不成立，那么优化器都将进行创建解析树、生成执行计划的动作。

这个过程就叫硬解析。

1.1.2.1.2Oracle硬解析的危害硬解析即整个SQL语句的执行需要完完全全的解析，生成执行计划。

而硬解析，生成执行计划需要耗用CPU资源，以及SGA（shared pool）资源。

在此不得不提的是对库缓存中latch的使用。

latch是锁的细化，可以理解为是一种轻量级的串行化设备。

当进程申请到latch后，则这些latch用于保护共享内存的数在同一时刻不能被两个以上的进程修改。

在硬解析时，需要申请latch的使用，而latch的数量在有限的情况下就会出现争用等待的情况。

大量的latch的使用由此造成需要使用latch的进程排队越频繁，性能则逾低下。

因此创建解析树、生成执行计划对于sql的执行来说是开销昂贵的动作，所以，应当极力避免硬解析，尽量使用软解析。

1.1.2.1.3使用绑定变量避免硬解析绑定变量的本质就是本来需要做Oracle硬解析SQL变成软解析，以减少ORACLE 花费在SQL解析上的时间和资源。

假如有两条SQL:Select salary from user where name=’A’;Select salary from user where name=’B’;如果没有用绑定变量，那么这2条SQL会被硬解析2次，因为他们的谓词部分不一样，oracle认为这是两条不同的SQL语句。

如果我们用了绑定变量，如： Select salary from user where name=:X;这时，之前的2条SQL就变成了一条SQL，Oracle只需要对每一条SQL做一次硬解析，之后类似的SQL 都使用这条SQL产生的执行计划，这样就可以大大降低数据库花费在SQL解析上的资源开销。

这种效果当SQL执行的越多，就越明显。

简单的说，绑定变量就是拿一个变量来代替谓词常量，让Oracle每次对用户发来的SQL做hash 运算时，运算出的结果都是同样的Hash值，于是将所有的用户发来的类似的SQL看作是同一条SQL语句。

1.1.2.1.4应用代码的绑定变量改造方法a、动态绑定变量set serverout on;set timing on;declarel_sql varchar2(2000);l_count number;l_param1 varchar2(100);l_param2 varchar2(100);beginl_param1:='a';l_param2:='b';l_sql:='select count(*) into :x from table1 where col_1=:y and col_2=:z ';Execute Immediate l_sql into l_count using l_param1,l_param2;dbms_output.put_line(l_count);end;/1.1.3、TOP SQL优化方案对核心系统数据库业务高峰期进行AWR报告的多次采样分析，对AWR报告中大量消耗系统资源的低效率SQL语句，建议进行集中的、多批次的优化改造。

1.1.3.1SQL性能优化相关知识点介绍访问表的方式ORACLE 采用两种访问表中记录的方式：a. 全表扫描全表扫描就是顺序地访问表中每条记录. ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描。

b. 通过ROWID访问表你可以采用基于ROWID的访问方式情况,提高访问表的效率, ROWID包含了表中记录的物理位置信息。

ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系. 通常索引提供了快速访问ROWID的方法,因此那些基于索引列的查询就可以得到性能上的提高。

1、全表扫描相关的知识1）什么叫全表扫描（TABLE FULL SCAN）在数据库中，对无索引的表进行查询一般称为全表扫描。

全表扫描是数据库服务器用来搜寻表的每一条记录的过程，直到所有符合给定条件的记录返回为止。

全表扫描的成本 = 表的数据块总数 / 多块读取2）全表扫描的危害大量消耗硬件资源尤其是系统I/O资源，被迫在硬件上进行大量的投入。

数据库的响应时间变慢，特别是在OLTP类型的数据库上，由于其小事务、高并发的特点，对全表扫描是无法容忍的，要尽可能的避免。

3）全表扫描的原因A、缺乏索引就是缺乏相关约束条件字段的索引。

解决方式：选择可选性最高的字段创建索引。

B、索引被抑制由于索引字段的隐式转换、约束条件字段前加函数、查询条件中使用<>操作符、%开头的模糊查询以及查询条件中没有组合索引的前导致列导致索引无法被正常使用。

解决方式：对SQL语句进行改写。

C、索引没有启动表和索引的统计信息没有及时更新，导致基于成本的oracle优化器没有选择合适的按索引访问数据的执行路径。

解决方式：及时收集最新的统计信息或者采用hint强制使用索引。

2、索引相关知识点1）什么是索引索引是一种允许直接访问数据表中某一数据行的树型结构，为了提高查询效率而引入，是一个独立于表的对象，可以存放在与表不同的表空间中。

索引记录中存有索引关键字和指向表中数据的指针（地址）。

对索引进行的I/O操作比对表进行操作要少很多。

2）索引的分类A、索引逻辑分类单列索引：基于一列的操作多列索引：组合索引，最多为32列。

组合索引的列不一定与表中列顺序相同。

惟一索引：列的值各不相同。

非惟一索引：列的值允许相同。

基于函数的惟一索引：利用表中一列或多列基于函数表达式所创建的索引。

B、索引物理分类分区或非分区索引，非分区既可以是B－树，也可以是位图索引。

3）B-TREE索引结构自上而下，是根结点、分枝结点及叶子结点，叶子结点中有指向表中数据行的索引行。

叶子结点被双向链表在一起，以方便按索引关键字升序或降序扫描。

4）索引的选择性（Selectivity）索引的“可选择性”是指在该索引列里存储的不同值的数目和记录总数的比。

比如某个表的记录数是1000条，而该表的索引列的值只有500个不同的值（有500个是相同或是空），这样索引的可选择性为500/1000为0.5 。

这样当然效果就不好，最好的索引可选择性（如主键索引）是1.0。

选择性越高，索引返回的数据就越少。

索引的可选择性是衡量索引的利用率的方法，比如在极端的情况下，一个表记录数是1000，而索引列的值只有5个不同的值，则索引的可选择性很差（只有0.005），这样的情形使用全表扫描要比采用索引还好。

当然了，如果查询所选择的行超过1/3，那么无论可选择性有多么高，全表扫都比索引读来得快。

组合索引包括多个字段，组合索引的选择性是多个索引字段选择性的累计，因此如果sql约束条件中包含了组合索引的所有字段，那么使用组合索引的效率是很高的。