Oracle中资源的共享与竞争及问题定位

核心提示： 接下来的 |s/);$/,__FILE__,__LINE__&/ 是将 ociparse 语句的右括号进行替换,将用于调试监控的两个参数(PHP 中的宏 ) 加上,$ 不是指一个真正的字符,而是指一个特定的位置 -- 行尾,以避免无辜的 ); 被替换掉，另一个命令 -c ':x!&

接下来的 |s/);$/,__FILE__,__LINE__&/ 是将 ociparse 语句的右括号进行替换,将用于调试监控的两个参数(PHP 中的宏 ) 加上,$ 不是指一个真正的字符,而是指一个特定的位置 -- 行尾,以避免无辜的 ); 被替换掉。另一个命令 -c ':x!' 是将该文件存盘退出。

打出这么一套组合拳需要你对这些命令了如指掌 , 如果你对某个文件没有写权 , 或出了其它岔子 , 那简直是一场灾难 , 这种魔法级的指令总是高风险的,搞不好会走火入魔,让你发下毒誓有生之年不再碰它。所以谨慎与备份总是对的。

3. 对各种应用程序中的情况进行监控

假设一个系统中不仅仅有 PHP 程序,还有 C 程序与数据库进行连接,那么数据库系统一旦出了问题,如资源消耗过多,造成死锁等。

ps ax | grep oracleORCL

是看不出什么东西的,因为这个进程是 Oracle 的 shadow 进程,命令名字都被改了,从 /proc 文件系统中提供的信息中也榨不出什么有用的东西了,所以,如果发现一个进程 ( 这是 ps ax 的实际输出 ) 如下:

10406 ? R 159:10 oracleORCL (DESCRIPTION=(LOCAL=no)(ADDRESS=(PROTOCOL=

确定这个进程长时间处于 running 状态的肇事者就成为一个难题 , 首先 , 进程的运行者是Oracle,连接者却可能是来自本机 , 来自局域网络 , 来自 internet 的 nobody 用户 , 所以冤无头,债无主。查看 v$session, v$process, v$..., 也没有关于客户端的足够信息。可以用来缩小范围的是 SQL 语句 , 但仍不足以构成充分的说服力让某一应用的开发人员确信是自己的程序出了问题。观察字段丰富的 v$session 视图,里面有一个十分诱人的 client_info 字段 , 顾名思义 , 不能不让人想入非非:一定是关于 Oracle客户端的信息的,可惜它一般是 NULL 值, 笔者从 ORACLE 文档中终于发现了