Um breve "olá"
Faz tempo que não posto nada, no entanto, objetivo é o exame 1Z0-052. Eu sei, já deveria ter feito, mas... Não deu, até agora. Estou voltando aos estudos, e vou tentar postar aqui o que eu puder acerca do conteúdo da segunda prova. O texto abaixo vai dar uma "explicada" nos principais processos de segundo plano do banco de dados. Espero que ajude, boa leitura.
Estrutura de Processos de Segundo Plano
O que são?
Os processos em
segundo plano são aqueles que são iniciados juntamente quando a instância é iniciada e
executados até que esta seja finalizada. Existem cinco processos que eu diria que são os principais: SMON – System Monitor, PMON – Process Monitor, DBWn – Database Writer,
LGWRn – Log Writer, CKPT – Checkpoint Process. Em releases recentes, novos
processos foram adicionados, tais como MMON – Manageability Monitor e o MMAN –
Memory Manager. Outros não são essenciais, mas existirão em quase todas as instâncias, o ARCn – Archiver e o RECO – Recoverer.
SMON (System Monitor)
É responsável por
montar e abrir o banco de dados. Monta o banco, localizando e validando o
arquivo de controle. Depois, abre o banco, localizando e validando os arquivos
de dados e os arquivos de log. Após aberto, o SMON cuida da organização doméstica
da instância, como organizar o espaço no arquivo de dados.
PMON (Process Monitor)
O PMON monitora todos
os processos de servidor e detecta os problemas com as sessões. Se uma sessão
terminar de maneira anormal, o PMON destruirá o processo de servidor, retornará
sua memória ao pool de memória livre do sistema operacional e executará
rollback de todas as transações incompletas que possam estar em andamento.
DBWn (Database Writer)
As sessões não têm
como regra geral gravar no disco, elas gravam em buffers no cache de buffer do
banco, o DBWn que grava os dados no disco.
O DBWn grava os
buffers sujos do cache de buffer no banco de dados, mas não assim que são “sujos”,
pelo contrário, gravam o menor número de buffers possível, o suficiente para
resolver o problema. Pois acessar ao disco prejudica o desempenho, quando uma
sessão modifica em bloco é possível que o mesmo bloco seja modificado
novamente, pela mesma sessão ou por uma sessão diferente. Em geral, serão
gravados no disco buffers que tenham sido pouco acessados ou modificados
recentemente. Gravar a menor quantidade possível, o mais raramente possível. Os
DBWn gravaram caso não existam mais buffers livres, um excesso de buffer sujo,
um tempo limite de 3 segundos quando o DBWn gravará alguns buffers e quando há
um checkpoint, quando ocorre um checkpoint todos os buffers sujos serão
gravados, o que causará uma diminuição no desempenho e os usuários reclamarão,
o ideal é não utilizar checkpoints. Checkpoints automáticos ocorrem em
processos de shutdown, quando a instância está sendo fechada, então os buffers
são gravados a fim de que os arquivos de dados estejam sincronizados. O
checkpoint forçado pode ser realizado com a instrução: alter system checkpoint.
Também existem os
checkpoints parciais, que é quando um arquivo de dados ou tablespace é colocado
em Offline, quando o tablespace é colocado no modo backup, quando o tablespace
é configurado para somente leitura. São menos drásticos do que um checkpoint total
e ocorrem apenas nessas circunstâncias.
LGWRn – Log Writer
O LGWRn grava o
conteúdo do buffer de log nos arquivos de log no disco. Uma gravação do do
buffer de log nos arquivos de redo log online é geralmente referenciada como
fazer flush do buffer de log.
Quando você aplica uma
alteração a um bloco no cache de buffer, o vetor dessa alteração é gravado o
log de buffer, o LGWRn grava o conteúdo do buffer do log no redo log online no
disco, praticamente em tempo real. Quando uma sessão emite um COMMIT, a sessão
é suspensa enquanto o LGWRn grava o buffer no disco, após gravar, o commit é
confirmado e a transação se torna irreversível. Existem três circunstancias
que obrigarão o LGWR a fazer flush para o buffer de log: se uma sessão emitir
um comando COMMIT, se o buffer de log estiver 1/3 completo e se o DBWn estiver
para gravar buffers sujos.
CKPT (Checkpoint Process)
CKPT sinalização
quando os buffers sujos devem ser gravados no disco. A partir da versão 8i
passam a ser possíveis fazer checkpoints incrementais. O mecanismo de
checkpoint incremental instrui o DBWn a gravar os buffers sujos a uma taxa
constante, para que haja sempre um intervalo previsível entre o DBWn (que grava
os blocos usando um algoritmo preguiçoso) e o LGWR (que grava os vetores de alteração
praticamente em tempo real). Os checkpoints incrementais resultam em um
desempenho muito mais suave e tempos de recuperação mais previsíveis do que o
mecanismo de checkpoint completo mais antigo. Os checkpoints totais só
ocorreram se houver uma solicitação do DBA ou como parte de uma processo de
shutdown do banco de dados.
MMON (Manageability Monitor)
Processo introduzido
após a versão 10g, é o processo de ativação de grande parte dos recursos de
automonitoramento e autoajuste do banco de dados. O MMON guarda no dicionário
de dados, informações que captura as estatísticas da SGA. Podem ser armazenadas
indefinidamente, mas em geral ficam oito dias. O MMON também monitora o banco
de dados e a instância para verificar se alertas devem ser disparados.
MMAN (Memory Manager)
O MMAN permite o gerenciamento
automático de memória. Antes da versão 9i do banco de dados, o gerenciamento de
memória no ambiente Oracle estava longe de ser satisfatório. A memória PGA associada
aos processos de servidor de sessão era não transferível: o processo de
servidor ocupava a memória do pool de memória livre do sistema operacional e
nunca a retornava – mesmo que ela só́ fosse necessária por um curto período de
tempo. As estruturas da memória SGA eram estáticas: definidas na hora da inicialização
da instância e inalteráveis a menos que a instância fosse desligada e
reiniciada.
A versão 9i mudou
isso: as PGAs podem crescer e encolher, com o servidor passando memória para as
sessões sob demanda, ao mesmo tempo garantindo que a memória PGA total alocada permaneça
dentro de certos limites. A SGA e seus componentes (com a notável exceção do
buffer de log) também pode ser redimensionada. A versão 10g automatizou o
redimensionamento da SGA: o MMAN monitora a demanda por estruturas de memória
SGA e pode redimensioná-las conforme o necessário. A versão 11g leva o
gerenciamento de memória mais adiante: tudo o que o DBA precisa é definir um
objetivo global para o uso da memória e o MMAN observará a de "manda
pela memória PGA e a memória SGA e alocará a memória para as sessões e para as
estruturas SGA conforme o necessário, mantendo o total de memória alocada
dentro de um limite definido pelo DBA.
ARCn (Archiver)
Processo opcional do
Oracle, mas geralmente muito utilizado no dia-a-dia empresarial. Todos os
vetores de alteração aplicados aos blocos de dados são gravados no buffer de
log (pelas sessões que fazem as alterações) e, em seguida, nos arquivos de redo
log online (pelo LGWR). Os arquivos de redo log online são de número e tamanho
fixos: uma vez que tenham sido preenchidos, o LGWR os sobrescreverá com mais
dados de redo. O tempo decorrido antes que isso aconteça depende do tamanho e
do número de arquivos de log online e da quantidade de atividade DML (e,
portanto, a quantidade de informações de redo gerada) no banco de dados. Isso
significa que o redo log online só́ armazena vetores de alteração de atividade
recente. Para preservar um histórico completo de todas as alterações, os
arquivos de log online devem ser copiados à medida que forem preenchidos e
antes de serem reutilizados. O ARCn é responsável por isso. Desde que essas cópias,
conhecidas como arquivos de redo log arquivados, estejam disponíveis, será́
sempre possível recuperar o banco de dados de qualquer dano restaurando os
backups do arquivo de dados e aplicando neles os vetores de alteração extraídos
de todos os arquivos de redo log arquivados gerados desde que os backups foram
criados. Então, a recuperação final, que irá recuperar o backup atualizado,
virá dos arquivos de redo log online. A maioria dos bancos de dados transacionais
de produção executarão no modo archive
log, o que significa que o ARCn é iniciado automaticamente e que o LGWR não
pode sobrescrever um arquivo de log online até que o ARCn o tenha arquivado
com êxito em um arquivo de log arquivado.
RECO (Recoverer Process)
Uma transação distribuída
é uma transação que envolve atualizações a dois ou mais bancos de dados, é
projetada por programadores e opera por meio de links de bancos de dados.
Considere este
exemplo:
update employees set salary=salary * 1.1 where
employee_id=1000;
update employees@dev set salary=salary * 1.1 where
employee_id=1000;
commit;
commit;
A primeira atualização
é aplicada a uma linha no banco de dados local. A segunda, a uma linha em um
banco de dados remoto identificado pelo link de banco de dados DEV.
O comando COMMIT
instrui os dois bancos de dados a confirmar a transação, que consiste em ambas
as instruções. As transações distribuídas requerem um commit de duas fases
(two phase commit). O commit em cada banco de dados deve ser coordenado: se um
falhar e o outro for bem-sucedido, os dados globais estariam em um estado
inconsistente. Um commit de duas fases prepara cada banco de dados instruindo
seus LGWRs para fazer flush do buffer de log para o disco (a primeira fase) e
uma vez que isso é confirmado, a transação é marcada como confirmada em todos
os lugares (a segunda fase). Se algo sair errado em algum lugar entre as duas
fases, o RECO assume o controle para cancelar o commit e fazer um rollback do
trabalho em todos os bancos de dados.
Existem outros vários
processos de segundo plano, os quais podem ser consultados com a instrução:
select program from v$process order by program;
Nenhum comentário:
Postar um comentário