Buffer sort引发的血案
今天遇到的一个问题，在线系统上，有两张表，test1大概50G，test2大概200G，需要查询出来test1表中部分记录，并且这些记录不存在test2表中。于是就写了一个sql：
select t1.*
from test1 t1, test2 t2
where t1.col1 = t2.col1(+)
and t1.col2 = t2.col2(+)
and t1.col3 = t2.col3(+)
and t2.col1 is null;
因为是在线系统，考虑对系统的影响，这个就放到备库中去执行，而test1和test2这两张表又不在一个物理db上，所以就写了下面的sql：
select /*+ ordered use_hash(t,f) parallel(t 4) parallel(f 4) */ t1.*
from test1 t1, test2@remote_stb t2
where t1.col1 = t2.col1(+)
and t1.col2 = t2.col2(+)
and t1.col3 = t2.col3(+)
and t2.col1 is null;
分别打开两个物理备库，进行查询，结果出现了ORA-1652: unable to extend temp segment by 128 in tablespace TEMP。
分析原因：
考虑到使用hash join，先要构造test1的哈希表，test1表有50G，所以就在standby上增大了临时表空间，想着一定没有问题了，天不遂人愿，同样的错误又出现了，崩溃。于是就查看执行计划：
SQLPLAN
--------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS
1 0 SORT (AGGREGATE)
2 1 PX COORDINATOR
3 2 PX SEND (QC (RANDOM)) OF :TQ10002
4 3 SORT (AGGREGATE)
5 4 FILTER
6 5 HASH JOIN (OUTER)
7 6 PX RECEIVE
8 7 PX SEND (HASH) OF :TQ10001
9 8 PX BLOCK (ITERATOR)
10 9 TABLE ACCESS (FULL) OF test1
11 6 BUFFER (SORT)
12 11 PX RECEIVE
13 12 PX SEND (HASH) OF :TQ10000
14 13 REMOTE
临时表空间应该不是问题，所以推断应该是执行计划出来问题，查看执行计划，出现sort的地方就只有SORT (AGGREGATE)和BUFFER (sort)，由于是count的计数，所以SORT (AGGREGATE)不会使用到排序空间，那只有BUFFER(sort)。于是上网上搜索，发现Lewis的一篇介绍BUFFER（sort）的博客：
http://jonathanlewis.wordpress.com/2006/12/17/buffer-sorts/
http://jonathanlewis.wordpress.com/2006/12/13/cartesian-merge-join/
里边有介绍buffer(sort)的内容。
但博客里没有找到灵感，后面再仔细的看一下，翻译下。不过最后问题的解决还是同事的提醒，在并发的时候，hash join会对探测表进行buffer sort，去掉并发的hint，sql最终跑了出来。究竟为什么并发的hash join会出现这样的情况，有待研究。
未完待续……