alert日志中的一条ora警告信息的分析(59天)
alert日志中的一条ora警告信息的分析(59天)
今天照例检查数据库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 |
最后马上和team里面确认了下，是有一个人执行的。
然后为了阻止隐患，为邮件给关联的team,对于sql的优化问题一点那个要优化转发到dba team。
看似一个很小的问题，可能包含着错误的操作。