本文共 1724 字，大约阅读时间需要 5 分钟。
从alert日志里面看到的
Fri Jul 12 09:08:23 ICT 2013
ORA-1652: unable to extend temp segment by 128 in tablespace TEMP
查询temp_usage，发现目前使用的只有goldengate的10多个session,占用的自用很少，查询现在的temp usage已经恢复正常了。
SQL> select TABLESPACE_NAME,TOTAL_BLOCKS,USED_BLOCKS,FREE_BLOCKS from v$sort_segment;
TABLESPACE_NAME TOTAL_BLOCKS USED_BLOCKS FREE_BLOCKS
------------------------------- ------------ ----------- -----------
TEMP 1023872 7936 1015936
导出awr报告，数据库整体负载很小。top sql里面看到的sql貌似都加了Hint，是被优化过的。
（awr报告时1小时一生成，可能有很多信息都不准确）
没办法，最后查ASH，精确到那一分钟，得到了以下的信息，
| Service | Module | % Activity | Action | % Action |
| XXXX01 | TOAD 9.6.1.1 | 83.08 | UNNAMED | 83.08 |
|
| JDBC Thin Client | 13.85 | UNNAMED | 13.85 |
并且发现下面的sql耗费了大量的资源，
Top SQL Statements
| SQL ID | Planhash | % Activity | Event | % Event | SQL Text |
|
| 3702571469 | 83.08 | CPU + Wait for CPU | 83.08 | SELECT /*+ leading (ar1_charge... |
|
| 1042878405 | 9.23 | CPU + Wait for CPU | 9.23 | SELECT MT.SHORT_DESC, MO.ENTIT... |
|
| 3257149028 | 1.54 | CPU + Wait for CPU | 1.54 | SELECT AR_BALANCE FROM AR1_ACC.. |
猛一看，这个sql应用了大量的hint,细细一看，是一个很有问题的sql
关联了好几个大表，但是没有关联。
SQL details:
| SQL Id | SQL Text |
| 7v8g1ffh5mwz7 | SELECT /*+ leading (xxxxx1 xxxx2 xxx3) use_nl (xxxxx1 xxxx2 xxx3) index (xxxxx1 xxxx2 _ix) index (xxxx2 xxxx2 _pk) */ xxxxx1 .CHARGE_ID, xxxxx2.debit_id, xxxx2.invoice_id, xxxx1.partition_id, xxxx1.period_key, ROW_NUMBER () OVER (ORDER BY xxxx2.DEBIT_ID DESC) RN FROM xxxx1, xxxx2, xxx3 WHERE xxxx1.ACCOUNT_ID = 10000027 |
最后马上和team里面确认了下，是有一个人执行的。
然后为了阻止隐患，为邮件给关联的team,对于sql的优化问题一点那个要优化转发到dba team。
看似一个很小的问题，可能包含着错误的操作。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-766192/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-766192/