A arquitetura do ORACLE

Publicado em: 07/05/2003

O conhecimento da arquitetura interna do ORACLE de extrema importncia para a compreenso das tcnicas de
otimizao do produto. Basicamente, os seus mecanismos de execuo so as estruturas de memria e os
processos executados em background. Todas as vezes que um banco inicializado, uma SGA alocada e os
processos so inicializados. A combinao das estruturas de memria na SGA e dos processos em background
chamada de instncia ORACLE. Algumas arquiteturas de hardware permitem mltiplos computadores
compartilharem os mesmos dados, softwares ou perifricos. Com a opo Parallel Server do ORACLE, podemos
tirar proveito dessa caracterstica atravs da execuo de mltiplas instncias que compartilham um nico banco
de dados. Assim, os usurios de diversas mquinas podem acessar o mesmo banco de dados com uma melhoria
na performance.
SGA A SGA um grupo de buffers de memria compartilhados que so destinados pelo ORACLE para uma
instncia. Basicamente formada pelas estruturas identificadas por shared pool, database buffer cache e redo log
buffer cache. Entretanto, em algumas configuraes do ORACLE podem existir outras estruturas.
Processos em Background Os processos em background executam tarefas distintas assincronicamente em
benefcio a todos os usurios de um banco de dados. No existe uma relao direta entre os processos em
background e os processos dos usurios conectados a uma instncia ORACLE. Apesar de poderem existir outros
em uma instncia, o que depende da configurao do ORACLE utilizada, os processos mais conhecidos so o
PMON, SMON, DBWR, LGWR, RECO, LCK, CKPT e o ARCH.
Geralmente um banco de dados est associado a somente uma instncia. Entretanto, como vimos, em algumas
configuraes do ORACLE, um banco de dados pode estar associado a mais de uma instncia. Assim, precisamos
diferenciar os dois conceitos: um banco de dados formado pelos arquivos fisicamente armazenados em disco
enquanto que uma instncia formada pelas estruturas e processos em memria. O banco de dados
permanente, enquanto que uma instncia voltil. Naturalmente, para acessarmos um banco de dados
necessrio que uma instncia seja inicializada e associada a ele.
Estruturas de Memria
As estruturas de memria so criadas pelo ORACLE e usadas para completar diversas tarefas. Por exemplo, elas
so usadas para guardar o cdigo de um programa que est sendo executado e os dados que podem ser
compartilhados pelos usurios.
SGA e PGA.
As principais estruturas so a SGA (System Global Area ou rea Global do Sistema) e a PGA (Program Global Area
ou rea Global de Programa).
A PGA o buffer de memria que contm dados e algumas informaes de controle de uma sesso de um usurio.
A PGA criada e alocada quando um novo processo inicializado no servidor. As suas informaes dependem da
configurao do ORACLE. Assim, existe uma rea de memria PGA para cada usurio que est executando seus
trabalhos no ORACLE. Dentro da PGA existem trs estruturas: uma contendo um espao para a pilha (para
armazenar as variveis e matrizes), outra contendo dados sobre a sesso do usurio e uma terceira com as
informaes dos cursores usados. A PGA no compartilhada entre os usurios; ela nica para cada sesso.
A SGA uma regio de memria compartilhada por todos os usurios e alocada pelo ORACLE. Contm os dados e
as informaes de controle de uma instncia. Ela alocada quando uma nova instncia inicializada e liberada
quando a mesma finalizada. Os dados na SGA so compartilhados pelos usurios que estiverem conectados ao
banco de dados e, para otimizar a performance, as entradas na SGA devem ser as maiores possveis para guardar
a maior quantidade de dados e minimizar o I/O em disco, uma das causas crticas que tornam um banco de dados
lento. As informaes na SGA esto organizadas em diversos tipos de estruturas de memria, incluindo o buffer do
banco de dados e o buffer para recuperao do banco, por exemplo. As estruturas tm tamanho fixo e so criadas
durante a inicializao da instncia. O grupo de buffers do banco de dados em uma instncia so chamados de
database buffer cache. Esses buffers podem conter os dados modificados que ainda no foram escritos em disco,
para os arquivos de dados apropriados. Desse modo o I/O minimizado e h uma melhora significativa da
performance.
Essa estrutura compartilhada entre todos os usurios conectados a um banco de dados e os blocos de dados que
so armazenados no database buffer cache tm seus tamanhos determinados pelo parmetro DB_BLOCK_SIZE. O

nmero de blocos em memria determinado pelo parmetro DB_BLOCK_BUFFERS.

