Os principais processos em background de um banco de dados Oracle, são: PMON, SMON, DBWR, LGWR, RECO, CKPT e o ARCH.

O que é um processo

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.

Database writer - DBWR

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 número de processos é controlado pelo parâmetro DB_WRITER_PROCESSES.

Log writer - LGWR

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.

Checkpoint - CKPT

O Checkpoint Process é responsável pela atualização do cabeçalho das informações de status do banco de dados nos arquivos de controle (Control Files) e nos arquivos de dados (Data Files) para refletir o último SCN (System Change Number).

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.

O CKPT efetua periodicamente uma verificação (checkpoint) para se certificar de que todas as informações modificadas na memória estão armazenadas fisicamente no disco, sendo realizada nas seguintes condições:

• 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.

O processo de Checkpoint é habilitado através do parâmetro CHECKPOINT_PROCESS.

System Monitor - SMON

O processo System Monitor verifica a consistência no banco de dados, localizando e validando o arquivo de controle no momento em que o banco é montado e, se necessário, inicia a recuperação do banco de dados quando ele é aberto. Além desta funcionalidade, o SMON é responsável por unir espaços livres nos tablespaces regularmente se eles forem gerenciados pelo dicionário.

Os arquivos de controle (Control Files) são arquivos físicos do sistema operacional responsáveis por armazenar informações necessárias para manter e verificar a integridade do banco de dados. Um banco de dados Oracle deve possuir no mínimo um arquivo de controle.

O SMON é o processo utilizado em circunstâncias como uma queda ou falha de sistema, executando a recuperação de falhas aplicando as entradas dos arquivos de redo log aos arquivos de dados. A sua principal função é abrir a conexão entre a instância e o banco de dados, além de realizar funções de monitoramento e organização.

É importante ressaltar que ao ocorrer uma falha na instância Oracle as informações contidas na área SGA que não foram gravadas em disco serão perdidas. Após a perda da instância, o processo de segundo plano SMON recupera automaticamente a instância quando o banco é reaberto.

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:

1. 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;
2. Abrir o banco de dados para permitir que os usuários estabeleçam logon;
3. Submeter à rollback as transações não submetidas à commit.

Process Monitor - PMON

O Process Monitor ou PMON é um processo em segundo plano criado no momento em que a instância do banco de dados é inicializada. Ele disponibiliza recursos se um dos processos do Oracle falhar. Por exemplo, se uma conexão de usuário cair, um processo do Oracle falhar ou ocorrer uma falha de hardware, o processo PMON aplica o rollback de transações que estavam em andamento, remove os bloqueios nas linhas afetadas da tabela e remove o processo desconectado da lista de processos ativos.

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:

• Aplica rollback na transação que estava em andamento;
• Marca os blocos da transação como disponíveis no buffer cache;
• Remove os locks (bloqueios) sobre as linhas afetadas na tabela;
• Remove o ID do processo desconectado da lista de processos ativos.

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.

Se o banco estiver em modo archivelog, o archiver process copiará os redo logs em um ou mais diretórios de destino, dispositivos ou localizações da rede sempre que um redo log ficar totalmente preenchido e as informações de redo começarem a preencher o redo log seguinte, em sequência.

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.

Possíveis soluções para este problema:

• Aumentar o tamanho dos redo log files;
• Aumentar o número de grupos de redo log;
• Aumentar a quantidade de processos ARCn.

Podem ser inicializados até 10 processos ARCn para cada instância, aumentando o valor do parâmetro de inicialização LOG_ARCHIVE_MAX_PROCESSES.

Como verificar se meu banco de dados está habilitado o modo archive?

Conecte na sua base de dados e de o comando:

archive log list

1. Archive habilitado:

SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled                  <---- Habilitado
Archive destination            +DG_ARCH_01      <--- Diretório aonde está sendo gravado
Oldest online log sequence     5
Next log sequence to archive   8
Current log sequence           8

2. Archive desabilitado:

SQL> archive log list
Database log mode             No Archive Mode
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
Oldest online log sequence     5
Next log sequence to archive   8
Current log sequence           8

Como alterar o Archive Mode

1. Conecte na base de dados:

sqlplus "/as sysdba"

2. Baixe a mesma e inicie em modo mount:

shutdown immediate
startup 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 ;

SQL> show parameter log_archive_dest_1

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
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:

alter database open ;

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)

alter system switch logfile ;

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.