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 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, 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=152 5))" 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, tornandoas 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.