O contedo do database buffer cache organizado em duas listas: a lista de blocos alterados e a lista dos blocos
menos recentemente utilizados (LRU - Least Recently Used). Essa segunda lista contm os blocos livres, aqueles
que esto em uso e os blocos alterados. Quando um processo servidor precisa ler dados de um bloco do disco para
o database buffer cache, ele pesquisa a LRU para localizar um bloco livre e, quando encontrar um bloco alterado,
movimenta-o para a lista de blocos alterados. Esse processo termina quando um bloco livre localizado ou quando
um nmero especfico de blocos so pesquisados sem encontrar um bloco livre.
Durante uma operao de SELECT, o ORACLE requer que os blocos que contm a informao desejada esteja em
memria. Assim, a lista LRU pesquisada e, se os blocos no estiverem em memria, o produto efetua as leituras
fsicas necessrias. Caso o bloco esteja em memria, so efetuadas leituras lgicas. Lembremo-nos de que
nenhuma tabela pode ocupar menos de dois blocos de dados: um bloco para o cabealho e pelo menos outro bloco
de dados.
O redo log buffer cache da SGA armazena todas as alteraes feitas em um banco de dados em memria. Todas
as entradas redo log neste buffer so escritas nos arquivos redo log, que so usados para a recuperao do banco
de dados, se necessrio.
A shared pool uma poro de memria compartilhada que contm as reas chamadas shared SQL, estruturas de
memria compartilhadas que contm os comandos SQL que esto sendo executados pelos mltiplos usurios
conectados a um banco de dados. Essas reas compartilhadas shared SQL contm informaes como o texto e a
forma interpretada dos comandos SQL, a fase de anlise dos comandos SQL e seus planos de execuo,
informaes do dicionrio de dados e de geradores de nmeros seqenciais. Uma nica rea shared SQL pode ser
compartilhada por diversas aplicaes que usam o mesmo comando definido na rea compartilhada de comandos
SQL, deixando assim mais rea em memria disponvel para os outros usurios e melhorando a performance de
execuo de um comando, j que o plano de execuo j est definido e o ORACLE no precisa defini-lo
novamente.
A shared pool contm ainda o data dictionary cache, com as informaes do dicionrio de dados, e o sequence
cache, com as informaes dos geradores de nmeros seqenciais. Um cursor um nome ou ponteiro para a
memria associada a um comando especfico. Muitas aplicaes ORACLE tiram proveito dos cursores.
Processos.
Os processos podem ser vistos como programas que trabalham em memria (em background) e executam outras
tarefas especficas para o ORACLE. Um processo uma forma de controle ou um *mecanismo no sistema
operacional que pode executar uma srie de passos e normalmente tem sua rea particular de memria. Alguns
sistemas operacionais usam o termo job ou tarefa.
Existem dois tipos gerais de processos: os processos dos usurios e os processos do prprio ORACLE.
Um processo de usurio criado e mantido para executar o cdigo da aplicao (por exemplo um programa
Pro*C) ou uma ferramenta ORACLE (por exemplo o SQL*Plus). Os processos dos usurios tambm gerenciam a
comunicao com os processos do servidor ORACLE atravs do program interface.
Os processos ORACLE so chamados por outros processos para executar algumas funes especficas. O produto
cria os processos servidores (server process) para controlar as requisies dos processos dos usurios conectados
a um banco de dados. Assim, os processos servidores so incumbidos de comunicar-se com os processos dos
usurios e interagir com o ORACLE para acessar seus recursos.
Por exemplo, se um usurio pesquisa alguns dados que no estejam no database buffer cache da SGA, o processo
servidor l os dados apropriados dos blocos de dados dos arquivos e os coloca na SGA, para uso dos usurios.
Dependendo da configurao do ORACLE, um processo servidor pode ser compartilhado por diversos usurios.
Todos os comandos SQL so processados pelos processos servidores que se utilizam de trs fases para o
processamento: anlise, execuo e busca dos dados. O plano de cada comando armazenado na SGA, nas reas
que contm comandos SQL a serem compartilhados entre os usurios.
O ORACLE cria um conjunto de processos que rodam em background para cada instncia. Esses processos
executam diversas tarefas. So eles: DBWR, LGWR, CKPT, SMON, PMON, ARCH, RECO, Dnnn e LCKn.

