Software Code Area

Armazenam os arquivos executáveis do Oracle, em execução como parte de uma instância do Oracle. Essas áreas de código têm natureza estática e só mudam quando é instalado um novo release do software.

Geralmente estão localizadas em uma área privilegiada da memória, isoladamente dos outros programas do usuário. Ele é read-only, obviamente, e pode ser instalado como compartilhável ou não compartilhável. Instalar o software code do Oracle como compartilhável economiza memória quando várias instâncias do Oracle estão em execução no mesmo servidor e no mesmo nível de release de software.

Background Process

Quando uma instância é inicializada, vários processos em segundo plano são iniciados. Um Background Process é um bloco de código executável responsável por alguma tarefa específica.

São assim chamados por trabalharem “nos bastidores”, diferente de uma sessão do SQL*Plus por exemplo. Juntos, a SGA e os background process formam uma instância do Oracle.

Abaixo, os background process:

SMON

• System Monitor. Executa o processo de recovery durante um startup caso tenha ocorrido um shutdown abort ou alguma outra falha, aplicando as entradas existentes nos arquivos de redo log;
• Expurga segmentos temporários durante a reinicialização da instância;
• Faz a “junção” do espaço livre das tablespaces gerenciadas por dicionário (algo raro e possivelmente inexistente na grande maioria dos bancos em versão 11g).

PMON

Process Monitor. Faz o trabalho de “limpeza” quando cai a conexão de um usuário ou se um processo de usuário falhar. Ele limpa o database buffer cache e todos os outros recursos qua a conexão estava utilizando. Ao detectar que a conexão não existe mais, o PMON executa 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.

DBWn

• O Database Writer (conhecido como DBWR nas versões anteriores) grava os blocos de dados novos ou modificados (conhecidos como dirty block, ou blocos sujos) existentes no buffer cache para os datafiles;
• 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.

LGWR

• O Log Writer é responsável pelo gerenciamento do redo log buffer;
• É 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.

ARCn

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.

Este 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 – as transações não serão concluídas até que as entradas sejam gravadas no redo log, mas os redo log files não estarão prontos para aceitar novas entradas porque ainda está sendo gravado no local do 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.

CKPT

O Checkpoint Process ajuda a reduzir o tempo necessário para a recuperação da instância. Durante um checkpoint, o CKPT atualiza o cabeçalho do controlfile e os datafiles para refletir o último SCN (System Change Number) bem-sucedido. Um checkpoint ocorre automaticamente sempre que um redo log file é preenchido.

Os processos DBWn gravam os dirty blocks para antecipar o checkpoint a partir do qual a recuperação da instância pode iniciar, reduzindo o MTTR (Mean Time to Recovery).

RECO

O Recoverer Process 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, o RECO forçará um rollback na trasação.

Posts relacionados:

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 1)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 2)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 3)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 4)

Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.