ORA-1652问题的分析

今天照例检查数据库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
	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。

看似一个很小的问题，可能包含着错误的操作。