O processo database writer (DBWR) escreve os blocos modificados do database buffer cache para os arquivos de
dados fsicos. O DBWR no precisa escrever os dados a cada comando COMMIT, pois otimizado para minimizar o
I/O. Geralmente o DBWR escreve os dados para o disco se muitos dados so lidos para o database buffer cache na
SGA e no existe espao livre para esses novos dados. Os dados menos recentemente usados so escritos para os
arquivos de dados em primeiro lugar.
O processo log writer (LGWR) escreve todas as entradas de redo log para o disco. Os dados de redo log so
armazenados em memria no redo log buffer cache, na SGA. No momento em que uma transao for efetivada
com o comando COMMIT e o redo log buffer estiver preenchido, o LGWR escreve as entradas de redo log nos
arquivos redo log apropriados.
A um tempo especfico, todos os dados do database buffer cache modificados so escritos em disco pelo processo
DBWR; este evento chamado de checkpoint. O processo checkpoint responsvel para informar ao processo
DBWR o momento de gravar os dados em disco. O DBWR tambm atualiza os arquivos de controle do banco de
dados para indicar o mais recente checkpoint. O processo CKPT opcional; se ele no estiver presente, o LGWR
assume sua responsabilidade.
O processo system monitor (SMON) efetua a recuperao da instncia em caso de falhas, durante a sua
inicializao. Em um sistema com mltiplas instncias (como na configurao Oracle Parallel Server, por exemplo),
o processo SMON de uma instncia tambm pode executar a recuperao de outras instncias que podem ter
falhado. Ele tambm limpa os segmentos temporrios que no esto sendo usados, liberando memria, e recupera
qualquer transao pendente no caso de uma falha em arquivos fsicos ou mesmo no disco. O processo de
recuperao dessas transaes executado pelo processo SMON quando a tablespace afetada volta a ficar
disponvel.
O process monitor (PMON) executa a recuperao do processo de um usurio quando esse processo falha. Limpa a
rea de memria e libera os recursos que o processo do usurio estava usando. O PMON tambm verifica o
processo despachante (dispatcher) e os processos servidores (server processes) e os reinicializa se tiver
acontecido qualquer falha.
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. Os arquivos redo log nada tm a ver com auditoria. Eles so usados somente para a
recuperao de um banco de dados.
O processo recoverer (RECO) usado para resolver transaes distribudas pendentes causadas por uma falha na
rede em um sistema de bancos de dados distribudos. A certos intervalos de tempo, o processo RECO do banco de
dados local tenta conectar-se ao banco de dados remoto para automaticamente completar e efetivar a transao
(COMMIT) ou descartar (ROLLBACK) a poro local de uma transao pendente em um sistema distribudo.
Os processos em background dispatchers (Dnnn) so opcionais e esto presentes somente quando a configurao
do Oracle Multi-thread Server usada. Pelo menos um processo dispatcher criado para cada protocolo de
comunicao em uso (D000, D0001, ..., Dnnn). Cada processo dispatcher responsvel pelo direcionamento das
requisies dos processos dos usurios conectados ao banco de dados para o processo servidor disponvel e pelo
retorno da resposta de volta para o processo do usurio apropriado.
Por sua vez, os processos lock (LCKn) so usados para controlar o lock entre instncias em uma configurao
Parallel Server.
Program interface.
O program interface o mecanismo pelo qual um processo do usurio se comunica com o processo servidor. Serve
como um mtodo de comunicao padro entre a poro cliente de uma aplicao ou uma ferramenta e o prprio
servidor ORACLE.
O program interface age como um mecanismo de comunicao, atravs da formatao dos dados requisitados,
trafegando esses dados, verificando e retornando possveis erros. Tambm executa converses de dados,
particularmente entre diferentes tipos de computadores ou tipos de dados usados pelos usurios.
Se o usurio e os processos servidores esto em diferentes computadores de uma rede ou se o processo
dispatcher estiver sendo usado para conectar processos de usurios e processos do servidor, ento o program
interface inclui um software de comunicao chamado SQL*Net, que faz a comunicao e transferncia de dados

entre computadores.
Como o ORACLE trabalha
Conhecendo os processos e estruturas de memria, fica bastante fcil para que entendamos o modo como ORACLE
trabalha:
1. Consideremos que uma instncia esteja sendo executada em um computador (servidor de um banco de dados).
2. Um computador usado para executar uma aplicao (poro cliente ou front end) executa uma aplicao de um
usurio. Essa aplicao cliente tenta estabelecer uma conexo com o servidor usando o driver apropriado do
SQL*Net.
3. O servidor est executando o driver apropriado do SQL*Net e detecta a requisio de conexo da aplicao
cliente e cria um processo servidor dedicado ao usurio.
4. O usurio executa um comando SQL e efetiva a transao com o comando COMMIT.
5. O processo servidor recebe o comando e verifica se as reas shared SQL, armazenadas na shared pool area,
contm um comando idntico ao emitido pelo usurio. Se localiza uma rea shared SQL com um comando idntico,
o processo servidor verifica os privilgios de acesso do usurio aos dados requisitados e o plano de execuo
definido usado para buscar os dados solicitados. Se o comando emitido pelo usurio no estiver presente nessa
rea, uma nova estrutura para o comando alocada e ento ele pode ser analisado e processado.
6. O processo servidor recupera qualquer valor armazenado nos arquivos de dados ou os busca da memria, se l
estiverem, no database buffer cache.
7. O processo servidor modifica os dados na SGA. O processo DBWR escreve os dados modificados em disco,
quando necessrio. No momento do comando COMMIT, o processo LGWR escreve imediatamente os registros das
transaes no arquivo redo log que estiver sendo usado no momento.
Se a transao for bem sucedida, o processo servidor manda uma mensagem atravs da rede para a aplicao. Se
no for bem sucedida, uma mensagem de erro ento emitida.
Acesso aos Dados
Antes que os dados possam ser acessados, um processo servidor criado para um determinado usurio conectado
ao ORACLE traz os blocos dos arquivos fisicamente armazenados nos discos para dentro do database buffer cache.
Cada comando SQL armazenado na estrutura de memria shared pool e so compartilhados entre todos os
usurios conectados a uma instncia. Em certo momento, os blocos de dados modificados pelos comandos dos
usurios que se encontram no database buffer cache so escritos novamente para os arquivos de dados. Isso
feito pelo processo em background DBWR.
Portanto, toda manipulao dos dados d-se na memria principal, ou seja, na SGA. por isso que os dados
precisam ser trazidos do disco para a memria antes de serem manipulados.
Usamos dois termos para referenciarmos ao acesso aos dados: cache miss e cache hit. O termo cache miss
usado para identificar as vezes que um processo experimenta acessar uma informao e o bloco que a contm
precisa ser lido do disco. O termo cache hit usado para identificar as vezes que um processo encontra uma
informao na memria. Assim, um acesso atravs de um cache hit mais rpido do que atravs de um cache
miss.
Essa a forma bsica em que se processa o acesso aos dados, usando como exemplo um comando SQL para a
atualizao de informaes em uma tabela:
SQL> UPDATE emp
2 SET sal = sal * 1.1
3 WHERE ename = 'SCOTT';

