Início / dba / Perguntas / 206514
Accepted
Jeff Bauersfeld
Asked: 2018-05-12 09:58:35 +0800 CST

Oracle 11g Fast Add Column demorando 11 horas

  • 772

Pelo que entendi, um novo recurso do Oracle 11g é a capacidade de adicionar uma coluna não nula com um valor padrão muito rapidamente, pois não atualizaria mais automaticamente todas as linhas da tabela com o valor padrão na nova coluna. No entanto, o comando a seguir leva aproximadamente 11 horas em uma tabela com aproximadamente 1,2 bilhão de linhas em um banco de dados 11.2.0.4 que acabou de ser atualizado de 10.2.0.5:

alter table table_name add column_name varchar2(6) default "DEFLT' not null;

Embora eu tenha visto o seguinte na documentação:

"No entanto, o comportamento otimizado está sujeito às seguintes restrições: • A tabela não pode ter nenhuma coluna LOB. Ela não pode ser organizada por índice, temporária ou parte de um cluster. Também não pode ser uma tabela de filas, uma tabela de objetos ou a tabela de contêiner de uma exibição materializada. •A coluna que está sendo adicionada não pode ser criptografada e não pode ser uma coluna de objeto, coluna de tabela aninhada ou uma coluna LOB."

Até onde sei, minha mesa não atende a nenhuma dessas condições. Descrever não mostra LOBs, ORGANIZATION INDEX não está na instrução create, não é uma tabela temporária, não é um cluster, fila, objeto ou tabela de contêiner. E a coluna, claro, é uma coluna varchar. Está faltando alguma coisa ou a resposta é apenas que estou enganado sobre minha mesa atender a um desses requisitos?

ETA: Não tenho certeza se isso é útil, mas notei em um artigo que o sinal de aviso de adição de coluna rápida é o uso de NVL no predicado de filtro. De um plano de explicação em uma tabela de teste, não parece que meu banco de dados esteja executando adições rápidas:

SQL_ID  f78gwf6cz50uq, child number 0
-------------------------------------
select count(1) from t where z = 123456

Plan hash value: 1842905362

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |       |       |   133 (100)|          |
|   1 |  SORT AGGREGATE    |      |     1 |    13 |            |          |
|*  2 |   TABLE ACCESS FULL| T    |   110K|  1406K|   133   (4)| 00:00:02 |
---------------------------------------------------------------------------

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

   2 - filter("Z"=123456)

Note
-----
   - dynamic sampling used for this statement (level=2)
oracle oracle-11g-r2

1 respostas

  1. Best Answer

    Ok, sacrifiquei um dos meus bancos de dados sandbox 10.2 por uma boa causa e o atualizei para 11.2.

    Como eu suspeitava, a otimização DDL acima não funciona com o parâmetro compatível ainda definido como '10.2.*'.

    Depois de aumentar o parâmetro compatível, funciona como pretendido:

    SQL> show parameter compa

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cell_offload_compaction              string      ADAPTIVE
compatible                           string      10.2.0.5.0
plsql_v2_compatibility               boolean     FALSE

SQL> alter table t1 add C_DDL number default 42 not null;

Table altered.

Elapsed: 00:00:52.85
SQL> alter system set compatible='11.2.0.0.0' scope=spfile;

System altered.

Elapsed: 00:00:00.00

SQL> shu immediate
startup
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> ORACLE instance started.

Total System Global Area 1068937216 bytes
Fixed Size                  2260088 bytes
Variable Size             289407880 bytes
Database Buffers          771751936 bytes
Redo Buffers                5517312 bytes
Database mounted.
Database opened.

SQL> alter table t1 add D_DDL number default 42 not null;

Table altered.

Elapsed: 00:00:00.04
    • 3

relate perguntas