今天照例检查数据库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 FROM xxxx1, xxxx2, xxx3 WHERE xxxx1.ACCOUNT_ID = 10000027 |
最后马上和team里面确认了下，是有一个人执行的。
然后为了阻止隐患，为邮件给关联的team,对于sql的优化问题一点那个要优化转发到dba team。
看似一个很小的问题，可能包含着错误的操作。