1. O usurio emite um comando UPDATE, para atualizar a coluna SAL da linha identificada pela coluna
ENAME='SCOTT' de uma tabela hipottica chamada EMP.
2. O comando emitido pelo usurio analisado e armazenado na SGA, na estrutura shared pool.
3. O processo servidor, criado quando o usurio faz a sua conexo com o ORACLE, efetua as leituras fsicas
necessrias e traz os blocos de dados armazenados nos arquivos de dados para dentro da SGA, na estrutura
database buffer cache.
4. Em seguida o ORACLE aplica a alterao definida no comando UPDATE nos blocos de dados que possuem a linha
identificada por ENAME='SCOTT'.
5. Sob certas condies, o processo em background DBWR escreve os blocos de dados alterados de volta para o
arquivo de dados fsico apropriado. Esse processo em background o responsvel por essa tarefa. Ele
simplesmente libera rea de memria do database buffer cache, j que a rea dessa estrutura limitada.
Processos de usurios e processos servidores.
Um processo de um usurio criado quando o usurio executa uma aplicao, ou seja, quando cria uma conexo
com uma instncia. Nesse momento, o ORACLE cria um processo servidor dedicado que usado para executar as
requisies do processo do usurio ao qual se associa.
Portanto, um processo servidor comunica-se com um processo de um usurio, ou seja, sempre vai ser requisitado
para executar qualquer comando. Entretanto, em algumas configuraes do ORACLE, um processo servidor pode
ser compartilhado por diversos processos de usurios, isto , no vai ser utilizado para a conexo direta com
qualquer processo de usurio; na verdade essa conexo d-se com a utilizao de outros processos. Portanto, nem
sempre verdade que um processo servidor deve estar dedicado a um processo de um usurio.
Basicamente, as funes de um processo servidor so:
1. Analisar e executar os comandos SQL.
2. Verificar se os blocos de dados encontram-se na estrutura database buffer cache.
3. Ler os blocos de dados dos arquivos fsicos no disco e lev-los para dentro do database buffer cache, na SGA.
Essa operao somente feita se os blocos de dados a serem utilizados no se encontrarem em memria.
4. Retornar resultados dos comandos SQL para os processos dos usurios que os emitiram.
Em um terminal dedicado em arquitetura multi-usurio, os processos dos usurios permanecem no servidor, assim
como os processos servidores criados pelo ORACLE . Em arquitetura cliente-servidor os processos dos usurios
permanecem na poro cliente, enquanto os processos servidores criados pelo ORACLE permanecem no servidor.
Entretanto, para o ORACLE a forma de acesso independe da arquitetura utilizada, pois as estruturas na SGA, os
processos e os prprios arquivos fsicos so basicamente os mesmos.
A estrutura shared pool e seus buffers.
A estrutura de memria compartilhada chamada shared pool contm informaes usadas para executar os
comandos SQL. formada pelos buffers denominados shared SQL, data dictionary cache e sequence cache.
Os buffers identificados como shared SQL areas contm o seguinte:
1. O texto dos comandos SQL e PL/SQL.
2. A forma analisada dos comandos SQL e PL/SQL.
3. O plano de execuo para os comandos SQL e PL/SQL.
O compartilhamento dos planos de execuo dos diversos comandos nas reas de comandos SQL compartilhados
melhoram o uso da memria, uma vez que as definies dos comandos podem ser compartilhadas entre as

diversas aplicaes.
A memria tambm dinamicamente ajustada de acordo com o conjunto de comandos SQL que so executados e,
como a fase de parse ou anlise resumida, o tempo de execuo de um comando pode diminuir
consideravelmente.
Por sua vez os buffers identificados como data dictionary cache contm:
1. Linhas com as informaes do dicionrio de dados.
Finalmente, os buffers identificados como sequence cache contm:
1. Informaes sobre os geradores de nmeros seqenciais usados pelos usurios
Database buffer cache.
A estrutura de memria compartilhada chamada database buffer cache contm cpias dos
blocos de dados que so lidos do disco pelos processos servidores. Os buffers so
compartilhados por todos os usurios conectados a uma instncia ORACLE.
O tamanho dos blocos de dados determinado pelo parmetro DB_BLOCK_SIZE,
especificado no momento da sua criao e no pode ser alterado a menos que o banco seja
novamente recriado.
O nmero de blocos lgicos em memria determinado pelo parmetro
DB_BLOCK_BUFFERS. Esses dois parmetros configuram o tamanho do database buffer
cache.
Ele organizado em duas listas: a dirty list e a least recently used list (LRU). A dirty list
uma lista que contm os blocos alterados que ainda no foram escritos em disco.
A LRU uma lista que contm blocos do ORACLE que foram alterados pelos comandos dos
usurios mas ainda no foram gravados em disco. Contm ainda blocos livres e blocos em
uso.
Assim, quando um processo servidor precisa ler um bloco de dados do disco para a memria,
ele:
1. Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado.
2. Caso esse bloco de dados no seja localizado, o processo servidor pesquisa a lista LRU em
busca de um bloco livre.
3. Em seguida, o processo servidor move os blocos alterados encontrados na lista LRU para a
dirty list, ou seja, movimenta-os para a lista de blocos alterados ainda no gravados nos
arquivos de dados, de acordo com a localizao de cada um deles, durante o processo de
pesquisa de um bloco livre.
4. Finalmente, o processo servidor efetua uma cpia do bloco de dados do disco para um
bloco livre.
5. Esse procedimento termina quando o processo servidor localiza um bloco livre ou se um
nmero especfico de blocos forem pesquisados sem encontrar um nico bloco livre.
Se nenhum bloco foi encontrado, o ORACLE deve gravar os blocos alterados da dirty list para
os arquivos em disco, para liberar espao em memria para os novos blocos de dados que
precisam ser manipulados pelos comandos dos usurios.
Operao envolvendo o comando SELECT.

