增幅列在甲骨文

大小的影响，我有一个剧本增幅列在甲骨文

SQL script: alter table xx_vms.es_lot_updates modify (routing_list varchar2(1000));

本专栏以前的大小为255。现在我常常会增加它的大小为1000 但在该表中，列routing_list一片空白。偶尔它有价值。

此列的增量大小是否会造成性能问题？我很困惑！请帮忙。谢谢。

来源

2013-05-15 duykaka

不，没有性能问题。您所做的只是允许在该列中插入更大的文本字符串。请记住，您应始终尽可能严格地对待表格中允许的内容，您可以根据需要随意制作列。（varchar2的最大4000字节）

来源

2013-05-15 09:35:33 winkbrace

这是一个好消息。谢谢。 – duykaka

这取决于。带有varchar2（1000）的表格使用更多的数据库块进行存储，因此，当您要读取更多的块时，全表扫描可能会更加昂贵。这里有一个简单的测试：

17:48:25 [email protected]> create table c1000 (txt varchar2(1000)); 

Table created. 

Elapsed: 00:00:00.21 
17:48:37 [email protected]> create table c255 (txt varchar2(255)); 

Table created. 

Elapsed: 00:00:00.03 

-- for this test we assume that only 10% of columns are filled with data 
17:50:21 [email protected]> ed 
Wrote file S:\spool\sandbox\BUFFER_HR_32.sql 

    1 insert into c255 
    2 select decode(mod(rownum,10), 0, lpad('x', 255,'x')) from dual 
    3* connect by rownum <= 1e5 
17:50:24 [email protected]>/

100000 rows created. 

Elapsed: 00:00:01.26 
17:50:47 [email protected]> ed 
Wrote file S:\spool\sandbox\BUFFER_HR_32.sql 

    1 insert into c1000 
    2 select decode(mod(rownum,10), 0, lpad('x', 1000,'x')) from dual 
    3* connect by rownum <= 1e5 
17:50:51 [email protected]>/

100000 rows created. 

Elapsed: 00:00:01.45 
17:50:52 [email protected]> commit; 

Commit complete. 

Elapsed: 00:00:00.01 
17:51:20 [email protected]> select table_name, blocks from user_tables where table_name in ('C255', 'C1000'); 

TABLE_NAME       BLOCKS 
------------------------------ ---------- 
C1000        1756 
C255         622 

Elapsed: 00:00:00.20 
17:53:28 [email protected]> set autotrace traceonly statistics 
17:53:37 [email protected]> select * from c1000; 

100000 rows selected. 

Elapsed: 00:00:01.30 

Statistics 
---------------------------------------------------------- 
      1 recursive calls 
      0 db block gets 
     1901 consistent gets 
     1694 physical reads 
      0 redo size 
    10586458 bytes sent via SQL*Net to client 
     2552 bytes received via SQL*Net from client 
     201 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    100000 rows processed 

17:53:50 [email protected]> select * from c255; 

100000 rows selected. 

Elapsed: 00:00:00.63 

Statistics 
---------------------------------------------------------- 
      1 recursive calls 
      0 db block gets 
     825 consistent gets 
     295 physical reads 
      0 redo size 
    3107206 bytes sent via SQL*Net to client 
     2552 bytes received via SQL*Net from client 
     201 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
    100000 rows processed

看看consistent gets统计。与完整扫描c255相比，完全扫描c1000可以实现两倍的IO。

但是，如果您使用主键仅选择几行，我认为您不会注意到显着差异。

来源

2013-05-15 10:04:31

你正在证明的是，更大的表需要更长的时间从磁盘读取比较小的一个:)在OP的情况下，他只增加了容量，所以他不会看到你演示的效果。 – Ronnis

@罗尼斯他有理由提高能力，不是吗？我猜想他会在那里储存更多的数据 –

也许。我的观点是：在VARCHAR2的情况下，增加*容量和*利用*容量之间存在差异。他在询问“这个专栏的增量大小是否会造成绩效问题”，而不是。但是利用这种能力会是这样，这就是你的测试案例所展示的。我只是想帮你写一个更细致的答案。 – Ronnis

不，它已经没有太多做的性能，VARCHAR2最大尺寸为4000

一旦你改变表做remeber编译所有的依赖，因为他们将是无效的，例如

程序和包

来源

2013-05-15 10:15:22 abhi

增幅列在甲骨文

回答

相关问题