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.
Ferramentas de Administrao
O SQLServer vem com vrias ferramentas de administrao que podem ser executadas
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.
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.
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';
Por sua vez os buffers identificados como data dictionary cache contm:
1. Linhas com as informaes do dicionrio de dados.
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.
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
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
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
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>
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
###################
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)
)
)
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.
Processo LGWR.
O processo em background log writer (LGWR) escreve as entradas de redo log para o
disco. Isso acontece quando:
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.