• “在数据库级别没有利用率”* -这是您问题中的关键信息。这意味着您几乎所有的时间都花在网络上或处理传入数据的客户端机器上（例如：可能将其写入文件或它所做的任何其他操作）。这使得这不是一个数据库问题。没有查询调优可以提供帮助，因为查询本身提供数据的速度与您使用数据的速度一样快。问题是你不能很快地使用它，但这不是数据库的错。事实上，这是Exadata，并有一堆CPU并没有帮助你在这种情况下-没有字面上的所有权力做什么。在只有一个或两个CPU可用的非Exadata中进行串行直接路径全表扫描同样快。出于这个原因，不要试图要求并行来解决这个问题，它不会有帮助。当你有一些查询复杂性时，过滤器 predicate 、连接、排序、有限的列列表，几乎任何超过select * from table的东西，都是有用的。

这里有一些东西要检查。
1.请确保您的提取大小至少在数千。1或10或100的提取大小可能会导致太多的网络往返，如果延迟在几十毫秒或更高，这可能会使提取数百万行非常低效。将获取大小增加到适当的大小。检查你的网络延迟（使用ping），以确保它是合理的。您可以通过在共享池（v$sql）中找到您的SQL并将rows_processed除以fetches来确定获取大小。
1.你的行列非常宽。如果每行有数千个字节，那么通过网络获取900万行并写入磁盘所需的工作量要比每条只有几十个字节的900万行多得多。考虑省略可能不需要的过大列。
1.您的应用程序处理行的速度很慢。它在分类吗？在那几排上转来转去做些什么？调整应用程序。
1.应用程序向文件写入行的速度很慢。您正在写入的文件系统可能很慢（例如，NFS到某个远程网络）。请您的操作系统管理员或存储团队查看此信息。如果写入过程受I/O限制（不受CPU限制），请考虑内联压缩，以便写入磁盘的字节更少。
最后，当您查看了所有这些选项后，仍然需要拉取以更快地进行，您可能需要建立多个并发连接，每个连接都拉取表的一部分。例如，如果有10个进程选择select * from table where MOD(pkcol,10)=:thread-1，并且它们绑定了各自的线程号，那么它们将各自提取表的1/10。虽然这意味着数据库端的工作量增加了10倍，但它将克服网络、应用程序处理行的限制，并在一定程度上帮助通过使用多个CPU写入文件。如果这有帮助，但您的DBA抱怨负载（这 * 可能 * 导致Example存储单元上的CPU过多，因此不应过度使用），那么请考虑对表进行分区，并让各个并发进程拉取各个分区。这将把存储单元上的负载降低到可接受的水平。