Para uma operao que envolve o comando SELECT preciso que os blocos de dados que
contm as linhas a serem retornadas, de acordo com o critrio de pesquisa, estejam em
memria, no database buffer cache.
So executados os seguintes passos:
1. A lista LRU pesquisada para que os blocos de dados necessrios sejam encontrados.
2. Caso no se encontrem em memria, o processo do servidor executa as leituras fsicas
necessrias e traz os blocos para a memria.
3. Em seguida so feitas leituras lgicas em memria.
Nenhuma tabela ocupa menos de dois blocos de dados. Portanto, quando uma certa
informao armazenada em uma tabela requerida na memria, pelo menos dois blocos de
dados so necessrios: um bloco de cabealho e outro bloco com os dados.
Segmentos de rollback.
Um segmento de rollback uma poro de um banco de dados que registra as aes das
transaes dos usurios nos dados para que possam ser desfeitas sob certas circunstncias;
um objeto usado para gravar os dados alterados pelos processos dos usurios. Cada banco
de dados deve possuir pelo menos um deles.
Um segmento de rollback usado para permitir a consistncia da leitura, recuperar um
comando quando ocorre o dead-lock, recuperar uma transao at uma certa marca
identificada por um SAVEPOINT, recuperar uma transao terminada por uma falha de
processo de um usurio e desfazer todas as transaes pendentes durante a recuperao de
uma instncia.
Cada transao deve ser assinalada a um segmento de rollback. Isso pode ser feito
automaticamente baseado em alguns critrios que o ORACLE possui, como pode ser feito
manualmente pelos usurios atravs do comando:
SQL> ALTER SYSTEM USE ROLLBACK SEGMENT rbs_<numero>;
Onde:
RBS_<numero> Nome do segmento de rollback.
Operao envolvendo o comando UPDATE.
Todas as operaes de atualizao de dados em um banco de dados envolvem os segmentos
de rollback para permitir a consistncia da leitura, a recuperao das informaes e permitir
que uma transao ou um comando sejam desconsiderados ou desfeitos.
So executados os seguintes passos:
1. Os blocos de dados da tabela a ser alterada, com as linhas que sofrero as alteraes, so
trazidos para a memria.
2. Os blocos de um segmento de rollback so alocados na mesma estrutura database buffer
cache. Nesse momento, o ORACLE aloca automaticamente um segmento de rollback
disponvel ou algum especificado pelo comando ALTER SYSTEM USE ROLLBACK SEGMENT.
3. So feitos locks exclusivos nas linhas modificadas.
4. Os dados antigos so gravados em um bloco do segmento de rollback acionado
anteriormente. Nele so armazenados tambm a identificao da transao do usurio que
executou o comando UPDATE, o endereo da coluna com a especificao do bloco de dados
acionado, a identificao do arquivo fsico e o nmero da linha e da coluna a serem alteradas
em seguida.

5. As alteraes so aplicadas nas linhas da tabela em cada um dos blocos de dados que as
armazenam.
Caso o mesmo usurio que tenha executado um comando UPDATE pesquisar a tabela
atualizada, ele enxergar sua alterao. Os outros usurios no a enxergaro, isto , lero
apenas o valor antigo armazenado no segmento de rollback. Dessa forma mantm-se a
consistncia de leitura. Naturalmente, quando o usurio que executou o comando UPDATE
efetivar as alteraes com o comando COMMIT, todos os outros usurios passaro a
enxergar as alteraes feitas, exceto se algum outro estiver executando uma operao em
andamento com o comando SELECT.
Consistncia de leitura.
Durante todo o processamento de um comando SQL, o ORACLE mantm uma consistncia
dos dados de uma tabela de acordo com o momento em que o comando for inicializado.
Para o comando SELECT, o ORACLE marca o momento da sua execuo como o instante a
partir do qual a consistncia de leitura mantida.
A partir deste momento, quaisquer alteraes feitas em uma tabela por outros usurios no
so enxergadas pelo usurio que emitiu o comando SELECT, at que os outros usurios que
atualizaram a tabela terminem suas transaes, com os comandos COMMIT ou ROLLBACK.
Todas as alteraes feitas so mantidas em segmentos de rollback alocados pelo ORACLE ou
pelos prprios usurios. Para quem estiver lendo a tabela o ORACLE l os valores antigos no
segmento de rollback apropriado, e no nos blocos de dados alterados.
A seguir apresentamos o funcionamento desse mecanismo:
10 h 00 min SQL> UPDATE EMP ...;
s dez horas o usurio A executa o comando UPDATE mas no efetiva a alteraes.
10 h 01 min SQL> SELECT ... FROM emp;
s dez horas e um minuto o usurio B pesquisa a tabela EMP. Ele no enxerga as alteraes
feitas pelo usurio A. Do segmento de rollback que registrou a alterao do usurio A
trazido o valor antigo s alteraes, ocorrendo a consistncia da leitura.
10 h 02 min SQL> COMMIT;
s dez horas e dois minutos o usurio A efetiva sua transao. Como no existe nenhum
processo de leitura em andamento e no foi utilizado comando SET TRANSACTION READ
ONLY, os segmentos de rollback alocados so liberados.
10 h 03 min SQL> SELECT ... FROM emp;
Finalmente, s dez horas e trs minutos o usurio B passa a enxergar as alteraes feitas na
tabela EMP pelo comando UPDATE do usurio A, pois a transao foi terminada e efetivada
com o comando COMMIT.
Processo DBWR.
O processo Database Writer (DBWR) gerencia o database buffer cache para que os processos
dos usurios sempre localizem blocos livres para o processamento de seus comandos.
Ele escreve todos os buffers alterados para os arquivos de dados, usando o algoritmo LRU
para manter os blocos mais utilizados em memria.
O DBWR adia ao mximo a escrita dos blocos alterados para a otimizao do I/O em disco,
que uma das principais causas para a queda da performance de um banco de dados.

