近期一位同事问我他们通过pl/sql dev导出为csv文本文件的SQL语句一直执行不下去

原来数据库仓库里的一张分区表，数据量超级多，一天平均数据量超过8千多万行...而他们想导出一个月的数据，但是实际执行sql时发现sql无法执行完成。
然后他们将查询条件缩减为一个星期，结果还是不行....尝试按天导出，试了以后还是不行...

他们几乎折腾了3天多，甚至提出了一些不太合理数据库要求（比如讲数据库的temp表空间夸张为几个TB）。

他们sql是如下：

select t.cuttime,t.ceventid,t.cstbid,t.csource from abc.test_source t
where t.cuttime>=to_date('2013/08/06 00:00:00','yyyy/mm/dd hh24:MI:ss')
and t.cuttimeand t.ceventid in (1,2,5,7,23,21,26);

我随便看看表中数据行条数，执行如下sql，结果跑半天没有结果出来，看来该表确实很大,然后我取消了sql
select count(*) from abc.test_SOURCE

通过如下查询可以判断，该表是分区表：
select * from user_PART_TABLES b where b.owner='abc' and table_name='test_SOURCE'

在通过如下查询初步判断，该分区表每天生成一个分区表：
SQL> col segment_name format a30
SQL> col owner format a10
SQL> select owner,segment_name,partition_name,segment_type from dba_segments where segment_name='test_SOURCE' AND OWNER='abc';

根据以上查询结果，查询了一天生成的分区表中记录数，大致在8千万以上：
select count(*) from abc.test_SOURCE partition (test_SOURCE_P_20130806);

如果采用如下原始sql肯定是跑不动的。

select t.cuttime,t.ceventid,t.cstbid,t.csource from abc.test_source t
where t.cuttime>=to_date('2013/08/06 00:00:00','yyyy/mm/dd hh24:MI:ss')
and t.cuttimeand t.ceventid in (1,2,5,7,23,21,26);

我对以上sql进行了如下的改造后，查询结果可以出来了：
select count(*) from abc.test_source partition (VAV_SOURCE_P_20130806) t
where t.ceventid in (1,2,5,7,23,21,26);

在加上pl/sql dev的导出CSV功能，再次进行导出发现导出成功。在次过程也发现那些操作者对PLSQL Dev的csv文件导出功能也不熟，以为先将查询结果展现完毕才能完整导出为csv文件，实际上在PLSQL Dev上没有必要查询出结果集展现而直接选择导出CSV文件即可。

为此有了如下的体会：
选用scale out和scale up的IT架构和系统软件还不够，应用软件的设计也应该遵循此原则,还有团队...