Categorias
Picture of Roberto Sobrinho
Roberto Sobrinho

31/01/2025

Performance no Oracle: Quando e Como Usar LOGGING e NOLOGGING

No Oracle, LOGGING e NOLOGGING controlam como as alterações no banco são registradas nos redo logs, que são necessarias para recuperar dados em caso de falhas.

O modo LOGGING registra todas as alterações, garantindo que os dados possam ser restaurados. Já o modo NOLOGGING melhora a performance ao reduzir ou até eliminar a geração de redo logs em operações específicas, como cargas diretas de dados. Porém, dados inseridos com NOLOGGING não são protegidos por redo logs e não podem ser recuperadas em caso de falhas.

Se for necessário garantir que todas as operações gerem redo logs, mesmo que estejam configuradas como NOLOGGING, o recurso FORCE LOGGING pode ser habilitado. No nível do banco, ele força o registro no redo log, oferecendo maior segurança para ambientes críticos. Saiba mais sobre o FORCE LOGGING neste post do blog: Force Logging Oracle: como ativar e desativar.

Diferenças práticas entre logging e nologging

Por padrão, as tabelas seguem o comportamento da tablespace onde são criadas. Se nada for especificado, o modo LOGGING é ativado.

No modo NOLOGGING, a geração de redo diminui ou desaparece em operações específicas, como cargas diretas (direct path insert).

  • Inserções comuns (INSERT, sem APPEND), atualizações (UPDATE), exclusões (DELETE) e comandos como MERGE continuam gerando redo, mesmo em tabelas configuradas com NOLOGGING.
  • Apenas operações de carga direta, como INSERT /*+ APPEND */ ou /*+ APPEND VALUES */,, evitam a geração de redo, gravam os dados diretamente nos blocos.

O uso de NOLOGGING pode aumentar muito a performance, mas traz o risco de perda de dados, já que eles não serão recuperáveis por um RECOVER.. Para dados críticos, use LOGGING ou faça um backup imediatamente após a carga.

Preparação do ambiente

SQL> CREATE TABLESPACE TBS_TESTE_HR SIZE 1G AUTOEXTEND ON NEXT 250M;

Tablespace created.

SQL> CREATE TABLE HR.EMP AS  
  2  SELECT ROWNUM emp_id,  
  3         MOD(ROWNUM, 1000) dept_id,  
  4         'Employee ' || ROWNUM emp_name,  
  5         'Descrição para linha ' || ROWNUM description  
  6  FROM dual CONNECT BY ROWNUM <= 2000000;

Table created.

SQL> INSERT INTO HR.EMP  
  2  SELECT *  
  3  FROM HR.EMP;

2000000 rows created.

SQL> COMMIT;

Commit complete.

SQL> SELECT COUNT(1) TOTAL_LINHAS FROM HR.EMP;

TOTAL_LINHAS  
------------  
     4000000  
     
SQL> -- Criar tabela destino para os testes

SQL> CREATE TABLE HR.PEDIDOS  
  2  TABLESPACE TBS_TESTE_HR  
  3  AS  
  4  SELECT * FROM HR.EMP WHERE 1=0;

Table created.

SQL> SELECT owner, TABLE_NAME, LOGGING from dba_tables where TABLE_NAME = 'PEDIDOS' and owner = 'HR';

OWNER   TABLE_NAME           LOGGING
------- -------------------- ----------
HR      PEDIDOS              YES

SQL>

Como foram criadas as tabelas para os testes?

Tabela HR.EMP

  • Criada com 4 milhões de registros simulados.
  • Serve como base de dados para os testes de inserção.

Tabela HR.PEDIDOS

  • Criada sem dados, apenas com a estrutura da tabela HR.EMP.
  • Usada como destino das inserções nos testes.

O que é APPEND e como ele funciona com NOLOGGING?

O APPEND é uma hint que transforma o comando INSERT em uma carga direta de dados (direct path insert). Nesse tipo de operação, os dados são gravados diretamente nos blocos da tabela no disco.

Quando usado junto com o modo NOLOGGING, o APPEND não gera redo logs, o que otimiza ainda mais a operação. Essa combinação é especialmente útil para cargas de dados massivas, onde a prioridade é a performance.

