通過shell繫結系統程式調優

資料庫的效能調優，需要基於作業系統的效能指標，如果作業系統級發生了一些狀況，那麼會潛移默化的影響到資料庫層面。而資料庫中對應的程式和作業系統級也有一定的對映關係，在專有伺服器模式下大體如此。
有時候如果你注意到作業系統級有一些程式消耗資源高，那麼很可能這個程式對應的資料庫程式存在潛在的問題，這種方法在平時的效能診斷調優中屢試不爽，基本能夠很快的定位出問題所在。
一方面可以通過資料庫的檢視對映來分析排查問題，但是很可能等你sql語句準備好了的時候，程式的某些任務也執行完成了，無法同步的抓取到一些很關鍵的資訊。
以下的shell指令碼對作業系統級的程式和資料庫層的程式進行了對映，能夠找到對應的session，然後得到當前活最近執行的sql語句。

if [ -z "$1" ]; then
 echo "no process has provided!"
 exit 0
fi
sh_tmp_process=`sqlplus -silent $DB_CONN_STR@$SH_DB_SID < set pagesize 0 feedback off verify off heading on echo off
select addr from v\\$process where spid=$1;
exit;
END`


if [ -z "$sh_tmp_process" ]; then
 echo "no process exists or session is not from a DB account"
 echo
 echo "####### Process Information from OS level as below ########"
 ps -ef|grep $1|grep -v "grep"|grep ora
 echo "##############################################"
 exit 0
else
 echo '*******************************************'
 echo "Process has found, pid: $1  ,  addr: $sh_tmp_process    "
 echo
 echo "####### Process Information from OS level as below ########"
 ps -ef|grep $1|grep -v grep|grep ora
 echo "##############################################"
 sqlplus -s $DB_CONN_STR@$SH_DB_SID < col machine format a20
col terminal format a15
col osuser format a15
col process format a15
col username format a15
set linesize 150
select sid,serial#,username,osuser ,machine,process,terminal,type,to_char(LOGON_TIME,'yyyy-mm-dd hh24:mi:ss')login_time from v\$session
where paddr='$sh_tmp_process';
prompt .
col sql_id format a30
col prev_sql_id format a30
col sql_text format a60
set linesize 150
set pages 50
select sql_id,sql_text from v\$sql where sql_id in (select sql_id from v\$session where paddr='$sh_tmp_process' and sql_id is not null  ) and rownum<2;
select sql_id prev_sql_id ,sql_text from v\$sql where sql_id in (select prev_sql_id sql_id from v\$session where paddr='$sh_tmp_process'  ) and rownum<2;
EOF
fi


假設指令碼名為showpid.sh 則執行方式如下，我們碰到了一個程式異常，pid為29291
> ksh showpid.sh 29291
*******************************************
Process has found, pid: 29291  ,  addr: 000000089837FF20

####### Process Information from OS level as below ########
oraccbs1 21784 31648  0 20:05 pts/3    00:00:00 ksh showpid.sh 29291
oraccbs1 29291     1 90 20:00 ?        00:04:30 oracleCUST01 (LOCAL=NO)
##############################################

       SID    SERIAL# USERNAME        OSUSER          MACHINE              PROCESS         TERMINAL        TYPE       LOGIN_TIME
---------- ---------- --------------- --------------- -------------------- --------------- --------------- ---------- -------------------
      4779      10699 PRODTEST        PRODOSUSER      xxxxxxxxxx           4956:5500       TIT_C15-xxxx    USER       2015-01-31 20:00:29

SQL_ID                         SQL_TEXT
------------------------------ ------------------------------------------------------------
248xkdahtdb2q                  

 UPDATE
COMM_ACTIVITY SET COMM_ACTIVITY.EXTRACT_STATUS = NVL(:1 ,
EXTRACT_STATUS), COMM_ACTIVITY.SOURCE_TYPE = NVL(:2 , SOURCE_TYPE),
OPERATOR_ID = :3 , APPLICATION_ID = :4 , DL_SERVICE_CODE = :5 ,
DL_UPDATE_STAMP = :6 , SYS_UPDATE_DATE = SYSDATE where
COMM_ACTIVITY.ACTIVITY_CODE=:7  AND
COMM_ACTIVITY.EXTRACT_STATUS=:8

通過如上的命令能夠很快的定位到程式和session對應的sql語句，對於排查問題來說更加直觀。
現在只需要分析一下這條語句即可，看看是什麼原因導致資源消耗異常。
最後發現這條看似簡單的update語句走了全表掃描。其實可以進行一定的優化的。對於這條語句的分析詳情請參見http://blog.itpub.net/23718752/viewspace-1422310/

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1424376/，如需轉載，請註明出處，否則將追究法律責任。