Servidores SQL - SQL SERVER 7.

0 e Oracle

SQL SERVER
O SQL Server um sistema de gerenciamento de banco de dados cliente/servidor de
alto desempenho com alta integrao com o Windows NT. Suas caractersticas so:
Integrao com os servios de multithareding [ mltiplas linhas], agendamento,
Monitor de desempenho e log de eventos do Windows NT. Um usurio pode se conectar
ao SQL Server com a mesma senha usada para a rede Windows NT.
Replicao nativa permite disseminar informaes para vrios locais, reduzindo a
dependncia de um servidor nico, e deixando a informao necessria mais prxima
de quem realmente precisa dela.
Arquitetura paralela, que executa as funes de banco de dados simultaneamente para
diversos usurios, e tira proveito de sistemas com mltiplos processadores.
Gerenciamento centralizado de todos os servidores por meio de uma arquitetura de
gerenciamento distribuda, com uma interface visual de gerenciamento.

Distributed Management Framework (DMF)

O SQL Server possui uma arquitetura distribuda de gerenciamento [Distributed
Management Framework], composta de objetos, servios e componentes. Por meio
dela, vrios servidores podem ser gerenciados completamente a partir de qualquer
local na rede. Entre outros componentes, essa arquitetura composta de:

SQL-DMO: biblioteca de objetos ActiveX que expe interfaces para todas as

funes de gerenciamento do SQL Server e pode ser usada em qualquer
linguagem compatvel com automao ActiveX. Permite gerenciar servidores, banco
de dados, tabelas e outros objetos relacionados ao banco de dados.
SQL Enterprise Manager: ferramenta grfica de administrao que, utilizando
os objetos SQL-DMO, simplifica o gerenciamento de um ambiente de mltiplos
servidores.
Servios SQLServerAgent e MSSQLServer: executando no servidor NT, o
servio SQLServerAgent permite agendar tarefas, como backups, por exemplo, e
definir alertas para informar quando ocorrem condies de erro diversas. O
servio MSSQLServer o componente central, que permite inserir, atualizar e
consultar dados armazenados no SQLServer.

Ferramentas de Administrao
O SQLServer vem com vrias ferramentas de administrao que podem ser executadas

a partir de um servidor Windows NT, de uma estao Windows NT Workstation, ou at

mesmo a partir do Windows 95/98. So elas:
Enterprise Manager: como j foi dito, gerencia vrios servidores, permitindo executar
qualquer tarefa relacionada ao SQLServer. Como ser visto adiante, ele roda dentro
MMC ( Microsoft Management Console). Para execut lo por meio de Iniciar,
Executar, entre com a seguinte instruo: mmc /s "pasta-base_do_SQLServer
\BINN\SQLServer Enterprise Manager.MSC", substituindo pasta-base_do_SQLServer
pela pasta na qual voc instalou o SQLServer 7. Por padro, C:\MSSQL7.
Service Manager (SQLMANGR.EXE): permite iniciar, pausar, continuar e parar
("finalizar") os servios do SQLServer.
Query analyzer (ISQLW.EXE) : permite administrar diretamente o SQLServer usando
comandos Transact-SQL. Os comandos SQL podem ser executados interativamente, ou
podem ser executados de procedimentos armazenados ou scripts.
Profiler (SQLTRACE.EXE) : permite monitorar toda atividade do servidor e registrar
essa atividade em arquivos de log, incluindo comandos SQL executados pelo servidor.
ClientNetwork Utility (CLICONFG.EXE) : configura o software de acesso cliente numa
estao.
Performance Monitor (SQLCTRS.PMC) : integra o Performance Monitor
("Desempenho do Sistema") do Windows NT com o SQLServer para monitorar o
desempenho do sistema.
Server Network Utility ( SRVNETCN.EXE) : permite adicionar, remover ou configurar
as Net-libraries, que so os protocolos aceitos para comunicao do cliente com o
servidor.
SQL Server Books Online: toda documentao do SQL Server para consultar on-line.
Permite fazer pesquisas de texto na documentao. Para execut-lo , em Iniciar,
Executar, entre com HH pasta_base_do_SQLServer\BOOKS\SQLBOL.CHM, em que
pasta_base_do_SQLServer o diretrio em que o SQLServer foi instalado. Por padro,
C:\MSSQL7.
Uninstall SQL Server 7.0 : permite que voc remova a instalao existente do SQL
Server 7.0.</font>

