Administração de Banco - 1

Prévia do material em texto

Administração de 
Banco de Dados I
Material Teórico
Responsável pelo Conteúdo:
Prof.a Esp Lúcia Contente Mós
Revisão Textual:
Prof. Esp. Claudio Pereira do Nascimento
Arquitetura de Banco de Dados
• Componentes Arquitetônicos do Oracle.
 · Entender os conceitos e a arquitetura do banco de dados;
 · Conhecer o funcionamento e a interação dos componentes para 
projetar, criar e manter o banco de dados;
 · Descrever os componentes de arquitetura de banco de dados e os 
respectivos relacionamentos;
 · Gerenciar arquivos do Banco de Dados e Estabelecer conexões ao 
Banco de Dados.
OBJETIVO DE APRENDIZADO
Arquitetura de Banco de Dados
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas:
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você 
também encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão 
sua interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Arquitetura de Banco de Dados
Componentes Arquitetônicos do Oracle
Figura 1 – Visão Geral da Arquitetura de Banco de Dados
Fonte: Watson, 2009
O servidor Oracle é um Sistema de Gerenciamento de Bancos de Dados e Objeto 
Relacional que garante um ambiente de alto desempenho e robustez.
Componentes Principais
Há vários processos, estruturas de memória e arquivos em um servidor Oracle. 
Esses itens são responsáveis pelo desempenho do banco de dados para garantir a 
recuperação do banco de dados na ocorrência de uma falha de software e/ou de 
hardware, ou ainda realizar atividades importantes para a administração do banco 
de dados. O servidor Oracle é a combinação de uma instância Oracle (parte lógica 
– memória) e um banco de dados Oracle (parte física – HD).
Instância Oracle
Figura 2 – Instância
Fonte: Watson, 2009
8
9
Uma instância Oracle consiste na estrutura de memória SGA e nos processos 
background (que são executados em segundo plano) usados para gerenciar bancos 
de dados. Uma instância é identificada pela utilização de métodos específicos de 
cada sistema operacional. Para cada banco de dados só existe uma instância.
Pool Compartilhado
É dividido em 2 partes principais: cache de biblioteca e cache de dicionário 
de dados.
No cache de biblioteca é verificada a análise da sintaxe do comando e no cache 
de dicionário de dados é verificado se o objeto existe e se o usuário tem privilégios 
para executar o comando analisado.
A memória alocada para o Shared Pool é determinada pelo parâmetro de 
inicialização SHARED_POOL_SIZE.
Cache de Buffer de Dados
Quando ocorre uma consulta, o processo do servidor Oracle consulta os blocos 
necessários no Cache de Buffer do Banco de Dados. Se o bloco não é encontrado 
nesse cache, o processo do servidor lê o bloco no arquivo de dados e coloca uma 
cópia do objeto no Cache de Buffer do Banco de Dados. Através de um algoritmo 
LRU, o processo servidor Oracle controla os buffers não acessados recentemente, 
de modo a criar blocos livres no Cache de Buffer do Banco de Dados. DB_CACHE_
SIZE é o parâmetro dimensiona o cache de buffer default.
Buffer de Redo
O Buffer de Redo Log é um buffer circular que contém alterações feitas em 
blocos de arquivos de dados. Essas informações são armazenadas em entradas 
de redo. As entradas de redo contêm as informações necessárias para recriar os 
dados anteriores às alterações feitas pelas operações INSERT, UPDATE, DELETE, 
CREATE, ALTER ou DROP. O tamanho do Buffer de Redo Log é definido pelo 
parâmetro de inicialização LOG_BUFFER.
Pool Grande
Com a alocação de memória de sessão do Large Pool para o Servidor Com-
partilhado, Oracle XA ou buffers de consultas paralelas, o Oracle pode usar o 
Shared Pool principalmente para armazenar instruções SQL compartilhadas no 
cache, esse procedimento reduz a carga em áreas do Shared Pool. O ganho de 
desempenho é resultado da redução do overhead causado pelo aumento ou pela 
compactação do cache SQL compartilhado.
Processos de Segundo Plano
Mantêm e impõe relacionamentos entre estruturas físicas (arquivos) e estruturas 
lógicas (SGA). Existem 5 processos que são obrigatórios: DBWR: Database Writer, 
LGWR: Log Writer, PMON: Monitor de Processo, SMON: Monitor de Sistema e 
CKPT: Ckeckpoint.
9
UNIDADE Arquitetura de Banco de Dados
Database Writer
O processo do servidor registra alterações feitas em blocos de undo e de dados 
no Cache de Buffer do Banco de Dados. O DBWR grava os blocos sujos, ou seja, 
blocos com dados alterados que não sofreram commit do Cache de Buffer do 
Banco de Dados nos arquivos de dados. Essa estratégia garante que um número su-
ficiente de blocos livres (blocos que podem ser sobregravados quando os processos 
do servidor precisam ler blocos dos arquivos de dados) esteja disponível no Cache 
de Buffer do Banco de Dados.
O DBWR adia a gravação nos arquivos de dados até ocorrer um dos seguin-
tes eventos:
• ocorrência de um checkpoint;
• o número de blocos sujos atinge um valor limite, memória cheia;
• um processo varre um número especificado de blocos à procura de blocos 
livres e não encontra nenhum;
• ocorre um timeout de 3 segundos;
• uma solicitação de ping no ambiente RAC (Real Application Clusters);
• um tablespace normal ou temporário é colocado off-line;
• ocorrência de um comando DDL.
Log Writer
O LGWR executa gravações sequenciais do Buffer de Redo Log no arquivo de 
redo log on-line nas seguintes situações:
• quando uma transação é submetida a commit;
• quando um terço do Buffer de Redo Log está cheio;
• quando há mais de um 1 MB de alterações registrado no Buffer de Redo Log;
• antes que o DBWR grave blocos modificados do Cache de Buffer do Banco de 
Dados nos arquivos de dados.
Como o redo é necessário para a recuperação, o LGWR confirma a operação 
de commit somente após a gravação do redo em disco.
SMON – Monitor do Sistema
Se ocorrer uma falha na instância Oracle, as informações contidas na SGA que 
não foram gravadas em disco serão perdidas. Por exemplo, uma falha no sistema 
operacional provoca uma falha na instância. Após a perda da instância, o processo 
de segundo plano SMON recupera automaticamente a instância quando o banco 
de dados é reaberto. A recuperação da instância consiste nas seguintes etapas:
• Etapa 1: Rollforward para recuperar os dados que não foram registrados nos 
arquivos de dados, mas que foram registrados no arquivo de redo log on-line. 
10
11
Esses dados não foram gravados em disco devido à perda da SGA durante uma 
falhade instância. Durante esse processo, o SMON lê o arquivo de redo log 
on-line e aplica as alterações registradas nesse arquivo aos blocos de dados. 
Como todas as transações submetidas a commit foram gravadas nos arquivos 
de redo log on-line, esse processo recupera completamente as transações.
• Etapa 2: Abertura do banco de dados para que os usuários possam efetuar 
logon. Os dados não bloqueados por transações não recuperadas são imedia-
tamente disponibilizados.
• Etapa 3: Rollback de transações não submetidas a commit. O rollback dessas 
transações é efetuado pelo SMON ou pelos processos individuais do servidor 
à medida que eles acessam dados bloqueados.
PMON – Monitor do Processo
O processo de segundo plano PMON faz uma limpeza após ocorrerem falhas 
em processos. Para isso, executa as seguintes ações:
• desfaz a transação atual do usuário;
• libera todos os bloqueios de tabela ou linha mantidos no momento;
• libera outros recursos reservados pelo usuário no momento;
• reinicializa dispatchers inativos.
Processo Checkpoint
A cada três segundos, o processo CKPT armazena dados no arquivo de controle 
para identificar o local no arquivo de redo log on-line em que a recuperação deve 
começar. Esse local é denominado checkpoint. O objetivo de um checkpoint é 
garantir que todos os blocos no Cache de Buffer do Banco de Dados modificados 
antes de determinado momento sejam gravados nos arquivos de dados. É nesse 
momento (denominado posição de checkpoint) que a recuperação do banco de 
dados deve iniciar em caso de falha na instância. O DBWR já terá gravado todos os 
buffers no Cache de Buffer do Banco de Dados modificados antes desse momento. 
No caso de uma alternância de log, o CKPT também grava essas informações de 
checkpoint nos cabeçalhos dos arquivos de dados.
Os checkpoints são iniciados pelos seguintes motivos:
• garantir que os blocos de dados modificados na memória sejam gravados em 
disco regularmente para que os dados não se percam em caso de falha no 
sistema ou no banco de dados;
• reduzir o tempo necessário para a recuperação da instância. Somente as en-
tradas no arquivo de redo log on-line posteriores ao último checkpoint preci-
sam ser processadas para que a recuperação ocorra.
Podemos utilizar as Views Dinâmicas V$Process e V$BGProcess para encontrar 
os processos de segundo plano ativos.
11
UNIDADE Arquitetura de Banco de Dados
Processos Usados Para Estabelecer Conexão com uma Instância
Figura 3 – Estabelecimento de Conexão e Criação de Sessão
Fonte: Watson, 2009
Estabelecendo uma Conexão e Criando uma Sessão
Antes de submeterem instruções SQL a um banco de dados Oracle, os usuários 
devem se conectar a uma instância.
O usuário inicia uma ferramenta como o SQL*Plus ou executa uma aplicação qual-
quer, essa ferramenta ou essa aplicação é executada como um processo do usuário.
Na maioria das configurações básicas, quando um usuário efetua logon no ser-
vidor Oracle, é criado um processo no computador que executa esse servidor. Esse 
processo denomina-se processo do servidor. O processo do servidor se comunica 
com a instância Oracle em nome do processo do usuário executado no cliente. O 
processo do servidor executa instruções SQL em nome do usuário.
Conexão
Uma conexão é um caminho de comunicação entre um processo do usuário e 
um servidor Oracle. Um usuário do banco de dados pode se conectar a um servidor 
Oracle de três formas:
• O usuário efetua logon no sistema operacional que está executando a instância 
Oracle e inicia uma aplicação ou uma ferramenta que acesse o banco de dados 
nesse sistema. O caminho de comunicação é estabelecido por meio dos mecanis-
mos de comunicação entre os processos disponíveis no sistema operacional host.
12
13
• O usuário inicia a aplicação em um computador local e se conecta por uma 
rede ao computador que está executando a instância Oracle (servidor).
• Em uma conexão de arquitetura de três camadas, o computador do usuário se 
comunica pela rede com uma aplicação ou um servidor de rede, que, por sua 
vez, conecta-se por uma rede à máquina que está executando a instância Oracle.
Seções
Uma seção é uma conexão específica de um usuário com um servidor Oracle. 
A seção começa quando o usuário é validado pelo servidor Oracle e termina quan-
do ele efetua logout ou quando ocorre um encerramento anormal. Pode haver 
várias seções concorrentes para um usuário se ele efetuar logon a partir de várias 
ferramentas, aplicações ou terminais ao mesmo tempo. Com exceção de algumas 
ferramentas especializadas de administração de banco de dados, o início de uma 
seção de banco de dados exige que o servidor Oracle esteja disponível para uso.
O tipo de Conexão aqui explicado, onde há uma correspondência de um a um entre 
um processo de usuário e de servidor, é chamado de Conexão de servidor dedicado. 
Com uma confi guração MTS (Multithreaded Server, Servidor multithread), diversos 
processos de usuário podem compartilhar processos de servidor.
Componentes da PGA – Área Global do Programa
A PGA (Program Global Area ou Process Global Area) é uma região da me-
mória que contém os dados e as informações de controle de um único processo 
do servidor ou de um único processo de segundo plano. A PGA é alocada quando 
um processo é criado e desalocada quando o processo é encerrado. Ao contrário 
da SGA, que é compartilhada por vários processos, a PGA é uma área usada por 
apenas um processo.
A PGA é uma área reservada para fazer operações de classificação e organização 
dos dados.
Arquivos de Bancos de Dados Oracle
Os arquivos de bancos de dados são arquivos do sistema operacional que possi-
bilitam o armazenamento físico dos dados do banco de dados. Os arquivos de ban-
cos de dados são usados para garantir que os dados fiquem consistentes e possam 
ser recuperados caso aconteça erro na instância.
A estrutura física de um banco de dados Oracle inclui três tipos de arquivos: 
arquivos de controle, arquivos de dados e arquivos de redo log on-line.
13
UNIDADE Arquitetura de Banco de Dados
Arquivo de Dados
Os arquivos de dados contêm os dados do banco de dados. Os dados são arma-
zenados em tabelas definidas pelo usuário, mas também contêm o dicionário de 
dados, as imagens originais de dados modificados, índices e outros tipos de estrutu-
ras. Um banco de dados possui pelo menos um arquivo de dados. As características 
dos arquivos de dados são:
• Cada tablespace de um banco de dados Oracle consiste em um ou mais 
arquivos denominados arquivos de dados. Esses arquivos são estruturas físicas 
compatíveis com o sistema operacional no qual o servidor Oracle é executado.
• Um arquivo de dados só pode pertencer a um tablespace.
• Um servidor Oracle cria um arquivo de dados para um tablespace alocando o 
volume de espaço em disco especificado e um pequeno overhead.
• O administrador do banco de dados pode alterar o tamanho de um arquivo de 
dados após sua criação ou pode especificar que um arquivo de dados cresça 
dinamicamente à medida que os objetos do tablespace crescem.
Arquivos de Redo Logs
Os arquivos de redo log mantem os registros das operações dml (insert, update 
e delete) e ddl (alter, create e drop) que ocorrem no banco de dados. Os commits 
geram também um registro de ocorrência. Esses arquivos servem para realizar a 
recuperação do banco de dados.
Arquivo de Controle
O arquivo de controle localiza os arquivos de dados e de redo log. Um banco de 
dados precisa de pelo menos um arquivo de controle. Nesse arquivo são encontradas 
todas as estatísticas da instância, além do nome do banco de dados e sua data de 
criação. A maioria views que possuem o prefixo v$, mantém seus dados no arquivo 
de controle.
Outros Arquivos Importantes
O servidor Oracle também usa outros arquivos que não fazem parte do banco 
de dados:
• O arquivo de parâmetros contém parâmetros que dimensionam todas as estru-
turas da SGA. Além de todos os parâmetros de inicialização do banco de dados.
• O arquivo de senhas autentica os usuáriosque têm permissão para inicializar 
e desativar uma instância Oracle, ou seja, usuários com privilégios de DBA.
• Os arquivos de redo log arquivados, ou seja, os archives são cópias dos ar-
quivos de redo log que podem ser necessários para a recuperação depois de 
falhas físicas.
14
15
Processamento de Instruções SQL
Os processos de usuário e de servidor são os principais processos envolvidos na 
execução de uma instrução SQL. Entretanto, outros processos podem contribuir 
para que o servidor conclua o processamento da instrução SQL.
Componentes Usados Para Processar SQL
Nem todos os componentes de uma instância Oracle são usados para processar 
instruções SQL.
• Os processos de usuário e de servidor são usados para conectar um usuário a 
uma instância Oracle. Esses processos não fazem parte da instância Oracle, 
mas são necessários para processar uma instrução SQL.
• Alguns processos de segundo plano, estruturas de SGA e arquivos de bancos 
de dados são usados para processar instruções SQL. Dependendo do tipo de 
instrução SQL, diferentes componentes são usados:
 » As consultas exigem processamento adicional para retornar linhas ao usuário.
 » As instruções DML (Data Manipulation Language) exigem processamento 