O processo DBWR escreve os blocos alterados para o disco quando:

1. A dirty list ultrapassar um certo limite. Essa lista usada no database buffer cache e
contm os buffers alterados.
2. Um processo pesquisar um nmero especfico de buffers na LRU sem encontrar um bloco
livre.
3. Ocorrer o time-out, ou seja, quando um certo tempo limite for ultrapassado. Esse tempo
limite geralmente de trs segundos.
4. Ocorrer um checkpoint.
Configurao multi-threaded
O ORACLE pode ser configurado em trs diferentes formas para variar o nmero dos
processos de usurios que podem estar conectados em cada processo do servidor.
Dedicated Server Um processo servidor dedicado manuseia as requisies emitidas por um
nico usurio.
Esse processo servidor criado quando ocorre a conexo de um usurio com o ORACLE.
Multi-Threaded Server A configurao Multi-Threaded Server do ORACLE permite que
diversos processos de usurios conectados a uma instncia possam compartilhar um
conjunto de processos servidores disponveis.
Esses processos servidores so fornecidos pelo ORACLE quando o usurio requisita um
comando.
Combined User/Server Process Nesta configurao os cdigos de uma aplicao e do ORACLE
so combinados em uma nica tarefa.
Essa configurao disponvel em alguns sistemas operacionais, como o VMS.
Com a utilizao apropriada dessas configuraes, podemos eventualmente melhorar o
desempenho do banco de dados. Por isso, nessa sesso discutiremos a arquitetura multithreaded, suas vantagens e a configurao do ambiente.
Quando devemos usar?
O uso do multi-threaded tem diversas vantagens em relao s outras configuraes. Com
ele podemos reduzir o nmero de processos em execuo na instncia e, dessa forma,
conseguimos aumentar o nmero de possveis usurios. O nmero de processos
desocupados pode ser drasticamente diminudo e temos uma sensvel melhora no uso da
memria.
Somente em algumas situaes especiais devemos usar a configurao de servidores
dedicados. Para a execuo de procedimentos em lote, com uma grande quantidade de
comandos SQL e para nos conectarmos como INTERNAL (para fazermos o STARTUP,
SHUTDOWN ou a recuperao do banco de dados, por exemplo), devemos usar os servidores
dedicados. Tambm devemos faz-lo em algumas situaes incomuns envolvendo os deadlocks no ambiente multi-threaded.
A arquitetura multi-threaded.
A primeira caracterizada pela conexo dos usurios. Durante uma tentativa de conexo,
um processo chamado LISTENER (que faz parte do SQL*Net verso 2) percebe a requisio e
determina se o processo do usurio pode ou no usar um processo servidor compartilhado.
Caso seja permitido, o LISTENER informa ao processo do usurio o endereo de um processo
chamado despachante, ao qual permanecer conectado enquanto durar a sua sesso.
Quando o usurio requisita uma conexo dedicada, o LISTENER cria um processo servidor

dedicado e o associa ao usurio. Essa facilidade somente possvel com a verso 2 do

