Oracle数据库高并发相关性能问题经验总结

一、高并发的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区分不同sql）

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。 启用后 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）

   （库调整了_use_adaptive_log_file_sync 参数后，生产库的LOG FILE SYNC的等待时间明显降低，从10MS降低到不到1MS。）

3，control file sequential read (重建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）

文档 ID 214122.1

However,the parameter will be resized to the max allowable value by the operating system TCP/IP parameters.

Sun Solaris:    tcp_conn_req_max_q

HP-UX:          tcp_conn_req_max  

HP Tru64 / AIX  somaxconn   

Linux

strace -fo /tmp/queue.log lsnrctl start listener

vi /tmp/queue.log and search on listen

Oracle Version   Default QUEUESIZE Value

                 

9.2              10317 listen(8, 128) 

10.1             15520 listen(8, 128) 

10.2             30842 listen(8, 128) 

11.1             31140 listen(8, 128) 

11.2             2099  listen(8, 128) 

Default QUEUESIZE values show PID, FD and QUEUESIZE

    10317 listen(8, 128)

That is PID 10317

FD (File Descriptor) 8

QUEUESIZE 128

128 is the default value taken from SOMAXCONN value. See /usr/include/linux/socket.h

This is the same for other platforms tested HP and AIX. That is SOMAXCONN value is used for default value of QUEUESIZE for the TNS listener.

HP default QUEUESIZE is therefore 4096

AIX default QUEUESIZE is therefore 1024

Solaris testing shows the following.

Solaris 

Oracle Version   Default QUEUESIZE Value

  

9.2              20423: listen(10, 5, 1)

10.1             26948: listen(10, 32, 1) 

10.2             4621: listen(10, 32, 1) 

11.1             12585: listen(10, 32, 1

11.2             552: listen(10, 32, SOV_DEFAULT) 

From 10.1 onwards Solaris Oracle Net code is set to use value of 32. 

This is fixed from release 11.2.0.4 and 12c onwards, that is Solaris QUEUESIZE will default use SOMAXCONN.

See Bug:13113888 Default Queuesize From Solaris not using OS Default

五、分区表维护问题：

2.审视当前的清理方案是否有风险，比如清理时间过长。

3.global 索引是否可以修改为local 索引

4.global 索引是否可以drop

5.global索引是否需要定期重建

6.清理时长，如果时间太长，是否需要增加并行