问题概述
某客户生产库，ADG备库出现应用日志异常缓慢的情况，需分析并处理问题。
查看备库的归档接收和应用情况发现：备库的归档日志已接收到722文件，但是当前仅应用到701这个文件 ：
查看当前应用延迟，发现dg同步已延迟1天4小时48分，而传输日志正常。
查看dg速度发现，应用速度仅在1M左右每秒，应用进程速率异常缓慢。
查看当前dg状态，并未发现gap。
故障分析
查看当前数据库等待：发现数据库出现free buffer waits等待。
free buffer waits等待指的是当需要在buffer cache中寻找可用块但是找不到时，就会发生这个等待。
故障分析：
1）由于该DG环境搭建完成到应用延迟异常中途并无业务连接，故排除存在大批量DML操作和低效SQL的情况。
2）查看备库db_writer_processes参数值为4，配置正常。
3）检查备库standby log 状态，无异常
4）查看主机 IO 正常：
由于dg备库使用的是文件系统，数据库使用disk_asynch_io和filesystemio_options两个参数来控制异步IO。
disk_asynch_io是相当于主开关，不管是文件系统还是raw，控制着异步IO的开启与关闭。
filesystemio_options是子开关，控制着文件系统上的异步IO。
所以如果数据库只用了文件系统，那么异步IO只是受filesystemio_options控制。
此时查看数据库参数配置，disk_asynch_io值为true合理，而建议filesystemio_options调整为setall （文件系统同时启用异步和直接I/O） 。
5）查看主备库的内存参数信息，发现主备库的主机内存均为64G，数据库均为SGA自动内存管理。
主库的SGA_TARGET设置为20G，buffer cache当前值为14G，而备库的SGA值为6.4G，buffer cache当前值仅为5G。
故调整备库SGA到20G，调整filesystemio_options为setall。
调整参数后重启数据库并应用dg，观察速度并没有提升，延迟仍然在增加。
解决方案
再次观察数据库等待事件，发现此时仍出现“free buffer waits”等待。
查看11file#的blocksize为16384。该数据文件使用的是16K的块大小，故猜想发生free buffer waits是不是因为16k的buffer cache值过小导致的。查看db_16k_cache_size的参数值为128M：
查看主库db_16k_cache_size为512M，故调整备库db_16k_cache_size参数值和主库保持一致，重新应用dg后，观察数据库应用情况，发现此时apply速度从之前的1M/s上升到8M/s，最大应用速度达到38M/s。
ALTER SYSTEM SET db_16k_cache_size='512M' SCOPE=BOTH;
从Alert日志来看，调整参数后，一个归档的应用时间大大缩短，并且在8月16日14:05追平延迟。故障解决。
综上，本次dg备库应用延迟异常缓慢主要是因为数据文件使用的块大小为16K，而针对16k的块缓存池设置过小，引起数据库出现“free buffer waits”等待，导致应用日志过缓，dg延迟严重。
