Na versão 11g do Oracle, a Oracle introduziu uma nova técnica de otimização para melhorar o desempenho das operações DDL. Este novo recurso permite um tempo de execução extremamente rápido ao adicionar um NOT NULL coluna com valor padrão para uma tabela existente. Desde a versão 12c, a otimização DDL foi estendida para incluir NULL colunas com valor padrão.
Considere a seguinte tabela de teste com 1.000.000 linhas:
sql> create table xxy
as select rownum a from dual connect by level <= 1e6
;
sql> select /*+ gather_plan_statistics */ count(1) from xxy;
sql> select * from table(dbms_xplan.display_cursor);
Agora vamos adicionar uma coluna extra não nula com um valor padrão em sessões diferentes para 11g e 12c:
11g> alter table xxy add b number default 1;
--Table XXY altered. Elapsed: 00:01:00.998
12c> alter table xxy add b number default 1;
--Table XXY altered. Elapsed: 00:00:00.052
Observe a diferença no tempo de execução:1M de linhas atualizadas em 5 ms!?
O plano de execução mostra:
11g> select count(1) from xxy where b = 1;
COUNT(1)
----------
1000000
11g> select * from table(dbms_xplan.display_cursor);
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 1040 (100)| |
| 1 | SORT AGGREGATE | | 1 | 13 | | |
|* 2 | TABLE ACCESS FULL| XXY | 898K| 11M| 1040 (1)| 00:00:13 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("B"=1)
Note
-----
- dynamic sampling used for this statement (level=2)
12c> select count(1) from xxy where b = 1;
12c> select * from table(dbms_xplan.display_cursor);
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 429 (100)| |
| 1 | SORT AGGREGATE | | 1 | 5 | | |
|* 2 | TABLE ACCESS FULL| XXY | 1000K| 4882K| 429 (2)| 00:00:01 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(DECODE(TO_CHAR(SYS_OP_VECBIT("SYS_NC00002$",0)),NULL,NVL("
B",1),'0',NVL("B",1),'1',"B")=1)
Note
-----
- statistics feedback used for this statement
O plano de execução em 12c mostra em contraste com 11g uma parte de predicado complexa envolvendo uma nova coluna interna
SYS_NC00006$ . Esse predicado indica que, internamente, a Oracle ainda está considerando a coluna B como potencialmente capaz de conter valores não padrão. Isso significa - o Oracle inicialmente não atualiza fisicamente cada linha com o valor padrão.
Por que uma nova coluna interna
SYS_NC00006$ é criado? 12c> select column_name, virtual_column, hidden_column, user_generated
from user_tab_cols
where table_name = 'XXY'
;
COLUMN_NAME VIR HID USE
---------------- --- --- ---
B NO NO YES
SYS_NC00002$ NO YES NO
A NO NO YES
12c> select a, b, SYS_NC00002$ hid from xxy where a in (1,10);
A B HID
---------- ---------- ----------------
1 1
10 1
12c> update xxy set b=1 where a=10 and b=1;
1 row updated.
12c> select a, b, SYS_NC00002$ hid from xxy where a in (1,10);
A B HID
---------- ---------- ----------------
1 1
10 1 01
Observe a diferença nos valores de B e das colunas internas relacionadas. A Oracle está simplesmente verificando através de sua coluna interna gerada pelo sistema (por exemplo,
SYS_NC00006$ ) e através do SYS_OP_VECBIT função se deve considerar o valor padrão da coluna B ou o valor real modificado por meio de uma instrução DML explícita. O que há com duas instruções alter separadas?
12c> alter table xxy add (b integer);
12c> alter table xxy modify b default 1;
12c> select count(b), count(coalesce(b,0)) nulls from xxy where b = 1 or b is null;
COUNT(B) NULLS
---------- ----------
0 1000000
O valor da nova coluna permanece NULL para todas as linhas. Nenhuma atualização real é necessária, portanto, a instrução DDL não será otimizada.
Aqui é um artigo da OTN que explica a nova otimização DDL com mais detalhes.
