oracle 数据库新开连接慢（连上后速度正常）

0.现象

1.原因：新建连接时，需要根据/etc/resolv.conf去解析，当解析失败达到超时时间后才可以连接

注释点对应的nameserver即可

cat /etc/resolv.conf

2.注释后带来的问题

3.延伸拓展

oracle慢，要看通过在慢的时间段内的AWR、ASH报告来观察。

另外在系统慢的时候，查询select * from v$session_wait where wait_class<>'Idle'

看系统当前等待事件，基本上可以定位到慢的原因。

没有具体环境，只能帮你到这了。

resmgr:cpu quantum是Resource Manager特性导致的等待事件，理论上只有版本10g以后才可能出现，同时应当仅在resource manager plan被激活的时间窗口中发生该等待事件。

该等待事件存在的意义是当resource manager控制CPU调度时，需要控制对应进程暂时不使用CPU而进程到内部运行队列中，以保证该进程对应的consumer group(消费组)没有消耗比指定resource manager指令更多的CPU。

此时session就会以”resmgr:cpu quantum”的名义等待在内部运行队列中，wait一段时间以减少对CPU的争用，直到再次获得CPU时该等待事件结束。

需要注意的是虽然国内的绝大多数数据库都不太可能去设置resource plan激活某种资源计划，但是10g开始默认的gather_stats_job自动收集统计信息作业会在每个工作日的晚上22:00-06:00和周六、周日全天打开default_maintance_windows该维护窗口会默认打开一个Oracle预定义的资源计划，在这个窗口中服务进程仍可能进入resmgr:cpu quantum等待事件。

合理的resmgr:cpu quantum是为了实现cpu control的必要代价，但是存在一些BUG可能导致服务进程因为resmgr:cpu quantum而HANG住，并一直等待该事件，这些BUG主要发生在10g的10.2.0.5之前。

---