关于oracle:转发硬货Oracle数据库出现问题时这十个脚本帮你快速定位原因

“喂，李总您好！”

“小张，快点看看 ERP 数据库，利用又打不开了！”

“好的，马上。”

小张从彩色背包拿出电脑，连上手机热点就开始查看，刚连上数据库，电话铃声又响起来了 …..

这样的场景对于 Oracle DBA 来说太相熟了，只有利用一出问题，不管何时，不管何地，总是第一个接到电话，重大状况下会是一轮电话轰炸。

老手和专家之间遇到此类问题，首先是心态，老手遇到问题心里慌，不知从何下手，胆大大意，专家因为经验丰富，往往从容沉着、指挥若定、抽丝剥茧、胆大心细，然而教训这货色就跟吃过的盐、走过的桥一样，必须亲自多做、多学能力取得。而另外一个十分重要的就是诊断思路和辅助脚本，本文讲述各种场景下的通用解决思路，分享用到的一些脚本，帮忙大家疾速定位问题并解决，缩小业务的中断事件，早日成为专家，升职加薪，迎娶 …

>>>> 查看操作系统负载

登上数据库服务器后，第一个就是通过系统命令确认下 CPU、内存、I/ O 是否异样，每个零碎的命令不一样，常见的有 top、topas、vmstat、iostat。

>>>> 查看期待事件

第二步就是连到数据库查看流动的期待事件，这是监控、巡检、诊断数据库最根本的伎俩，通常 81% 的问题都能够通过期待事件初步定为起因，它是数据库运行状况最间接的体现，如下脚本是查看每个期待事件的个数、期待时长，并排除了一些常见的 IDLE 期待事件。

-- 墨天轮 wait_event
col event for a45
SELECT  inst_id,EVENT, SUM(DECODE(WAIT_TIME, 0, 0, 1)) "Prev", SUM(DECODE(WAIT_TIME, 0, 1, 0)) "Curr", COUNT(*) "Tot" , sum(SECONDS_IN_WAIT) SECONDS_IN_WAIT
FROM GV$SESSION_WAIT
WHERE event NOT
IN ('smon timer','pmon timer','rdbms ipc message','SQL*Net message from client','gcs remote message')
  AND event NOT LIKE '%idle%'
  AND event NOT LIKE '%Idle%'
  AND event NOT LIKE '%Streams AQ%'
GROUP BY inst_id,EVENT
ORDER BY 1,5 desc;

这里就须要把握一些常见异样期待事件的起因，并造成条件反射，比方 library cache lock、read by other session、row cache lock、buffer busy waits、latch:shared pool、gc buffer busy、cursor: pin S on X、direct path read、log file sync、enq: TX – index contention、PX Deq Credit: send blkd、latch free、enq: TX – row lock contention 等等，如果异样期待事件的个数和等待时间很长，那么排查起因的入口就在这里。

>>>> 依据期待事件查会话

失去异样期待事件之后，咱们就依据期待事件去查会话详情，也就是查看哪些会话执行哪些 SQL 在期待，另外还查出来用户名和机器名称，以及是否被阻塞。另外如下脚本可改写成依据用户查会话、依据 SQL\_ID 查会话等等。

-- 墨天轮 session_by_event
SELECT /*+rule */ sid, s.serial#, spid, event, sql_id, seconds_in_wait ws, row_wait_obj# obj, s.username, s.machine,
BLOCKING_INSTANCE||'.'||blocking_session b_sess FROM v$session s,
v$process p WHERE event='&event_name' AND s.paddr = p.addr order by 6;

>>>> 查问某个会话详情

失去会话列表之后，能够依据如下 SQL 查问某个会话的详细信息，如上次个执行的 SQL\_ID，登录工夫等，该 SQL 也可改写成多个。

-- 墨天轮 session_by_sid
SELECT s.sid, s.serial#, spid, event, sql_id, PREV_SQL_ID,
seconds_in_wait ws, row_wait_obj# obj, s.username, s.machine,
module,blocking_session b_sess,logon_time  FROM v$session s, v$process p WHERE sid = '&sid' AND s.paddr = p.addr;

>>>> 查问对象信息

从后面两个 SQL 都能够看到会话期待的对象 ID，能够通过如下 SQL 查问对象的详细信息。

-- 墨天轮 obj_info
col OBJECT_NAME for a30
select owner,object_name,subobject_name,object_type from dba_objects where
object_id=&oid;

>>>> 查问 SQL 语句
依据 SQL\_ID、HASH\_VALUE 查问 SQL 语句。如果 v$sqlarea 中查不到，能够尝试 DBA\_HIST\_SQLTEXT 视图中查问。

-- 墨天轮 sql_text
select sql_id,SQL_fullTEXT from v$sqlarea where (sql_id='&sqlid' or
hash_value=to_number('&hashvale') ) and rownum<2;

对于 SQL 语句的执行打算、对象的统计信息、性能诊断、跟踪 SQL 等这里就不开展，前面打算出一个相似的系列，敬请关注。

>>>> 查问会话阻塞状况

通过如下 SQL 查问某个会话阻塞了多少个会话。

-- 墨天轮 blocking_sess
select count(*),blocking_session from v$session where blocking_session
is not null group by blocking_session;