SQL*Net. As verses anteriores no suportam a facilidade do multi-threaded, ou seja, elas
aceitam to somente as conexes a processos servidores dedicados.
A segunda fase caracterizada pela emisso dos comandos SQL por parte dos usurios.
Quando um deles emite qualquer comando, essa requisio recebida pelo processo
despachante ao qual o usurio est conectado. Por sua vez, o despachante coloca a
requisio em uma fila de requisies, ou fila de entrada, que se encontra na SGA. O
primeiro processo servidor compartilhado que estiver disponvel obtm a requisio na fila de
entrada e o processa. Ao trmino do processamento, o processo servidor coloca a resposta
em uma fila de respostas, nica para o despachante ao qual o usurio estiver conectado.
Finalmente, esse despachante retorna a resposta ao usurio original.
A fila de entrada, que recebe todas as requisies dos usurios, nica na instncia e
compartilhada por todos os despachantes. Essa fila do tipo FIFO, ou seja, primeiro-queentra-primeiro-que-sai (first-in-first-out). As filas de respostas so usadas para conter todas
as respostas dos comandos SQL executados pelos processos servidores compartilhados.
Cada um dos despachantes possui a sua prpria fila de respostas.
O contedo da PGA e da SGA diferencia-se quando implementamos o uso dos processos
servidores dedicados e compartilhados. A alocao de memria sem o multi-threaded, ou
seja, na configurao convencional (dedicada), difere-se da mutlti-threaded por que, nessa,
parte do contedo da PGA passa a residir na SGA; somente encontra-se originalmente na
PGA um espao para a pilha, que contm as variveis usadas por um usurio. As
informaes sobre as sesses dos usurios, que inclui dados sobre a segurana e o uso dos
recursos do ORACLE, assim como as informaes sobre o estado dos cursores, passam a
residir na SGA. Essa alterao na PGA e na SGA totalmente transparente para os usurios.
Podemos especificar o montante de memria na SGA a ser alocada para cada usurio atravs
dos profiles, que controlam o uso dos recursos banco de dados.
A configurao do multi-threaded relativamente simples. Devemos inicialmente instalar e
configurar o SQL*Net Verso 2. Sem a verso 2 desse produto ficamos impedidos de usar
essa configurao.
Nesse documento no abordaremos toda a configurao, entretanto apresentaremos, em
seguida, os passos bsicos para configurarmos uma mquina servidora de banco de dados:
Passo 1: Configurar e criar o processo LISTENER.
O LISTENER o processo que controla as conexes s instncias. Podemos ter vrios
processos rodando em uma mesma mquina; entretanto apenas um j o suficiente, pois
podemos configur-lo para suportar diversas instncias e diferenciados protocolos. Os tipos
de conexes so determinados pelos protocolos usados pelos processos despachantes.
Existe um arquivo especial, denominado LISTENER.ORA, que usamos para a configurao do
LISTENER. Geralmente ele encontra-se no diretrio $ORACLE_HOME/NETWORK/ADMIN. Em
alguns sistemas UNIX, esse diretrio default pode ser o /etc.
Entretanto, podemos especificar qualquer diretrio que desejarmos; para isso configuramos
a varivel de ambiente chamada TNS_ADMIN com o nome do diretrio desejado.
Nesse arquivo texto (LISTENER.ORA) inserimos todas as informaes sobre a configurao
do LISTENER. Abaixo, apresentamos um modelo:

################
# Exemplo do arquivo listener.ora
################
LISTENER =
(ADDRESS_LIST =
(ADDRESS =
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)

)
)
STARTUP_WAIT_TIME_LISTENER=0
CONNECT_TIMEOUT_LISTENER=10
LOG_FILE_LISTENER=listener.log
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(SID_NAME=sid1)
(ORACLE_HOME=/usr/oracle)
)
)
TRACE_LEVEL_LISTENER=0
Para criarmos o processo, usamos o utilitrio LSNRCTL:
$ lsnrctl start
Passo 2: Configurar os descritores de conexo.
Os descritores de conexo so usados para facilitar a conexo dos usurios. Eles so
armazenados no arquivo TNSNAMES.ORA, que fica nos mesmos diretrios onde podemos
encontrar o LISTENER.ORA. A seguir temos um exemplo:

###################
# Exemplo do arquivo tnsnames.ora
###################
sid1mts =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)
)
)
(CONNECT_DATA=
(SID=sid1)
)
)
sid1dedic =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.1.1.10)
(PORT=1525)
)
)
(CONNECT_DATA=
(SID=sid1)
(SERVER=DEDICATED)
)
)
Passo 3: Configurar e criar a instncia.
Devemos fechar o banco e encerrar a instncia para em seguida colocarmos o banco no ar,
usando o arquivo de inicializao com os seguintes parametros:

MTS_DISPATCHERS="tcp,3", "ipc,2"
MTS_MAX_DISPATCHERS=10

