1、Server Process

oracle的服务进程也称为shadow进程，主要是用于响应客户端请求执行相关的SQL语句，该进程运行的效率会对oracle的客户端的操作人员的体验产生很大的影响，oracle有大量的等待时间和这个进程的活动相关。那么他会对系统产生哪些影响呢？
一般来说一个执行良好的运行状态oracle server process，会消耗一定程度的cpu资源，而这些CPU资源往往是USER态下的cpu，如果用sar –u去看，也就是标准的user%消耗 。
同理，为了响应客户端的请求而运行的sql语句，会在OS层产生大量的物理读和逻辑读（如果他所需的数据大量的存在于cache中，那么他会产生大量的逻辑读，并且造成cpu的user%消耗，如果他需要从存储上读取数据相应会产生物理读，造成io的压力）。如果该进程处于排他性的资源竞争或者因为SQL效率，系统资源，网络存储瓶颈，会导致应用效率的降低。

2、HP KI TOOLS

Ki tools 是一个功能强大的性能分析及软件故障分析工具。通过ki工具我们可以自定义跟踪时间点和跟踪内容，既可以跟踪单个进程，也可以对整个系统进行跟踪分析，通过KI，我们抓取出trace 报告，并最终生成可读性较强的报告。报告格式包括文本及超文本格式。 一般来说通过该工具我们可以发现如下方面的问题并进行分析：
1、详细的cpu、mem、io、network性能；
2、进程及线程的详细活动；
3、进程间竞争；
从适用性上来说，经过十几年在hpux上的运行，该工具几乎覆盖了hpux所有的版本和平台。与此同时，HP开始开发linux平台的版本，已知至少可以支持若干主流产品，比如RHEL 6和SLES 12(X86-64BIT)

3、通过KI分析oracle server process

在我们了解了KI TOOLS和ORACLE SERVER PROCESS 之后，让我们通过HP ki工具trace一个server process并产生报告来看看.
使用runki命令跟踪一个server process，在生成跟踪数据后，抽取数据进行分析，我们按照报告的顺序进行分析。

　　　　　　　　　　　图一：kipid输出的该进程的调度活动

从图一中，我们可以看到该进程分别有三种时间态。运行时间、队列里面等候时间、sleep时间。具体到这个场景我们也可以看到大部分的消耗是消耗在user%下面，无疑这个时候系统管理员可以先稍微松口气。

　　　　　　　　　　　　图二：调度活动的细化

让我们继续看，从图二中，可以看到绝大多数的cpu消耗，是在user%态下，这个无疑是一个非常好的结果，如果是高系统态消耗（sys%）。我们需要继续深入分析搞系统态的原因。 另外我们会发现 在CPU MIGRS和node migrs，前者是指进程在不同core之间切换，而后者是指在不同的socket之间切换。一般来说，无论是在UNIX还是在LINUX环境下，这种切换都是SMP系统的正常行为，他可以确保进程以最快的速度获得cpu资源，但是可能会导致cpu cache的 reload，也就是说很多时候，管理员需要在不同场景下进行平衡，以期获得最大的性能收益。

　　　　　　　　　　　　表三：进程的等待

这是一个非常常见的oracle server process wait分析的输出结果， 我们看到在oracle的sleep的过程中，主要是由三个核心函数导致。需要注意的是我们所说的sleep并不一定是缺陷，除了系统因素外，也可能是正常的客户端空闲导致的sleep。
具体来说：
Sk_wait_data：是指进程block在socket read()上， 也就是等待client传数据过来。因此他很大程度上应该是一个空闲状态。或者是client端存在瓶颈。
Sys_semtimedop:是指进程block在某些排他性操作上，比如logwrite写的完成，或者等待某些竞争性latch或者enqueue的释放。
Io_schedule:相对简单，很多时候是因为等待IO的完成而call sleep()。

　　　　　　　　　　　表四：sk_wait_data函数等待的原因

表四中我们可以看到， runq是一个比较重要的指标。 Read的runq明显大，表示client端存在某种瓶颈。 Write的runq大则表示没有那么多数据流来让Server Process忙起来。

　　　　　　　　　　　　　表五：ORACLE的内部等待

我们知道semaphore的操作往往是带有排他性的，在数据库里面更加常见，比如各类lock（enqueue）或者latch的竞争，而这类竞争在操作系统中会表现为SEM的等待。这个例子中我们看到应该是LGWR进程带来的等待。、


　　　　　　　　　　　　　　表六： IO的完成

简单的说我们在上图中，看到各种读调用，一般来说PREAD64()往往代表单块读写，对应都是directio类型。而readv()往往是多块连续读。

　　　　　　　　　　　图七：IO方面 AWR和KI的输出对比

在上图中我们可以发现oracle的awr和ki的报告所表现出的结果是类似的，但是需要注意的是AWR和ki 所 报告的磁盘io效率有所不同，AWR的磁盘访问速度往往大于系统工具所统计的时间，这是因为两种工具的统计范围不同，索然有参考性，但是不具备可对比性。

4、总结

通过上述分析介绍我们可以了解OS角度下的oracle进程的活动，一般来说，oracle内部的事件应该以oracle awr或者其他工具来分析，并作为事件的主导方，但是通过ki的使用我们可以更好地分析和处理所面对的问题，通过OS角度的分析我们可以有更加宽阔的视角来思考问题，并且快速排出系统在问题事件中所扮演的角色和责任，获得比较明显的收益。诚然KI TOOLS 存在一定的局限性，比如收集的数据必须是当前的数据，不具备回溯数据和储存历史数据的能力，运行的时长一般限制在20秒左右，运行时会产生一定级别的跟踪数据和一定的额外的系统负载生成的数据，对系统管理员的系统知识要求有相当的水平，并且具备一定的开发技能，以及可能有些用户对于适用DLKM存在限制或者疑虑，但是他仍然不失为一种有效的分析工具，为系统管理员提供了更加丰富的手段，来面对数据库与系统共存的复杂环境。

5、说明

本文参考了部分hp wtec数据用以进行数据说明，特此说明。