ora-01652为什么未使用的行限制器可以解决这个问题?

sirbozc5  于 2021-08-09  发布在  Java
关注(0)|答案(1)|浏览(299)

如果我在没有行限制器的情况下运行查询,就会收到一个ora-01652,告诉我临时表空间不足(我不是dba&我承认我不完全理解这个错误。)如果我添加一个rownum<100000000,它将在几秒钟内运行(是的,它被限制为十亿行)。我的内部查询只返回大约1000行。一个永远达不到的大得离谱的行限制器如何运行这个查询?有限查询和无限查询应该没有区别,不是吗?

select
    col1,
    col2,
    ...
from
        (
            select
                col1, col2,...
            from table1 a
                join table2 b-- limiter for performance
                     on a.column= b.column
                     or a.col= b.col
            where
                filter = 'Y'
                and rownum <1000000000  -- irrelevant but query doesn't run without it.
    )  c
join table3 d
        on c.id  = d.id
rsl1atfo

rsl1atfo1#

我们需要查看带有和不带有rownum条件的查询的执行计划。但是作为一个例子,添加一个“rownum”可以改变一个执行计划

SQL> create table t as select * from dba_objects
  2  where object_id is not null;

Table created.

SQL>
SQL> create index ix on t ( object_id );

Index created.

SQL>
SQL> set autotrace traceonly explain
SQL> select * from t where object_id > 0 ;

Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      | 82262 |    10M|   445   (2)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    | 82262 |    10M|   445   (2)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("OBJECT_ID">0)

SQL> select * from t where object_id > 0  and rownum < 10;

Execution Plan
----------------------------------------------------------
Plan hash value: 658510075

---------------------------------------------------------------------------------------------
| Id  | Operation                            | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |      |     9 |  1188 |     3   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY                       |      |       |       |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| T    |     9 |  1188 |     3   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX   |       |       |     2   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

这是一个过于简单的示例,但是您可以通过join等获得类似的结果,特别是“rownum”子句可能禁止将最里面的join折叠到最外面的join中,从而产生不同的计划。

相关问题