oracle嵌套表中的最大行数是多少

时间:2014-06-12 18:16:03

标签: sql database oracle oracle12c nested-table

CREATE TYPE nums_list AS TABLE OF NUMBER;

oracle的嵌套表中可能的最大行数是多少?

更新

CREATE TYPE nums_list  AS TABLE OF NUMBER;

CREATE OR REPLACE  FUNCTION  generate_series(from_n NUMBER, to_n NUMBER)
RETURN nums_list AS
ret_table nums_list := nums_list();
BEGIN

  FOR i IN from_n..to_n LOOP
    ret_table.EXTEND;
    ret_table(i) := i;
  END LOOP;
  RETURN ret_table;

END;


SELECT count(*)   FROM TABLE ( generate_series(1,4555555) );

这会出错:ORA-22813 operand value exceeds system limits, Object or Collection value was too large

2 个答案:

答案 0 :(得分:6)

range of subscripts for a nested table is 1..2**31所以你可以在集合中拥有2 ** 31个元素。该限制自至少8.1.6以来没有变化,但当然,它可能在未来发生变化。

答案 1 :(得分:3)

正如另外一个观察,嵌套表本身不是太大或使用太多内存。使用异常处理程序,您可以看到函数未抛出错误。您可以在匿名块中填充相同的内容:

DECLARE
  ret_table nums_list := nums_list();
BEGIN
  FOR i IN 1..4555555 LOOP
    ret_table.EXTEND;
    ret_table(i) := i;
  END LOOP;
  dbms_output.put_line(ret_table.count);
END;
/

anonymous block completed
4555555

你也可以从一个区块调用你的函数:

DECLARE
  ret_table nums_list;
BEGIN
  ret_table := generate_series(1,4555555);
  dbms_output.put_line(ret_table.count);
END;
/

anonymous block completed
4555555

只有在您将其用作表集合表达式时才会出现错误:

SQL Error: ORA-22813: operand value exceeds system limits
22813. 00000 -  "operand value exceeds system limits"
*Cause:    Object or Collection value was too large. The size of the value
           might have exceeded 30k in a SORT context, or the size might be
           too big for available memory.
*Action:   Choose another value and retry the operation.

原因文本是指SORT上下文,您的查询正在进行排序:

------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                 |     1 |     2 |    29   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                    |                 |     1 |     2 |            |          |
|   2 |   COLLECTION ITERATOR PICKLER FETCH| GENERATE_SERIES |  8168 | 16336 |    29   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

正如@a_horse_with_no_name建议的那样,你可以通过使你的函数流水线来避免这个问题:

CREATE OR REPLACE  FUNCTION  generate_series(from_n NUMBER, to_n NUMBER)
RETURN nums_list PIPELINED AS
BEGIN

  FOR i IN from_n..to_n LOOP
    PIPE ROW (i);
  END LOOP;
  RETURN;

END;
/

SELECT count(*)   FROM TABLE ( generate_series(1,4555555) );

  COUNT(*)
----------
   4555555 

那仍然是SORT AGGREGATE,但它似乎不再介意了。在这两种情况下都不确定为什么会这样做;也许其他人将能够解释它在做什么。 (顺便说一句,我在11gR2实例中这样做;我没有12c实例验证行为是否相同,但你的症状表明它会是这样)。或者也许它不是SORT上下文的问题,也许它是可用的内存。在我的环境中,您的版本似乎始终可以使用多达4177918个元素 - 这些元素似乎不是很重要,因此可能与环境有关吗?

但这取决于你打算如何使用该系列;从PL / SQL上下文中,您的原始版本可能更合适。