最终该问题通过检查等待事件的方式得以解决，下面简单描述一下处理过程：

会话1：

在服务器本地使用sqlplus登陆数据库实例，

1).执行下面的SQL语句确定本会话的SID：

SQL> SELECT DISTINCT SID FROM V$MYSTAT;

2).执行查询2条数据的临时表（固定耗时12秒）。

会话2：

在服务器本地使用sqlplus登陆数据库实例，

执行下面的SQL语句，查询会话1在查询2条数据的临时表时发生的等待事件：

SQL> set linesize 200
SQL> set pagesize 200
SQL> col program format a30
SQL> col machine format a30
SQL> col wait_class format a30
SQL> select username,program,machine,event,wait_class from v$session where wait_class <>'Idle' and sid=572

USERNAME? ? ? ? ? ? ? ? ? ? ? PROGRAM? ? ? ? ? ? ? ? ? ? ? ? MACHINE? ? ? ? ? ? ? ? ? ? ? ? EVENT? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? WAIT_CLASS
------------------------------ ------------------------------ ------------------------------ ---------------------------------------------------------------- ------------------------------
SYS? ? ? ? ? ? ? ? ? ? ? ? ? ? sqlplus@rx9900a (TNS V1-V3)? ? rx9900a? ? ? ? ? ? ? ? ? ? ? ? asynch descriptor resize? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Other

? ? 该等待事件的WAIT_CLASS为Other，比较异常，从EVENT可以大概了解该等待和异步IO有一定的关系，通过在MOS上检索该EVENT找到如下一篇文章：
?
Bug 9829397? Excessive CPU and many "asynch descriptor resize" waits for SQL using Async IO
?This note gives a brief overview of bug 9829397.
? The content was last updated on: 28-JUN-2013
? Click here for details of each of the sections below.

Affects:

It is believed to be a regression in default behaviour thus:
Regression introduced in 11.2.0.2
Fixed:

?

?

从文章可以看出该问题可能是个bug，通过在数据库实例关闭异步IO即可解决问题，根据文章执行如下的操作：

SQL> show parameter io

NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? VALUE
------------------------------------ ----------- ------------------------------
......
disk_asynch_io? ? ? ? ? ? ? ? ? ? ? boolean? ? TRUE
......

SQL> alter system set disk_asynch_io=false scope=spfile sid='scrk1';

System altered.

重启RAC第一个节点数据库实例之后问题即得到解决。