>>>> 查询数据库的锁

通过如下 SQL 查问某个会话的锁，有哪些 TM、TX 锁，以及会话和锁关联查问的 SQL，留神这里指定了 ctime 大于 100 秒，30% 的状况是人为误操作锁表，导致利用 SQL 被阻塞，无奈运行。

-- 墨天轮 lock
set linesize 180
col username for a15
col owner for a15
col OBJECT_NAME for a30
col SPID for a10

-- 查问某个会话的锁
select /*+rule*/SESSION_ID,OBJECT_ID,ORACLE_USERNAME,OS_USER_NAME,PROCESS,
 LOCKED_MODE from gv$locked_object where session_id=&sid;

-- 查问 TM、TX 锁
select /*+rule*/* from v$lock where ctime >100 and type in ('TX','TM') order by 3,9;

-- 查询数据库中的锁
select /*+rule*/s.sid,p.spid,l.type,round(max(l.ctime)/60,0)
lock_min,s.sql_id,s.USERNAME,b.owner,b.object_type,b.object_name from
v$session s, v$process p,v$lock l,v$locked_object o,dba_objects b
where  o.SESSION_ID=s.sid and s.sid=l.sid and o.OBJECT_ID=b.OBJECT_ID
and s.paddr = p.addr and l.ctime >100 and l.type in ('TX','TM','FB')
group by
s.sid,p.spid,l.type,s.sql_id,s.USERNAME,b.owner,b.object_type,b.object_name
order by 9,1,3

>>>> 保留现场证据

有的问题可能须要剖析很长时间，或者是须要内部人员帮助剖析，那么保留现场证据就十分重要了，上面脚本是 systemstate dump 和 hanganalyze 步骤，如果有 sqlplus 无奈登陆的状况，能够加 -prelim 参数。

--systemstate dump
sqlplus -prelim / as sysdba
oradebug setmypid
oradebug unlimit;
oradebug dump systemstate 266;
--wait for 1 min
oradebug dump systemstate 266;
--wait for 1 min
oradebug dump systemstate 266;
oradebug tracefile_name;

 --hanganalyze
oradebug setmypid
oradebug unlimit;
oradebug dump hanganalyze 3
 --wait for 1 min
oradebug dump hanganalyze 3
--wait for 1 min
oradebug dump hanganalyze 3
oradebug tracefile_name

>>>> 杀会话

通常状况下，初步定为问题后为了疾速复原业务，须要去杀掉某些会话，特地是批量杀会话，有时还会间接 kill 所有 LOCAL=NO 的过程，再杀会话时肯定要查看确认，更不能在别的节点或者别的服务器上执行。

- 墨天轮 kill_sess
set line 199
col event format a35

-- 杀某个 SID 会话
SELECT /*+ rule */ sid, s.serial#, 'kill -9'||spid, event,
blocking_session b_sess FROM v$session s, v$process p WHERE sid='&sid' AND s.paddr = p.addr order by 1;

-- 依据 SQL_ID 杀会话
SELECT /*+ rule */ sid, s.serial#, 'kill -9'||spid, event,
blocking_session b_sess FROM v$session s, v$process p WHERE sql_id='&sql_id' AND s.paddr = p.addr order by 1;

-- 依据期待事件杀会话
SELECT /*+ rule */ sid, s.serial#, 'kill -9'||spid, event,
blocking_session b_sess FROM v$session s, v$process p WHERE event='&event' AND s.paddr = p.addr order by 1;

-- 依据用户杀会话
SELECT /*+ rule */ sid, s.serial#, 'kill -9'||spid, event,
blocking_session b_sess FROM v$session s, v$process p WHERE username='&username' AND s.paddr = p.addr order by 1;

--kill 所有 LOCAL=NO 过程
ps -ef|grep LOCAL=NO|grep $ORACLE_SID|grep -v grep|awk '{print $2}' |xargs ki

>>>> 重启大法

tail -f alert_.log
alter system checkpoint;
alter system switch logfile;
shutdown immediate;

startu

如须要批改动态参数、内存等问题，须要重启数据库，（不要感觉重启很 LOW，在很多状况下为了疾速复原业务常常应用这个从网吧里传进去的绝招），记住千万不要在这个时候死磕问题起因、当作课题钻研，咱们的首要任务是复原业务。

>>>>CRT 按钮小技巧

另外介绍一个小技巧，就是把罕用的脚本整顿到 SecureCRT 的 Button Bar 中，只须要点一下设置好的 button，就相当于间接执行相应的 SQL 语句，这样就不必每次粘贴复制执行，或者是把脚本上传到每个服务器上。不过不要设置 DDL 等操作性的 button，免得正点。

以上就是遇到数据库问题用到的一些脚本，特地是利用反馈慢、卡的状况，另外倡议首先对脚本进行浏览而后再应用，还能够依据本人的环境改写，死记硬背，积攒教训。

我把这些脚本都整顿到墨天轮的罕用脚本中，下面还有许多其余监控、治理、诊断的工具脚本，大家能够收费去下面拷贝下载应用。（点击下方下载即可收费拷贝下载~）

下载网址：cs.enmotech.com/scripts