IO负载冲高数据库访问被拒绝案例
一、案例发生背景
2019年2月24日早上9点同事给我打来电话说上海平台数据库访问不了，PLSQL登录不上被拒绝了，现场IT也没有做什么操作。我挂完电话后立刻登录现场服务器查看了一下数据库系统日志，OS/ error 数据附加错误。用命令行尝试登陆数据库确实登录不上。检查了数据服务和监听服务也都正常启动的。为了能让现场业务赶快跑起来，我采用通用惯例方法将数据库监听和参数进行重置，然后数据库正常跑起。这个方法是在紧急情况下可以做的应急预案和方法。
为了避免这个类似的问题发生，我们应该从根本上去解决与剖析，首选我们我来分析一下这个问题发生的原因。
- 分析告警日志
我这里查的是事发当时前一天晚上的日志，从数据库告警日志发现，前一天晚上归档日志写入特别的缓慢，而且有很大的延迟，这个很有可能是磁盘IO资源不足导致的本机数据库数据写入变慢。到后面我们看到有一个DBGRL 有一个高级线程日志进程报错操作系统进程直接拒绝了写入归档日志。其原因应该还是服务器磁盘IO资源被占用完了。为什么IO资源会被用完，是不是有很多数据在复制拷贝。我们遇到类似问题时要大胆的假设，小心的求证。
为了证明我的猜测，我们首先我们来看一下系统日志是否有报错
系统日志在事发当时8点左右，有一个系统告警日志，网络链路被断开了。是什么原因导致这个网络被断开了，我首选确认了一下，这台服务器是一台数据库备份服务器，从A服务器，B服务器，C服务器，D服务器数据库中备份而来。而这台服务器也是做为1代老平台库使用。在每天晚上下半夜4点左右进行了任务计划远程拷贝。在这里我有检查了各备份源数据库服务器的备份任务计划：
接下来我们来看一下Oracle告警日志定位到下半夜4点左右是否有异常信息告警。
4点钟左右这个时间点这台服务器数据库写入会特别的缓慢，日志归档也是如此。当服务器IO资源都被耗尽时，归档日志写入为0kb.由此可见是各平台数据备份时间点都凑合到一块了，导致这台备份服务器磁盘IO负载过高，磁盘IO资源都用来做远程拷贝数据了。所以当IO消耗达到峰值时本地归档日志写进程为0kb.所以此时PLSQL无法登录，OS error，访问被拒绝。
- 解决方法
- 将各数据服务器上的备份任务计划的时间点岔开时间点备份。比如各服务器的备份时间最少相隔一个小时左右。
- 如果磁盘没有问题忽略告警避免触发写进程
ALTER SYSTEM SET EVENTS '10468 trace name context off';