一、高并发的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索引是否需要定期重建
清理时长,如果时间太长,是否需要增加并行
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索引是否需要定期重建
清理时长,如果时间太长,是否需要增加并行