数据库高并发性能问题诊断思路总结

一、高并发的dml引发问题：
1，ITL等待 （重建索引、增加init trans、加大pct free（索引只是重建后当时有效））
2，右增长索引的enq-index contention（重建索引减少碎片进而减少找空块的时间、控制并发、删除无用索引、或者改造为hash分区索引）
   通过以下方法激活索引分裂增强性优化，来缓解enq: TX – index contention争用
   To enable this fix set event 43822 to level 1
   命令：alter system set events '43822 trace name context forever,level 1';
3，高并发insert导致的enq-HW （控制并发、删除无用索引、或者改造为hash分区表/索引）

二、高并发查询引发问题：
1，cache buffer chains latch (优化sql减少buffer gets; 如果竞争是在branch block可以改造为hash分区索引;如索引碎片多，考虑重建。特别是consistent gets过多的情况)
2，cursor pin S （拆分高并发的sql + hints）
3，library cache (shared pool latch) （避免hard parse、增加shared pool size、通过增加shared pool size增加子池的个数，进而增加shared pool latch的个数）

三、跟redo相关的问题
1，log file sync /log file parallel write  （使用filesystem的卷的数据库启用ODM。 ics 启用后 log file parallel write 由0.89变成0.32ms）
2，_use_adaptive_log_file_sync=false （将log file sync的机制由Polling-10ms（11.2.0.3之后开始为true）改造为原来的特性：Post/wait-1ms）
   （ics库调整了_use_adaptive_log_file_sync 参数后，ICS生产库的LOG FILE SYNC的等待时间明显降低，从10MS降低到不到1MS。）
3，control file sequential read (netlife重建controlfile；增加online redo log file size为2G（目的：减少切换频率和产生的redo log个数，进而使得controlfile中一个block能够容纳更多log entry；并且减少gap发生的概率）；级联DG：生产-> 同城 -> 上海 )
4，16MB =< Log_buffer <= min(128MB, max(AUTO_SIZE,16M)) 
   300MB =< redoLog_file_size  <= 1024MB
   （AUTO_SIZE公式是 (number of strand) * (size of per stands) = (cpu_count/16) * (cpu_count*128)K , 化简之后等于（cpu_count的平方除以128）兆，即 power(cpu_count,2)/128 M）
   
四、连接相关问题：
1，数据库processes与中间件连接池相关问题 （initial - max）
2，listener queuesize （调大 64、128 。。。）（同时确保主机参数的tcp_conn_req_max_q >= listener queuesize，减少或消除Tcp listener drop）

五、分区表清理问题：
        审视当前的清理方案是否有风险，比如清理时间过长。
        global 索引是否可以修改为local 索引
        global 索引是否可以drop
        global索引是否需要定期重建
        清理时长，如果时间太长，是否需要增加并行