ora错误是01652的错误，单纯来看是由于临时表空间不足造成的。
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
因为问题发生在上午，从shared pool里查看对应的sql已经查不到了，这个时候使用ash是一个很方便的方式。
参考问题发生的时间点，抓取了一个4分钟的ash报告。
首先看到时间基本都消耗在了两个程序上，其中一个还是toad连接进来的session.
| Service |
Module |
% Activity |
Action |
% Action |
| USG01 |
EnvelopeMT@ccbdbpr2 (TNS V1-V3) |
72.81 |
UNNAMED |
72.81 |
|
|
TOAD 11.0.0.116 |
21.58 |
UNNAMED |
21.58 |
想看看具体的session情况,可以结合等待事件来分析一下，这个时候就可以很清楚的看到那个时间段的操作了。
| Sid, Serial# |
% Activity |
Event |
% Event |
User |
Program |
# Samples Active |
XIDs |
| 6937, 1129 |
27.91 |
db file sequential read |
21.29 |
USG1C |
EnvelopeMT@...2 (TNS V1-V3) |
148/240 [ 62%] |
0 |
|
|
|
CPU + Wait for CPU |
6.04 |
|
|
42/240 [ 18%] |
0 |
| 3992,34841 |
21.58 |
direct path read |
18.99 |
XXXXXX |
Toad.exe |
132/240 [ 55%] |
0 |
|
|
|
CPU + Wait for CPU |
2.59 |
|
|
18/240 [ 8%] |
0 |
| 6844,29137 |
10.50 |
db file sequential read |
10.22 |
USG1C |
EnvelopeMT@...2 (TNS V1-V3) |
71/240 [ 30%] |
0 |
| 384, 4043 |
9.93 |
db file sequential read |
6.62 |
PRDUSG1C |
pm1EnvelopeMT@...2 (TNS V1-V3) |
46/240 [ 19%] |
23 |
|
|
|
CPU + Wait for CPU |
3.31 |
|
|
23/240 [ 10%] |
14 |
| 7130, 5817 |
5.18 |
db file sequential read |
5.04 |
PRDUSG1C |
pm1EnvelopeMT@...2 (TNS V1-V3) |
35/240 [ 15%] |
0 |
但是分析sql语句的时候却没有发现toad相关的session执行的sql语句。
| SQL ID |
Planhash |
Sampled # of Executions |
% Activity |
Event |
% Event |
Top Row Source |
% RwSrc |
SQL Text |
| 421773076 |
1 |
27.91 |
db file sequential read |
21.29 |
TABLE ACCESS - BY LOCAL INDEX ROWID |
18.56 |
SELECT RE.L3_NET_START_TIME, R... |
|
|
|
|
|
|
CPU + Wait for CPU |
6.04 |
SORT - ORDER BY |
3.02 |
|
| 2387198001 |
30 |
7.77 |
db file sequential read |
6.76 |
UPDATE |
6.47 |
UPDATE RATED_EVENT SET L3_NET_... |
|
|
|
|
|
|
CPU + Wait for CPU |
1.01 |
UPDATE |
0.86 |
|
| 958688106 |
28 |
5.76 |
CPU + Wait for CPU |
5.76 |
SELECT STATEMENT |
3.45 |
/* */ SELECT CYCLE_CODE, CYCLE... |
|
| 421773076 |
1 |
5.32 |
db file sequential read |
5.32 |
TABLE ACCESS - BY LOCAL INDEX ROWID |
5.18 |
SELECT RE.L3_NET_START_TIME, R... |
|
| 421773076 |
1 |
5.04 |
db file sequential read |
4.89 |
TABLE ACCESS - BY LOCAL INDEX ROWID |
4.89 |
SELECT RE.L3_NET_START_TIME, R... |
从以上问题可以简单的分析出，资源的消耗在一个job和toad相关的session上，至于toad的进程在那个时间点在做什么通过ash还没有抓取到更详细的信息。但是可以从等待事件来看，是在做一个大查询。
根据系统的负载最后给出了几点建议。
首先是根据报告对那个时间点操作的客户进行确认，是否做了一些额外的操作。
然后从目前的系统角度来看，这个库的temp空间本身也存在着一定的不足，目前只有8G，需要做一定的扩展，因为库中有几个大表，都在百G级别，一些排序操作可能会消耗相当大的temp空间。
最后和开发确认资源消耗较多的sql语句。（28kbzsqpfpp7j)
开发给出的反馈是这个job的程序很久没有更新了。我简单检查了一下最近的执行历史做了确认。
所以问题就锁定在两个方面，一个是toad相关的session导致的，一个是temp空间不足造成的（一种可能甚至是toad对应的session消耗了一部分的temp空间，到了sql_id(28kbzsqpfpp7j) temp空间或者说sql_id在做排序操作的时候消耗的temp空间过大）
排除了其他原因之后，再次尝试跑就没有问题了。对于临时表空间的扩展也在稍后做了添加。
