enq:TX -index contentioncursor: pin S wait on Xdirect path read

通过监控发现服务器IO和CPU使用率已经高达90%整个数据库算是夯住了！根据经验判断应该是性能的问题

--该方法是从共享池得到如果SQL已被age out出share pool，则查找不到select * from table(dbms_xplan.display_cursor('&sql_id',null,'typical'));--该方法是通过awr中得到select * from table(dbms_xplan.display_awr('&sql_id'));

1.定位到SQL的内存地址，从内存中刷出执行计划select address,hash_value,executions,parse_calls from  v$sqlarea wheresql_id='4ca86dg34xg62';
--刷出内存exec sys.dbms_shared_pool.purge('C000000A4C502F40,4103674309','C');  
2.收集分区统计信息
BEGIN    -- 为整个表加上统计信息（包括所有分区）    DBMS_STATS.GATHER_TABLE_STATS(        ownname     => 'YOUR_SCHEMA', -- 替换为你的模式名        tabname     => 'YOUR_PARTITIONED_TABLE', -- 替换为你的分区表名        cascade     => TRUE, -- 收集所有分区的统计信息        estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, -- 自动估算采样百分比        method_opt  => 'FOR ALL COLUMNS SIZE AUTO', -- 为所有列自动决定采样大小        degree      => DBMS_STATS.DEFAULT_DEGREE -- 使用默认并行度    );END;/

分区索引的失效，会引起执行计划的改变
1.TRUNCATE、DROP 操作可以导致该分区表的全局索引失效，而分区索引依然有效，如果操作的分区没有数据，那么不会影响索引的状态。需要注意的是，对分区表的 ADD 操作对分区索引和全局索引没有影响。
2.如果执行 SPLIT 的目标分区含有数据，那么在执行 SPLIT 操作后，全局索引和分区索引都会被被置为 UNUSABLE。如果执行 SPLIT 的目标分区没有数据，那么不会影响索引的状态。
3.对分区表执行 MOVE 操作后，全局索引和分区索引都会被置于无效状态。
4.对于分区表而言，除了 ADD 操作之外，TRUNCATE、DROP、EXCHANGE 和 SPLIT 操作均会导致全局索引失效，但是可以加上 UPDATE GLOBAL INDEXES 子句让全局索引不失效。