ANBOB™

近期一个客户的Oracle 19c (19.4) RAC环境凌晨的批处理任务执行失败，调用方式从A库dblink 到B库2节点执行 Insert .. select /*+ PARALLEL (“A2”, 6) */* from t@dblinkb_2, 从ASH查看2节点为session 等待，因为使用Parallel Hint, 大量session 等待PX Deq. 和 Enq: ss – contention,  DFS lock handle. 当时KILL掉了那批FG 进程后重新调用正常。

Enq: ss – contention

ss==> Sort Segment issues 是一个排序temp段的队列等待，Ensures that sort segments created during parallel DML operations aren’t prematurely cleaned up。

Sort Segment在 RAC 中按实例维护，分配给一个实例的空间对其他实例不可见。 这意味着 ORA-01652 错误在 RAC 中的处理方式不同：首先启动跨实例调用，而不是将错误返回给调用者，以查看是否有任何其他实例可以释放已分配但未使用的临时空间。 （GV$TEMP_EXTENT_POOL 给出了每个实例关于分配的和使用的内容的概述。）, TEMP表空间被划分为多个Extent区段(在11.2中，区段大小为1M，不确定区段大小是否可控)。这些区段映射缓存在本地SGA中，本质上是为连接到该实例的会话使用软保留(extents are cached  called “soft reserved”  )这些区段。但是，请注意，临时表空间中的区段不会在实例启动时缓存，而是在需要时缓存区段。

从gv$temp_extent_pool可以看到每个实例cached sort segment extent在每个temp file上的分配，即使是cached没有used，本实例的extent也不会被另一实例直接使用，当实例1 可用的temp不足时，实例1需要从实例2窃取空间(uncache) ，在11g中uncache一次是100个extents，并且也不会主动去uncache extent release会表空间，直到其它实例申请re-uncache.  当进程用完temp tablespace中任何新的可分配空间时，它会请求集群中的其他实例释放任何未使用的空间。 这是通过跨实例调用完成的CIC (Cross Instance Call)。 CIC 受 SS 排队保护。 SS 入队是在表空间 (p1) 和实例 (p2) 上进行的。如果做10046 看够到到跨实例uncache窃取的锁信息：

...
#1: nam='enq: TS - contention' ela= 4172867 name|mode=1414725636 tablespace ID=3 dba=2 obj#=0 tim=6322835898
#2: nam='enq: SS - contention' ela= 608 name|mode=1397948417 tablespace #=3 dba=2 obj#=0 tim=6322837101
#3: nam='enq: SS - contention' ela= 414 name|mode=1397948422 tablespace #=3 dba=2 obj#=0 tim=6322837710
#4: nam='DFS lock handle' ela= 389 type|mode=1128857605 id1=14 id2=1 obj#=0 tim=6322838264
#5: nam='DFS lock handle' ela= 395 type|mode=1128857605 id1=14 id2=3 obj#=0 tim=6322838788
#6: nam='DFS lock handle' ela= 260414 type|mode=1128857605 id1=14 id2=2 obj#=0 tim=6323099335
...

可用空间的请求通过以下方式完成：
1. 在表空间/实例上进行 SS 排队。 这意味着任何试图代表这个表空间窃取空间的进程都将阻塞这个队列。

正如上面输出的测试用例中看到的，拥有更多临时表空间可能有助于缓解SS队列争用，因为SS锁位于表空间级别。从本质上讲，更多的临时表空间意味着更多的SS enqueues，但是，你会将争用从SS锁转移到“DFS lock Handle”等待，因为CIC是每个实例的区段uncaching操作。

