alert日志中的一条ora警告信息的分析(59天)
公众号：杨建荣的学习笔记 · 作者：笔记59天 · 发布：2014-05-01 08:54:46 · 原文链接
今天照例检查数据库alert日志，发现一个错误。但是也没在意，想可能有大的操作导致的，马上会释放空间的，但是转眼一想，这是生产库，而且现在时早上，泰国的运营商还不算忙时，需要重视这个问题，看有没有什么潜在的问题，
从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 |
| 7v8g1ffh5mwz7 | 3702571469 | 83.08 | CPU + Wait for CPU | 83.08 | SELECT /*+ leading (ar1_charge… |
| d8x0ns0xjbrp9 | 1042878405 | 9.23 | CPU + Wait for CPU | 9.23 | SELECT MT.SHORT_DESC, MO.ENTIT… |
| 2979km1x69s3g | 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 FROMxxxx1, xxxx2, xxx3 WHERE xxxx1.ACCOUNT_ID = 10000027 |