Part1环境信息

数据库：Oracle 19.23.0.0.0 集群
连接池：druid

Part2问题报错

Socket Time out

Part3问题处理

Part3.1、网络方面的波动

ping 数据库IP

Part3.2、数据库的繁忙状态

总体资源
sar

CPU使用
top

磁盘IO
iostat -x 3

Part3.3、问题SQL的定位

生成AWR和ASH报告追踪

@?/rdbms/admin/awrrpt

@?/rdbms/admin/ashrpt

通过报告查看的确是有 enq: TX - row lock contention 等待事件，也抓取到了这个SQL，和他的SQL ID（1ujwkqz3a4kf5）

查看执行计划

SQL> select * from table(dbms_xplan.display_awr('1ujwkqz3a4kf5'));

Plan hash value: 2806104620
--------------------------------------------------------------------------------------------------
| Id  | Operation       | Name              | Rows  | Bytes | Cost (%CPU)| Time      |
--------------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |                |    |     |     2 (100)|        |
|   1 |  UPDATE        | AAAAAAAAAAAAAA         |     |       |            |        |
|*  2 |   INDEX RANGE SCAN | AAAAAAAAAAAAAAAAAAAAAAAAAA |     1 |   947 |     1   (0)| 00:00:01  |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("AA_ID"=:74 AND "BBBB_ID"=:75 AND "CCCC_TAG"=:76 AND "DDD_GUID"=:73)
46 rows selected.

10046定位流程

select a.inst_id,b.spid, a.sid, a.serial#, a.MACHINE, a.logon_time
  from gv$session a, gv$process b
 where a.paddr = b.ADDR
   and a.username = '用户'
   and machine like '%机器名%';

这里的setospid就是上边的spid

SQL> oradebug setospid 46952
Oracle pid: 85, Unix process pid: 133506, image: oracle@cprac89 (O009)

SQL>  oradebug unlimit;
Statement processed.

SQL> oradebug tracefile_name
/u01/app/oracle/diag/rdbms/aaaa/aaa21/trace/aaaa_ora_73137.trc

SQL>  oradebug session_event 10046 trace name context forever ,level 12
Statement processed.

##卡死后可以结束
SQL> oradebug event 10046 trace name context off


用tkprof 格式化，
su - oracle
tkprof aaaa21_ora_73137.trc /tmp/sock_time_out

定位问题sql，查看执行信息，查看流程步骤

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.16     601.21          0          4          1           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.16     601.21          0          4          1           0

配合开发再定位，抓住问题源头

SELECT 'Instance '||s1.INST_ID||' '|| s1.username || '@' || s1.machine
|| ' ( SID= ' || s1.sid || ','|| s1.serial#||',@'||s1.INST_ID||' '||s1.status||  '  )  is blocking '
|| s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' ||s2.sql_id
FROM gv$lock l1, gv$session s1, gv$lock l2, gv$session s2
WHERE s1.sid=l1.sid AND
s1.inst_id=l1.inst_id AND
s2.sid=l2.sid AND
s2.inst_id=l2.inst_id AND
l1.BLOCK=1 AND
l2.request > 0 AND
l1.id1 = l2.id1 AND
l2.id2 = l2.id2 ;

记住SID和实例需要修改

SELECT * FROM gv$sql WHERE sql_id = (SELECT NVL(prev_sql_id,'1') FROM  gv$session WHERE sid=6165 and inst_id=1);

配合他先把这个会话干掉

alter system kill session '14545,42819' immediate;

Part4问题复盘

1、为什么用这种麻烦的方式，因为只有报socket，开发才会找我，只能是事后了，没发定位到源头

2、按照开发的说法，我一直想的是用10046定位整个连接会话，结果最后发现是源头是另一个会话的，但是也的确定位到被堵塞的SQL在一开始是被堵死的

3、唯一有用的是复现问题场景，但是查到另一个会话最后执行的是sql语句，本来想接着10046追踪的。但是开发通过查询sql最后自己定位到一个update语句，也是对这个数据库表的操作，我让他去修改业务逻辑去了（也许是差个提交？）

4、事后问大佬说是可以考虑用一下 oradebug hanganalyze 3 ，又得学习新知识了