MTS_SERVERS=4
MTS_MAX_SERVERS=14
MTS_SERVICE=sid1
MTS_LISTENER_ADDRESS="(ADDRESS=(PROTOCOL=TCP)(HOST=gp.com)
(PORT=1525))"
Registro das Transaes
O ORACLE registra todas as alteraes feitas em um banco de dados na estrutura redo log
buffer cache.
Um processo em background denominado LGWR escreve as informaes desses buffers para
o disco, sob certas circunstncias.
Um outro processo em background conhecido como ARCH pode ser opcionalmente utilizado
para armazenar as informaes sobre as alteraes feitas nos dados em outro dispositivo,
sempre que um arquivo redo log for preenchido.
Somente um arquivo redo log utilizado por vez, entretanto em um banco de dados podem
existir diversos arquivos de redo log. O seu nmero mnimo de dois grupos, cada um deles
podendo conter um ou mais arquivos.
Redo log buffer cache.
O redo log buffer cache uma estrutura de memria de uso circular que contm buffers ou
conjuntos de blocos ORACLE com informaes sobre todas as alteraes feitas nos dados de
um banco de dados. Essas informaes so armazenadas sob a forma de entradas de redo
log e so usadas para recosntruir as informaes dos segmentos alterados, inclusive os
segmentos de rollback.
As entradas de redo log armazenam todas as alteraes feitas em um banco de dados dentro
da estrutura redo log buffer cache. So usadas para reconstruir ou descartar as alteraes
feitas nos dados quando uma recuperao for necessria, ou seja, armazenam a before
image e a after image. Esses termos so usados para identificarmos os dados antes e depois
de uma alterao.
Em situaes especiais, podemos desejar no registrar as alteraes nos arquivos de log. Por
exemplo, na criao de um ndice ou de uma tabela e na carga de dados atravs do
SQL*Loader; nos comandos de criao de tabelas e ndices podemos usar a clusula
UNRECOVERABLE.
O tamanho dessa estrutura determinado pelo parmetro LOG_BUFFER.
Comando UPDATE e o redo log buffer.
Como vimos, todas as alteraes feitas nos dados so armazenadas como entradas de redo
na estrutura redo log buffer cache.
Assim, a operao de UPDATE envolve realmente os seguintes passos:
1. Os blocos de dados da tabela a ser alterada com as linhas que sofrero as alteraes so
trazidos para a memria, para dentro do database buffer cache.
2. Os blocos de um segmento de rollback so alocados na mesma estrutura. Nesse
momento, o ORACLE aloca automaticamente um segmento de rollback disponvel ou algum
especificado pelo comando ALTER SYSTEM USE ROLLBACK SEGMENT.
3. So feitos locks exclusivos nas linhas a serem modificadas.
4. A imagem das informaes antes e depois das modificaes so acionadas para dentro do
redo log buffer cache como entradas de redo log.

5. Os dados antigos so gravados em um bloco do segmento de rollback acionado

anteriormente juntamente com a identificao da transao do usurio que executou o
comando UPDATE, o endereo da coluna com a especificao do bloco de dados acionado, a
identificao do arquivo fsico e o nmero da linha e da coluna a serem alteradas em
seguida.
6. As alteraes so aplicadas nas linhas da tabela em cada um dos blocos de dados que as
armazenam.
Processo LGWR.
O processo em background log writer (LGWR) escreve as entradas de redo log para o disco.
Isso acontece quando:
1. Ocorre a efetivao de uma transao com o comando COMMIT.
2. A estrutura redo log buffer atinge aproximadamente 1/3 de seu tamanho.
3. O processo em background DBWR precisa limpar os blocos dos buffers para a ocorrncia
de um checkpoint.
4. Ocorre o time-out.
Em uma instncia existe somente um nico grupo de arquivos redo log sendo utilizado para
a escrita das entradas de redo log, da memria para o disco, simultaneamente, assim como
somente um processo LGWR ativo. Enquanto uma transao no for registrada em um
arquivo redo log o COMMIT emitido no confirmado. Uma transao pode fazer com que
outras transaes sejam tambm gravadas nos arquivos redo log (piggy-backed, brincadeira
conhecida entre ns como cavalinho), quando so efetivadas simultaneamente.
Quando um grupo for preenchido, ocorre o log switch, ou seja, o prximo grupo disponvel
passa a ser utilizado. Caso o banco opere no modo ARCHIVELOG, podemos usar os
parmetros LOG_ARCHIVE_BUFFER_SIZE e LOG_ARCHIVE_BUFFERS para melhorarmos a
gravao dos mesmos para outro dipositivo.
Operao envolvendo o comando COMMIT.
O comando COMMIT efetiva as alteraes feitas nos dados por uma transao, tornando-as
permanentes.
So executados os seguintes passos:
1. Um usurio emite o comando COMMIT para finalizar sua transao.
2. Um registro desse COMMIT colocado no redo log buffer.
3. O processo em background LGWR grava as entradas de redo log dos buffers para o
arquivo redo log correntemente em uso, se possvel usando uma gravao multi-bloco.
4. O usurio notificado de que a transao foi efetivada.
5. Os locks nos recursos so liberados assim como os blocos do segmento de rollback
alocados para a transao do usurio.
Apesar de no fazerem parte do processo de COMMIT de uma transao, precisamos
assinalar que os blocos de dados so marcados como alterados e os blocos do segmento de
rollback so liberados ou marcados como reutilizveis e, eventualmente, o processo em
background DBWR pode escrever os blocos de dados alterados do database buffer cache
para os arquivos fsicos em disco.
O processo LGWR registra permanentemente todas as alteraes nos dados feitas pelas
transaes dos usurios, enquanto o DBWR adia ao mximo a escrita dos blocos alterados

nas transaes para diminuir o I/O, ou seja, reduzir o tempo de processamento da gravao
dos blocos de dados alterados que se encontram na estrutura database buffer cache para os
arquivos fsicos em disco, melhorando, assim, a performance. O I/O um dos aspectos que
causam os maiores problemas e deve ser melhorado.
Os comandos COMMIT simultneos dos usurios fazem com que as entradas de redo log
para suas transaes sejam gravadas juntas em uma nica operao de gravao fsica nos
arquivos redo log. Alm do mais, ocorre somente uma nica operao de gravao de
entradas redo log por transao, pois essa gravao ocorre no momento do COMMIT e esse
comando termina uma transao lgica. O tamanho de uma transao no afeta o tempo
necessrio para uma operao de COMMIT.