OS Per

        如果数据库没有等待，SQL没有什么问题，那就要归结操作系统的问题。当你没什么方向，就要看看操作系统了。一般的troubleshooting过程就像洗被单子先勾起一个大框来，扔水里大面积揉搓，然后再具体哪里脏着重的洗。

        首先要看看topas ：CPU、IO、Memory 比如CPU较高，那么对你troubleshooting Database更有帮助，比如CPU有Ready Queue(RUN Q)，swap很高，内存消耗很大，那么你就会有针对性的看AWR了。因为操作系统是所有软件的运行平台。

调用操作系统的call，申请内存，使用内存，使用IO，Oracle直接用操作系统的API，这就是为什么从操作系统上可以看出数据库的问题。

Vmstat(对所用的CPU)

vmstat的第一列、Ready queue 排队的地方，如果不工作了，就Suspend等着。

ProcessDump里有call stack trace

AIX的

Resident Connection Pool 11g新功能没有用。

当r大于cpu数的时候，说明有1个process在等待，在q中没有调用到cpu中工作，这个vmstat是看整体的cpu的，和单个进程是有区别的，我们用topas看单个进程的cpu使用。

B如果高一般是IO阻塞了CPU。

swpd是swap的使用，free是空闲的内存。

C是消耗的cpu时间ms，e是强钟时间。

Mpstat(每块cpu的情况)

mpstat -A

Pstack

能看到Oracle内部的函数调用，判断hang的时候很有用的。一般都是极端的hang的情况哈。

declare

     icount number ;

begin

     loop

       select count (*) into icount from dba_objects where object_name like '%G%' ;

     end loop ;

end ;

然后我们看top，进程是19941,pstack 19441。

Strace –p

没用过~

Errorstack

oradebug setospid 19941

oradebug unlimit

oradebug dump errorstack 10

oradebug tracefile_name

/ u01 / app / oracle / diag / rdbms / prod / prod / trace / prod_ora_19941.trc

Errorstack要收集两次

Virtual Memory

        分页的handle是存在stack中的，操作系统使用内存是要先分成一个一个页，页由chain管理，页越多使用的stack内存就越高。存东西最终存在实际的物理内存中，虚拟的就到page这一层，如果内存资源不足，这时候page的内存就要page到swap中这就叫page out。如果说现在内存要工作了，并且我知道我要用的那块内存地址，我先到page table中去找，如果找不到就去swap中去找，然后再page in回来。

        Swap out和page out不同，当process工作的时候发现内存不够用并且不是首先要工作的process，这时候，process相关的所有内存都会放到swap中，腾出内存给先工作的process使用，这个动作就是swap out，而page out是从page中out到 swap。

Hugepage会减少swap

Sar

Pmap <ospid>

.so什么的是调用的SO库文件。

最后total是这个进程消耗的总内存大小。

内部的call调用HBA卡等等

Iostat