之前在博文中分享过一个ora错误。
对于此，根据日志分析了相关的ora错误，但是从客户的角度还是希望能够提前做些什么，所以aio的设置就成为刻不容缓的一个任务。
但是对于aio的设置大家还是存在一定的分歧。在此贴出来供大家讨论，在oracle官方文档中也没有详细的说明和建议。
首先aio的设置在/etc/sysctl.conf就有设置，里面会指定一个最大值，即aio-max-nr
对于aio的监控可以从下面的地方进行监控。
cat /proc/sys/fs/aio-max-nr
在系统中会根据系统的使用情况有对应的变化。
关于async-io的监控，下面的一个博客中有比较好的监控方案。可以参考一下
http://www.pythian.com/blog/troubleshooting-ora-27090-async-io-errors/
对于aio的设置有几种不同的争论。
在服务器上存在两个数据库实例，一个session占用在9000左右，另外一个访问量极小，不到100个session的使用情况。
根据aio的设置。有一种计算思路为：
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136
Number of sessions connected PRODB2 : 35
所以根据平均值得出每个session占用的aio值为 : 2558565/9171 = 278.98… 我们假设为 280
PRODB1和PRODB2的最大session设置为： 27040,所以根据计算得出需要设置的aio值为： 27040x280 = 7,571,200
对此还有一种不同的思路，即从操作系统层面，能够和数据库进行直接映射的就是进程了，数据库中的进程和操作系统进程由对应的映射关系，所以我们应该基于进程，即process来进行计算。
在专有服务器模式下，计算思路即为：
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136
Number of sessions connected PRODB2 : 35
所以根据平均值得出每个进程process占用的aio值为 : 2558565/9171 = 278.98… 我们假设为 280
PRODB1和PRODB2的最大进程设置设置为： 18000+2000,所以根据计算得出需要设置的aio值为： 20000x280 = 5,600，000
看似不经意的调整，但是结果却差别很大。
还有一种思路就是通过active session对应的进程情况进行计算，比如9000个session,但是active session只有1500左右，我们在这个时候假设并发为1500
根据并发情况得到一个aio的平均值，然后进行计算。
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136 这个时候并发session为1500左右
Number of sessions connected PRODB2 : 35 这个时候假设并发为35
所以根据平均值得出每个进程process占用的aio值为 : 2558565/1535 = 1666.81759… 我们假设为1666,相比之前的计算就差别很大了。
然后根据这个值来计算对应的aio最大值设置。假设这个时候最大的进程数为18000+2000=20000,所以根据计算得到的aio值就为：33,320,000
这个计算的值相比之前就差别太大了。
不过从不同的计算计算方式来看，个人还是倾向于第2种计算。当然这个问题也是持开放的态度，大家也可以提供意见，大家一起讨论。
当然不能给客户这三种思路让他们选，我们也是把前两种的思路结合起来，给了一个基本平均的值，这样下来aio的设置不会奇高，增长幅度也差不多在30%左右，但是还是有一定幅度的提升， 对于其它的参数影响也不会有很大的梯度。
之后就是建议客户计划进行数据库实例的重启使得这些参数变更生效了。
对于此，根据日志分析了相关的ora错误，但是从客户的角度还是希望能够提前做些什么，所以aio的设置就成为刻不容缓的一个任务。
但是对于aio的设置大家还是存在一定的分歧。在此贴出来供大家讨论，在oracle官方文档中也没有详细的说明和建议。
首先aio的设置在/etc/sysctl.conf就有设置，里面会指定一个最大值，即aio-max-nr
对于aio的监控可以从下面的地方进行监控。
cat /proc/sys/fs/aio-max-nr
在系统中会根据系统的使用情况有对应的变化。
关于async-io的监控，下面的一个博客中有比较好的监控方案。可以参考一下
http://www.pythian.com/blog/troubleshooting-ora-27090-async-io-errors/
对于aio的设置有几种不同的争论。
在服务器上存在两个数据库实例，一个session占用在9000左右，另外一个访问量极小，不到100个session的使用情况。
根据aio的设置。有一种计算思路为：
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136
Number of sessions connected PRODB2 : 35
所以根据平均值得出每个session占用的aio值为 : 2558565/9171 = 278.98… 我们假设为 280
PRODB1和PRODB2的最大session设置为： 27040,所以根据计算得出需要设置的aio值为： 27040x280 = 7,571,200
对此还有一种不同的思路，即从操作系统层面，能够和数据库进行直接映射的就是进程了，数据库中的进程和操作系统进程由对应的映射关系，所以我们应该基于进程，即process来进行计算。
在专有服务器模式下，计算思路即为：
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136
Number of sessions connected PRODB2 : 35
所以根据平均值得出每个进程process占用的aio值为 : 2558565/9171 = 278.98… 我们假设为 280
PRODB1和PRODB2的最大进程设置设置为： 18000+2000,所以根据计算得出需要设置的aio值为： 20000x280 = 5,600，000
看似不经意的调整，但是结果却差别很大。
还有一种思路就是通过active session对应的进程情况进行计算，比如9000个session,但是active session只有1500左右，我们在这个时候假设并发为1500
根据并发情况得到一个aio的平均值，然后进行计算。
Machine AIO consumption : 2,558,565
Machine AIO max limit : 3,145,728
Number of sessions connected PRODB1 : 9136 这个时候并发session为1500左右
Number of sessions connected PRODB2 : 35 这个时候假设并发为35
所以根据平均值得出每个进程process占用的aio值为 : 2558565/1535 = 1666.81759… 我们假设为1666,相比之前的计算就差别很大了。
然后根据这个值来计算对应的aio最大值设置。假设这个时候最大的进程数为18000+2000=20000,所以根据计算得到的aio值就为：33,320,000
这个计算的值相比之前就差别太大了。
不过从不同的计算计算方式来看，个人还是倾向于第2种计算。当然这个问题也是持开放的态度，大家也可以提供意见，大家一起讨论。
当然不能给客户这三种思路让他们选，我们也是把前两种的思路结合起来，给了一个基本平均的值，这样下来aio的设置不会奇高，增长幅度也差不多在30%左右，但是还是有一定幅度的提升， 对于其它的参数影响也不会有很大的梯度。
之后就是建议客户计划进行数据库实例的重启使得这些参数变更生效了。
