Principais Processos em Background do Banco de Dados Oracle [Artigo]
Saiba quais são os principais processos em background e suas responsabilidades.
[ Hits: 1.585 ]
Por: Carolina Robles das Neves em 20/10/2020 | Blog: https://www.linkedin.com/in/carolina-robles-das-neves-933289100/
Os principais processos em background de um banco de dados Oracle, são: PMON, SMON, DBWR, LGWR, RECO, CKPT e o ARCH.
Um processo pode ser conhecido como um "programa" que trabalha em memória (em background) e executa outras tarefas específicas para o ORACLE.
É uma forma de controle no sistema operacional que executa uma série de passos e possui sua área particular de memória. No sistema operacional Linux, chamamos no termo job ou tasks.
Existem dois tipos gerais de processos:
Processos dos usuários;
Processos do próprio ORACLE.
Um processo de usuário é criado e mantido para executar o código da aplicação ou uma ferramenta ORACLE (por exemplo, o SQL*Plus). Os processos dos usuários também gerenciam a comunicação com os processos do servidor ORACLE através do program interface.
O que é um Program Interface
O Program Interface é o mecanismo pelo qual um processo do usuário se comunica com o processo servidor. Serve como um método de comunicação padrão entre o cliente de uma aplicação ou uma ferramenta e o próprio servidor ORACLE.
Se o usuário e os processos servidores estão em diferentes computadores de uma rede, ou se o processo dispatcher estiver sendo usado para conectar processos de usuários e processos do servidor, então o program interface incluindo um software de comunicação chamado SQL*Net, que faz a comunicação (tradução) e a transferência de dados entre os computadores.
O ORACLE cria um conjunto de processos que rodam em background para cada instância, esses processos executam diversas tarefas.
O Database Writer (DBWR) grava os blocos de dados novos ou modificados (conhecidos como "dirty block", ou blocos sujos) existentes no database buffer cache para os datafiles. O DBWR não precisa escrever os dados a cada comando COMMIT, pois é otimizado para minimizar o I/O.
Ele usa o algoritmo LRU (Least Recently Used), escrevendo primeiro os blocos mais antigos e menos ativos. É possível inicializar até 20 processos DBWn, do DBW0 ao DBW9 e do DBWa ao DBWj.
O processo Log Writer (LGWR) escreve todas as entradas de redo log para o disco. Os dados de redo log são armazenados em memória no redo log buffer cache, na SGA. No momento em que uma transação for efetivada com o comando COMMIT e o redo log buffer estiver completo, ou preenchido, o LGWR escreve as entradas de redo log nos arquivos redo log apropriados.
Em tempos em tempos, todos os dados do database buffer cache modificados são escritos em disco pelo processo DBWR - Este evento é chamado de checkpoint.
O Log Writer é responsável pelo gerenciamento do redo log buffer, e é um dos processos mais ativos de uma instância, com intensa atividade de DML. Uma transação não é considerada concluída até que o LGWR grave com êxito as informações de redo, incluindo o registro de commit, nos redo log files.
Os dirty blocks do buffer cache não podem ser gravados nos datafiles pelo DBWn antes que o LGWR grave as informações de redo. Se os arquivos de redo log estiverem agrupados, e um dos arquivos de redo log multiplexados em um grupo for danificado, o LGWR gravará nos membros restantes do grupo e registrará um erro no arquivo de log de alerta. Se todos os membros de um grupo estiverem inutilizados, o processo LGWR falhará e a instância inteira ficará travada até que o problema seja corrigido.
O checkpoint informa ao processo DBWR o momento de gravar os dados em disco. O DBWR também atualiza os arquivos de controle (control File) do banco de dados para indicar o mais recente checkpoint. O processo CKPT é opcional; se ele não estiver presente, o LGWR assume sua responsabilidade.
O processo de checkpoint do Oracle faz com que os dirty buffers que ainda estão em cache sejam escritos em disco (datafiles). Também é executado um checkpoint para reduzir o tempo de um recovery.
Quando o checkpoint acontece? Acontece quando temos um shutdown consistente na instância (não abort), forçando via ALTER SYSTEM CHECKPOINT, no redo log switch e também no ALTER DATABASE BEGIN BACKUP.
Esses eventos acima forçam um database checkpoint, quando TODOS os dirty buffers serão escritos em disco. Mas existe o checkpoint que não escreve todos os buffers, mas apenas alguns.
Uma observação a se fazer é no log switch. Existe uma diferença de ambientes single instance e RAC. Em ambientes RAC, no log switch de uma instância, irá ocorrer um thread checkpoint, onde irá escrever os dirty buffers daquela thread específica. Então, quando acontece um thread checkpoint em todas as instâncias, na verdade aconteceu um database checkpoint.
Existe, então, o tablespace e data files checkpoints, quando é escrito os dirty buffers específicos de um data file ou um tablespace inteiro. Isso pode acontecer em algumas situações, como quando o tablespace é configurado como read-only, offline, shirink de tabelas etc.
Pra finalizar, existe também o incremental checkpoints. Esse tipo de checkpoint, ocorre para evitar escrever um grande número de blocos no swith do redo log. O DBW verifica a cada 3 segundos se tem algo para fazer. Quando o DBW escreve esses dirty buffers, ele avança o checkpoint position, fazendo com que o processo CKPT escreva a posição do checkpoint no control file, mas não nos data file headers.
Claro, essas não são todas as situações, mas são as que acontece com mais frequência. É bom entender esse processo, para entender o que acontece em um Instance Recovery, que é quando a instância não teve um shutdown consistente (abort, falta de energia etc).
Em uma falha da instância, não haverá um checkpoint para escrever os dirty buffers em disco. Logo, a instância estará em um estado inconsistente, com dados não commitados em data files e dados commitados que ainda não foram escritos nos respectivos data files.
O Instance Recovery é automático. Ele ocorre ao tentar abrir um banco que teve um shutdown inconsistente. Resumindo, esse processo utiliza o conteúdo do redo log, para criar novamente o buffer e o undo, tanto de transações com commit como as sem commit. Reconstruindo as alterações feitas após o checkpoint mais recente.
Como o Oracle sabe que uma instância precisa de um Recovery? Fácil! No redo existe uma flag, marcando se aquele redo thread esta aberto ou não. Ele marca como aberto quando a instância é aberta como read/write e marcado como fechado quando fazemos um shutdown corretamente. Caso ele tente abrir o banco e o redo thread já esteja marcado como open, então a instância precisa de um recovery. Quem faz esse processo é SMON process.
Quando ocorre um Log Switch. Um Log Switch (troca de log) acontece quando o Oracle troca de um redo log para outro. Enquanto isso, o servidor permanece gravando novas transações em outro grupo de log;
Durante um intervalo de tempo (definido no parâmetro LOG_CHECKPOINT_TIMEOUT do arquivo de parâmetros);
Quando acontece um shutdown;
O DBA força um checkpoint;
Quando a Tablespace é passada para Offline.
System Monitor - SMON
O processo SMON deverá sempre ser mantido em execução para uma instância, caso contrário, a instância será encerrada. Quando for necessária a recuperação de uma instância, o Oracle realizará as seguintes etapas através do SMON:
Executar rollforward para recuperar os dados que não foram registrados nos arquivos de dados, entretanto, que foram gravados no redo log online. Durante esse processo, o SMON lê os arquivos de redo log e aplica as alterações registradas nos blocos de dados;
Abrir o banco de dados para permitir que os usuários estabeleçam logon;
Submeter à rollback as transações não submetidas à commit.
O PMON, normalmente, é executado a cada três segundos para efetuar atividades de limpeza. Se PMON não está sendo executado, a instância do banco de dados será encerrada.
Exemplo: suponha que uma sessão do usuário esteja atualizando algumas linhas em uma tabela, colocando um bloqueio em uma ou mais linhas. Alguém chuta a tomada e corta a energia do usuário e a sessão do SQL*PLUS desaparece quando a estação de trabalho é desligada. No prazo de milissegundos, o PMON detectará que a conexão não existe mais e executará as seguintes tarefas:
O PMON também interagirá com os listeners, fornecendo informações sobre os status da instância para as solicitações de conexão recebidas.
Archiver - ARCn
O Processo Archiver (ARCH) copia os arquivos redo log para fita ou mesmo outro disco, no momento em que um deles torna-se completo. Esse processo geralmente está presente quando o banco de dados está sendo utilizado no modo ARCHIVELOG. Eles são usados somente para a recuperação de um banco de dados.
O ideal é que o processo de arquivamento precisa terminar antes que o redo log preenchido seja necessário novamente, caso contrário ocorrerão sérios problemas de desempenho, os usuários não conseguirão concluir suas transações até que as entradas sejam gravadas nos arquivos de redo log e o arquivo de redo log não estará pronto para aceitar novas entradas porque ainda está sendo gravado no local de arquivamento.
Como verificar se meu banco de dados está habilitado o modo archive?
Conecte na sua base de dados e de o comando:
1. Archive habilitado:
Automatic archival             Enabled                  <---- Habilitado
Archive destination            +DG_ARCH_01      <--- Diretório aonde está sendo gravado
2. Archive desabilitado:
Automatic archival             Disabled            <--- Desabilitado, ou seja, não está sendo gravado archive, caso precise recuperar as informações, não será possível.
Archive destination            +DG_ARCH_01
Como alterar o Archive Mode
1. Conecte na base de dados:
2. Baixe a mesma e inicie em modo mount:
3. Verifique para onde está apontando a gravação dos archives (diretório da gravação):
Ambiente Oracle RAC:
show parameter log_archive_dest (Verifique se possui o caminho do diretório, caso não tenha, set o novo caminho)
alter system set log_archive_dest_1='LOCATION=+DG_ARCH_01' SCOPE=BOTH SID='*' ;
Ambiente Oracle Single:
alter system set log_archive_dest_1='LOCATION=+DG_ARCH_01' SCOPE=BOTH ;
log_archive_dest_1                   string      LOCATION=+DG_ARCH_01
4. Altere a base para ARCHIVE ou NO ARCHIVE;
alter database archivelog ; (Habilitando modo archive)
alter database noarchivelog ; (Desabilitando modo archive)
5. Abra a base de Dados:
6. Check a integridade e geração de um novo archive após habilitado:
alter system archive log current ; (Esse comando gera archive alternando em todos os redos do rac)
Esse comando gera arch somente no nó em que você está conectado, ele imediatamente começa a gravar no próximo log de redo em segundo plano, informando ao processo ARCH para copiar o arquivo de redo log "antigo" para o sistema de arquivos de redo log).
Recoverer - RECO
O Recoverer Process (RECO) trata das falhas das transações distribuídas. Se uma transação alterar duas tabelas de bancos de dados diferentes, e a conexão de rede entre estes bancos falhar antes da atualização de um dos bancos (commit), o RECO forçará um rollback na transação.