Ativar FORCE LOGGING
SQL> ALTER DATABASE FORCE LOGGING;
Database altered.
SQL> SELECT FORCE_LOGGING FROM V$DATABASE;
FORCE_LOGGING
-------------
YES
SQL>Desativar FORCE LOGGING
SQL> ALTER DATABASE NO FORCE LOGGING;
Database altered.
SQL> SELECT FORCE_LOGGING FROM V$DATABASE;
FORCE_LOGGING
-------------
NO
SQL>Ativado (YES): Todas as operações, incluindo transações em direct path (INSERT /*+ APPEND */ ou INSERT /*+ APPEND VALUES */
Desativado (NO): Permite o uso de operações NOLOGGING em direct path, otimizando a performance por evitar geração de redo log, mas aumenta os riscos de perda de dados em caso de recovery.
Em ambientes configurados com DataGuard, é altamente recomendado que o FORCE LOGGING esteja ativo. Caso contrário, transações realizadas em objetos configurados como NOLOGGING, como operações INSERT /*+ APPEND */ ou INSERT /*+ APPEND VALUES */, não serão replicadas para o standby database.
Essas operações utilizam direct path, que evita a geração de redo log para melhorar a performance. Em um ambiente DataGuard, o standby depende dos redo logs para aplicar as mudanças. Sem esses logs, os dados inseridos não estarão disponíveis no banco de standby, resultando em inconsistência entre o primário e o standby.
Como continuação desse assunto, em breve publicarei as diferenças entre as combinações de LOGGING e NOLOGGING com e sem o uso do APPEND.
- LOGGING sem APPEND
- LOGGING com APPEND
- NOLOGGING sem APPEND
- NOLOGGING com APPEND
Explicarei como cada uma dessas configurações impacta o comportamento de geração de redo log, performance e integridade dos dados, além de apresentar exemplos práticos.
e zás . . .
🦒🌻 #20250123 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #OracleACE 🦒🌻