adicional para registrar as alterações efetuadas nos dados.
 » O processamento de Commit garante que os dados modificados em uma 
transação possam ser recuperados.
• Alguns processos de segundo plano necessários não participam diretamente 
do processamento de uma instrução SQL, mas são usados para melhorar o 
desempenho e recuperar o banco de dados.
• O processo de segundo plano opcional, ARC0, é usado para garantir que um 
banco de dados de produção possa ser recuperado.
Etapas do Processamento de Consultas
As consultas são diferentes de outros tipos de instruções SQL, porque, se forem 
bem-sucedidas, retornarão dados como resultados. Enquanto outras instruções 
apenas informam se houve êxito ou falha, uma consulta pode retornar uma linha 
ou milhares de linhas.
Cache de Biblioteca
O cache de biblioteca armazena informações sobre as instruções SQL mais 
usadas recentemente em uma estrutura de memória denominada Área SQL. 
A Área SQL compartilhada contém:
• O texto da instrução SQL
• A árvore de análise: Uma versão compilada da instrução
• O plano de execução: As etapas a serem seguidas durante a execução da instrução.
15
UNIDADE Arquitetura de Banco de Dados
O otimizador é uma função do servidor Oracle que determina o plano de exe-
cução ideal.
Se uma instrução SQL for executada novamente e uma Área SQL compartilhada 
já tiver o plano de execução da instrução, o processo de servidor não precisará 
analisar a instrução. O cache de biblioteca melhora o desempenho de aplicações 
que reutilizam as instruções SQL reduzindo o tempo de análise e os requisitos da 
memória. Se a instrução SQL não for reutilizada, em algum momento ela será 
retirada do cache de biblioteca.
O Cache de Biblioteca é usado para armazenar instruções SQL e blocos PL/
SQL a serem compartilhados pelos usuários. É gerenciado por um algoritmo de 
LRU (Least Recently Used) e é usado para evitar nova análise de instruções.
Se um usuário emitir uma instrução que já esteja no cache, o servidor Oracle 
poderá usar a versão armazenada no cache se for necessário analisá-la novamente.
Para determinar se uma instrução já está armazenada no cache, o servidor Oracle:
• reduz a instrução ao valor numérico do texto em ASCII;
• usa uma função hash desse número.
Cache do Dicionário de Dados
O cache do dicionário de dados é um conjunto das definições mais usadas 
recentemente no banco de dados. Ele inclui informações sobre arquivos de bancos 
de dados, tabelas, índices, colunas, usuários, privilégios etc.
O processo de servidor procura as informações no cache de dicionário para resol-
ver nomes de objetos e verificar os privilégios de acesso do usuário. Se necessário, 
o processo de servidor iniciará a carga dessas informações nos arquivos de dados.
Cache de Buffer do Banco de Dados
Quando uma consulta é processada, o processo de servidor procura no cache 
de buffer do banco de dados por blocos que sejam necessários. Se o bloco não for 
localizado no cache de buffer do banco de dados, o processo de servidor lerá o 
bloco no arquivo de dados e colocará uma cópia no cache de buffer. Como solici-
tações subsequentes pelo mesmo bloco, podem-se localizar o bloco na memória e 
as solicitações talvez precisem de leituras físicas. O servidor Oracle usa o algoritmo 
menos usado recentemente para retirar buffers que não foram acessados recente-
mente, a fim de criar espaço para novos blocos no cache de buffer.
Analisando uma Instrução SQL
Durante a fase de análise, o processo de servidor usa a Área na SGA conhecida 
como pool compartilhado para compilar a instrução SQL. O pool compartilhado 
possui dois componentes principais:
16
17
• Cache de biblioteca;
• Cache do dicionário de dados.
Durante o estágio de análise, a instrução SQL é transmitida do processo de 
usuário para o processo de servidor e uma representação analisada da instrução 
SQL é carregada em uma Área SQL compartilhada. Durante a análise, o processo 
de servidor:
• procura uma cópia existente da instrução SQL no pool compartilhado;
• valida a instrução SQL verificando sua sintaxe;
• efetua pesquisas no dicionário de dados para validar definições de tabela e coluna;
• adquire bloqueios de análise em objetos, de forma que as definições não se 
alteram durante a análise da instrução;
• verifica os privilégios do usuário para acessar os objetos de esquema mencionados;
• determina o plano de execução ideal para a instrução;
• carrega a instrução e o plano de execução em uma Área SQL compartilhada.
O estágio de análise inclui requisitos de processamento que em geral precisam 
ser atendidos apenas uma vez, não importa quantas vezes a instrução seja executa-
da. Normalmente, o servidor Oracle converte cada instrução SQL apenas uma vez, 
executando-a novamente quando houver referências subsequentes a ela. Entretan-
to, o servidor Oracle sempre verifica se o usuário possui os privilégios necessários 
para executar a instrução SQL.
Apesar de a análise de uma instrução SQL validar essa instrução, a análise so-
mente identifica erros que podem ser localizados antes da execução da instrução. 
Sendo assim, alguns erros não podem ser detectados através da análise. Por exem-
plo, os erros de conversão de dados ou os erros nos dados (como, por exemplo, 
uma tentativa de informar valores duplicados em uma chave primária) e conflitos 
são todos os erros ou situações que podem ocorrer e ser informados apenas duran-
te o estágio de execução.
Executando a Instrução SELECT
Neste ponto, o servidor Oracle possui todas as informações e recursos necessá-
rios para que a instrução seja executada. Para as instruções SELECT, o processo 
de servidor prepara-se para recuperar os dados.
Extraindo as Linhas de uma Consulta
No estágio de extração, as linhas são selecionadas, ordenadas (se necessário) e 
retornadas pelo servidor ao usuário. Dependendo do número de linhas retornadas 
em cada extração, uma ou mais extrações podem ser necessárias para transferir os 
resultados de uma consulta para o usuário.
17
UNIDADE Arquitetura de Banco de Dados
Etapas no Processamento de DML
Uma instrução DML (Data Manipulation Language) requer apenas duas fases 
de processamento:
• análise, que é a igual à fase de análise para o processamento de uma consulta;
• execução, que requer processamento adicional para efetuar alterações nos dados.
Fase de Execução de DML
Para executar uma instrução DML:
1. Se não houver blocos de undo e dados no cache de buffer, o processo 
de servidor fará a leitura dos arquivos de dados para a memória cache de 
buffer de dados.
2. O processo servidor bloqueia as linhas que sofrerão alterações.
3. No buffer de redo log, o processo de servidor registra os comandos que 
serão executados no undo e nos dados.
a) As modificações do blocode undo registram os valores dos dados antes 
de serem alterados. O bloco de undo é utilizado para guardar a imagem 
consistente, ou seja, a imagem “comitada” dos dados, de forma que as 
instruções DML possam sofrer rollback, caso seja necessário.
b) As alterações dos blocos de dados registram os novos valores dos dados.
4. O processo de servidor registra a imagem original do bloco de rollback e 
atualiza o bloco de dados. Essas duas alterações são efetuadas no cache de 
buffer do banco de dados. Qualquer bloco alterado no cache de buffer será 
marcado como buffer sujo, ou seja, os buffers que não são iguais aos blocos 
correspondentes no disco. O processamento de um comando DELETE ou 
INSERT usa etapas semelhantes. A imagem original de DELETE contém 
os valores de coluna na linha deletada e a imagem original de um INSERT 
contém as informações de localização de linha.
Características de Buffer de Redo Log
O processo servidor registra o bloco que foi alterado, o local da alteração e o 
novo valor em uma entrada de redo. O buffer de redo log é usado sequencialmente 
e as alterações efetuadas por uma transação podem ser intercaladas com alterações 
efetuadas por outras transações.
• É um buffer cíclico que será reutilizado depois de ser completamente preen-
chido, mas somente depois que todas as entradas de redo forrem gravadas 
fisicamente nos arquivos de redo log.
18
19
Segmento de Undo
Antes de efetuar uma alteração, o processo de servidor salva os antigos valores 
de dados em um segmento de undo. Essa imagem original será usada para:
• Desfazer as alterações se a transação for submetida a rollback.
• Fornecer consistência de leitura verificando se outras transações não reconhe-
cem alterações não submetidas a commit efetuadas pela instrução DML.
• Recuperar o banco de dados para um estado consistente em caso de falhas.
Segmentos de undo, como tabelas e índices existentes nos arquivos de dados 
e blocos de rollback, são levados para o cache de buffer do banco de dados 
quando necessário.
Os segmentos de undo são criados pelo DBA.
Processamento de COMMIT
O servidor Oracle utiliza um mecanismo de submissão de commit rápido, capaz 
de garantir que as alterações submetidas a commit possam ser recuperadas caso 
haja falha na instância.
Número de Alteração do Sistema
Sempre que uma transação é submetida a commit, o servidor Oracle atribui 
um SCN (System Change Number, número de alteração do sistema) à transação. 
O SCN é incrementado invariavelmente e é exclusivo no banco de dados. Ele é 
usado pelo servidor Oracle como um timestamp interno para sincronizar os dados 
e fornecer consistência de leitura quando os dados forem recuperados dos arquivos 
de dados. Com o SCN, o servidor Oracle pode executar verificações de consistência 
sem depender do horário do sistema operacional.
Etapas do Processamento de COMMITs
Quando um COMMIT é emitido, as seguintes etapas são executadas:
1. O processo de servidor coloca um registro de commit, junto com o SCN, 
no buffer de redo log.
2. O LGWR efetua uma gravação contígua de todas as entradas de buffer de 
redo log até, e inclusive, o registro de commit nos arquivos de redo log. 
Depois desse ponto, o servidor Oracle pode garantir que as alterações não 
serão perdidas mesmo que haja uma falha de instância.
3. O usuário é informado de que o COMMIT foi concluído.
4. O processo de servidor registra informações para indicar que a transação 
foi concluída e que os bloqueios de recurso podem ser liberados.
19
UNIDADE Arquitetura de Banco de Dados
A descarga dos buffers sujos para o arquivo de dados é efetuada de modo 
independente por DBW0 e pode ocorrer antes ou depois de submeter a commit.
LOG Writer
O LGWR executa gravações sequenciais do buffer de redo log no arquivo de 
redo log na ocorrência dos seguintes eventos:
• Quando um usuário emite um commit. Como o redo é necessário para a recu-
peração, o LGWR confirma o COMMIT somente após o conteúdo do buffer de 
redo log estar gravado no arquivo de redo, ou seja, gravado fisicamente no HD.
• Quando um terço do buffer de redo log está cheio.
• Quando há mais de um megabyte de alterações registradas no buffer de redo log.
• Antes de o DBWR gravar os blocos da memória cache de buffer de dados nos 
arquivos de dados, ou seja, de forma física no HD.
Outros Processos Necessários
Outros quatro processos necessários não participam diretamente do processa-
mento de instruções SQL:
• Database Writer (DBWR)
• Monitor de Processo (PMON)
• Monitor de Sistema (SMON) 
• Checkpoint (CKPT): O processo de checkpoint é usado para sincronizar ar-
quivos de bancos de dados.
Database Writer
O processo de servidor registra alterações a serem submetidas a rollback e 
blocos de dados no cache de buffer. O Database Writer (DBW0) grava os blocos 
sujos do cache de buffer do banco de dados nos arquivos de dados. Ele garante 
que um número suficiente de buffers livres (buffers que podem ser sobregravados 
quando os processos de servidor precisam ler blocos dos arquivos de dados) esteja 
disponível no cache de buffer do banco de dados. O desempenho do banco de 
dados melhora porque os processos de servidor efetuam alterações somente no 
cache de buffer e o DBWR faz o registro nos arquivos de dados até que um dos 
seguintes eventos aconteça:
• O número de buffers sujos alcance um valor-limite.
• Um processo varra um número específico de blocos à procura de buffers livres 
e não localiza nenhum.
• Um timeout ocorra (a cada três segundos).
20
21
• Um checkpoint ocorra. Um checkpoint é um meio de sincronização do cache 
de buffer do banco de dados com o arquivo de dados.
• Operações com Tabela (Create, Alter, Drop).
• Operações com Tablespace (Create, Alter, Drop).
• Ping do RAC (Real Application Cluster).
SMON: Monitor de Sistema
Se a instância Oracle falhar, qualquer informação na SGA que não foi gravada 
em disco se perderá. Por exemplo, a falha do sistema operacional causa uma falha 
na instância. Depois da perda da instância, o processo de segundo plano SMON 
executará automaticamente a recuperação da instância quando o banco de dados 
for reaberto.
A recuperação da instância consiste nas seguintes etapas:
• Etapa 1: Rollforward para recuperar dados que não foram registrados nos 
arquivos de dados, mas que foram registrados no redo log on-line. Esses da-
dos não foram gravados em disco por causa da perda da SGA durante falha na 
instância. Durante esse processo, SMON lê os arquivos de redo log e aplica as 
alterações registradas no redo log aos blocos de dados. Como toda transação 
submetida, a commit foi gravada nos redo logs, esse processo recupera com-
pletamente essas transações.
• Etapa 2: Abrir o banco de dados para permitir que os usuários estabeleçam 
logon. Qualquer dado que não esteja bloqueado por transações irrecuperáveis 
fica disponível imediatamente.
• Etapa 3: Submeter a rollback às transações não submetidas a commit. Elas são 
submetidas a rollback pelo SMON ou pelos processos de servidor individuais 
quando eles acessam os dados bloqueados.
PMON: Monitor de Processo
O processo de segundo plano PMON é responsável por limpar o segmento de 
undo na ocorrência de um commit efetuado pelo usuário.
Os administradores de bancos de dados são responsáveis pela manutenção do 
servidor Oracle para que o servidor possa processar solicitações do usuário. É ne-
cessário ter uma noção básica da arquitetura Oracle para mantê-la funcionando.
21
UNIDADE Arquitetura de Banco de Dados
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Banco de Dados: Projeto e Implementação
MACHADO, Felipe Nery Rodrigues. Banco de dados: projeto e implementação. São 
Paulo: Érica, 2004. 398 p.
Projeto de Banco de Dados: Uma Visão Prática
MACHADO, Felipe Nery Rodrigues; ABREU, Maurício Pereira de. Projeto de banco 
de dados: uma visão prática. 15. ed. São Paulo: Érica, 2007. 300 p.
OCA ORACLE DATABASE 11G – ADMINISTRAÇAO I
WATSON, John. OCA ORACLEDATABASE 11G – ADMINISTRAÇAO I. 1. Ed. 
São Paulo: BOOKMAN COMPANHIA, 2009.
OCP ORACLE DATABASE 11G – ADMINISTRAÇAO II
BRYLA, Bob. OCP ORACLE DATABASE 11G – ADMINISTRAÇAO II. 1. ed. São 
Paulo: BOOKMAN COMPANHIA, 2009.
OCA ORACLE DATABASE 11G – FUNDAMENTOS I AO SQL
RAMKLASS, Roopesh e WATSON, John. OCA ORACLE DATABASE 11G – 
FUNDAMENTOS I AO SQL. 1. ed. Rio de janeiro: Alta Books.
Projetando e Administrando Banco de Dados SQL Server 2000 .net: Como Servidor Enterprise
PATTON, Robert; OGLE, Jennifer. Projetando e Administrando Banco de Dados 
SQL Server 2000 .net: Como Servidor Enterprise. Tradução de Andréa Barbosa Bento; 
Cláudia Reali; Lineu Carneiro de Castro. Rio de Janeiro: Alta Books, 2002. 792 p.
22
23
Referências
DATE, C. J. Introdução a sistemas de bancos de dados. Tradução [8th. ed. 
Americana] de Daniel Vieira. Revisão técnica Sérgio Lifschitz. Rio de Janeiro: 
Elsevier, 2003. 865 p.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de Banco de Dados. 
Tradução de Marília Guimarães Pinheiro et al. Revisão técnica Luis Ricardo de 
Figueiredo. 4. ed. São Paulo: Pearson Addison Wesley, 2005. 724 p.
GILLENSON, Mark L. Fundamentos de sistemas de gerência de banco de 
dados. Tradução de Acauan Fernandes; Elvira Maria Antunes Uchoa. Rio de 
Janeiro: LTC, 2006. 304 p.
SILBERSCHATZ, Abraham, KORTH, Henry F.; SUDARSHAN, S. Sistema de 
Banco de Dados. Tradução de Daniel Vieira. Revisão técnica Luis Ricardo de Figuei-
redo; Caetano Traina Jr. 3. ed. São Paulo: Pearson Makron Books, 2007. 778 p.
23