LOGGING/NOLOGGING ajuda a gerenciar a habilitação de gravações de caminho direto para reduzir a geração de REDO e UNDO. É uma das várias maneiras de controlar o delicado equilíbrio entre recuperabilidade e desempenho.
Informações básicas da arquitetura Oracle
REFAZER é como a Oracle oferece durabilidade, o "D" em ACID. Quando uma transação é confirmada, as alterações não são necessariamente armazenadas ordenadamente nos arquivos de dados. Isso mantém as coisas rápidas e permite que os processos em segundo plano lidem com algum trabalho. REDO é uma descrição da mudança. Ele é armazenado rapidamente, em vários discos, em um log "burro". As alterações são rápidas e se o servidor perder energia um microssegundo após o retorno do commit, o Oracle pode passar pelos logs REDO para garantir que a alteração não seja perdida.
DESFAZER ajuda a Oracle a fornecer consistência, o "C" em ACID. Ele armazena uma descrição de como reverter a alteração. Essa informação pode ser necessária para outro processo que está lendo a tabela e precisa saber qual o valor usado estar em um momento mais antigo.
Gravações de caminho direto ignore REDO, UNDO, o cache e alguns outros recursos e modifique diretamente os arquivos de dados. Esta é uma opção rápida, mas potencialmente perigosa em muitos ambientes, e é por isso que existem tantas opções confusas para controlá-la. As gravações de caminho direto se aplicam apenas a INSERTS e somente nos cenários descritos abaixo.
Se você não fizer nada, a opção padrão é a mais segura, LOGGING.
As várias maneiras de controlar gravações de caminho direto
LOGGING/NOLOGGING é uma das várias opções para controlar gravações de caminho direto. Veja esta tabela de Pergunte ao Tom para entender como as diferentes opções funcionam juntas:
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING pode substituir todas essas configurações. Provavelmente existem alguns outros switches que eu não conheço. E, claro, existem muitas limitações que impedem o caminho direto - gatilhos, chaves estrangeiras, cluster, tabelas organizadas por índice, etc.
As regras são ainda mais restritivas para índices. Um índice sempre gerar REDO durante instruções DML. Apenas instruções DDL, como
CREATE INDEX ... NOLOGGING ou ALTER INDEX ... REBUILD em um índice NOLOGGING não gerará REDO. Por que existem tantas maneiras? Porque a capacidade de recuperação é incrivelmente importante e diferentes funções podem ter visões diferentes sobre o assunto. E às vezes as decisões de algumas pessoas precisam se sobrepor a outras.
Desenvolvedores decida no nível da instrução, "Modo de inserção". Muitas coisas estranhas podem acontecer com um
/*+ APPEND */ dica e os desenvolvedores precisam escolher cuidadosamente quando usá-lo. Arquitetos decidir no nível do objeto, "Modo Tabela". Algumas tabelas, independentemente de quão rápido um desenvolvedor queira inserir nelas, devem sempre ser recuperáveis.
Administradores de banco de dados decidir no modo de banco de dados ou tablespace, "Archive log" e FORCE LOGGING. Talvez a organização simplesmente não se importe em recuperar um banco de dados específico, então configure-o para o modo NOARCHIVELOG. Ou talvez a organização tenha uma regra estrita de que tudo deve ser recuperável, então defina o espaço de tabela para FORCE LOGGING.
