Oracle Background processes: Uma visão geral

Cada vez que iniciamos uma instância Oracle, são criados inumeros “background processes”. São basicamente
processos que correm em background que são sobretudo usados para algumas actividades específicas, como
por exemplo tarefas de manutenção.
Uma instância Oracle consiste essencialmente em shared memory e uma colecção de processos em background
e é identificada com um nome: SID.

A abordagem dos processos Oracle é diferente (por omissão) nos dois principais grupos de Sistemas Operativos: Enquanto que no UNIX a abordagem é “process based”, ou seja, existe um processo separado, no Windows a abordagem é “thread based”. A explicação é simples; O Oracle faz uso do SGA (System Global Area) para guardar informação relativa a todas as transacções ou sessões e como tal o SGA deve ser partilhado. Em Windows as threads não  conseguem aceder à memoria que existe de um outro processo, como tal, no Windows, o Oracle tem que ser um único processo com multipla threads.
Naturalmente no UNIX é possivel mudar o paradigma de “process based” para “thread based/shared” com algumas
mudanças de configurações no Oracle Net Services.

Dando uma vista de olhos pelos processos que correm no UNIX quando a instância não está iniciada temos:


lmarques@ubuntu:~$ ps -ef | grep oracle
oracle 759 1 0 Jun09 ? 00:00:00 /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr LISTENER -inherit
oracle 2736 2735 0 07:10 ? 00:00:00 oracleXE (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

 

Além do natural tnslsnr que é basicamente o Oracle TNS Listener, que espera por conecções
temos um outro processo chamado oracleXE, nome dado por convenção oracle+SID, sendo que neste caso
o SID é XE.
Seguidamente vamos alocar os recursos (SGA), arrancar os processos de background, mas sem inicializar (montar?)
a BD:

Connected to an idle instance.


SQL> startup nomount
ORACLE instance started.

Total System Global Area  293601280 bytes
Fixed Size 1258536 bytes
Variable Size 79694808 bytes
Database Buffers 209715200 bytes
Redo Buffers 2932736 bytes

 

Uma vez lido o ficheiro de inicialização, alocado o SGA, iniciado os processos em background e activado
os logs verificaremos o comando “ps -ef” de novo:


lmarques@ubuntu:~$ ps -ef | grep oracle
oracle 759 1 0 Jun09 ? 00:00:00 /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin/tnslsnr LISTENER -inherit
oracle 2807 1 0 07:20 ? 00:00:00 xe_pmon_XE
oracle 2809 1 0 07:20 ? 00:00:00 xe_psp0_XE
oracle 2811 1 0 07:20 ? 00:00:00 xe_mman_XE
oracle 2813 1 0 07:20 ? 00:00:00 xe_dbw0_XE
oracle 2815 1 0 07:20 ? 00:00:00 xe_lgwr_XE
oracle 2817 1 0 07:20 ? 00:00:00 xe_ckpt_XE
oracle 2819 1 0 07:20 ? 00:00:00 xe_smon_XE
oracle 2821 1 0 07:20 ? 00:00:00 xe_reco_XE
oracle 2823 1 0 07:20 ? 00:00:00 xe_cjq0_XE
oracle 2825 1 0 07:20 ? 00:00:00 xe_mmon_XE
oracle 2827 1 0 07:20 ? 00:00:00 xe_mmnl_XE
oracle 2829 1 0 07:20 ? 00:00:00 xe_d000_XE
oracle 2831 1 0 07:20 ? 00:00:00 xe_s000_XE
oracle 2833 1 0 07:20 ? 00:00:00 xe_s001_XE
oracle 2835 1 0 07:20 ? 00:00:00 xe_s002_XE
oracle 2837 1 0 07:20 ? 00:00:00 xe_s003_XE
oracle 2838 2800 0 07:20 ? 00:00:00 oracleXE (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

Como podem ver existem muitos processos com o prefixo xe (normalmente seria ora_, mas esta é a versão Express Edition),
o nome do processo e o sufixo que neste caso é o SID. Resumindo a notação:

ora(xe)_[processname]_SID

Facilmente percebemos que existe um processo no SO por cada processo Oracle, seguindo a abordagem
UNIX “process based”.
O nome destes processos é variado, uns são mais “conhecidos” que outros, no entanto cada um é desenhado
para um tarefa específica quer sejam elas tarefas de manutenção ou tarefas mais especificas, como por exemplo
lidar com circunstâncias anormalas que podem ocorrer.
Para quem não tem acesso a uma shell (ou GUI) do SO para verificar estes processos existe uma forma
alternativa usado a view v$process e a query:


SQL> select pid, username,terminal, program, background from v$process;

 

De forma a entender melhor o que cada um dos processos realmente faz segue um pequeno descritivo
de cada um deles:

PMON – Process Monitor; Basicamente limpa a casa, ou seja, liberta os recursos alocados de um processo
do utilizador que falhou (libertando locks e transacções que não foram commited).

MMAN – Ajusta dinamicamente o tamanho dos componentes do SGA. A partir do Oracle 10g apenas.

DBWR – Database Writer; Simplificando escreve dirty buffers da memória (db buffer) para o disco.
Dirty buffer é basicamente um buffer que foi modificado na memória mas não foi escrito para o disco.
(DOC: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c08memor.htm#8537).

LGWR – Log Writer; Escreve o redo log buffer proveninente do SGA (memoria) para o online redo logo file.
O redo log são ficheiros que guardam todas as alterações feitas à BD à medida que elas ocorrem.
Todas as instâncias Oracle teem associado um online redo log para proteger a BD em caso de ocorrência
de um problema grave.

CKPT – Checkpoint Process; Inicia um checkpoint marcando todos os datafiles e control files

SMON – System Monito; Trata do “crash recovery” quando a instância crasha e é necessário reinicia-la.
O SMON é tambem responsável pelo “coalescing” que é a junção de espaço vazio nos datafiles evitando alguma
fragmentação.

RECO – Distributed Transaction Recovery; Encontra transacções distribuidas pendentes e tenta resolvê-las. Transacções distruibuidas
envolvem normalmente multiplas base de dados. Por exemplo se existir um erro de rede e a transacção ficar pending, é tarefa do RECO
resolver este problema, sendo que isso resulte num rollback ou num commit da transacção.

ARC – Archiver Process; Copia o online redo log escrito pelo LGWR para outra directoria quando o
ficheiro (ou ficheiros de log) estão cheios. Os archive logs são usado para backups em caso de falha
nos discos. De notar que este processo só existe se a BD estiver em archivelog mode. o LGWR é o responsável
pelo arranque de um ou mais processos ARC.

No nosso caso este processo não existe pois a BD não está em archivelog mode.

CJQ0 – Dynamic Job Queue coordinator; Como o próprio nome coordena todo o processo de correr e agendar jobs e gere
toda a queue. Os jobs podem ser statements PLSQL ou procedures.

Dnnn – Dispacher Process; No nosso caso está com o nome: d000 e é responsável pelo routing de pedidos
dos utilizadores conectados para o(s) shared server disponíveis
e pela recepção da resposta e reencaminhamento
para os utilizadores. É criado um Dnnn por omissão na instalação.

Snnn – Shared Server Process; No nosso caso estão com o nome: s000, s001, s002, s003.
Cada shared server process serve pedidos numa configuração shared server. Os shared server process,
ao contrário dos dedicados não estão associados a um processo de utilizador.

PS: Existem alguns processos que não estão contemplados aqui, como por exemplo aqueles ligados ao Oracle RAC,
como é exemplo o LMS e o LMON.

Para finalizar vamos montar a BD e associar a instância que arrancámos com a BD:

 

SQL> alter database mount;
Database altered.


SQL> alter database open;
Database altered.

Nesta altura e depois do alter database open, os datafiles estão prontos, tal o redo logs. São feitos
alguns testes de consistência e recovery se necessário.

– Artigo originalmente escrito para o thewiseadvise.com – 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s