O APPEND é ideal para inserções baseadas em consultas (INSERT INTO ... SELECT). Já o APPEND VALUES expande essa funcionalidade para operações onde se insere dados utilizando a clausula VALUES, (INSERT INTO ... VALUES). Ambos seguem a mesma lógica: gravar os dados diretamente nos blocos da tabela.

  • APPEND grava os dados diretamente no disco.
  • Com NOLOGGING, os redo logs não são gerados, economizando recursos e acelerando a operação.
  • Porém, sem redo logs, não há recuperação dos dados em caso de falhas.

Como os testes são realizados?

  • Antes de cada teste, verificamos o valor atual de redo logs com a visão V$SYSSTAT.
  • Fazemos as inserções na tabela HR.PEDIDOS em diferentes cenários (LOGGING e NOLOGGING, com ou sem APPEND).
  • Após cada teste, verificamos novamente o valor dos redo logs para calcular a quantidade gerada.
  • Ativamos o comando SET TIMING ON para medir o tempo de execução de cada operação.

Com isso, conseguimos comparar como cada cenário impacta na performance e na geração de redo logs.

Teste 1: LOGGING sem APPEND

SQL> ALTER TABLE HR.PEDIDOS NOLOGGING;

Table altered.

SQL> SELECT owner, TABLE_NAME, LOGGING from dba_tables where TABLE_NAME = 'PEDIDOS' and owner = 'HR';

OWNER   TABLE_NAME           LOGGING
------- -------------------- ----------
HR      PEDIDOS              YES

SQL> SELECT value AS redo_antes  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';

REDO_ANTES  
-----------  
1510561132  

SQL> SET TIMING ON  
SQL> INSERT INTO HR.PEDIDOS  
  2  SELECT emp_id, dept_id, emp_name,  
  3         'LOGGING sem APPEND' description  
  4  FROM HR.EMP;  

4000000 rows created. 

Elapsed: 00:00:08.22  

SQL> SET TIMING OFF  
SQL> SELECT value AS redo_depois  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_DEPOIS  
-----------  
1748028892  

SQL>

LOGGING sem APPEND: (1748028892 - 1510561132) = 237.467.760 bytes Redo

Teste 2: LOGGING com APPEND

SQL> ALTER TABLE HR.PEDIDOS NOLOGGING;

Table altered.

SQL> SELECT owner, TABLE_NAME, LOGGING from dba_tables where TABLE_NAME = 'PEDIDOS' and owner = 'HR';

OWNER   TABLE_NAME           LOGGING
------- -------------------- ----------
HR      PEDIDOS              YES

SQL> SELECT value redo_antes  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';

REDO_ANTES  
-----------  
1748028892  

SQL> SET TIMING ON;  
SQL> INSERT /*+ APPEND */ INTO HR.PEDIDOS  
  2  SELECT emp_id, dept_id, emp_name,  
  3         'LOGGING com APPEND' description  
  4  FROM HR.EMP;  

4000000 rows created. 

Elapsed: 00:00:05.50  

SQL> SET TIMING OFF  
SQL> SELECT value redo_depois  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_DEPOIS  
-----------  
1976176832  

SQL>

LOGGING com APPEND: (1976176832 - 1748028892) = 228.147.940 bytes Redo

Teste 3: NOLOGGING sem APPEND

SQL> ALTER TABLE HR.PEDIDOS NOLOGGING;

Table altered.

SQL> SELECT owner, TABLE_NAME, LOGGING from dba_tables where TABLE_NAME = 'PEDIDOS' and owner = 'HR';

OWNER   TABLE_NAME           LOGGING
------- -------------------- ----------
HR      PEDIDOS              NO

SQL> SELECT value redo_antes  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_ANTES  
-----------  
1976176832  

SQL> SET TIMING ON;  
SQL> INSERT INTO HR.PEDIDOS  
  2  SELECT emp_id, dept_id, emp_name,  
  3         'NOLOGGING sem APPEND' description  
  4  FROM HR.EMP;  

4000000 rows created.

Elapsed: 00:00:07.14  

SQL> SET TIMING OFF  
SQL> SELECT value redo_depois  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_DEPOIS  
-----------  
2222224840  

SQL>

