Início / dba / Perguntas / 250059
Accepted
Max
Asked: 2019-10-03 00:28:50 +0800 CST

Qual é o propósito da cláusula NOLOGGING no banco de dados Oracle TABLES and INDEXES

  • 772

Eu estava vagando qual é o propósito prático de usar a cláusula NOLOGGING em tabelas e índices.

Pelo que sei da documentação do Oracle, podemos impedir que o banco de dados gere logs de redo somente ao INSERIR no modo de caminho direto. Não há possibilidade de evitar a geração de redo log ao UPDATING ou DELETING.

Então, geralmente escrevemos

INSERT /*+ APPEND NOLOGGING */ INTO TABLE ... ;
commit;

para evitar a geração de redo log.

Eu totalmente não entendo qual é a vantagem prática de usar a cláusula NOLOGGING na criação de TABLE ou INDEX nem usar a cláusula NOLOGGING na criação de TABLESPACES para definir o padrão nos objetos que serão criados nesse tablespace.

Alguém pode descrever um cenário prático onde definir esta cláusula em objetos de banco de dados pode dar vantagens?

oracle transaction-log

2 respostas

  1. Best Answer

    Não existe tal dica como NOLOGGING.

    Claro, UPDATEe DELETEas operações não podem tirar proveito de NOLOGGING, mas existem outras operações que podem:

    logging_clause

    O NOLOGGING é suportado apenas em um subconjunto dos locais que suportam o LOGGING. Apenas as seguintes operações suportam o modo NOLOGGING:

    DML:

    INSERT de caminho direto (serial ou paralelo) resultante de uma instrução INSERT ou MERGE. NOLOGGING não é aplicável a nenhuma operação UPDATE resultante da instrução MERGE.

    Carregador direto (SQL*Loader)

    DDL:

    CREATE TABLE ... AS SELECT (No modo NOLOGGING, a criação da tabela será registrada, mas as inserções de caminho direto não serão registradas.)

    CREATE TABLE ... LOB_storage_clause ... LOB_parameters ... CACHE | NOCACHE | LEITURAS DE CACHE

    ALTER TABLE ... LOB_storage_clause ... LOB_parameters ... CACHE | NOCACHE | CACHE READS (para especificar o registro de colunas LOB recém-criadas)

    ALTER TABLE ... modifique_LOB_storage_clause ... modifique_LOB_parameters ... CACHE | NOCACHE | CACHE READS (para alterar o registro de colunas LOB existentes)

    ALTER TABLE ... MOVER

    ALTER TABLE ... (todas as operações de partição que envolvem movimentação de dados)

    ALTER TABLE ... ADD PARTITION (somente partição hash)

    ALTER TABLE ... MERGE PARTITIONS

    ALTER TABLE ... SPLIT PARTITION

    ALTER TABLE ... MOVER PARTIÇÃO

    ALTER TABLE ... MODIFICAR PARTIÇÃO ... ADICIONAR SUBPARTIÇÃO

    ALTER TABLE ... MODIFICAR PARTIÇÃO ... COALESCE SUBPARTITION

    CRIAR ÍNDICE

    ALTER INDEX ... RECONSTRUIR

    ALTER INDEX ... RECONSTRUIR [SUB]PARTIÇÃO

    ALTER INDEX ... SPLIT PARTITION

    • 2

  2. O mecanismo NOLOGGING, como você apontou, é evitar a geração de informações de redo logging, e isso pode tornar o carregamento em massa mais rápido.

    Eu o uso normalmente para grandes trabalhos de carregamento. Por exemplo, carregar terabytes de imagens de satélite: significa que vou gravar TB de bits no banco de dados propriamente dito (os arquivos de dados), mas também gravarei terabytes nos logs de redo. Isso significa E/S adicionais nos logs, bem como muito espaço em disco para os logs de arquivo.

    Ao desabilitar o log durante essa carga, evito essas E/Ss e espaço extras.

    Claro, isso significa que, se eu tiver uma perda total de mídia (= uma unidade de disco falha irremediavelmente), não consigo recuperar: posso recuperar a mídia de um backup, mas não consigo avançar a falha carregar. Tudo bem: é mais rápido reiniciar o carregamento a partir do último ponto de confirmação do que fazer o banco de dados percorrer TB e TB de logs.

    Então, essencialmente, nologging faz sentido se:

    1. Você sabe com certeza que isso vai acelerar a carga.
    2. Você pode reiniciar/continuar facilmente a partir de qualquer falha (como: basta refazer o CREATE TABLE AS SELECTouINSERT SELECT
    • 1

relate perguntas