MS - SQL SERVER 7.0

O MS SQL Server 7.0 foi desenvolvido para reduzir o custo total da empresa,
facilitando a criao, o gerenciamento e a distribuio de aplicativos baseados no
processamento de transaes on-line (OLTP, Online Transaction Processing). O SQL
Server fornece ajuste e administrao automatizados ao banco de dados com excelente
desempenho, bem como ferramentas sofisticadas para operaes complexas. Inovaes

na facilidade de uso, escabilidade, confiabilidade e desempenho, um modelo de

programao rpida e simples para desenvolvedores, novo bloqueio dinmico no nvel
de linha, backup ativo e gerenciamento multilocal fazem do MS-SQL Server 7.0 a
escolha ideal para operaes da empresa.

Oracle
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.

</font>
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.</font>
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:

Consideremos que uma instncia esteja sendo executada em um computador

(servidor de um banco de dados).
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.
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.
O usurio executa um comando SQL e efetiva a transao com o comando
COMMIT.
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.
O processo servidor recupera qualquer valor armazenado nos arquivos de dados
ou os busca da memria, se l estiverem, no database buffer cache.
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';

O usurio emite um comando UPDATE, para atualizar a coluna SAL da linha

identificada pela coluna ENAME='SCOTT' de uma tabela hipottica chamada EMP.
O comando emitido pelo usurio analisado e armazenado na SGA, na estrutura
shared pool.
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.

Em seguida o ORACLE aplica a alterao definida no comando UPDATE nos blocos
de dados que possuem a linha identificada por ENAME='SCOTT'.
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.</li>

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:

Analisar e executar os comandos SQL.

Verificar se os blocos de dados encontram-se na estrutura database buffer cache.
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.
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:

texto dos comandos SQL e PL/SQL.

A forma analisada dos comandos SQL e PL/SQL.

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:

Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado.
Caso esse bloco de dados no seja localizado, o processo servidor pesquisa a lista
LRU em busca de um bloco livre.
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.
Finalmente, o processo servidor efetua uma cpia do bloco de dados do disco para
um bloco livre.
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:

A lista LRU pesquisada para que os blocos de dados necessrios sejam

encontrados.
Caso no se encontrem em memria, o processo do servidor executa as leituras
fsicas necessrias e traz os blocos para a memria.
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:

Os blocos de dados da tabela a ser alterada, com as linhas que sofrero as

alteraes, so trazidos para a memria.
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.
So feitos locks exclusivos nas linhas modificadas.
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.
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;</font>
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:

A dirty list ultrapassar um certo limite. Essa lista usada no database buffer
cache e contm os buffers alterados.
Um processo pesquisar um nmero especfico de buffers na LRU sem encontrar um
bloco livre.
Ocorrer o time-out, ou seja, quando um certo tempo limite for ultrapassado. Esse
tempo limite geralmente de trs segundos.
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
multi-threaded, suas vantagens e a configurao do ambiente.</font>

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 dead-locks 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, primeiroque-entra-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 multithreaded, ou seja, na configurao convencional (dedicada), difere-se da mutltithreaded 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
))" </font>

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:

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.
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.
So feitos locks exclusivos nas linhas a serem modificadas.
A imagem das informaes antes e depois das modificaes so acionadas para
dentro do redo log buffer cache como entradas de redo log.
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.
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:

Ocorre a efetivao de uma transao com o comando COMMIT.

A estrutura redo log buffer atinge aproximadamente 1/3 de seu tamanho.
O processo em background DBWR precisa limpar os blocos dos buffers para a
ocorrncia de um checkpoint.
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 diapositivo.

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:

Um usurio emite o comando COMMIT para finalizar sua transao.

Um registro desse COMMIT colocado no redo log buffer.
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.
O usurio notificado de que a transao foi efetivada.
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.