2.CIC。 space-release-CIC 在 CIC 类型上序列化。 也就是说，在整个节点上，任何试图代表任何表空间窃取空间的进程都必须等待 CIC 完成。 请注意，即使您创建 10 个临时表空间，任何时候也只有一个 CIC 处于未完成状态。
A. 在 CIC 下，请求其他实例中的 SMON 释放空闲空间如果有的话(un-reserve the cached extents using CI type locks and DFS lock handle  lock types CI-14-1, CI-14-2, and CI-14-3）,并确认 CIC 的完成。
b. 当所有 SMON 确认时，CIC 完成。

从上面的sql trace 将缓存的区段从一个实例移动到另一个实例大约花费了4.5秒。

上述进程可能挂起导致临时空间分配不平衡。在节点 2 上运行的大批量进程可能会消耗大部分临时表空间。在需要临时/排序段的节点 1 上运行的会话无法分配它们，因为该节点没有任何可用的，所以他们从节点 2 [SS enqueue] 请求它们，由于批处理仍在运行，因此无法返回它们。

即使批处理在节点 2 完成并且临时表空间中的块被释放后，也没有将它们重新分配给节点 1，因此阻塞的会话将得到保留。这些会话以及节点 1 临时表空间中的每个新请求空间都将保持阻塞状态。重启数据库实例也不会解决问题，因为 RAC“记住”临时表空间是如何在关闭时在节点之间共享的，所以几分钟后您将面临同样的问题。此时可以扩展新temp文件或增加新TEMP表空间。在oracle的不同版本形为有可能会改变。

–查找BLOCKer session

查看v$session.blocking_session ，或使用TanelPoder 的ash_wait_chains.sql 或hanganalyze dump 或v$wait_chains（有dia0每3秒检查local 每10秒检查global chains）.如看到

SQL> oradebug setmypid
SQL> oradebug setinst all
SQL> oradebug -g all hanganalyze 3


'rdbms ipc message'<='DFS lock handle'<='enq: SS - contention'<='PX Deq Credit: send blkd'

— 查找wait session

select distinct
u.username,
u.osuser,
u.sql_id,
w.event,
w.p2text as reason,
ts.name as tablespace,
nvl(ddf.file_name, dtf.file_name)
from
v$session_wait w,
v$session u,
v$tablespace ts
left outer join
dba_data_files ddf on ddf.tablespace_name = ts.name
left outer join
DBA_TEMP_FILES dtf on dtf.tablespace_name = ts.name
where u.sid = w.sid
and w.p2 = ts.TS#
and w.event = 'enq: SS - contention';

— Find block change tracking

select p1 "File #". p2 "Block #", p3 "Reason Code"
  from v$session_wait
 where event = 'enq: SS - contention';;

Note:
该event对应的p1, p2 and p3值：
P1–>The absolute file number for the data file involved in the wait.
P2–>The block number within the data file referenced in P1 that is being waited upon.
P3–>The reason code describing why the wait is occurring.

DFS lock handle
之前的文章Troubleshooting “DFS lock handle” wait event 介绍过，这里不在过多复述。 ENQ SS再等待DFS LOCK, DFS LOCK HANDLE需要从P1 值转换

DFS lock handle p1=>1128857605 p2=>14 p3=>2

P1
1128857605 转换16进制0x43490005 0x43=C 0x49=I 为CI MODE=5

P2
The following can be used as reference for understanding the id1 for CI call:

1 reuse (checkpoint and invalidate block range)
2 LGWR Checkpointing and Hot Backup
3 DBWR syncronization of SGA with control file
4 log file add/drop/rename notification
5 miscellaneous CTWR operations
7 Manged standby recovery related
8 alter rollback segment optimal
9 Signal Query Servers/coordinator
10 Create Remote parallel query Server
11 Set Global Partitions
12 Stop Disk Writes
13 Drop Sort Segments
14 Release unused space from Sort Segments
15 instance Recovery for Parallel operation Group
16 Validate parallel slave Lock Value
17 check transaction state objects
18 object reuse request
19 rolling release checks
20 propagate begin backup scn for a file
21 refresh top plan (for db scheduler
22 clear checkpoint progress record
23 drop temp file
24 QUiesce database Restricted
25 Update Dscn Tracking (ktcndt
26 Purge dictionary Object number Cache
27 set Database Force Logging mode
28 invalidate cached file address translations
29 Cursor Unauthorize Mode
30 process waiters after row cache requeue
31 Active Change Directory extent relocation
32 block change tracking state change
33 kgl mulitversion obsolete
34 set previous resetlogs data
35 set recovery destination pointer
36 fast object reuse request
38 ASM diskgroup discovery wait
39 ASM diskgroup release
40 ASM push DB updates
41 ASM add ACD chunk
42 ASM map resize message
43 ASM map lock message
44 ASM map unlock message (phase 1
45 ASM map unlock message (phase 2
46 ASM generate add disk redo marker
d47 ASM check of PST validity
48 ASM offline disk CIC
49 Logical Standby Sync Point SCN
50 update SQL Tuning Base existence bitvector
51 PQ induced Checkpointing
52 ASM F1X0 relocation
53 Scheduler autostart
54 KZS increment grant/revoke counter
55 ASM disk operation message
56 ASM I/O error emulation
57 DB Supp log cursor invalidation
58 Cache global range invalidation
59 Cache global object invalidation
60 ASM Pre-Existing Extent Lock wait
61 Perform a ksk action through DBWR
62 ASM diskgroup refresh wait
63 KCBO object checkpoint
64 KCBO object pq checkpoint
65 global health check event
66 Oracle Label Security refresh
67 thread internal enable
68 cross-instance registration
69 KGL purge unused subheaps
70 clear pin instance flag
71 Rolling operations CIC
73 readable stby: metadata flush
74 slave dskm message
75 update sysaux state sga variable
76 notify storage server reg/dereg
77 ASM ACD relocation xtnt info
78 Misc LogMiner CIC
101 ASM disk error emulation
102 Audit Management operations
103 invalidate sql profile cursors
104 Misc RMAN CIC
105 standby role change
106 Voting file refresh CIC
107 LGWR miscellaneous
108 Invalidate ASM spfile xmap CIC
109 load new system statistics
110 sync datafile move state
111 KSB Rolling Migration Test1
112 ASM map lock message for AVD
113 Oracle Label Security install
114 Oracle Label Security enforce
115 Oracle Database Vault config
117 Invalidate DB Props cache CIC
118 OBSOLETE
119 Propagate final ODPS
120 Post for cleanup of Audit
121 Assist offline from the DB side
122 Assist offline from the ASM side
123 Nuke ILM file stats
124 12.1 RM CIC in RMON

P3
The following can be used to understand id2:
1 used to pass in parameters
2 used to invoke the function in backgroud process
3 used to indicate the foreground has not returned
4 mounted excl, use to allocate mechanism
5 used to queue up interested clients

案例原因

回到这个案例，背景是了解到当晚B库的节点1有大量的数据加载操作。实例2 FG 并行查询Sort segment allocations空间紧张，通知所有实例CIC 等待DFS LOCK HANDLE, 其它会话等它完成 等ENQ SS, 而实例1一直未答复sort segment清理完成。 因为 Sort Segments cleanup是后台进程SMON责任，实例1 DBW似乎在等SMON或DBW很忙未完成，TEMP表空间已大到1.5TB，问题时TEMP表空间使用率很低。因为没有hanganalyze 等信息和SMON、DBW等trace 文件， 不过从DASH看到DBW是持续在db file parallel write（P1=1）,

如果再次发生可以执行如下，

1, 生成DBW和SMON的trc

oradebug setorapname dbw0;
oradebug dump errorstack 3;
oradebug tracefile_name;
and
oradebug setorapname smon;
oradebug dump errorstack 3;
oradebug tracefile_name;

2. Pstacks of SMON from the same instance as the blocking DBW0 :

watch -n 2 'pstack PID_OF_SMON >> pstack.txt; echo -e "\n" >> pstack.txt'

3. Global hanganalyze report

根据现象比较匹配Bug 32996974 Cluster-wide hang and ‘DFS lock handle’ wait event under severe temp space pressure on an instance in RAC适配几乎ORACLE 19C 所有版本， 在19.15 RU包含. 如果没有安装该补丁有可能等CIC到无限期，该补丁是增加了wait的超时间(_ktst_dbg 30s），CIC 5次重试后如果还无法失败会终止等待和查询报错ORA-12955 error，无限等CIC时间长的原因有可能是SMON很忙或在执行instance recovery 任务，或无法获取到队列lock. 也可能SMON实际是正在释放Unused Sort Extents但是因为TEMP过大，如本案例temp大小上TB。也可能是SMON和DBW之间的通信问题，另一个就是oracle bug,因为一些原因 第1次的CIC无法完成并无限期等待后面的CIC请求要等第一次完成。

临时解决方法
1， 增加更多的tempfiles,那样它不属于任何instance
— or —
2,  resize tempfile
resize操作触发取消cached extent活动，您将注意到所有实例都在取消缓存临时区段。即使resize的和原来小一点，也会uncached 所有extent.
— or –
3，杀掉PQ slave等待的会话，重新调用。

一个好的方法可能是为OLTP用户和DSS用户分配不同的临时表空间，并将工作负载关联到特定的实例。

打赏

微信扫一扫，打赏作者吧～