NOLOGGING sem APPEND: (2222224840 - 1976217132) = 246.007.708 bytes Redo

Teste 4: NOLOGGING com APPEND

SQL> ALTER TABLE HR.PEDIDOS NOLOGGING;

Table altered.

SQL> SELECT owner, TABLE_NAME, LOGGING from dba_tables where TABLE_NAME = 'PEDIDOS' and owner = 'HR';

OWNER   TABLE_NAME           LOGGING
------- -------------------- ----------
HR      PEDIDOS              NO

SQL> SELECT value redo_antes  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_ANTES  
-----------  
2222224840  

SQL> SET TIMING ON  
SQL> INSERT /*+ APPEND */ INTO HR.PEDIDOS  
  2  SELECT emp_id, dept_id, emp_name,  
  3         'NOLOGGING com APPEND' description  
  4  FROM HR.EMP;  

4,000,000 rows created.  
Elapsed: 00:00:03.94  

SQL> SET TIMING OFF  
SQL> SELECT value redo_depois  
  2  FROM v$sysstat  
  3  WHERE name = 'redo size';  

REDO_DEPOIS  
-----------  
2222367760  

SQL>

NOLOGGING com APPEND: (2222367760 - 2222224840) = 142.920 bytes Redo

Tabela comparativa

Cenário
Redo Gerado (Bytes)Uso de Redo
(%)		Tempo
(s)		Uso de Tempo (%)
LOGGING sem APPEND237.467.760100%8.22100%
LOGGING com APPEND228.147.94096%5.5067%
NOLOGGING sem APPEND246.007.708104%7.1487%
NOLOGGING com APPEND142.9200.06%3.9448%

Dados inseridos com NOLOGGING APPEND não são protegidos por redo logs.
Se ocorrer uma falha ou houver necessidade de recuperação (recover), esses dados não poderão ser restaurados.

Para cargas de dados críticas, a recomendação é utilizar LOGGING ou realizar um backup completo imediatamente após a carga.

e … zas

Remover Objetos Criados

SQL> DROP TABLE HR.PEDIDOS PURGE;

Table dropped.

SQL> DROP TABLE HR.EMP PURGE;

Table dropped.

SQL> DROP TABLESPACE TBS_TESTE_HR INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

SQL>

🐤🐣#20250131 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #OracleACE  🐤🐣

Compartilhe

Facebook
Twitter
LinkedIn
WhatsApp
Email
Print

Pesquisar

Roberto Sobrinho

Sou Roberto Fernandes Sobrinho, também conhecido como Sobrinho DBA , pós graduado em “Architecture and Database Administration”, entusiasta, dedicado e com 20 anos de experiência com Oracle Database e suas diversas distribuições e variações.

Oracle ACE Associate

2025

Specialist

Exadata Database Machine X9M

Professional

Oracle Database Administration

Professional

Oracle Database 19c: RAC, ASM, & Grid Infra Administrator

Professional

Oracle Autonomous Database Cloud

Professional

Oracle Cloud Database Migration and Integration

Professional

Oracle Database PL/SQL Developer

Associate

Oracle Cloud Infrastructure Architect

Associate

Oracle Cloud Infrastructure Foundations

Categorias

Categorias

Tags

Tags
23ai ativar Auditing auditoria backup cdb crontab dba desativar dml ErroORA error erro_patch fbi find force logging; append full table scan index inserir rapido lentidão linux locate log ojvm OPW ORA ORA-01017 oracle orapwd patch pdb pl/sql RAC RAC 19c recuperação rman senha shell source sql SYSDBA tuning Unified Auditing user view

HugePages no Oracle: Configuração Passo a Passo no Red Hat 9.5

Oracle Unified Auditing: habilitar auditoria de logins malsucedidos e DDL passo a passo

Script para identificar discos ASM, ASMLIB e SO rapidamente

Performance no Oracle: Quando e Como Usar LOGGING e NOLOGGING

Performance no Oracle: Quando e Como Usar LOGGING e NOLOGGING

11 97160-0775
contato@dbasobrinho.com.br
LinkedIn
Política de Privacidade
Termos de Uso

Desenvolvido por: Hallan Design

Todos os direitos reservados © 2025 Roberto Sobrinho