Artigo 4 da série “Arquitetura em posts”

O desenho representa o servidor de banco de dados. O que está dentro do quadrado pontilhado é a Instância que é composta pela System Global Area (quadrados azuis) e os Processos em Background (bolas verdes e amarelas). Os arquivos são representados pelos cilindros marrons.

Para montar o BD de forma que seja utilizável pelos usuários (modo open), o servidor utilizará o Control File para saber onde estão os arquivos, e o Parameter File para alocar a memória.

Após ser validado, o usuário se conectará ao BD através de um processo servidor dedicado ou compartilhado. Um pouco sobre como a conexão acontece já foi tratado aqui.

Ao receber a solicitação de update do usuário, o BD checará se o usuário tem direito de fazer isto nesta tabela. Se não tiver, o BD retornará um erro e estará encerrada a solicitação.

Caso o usuário tenha este direito, o BD tratará o update submetido, verificando se este já se encontra na Library Cache (biblioteca para códigos) e, se já estiver, será imediatamente executado. Se não estiver, será feito a análise sintática (parse), o plano de execução, armazenamento na biblioteca de códigos, e a execução.

Na execução, o Oracle primeiramente checa se os dados necessários estão no Database Buffer Cache e, caso não estejam lá, os dados serão buscados nos datafiles e transferidos para este cache.

É feito o update.

Imediatamente é aplicado um row-level lock para impedir que outros usuários tentem alterar a mesma linha, e também é registrada a transação no Redo Log Buffer.

O usuário faz então um commit para validar a transação.

Neste momento o servidor altera o dado no Database Buffer Cache, o processo Log Writer escreve a transação no Redo Log File e é retornada a mensagem de sucesso na transação para o usuário.

Outros processos ainda vão trabalhar para direta, ou indiretamente, garantir a integridade do BD:

- O processo ARC0 transferirá o on line redo log file para a área destinada aos Archive Files a cada log switch;

- O processo DBW0 escreverá o dado do Database Buffer Cache para o Datafile;

- O CKPT auxiliará a sincronia do Database Buffer Cache com os Data Files, anotando o SCN nos Control Files.

Artigo 3 da série “Arquitetura em posts”

ESTRUTURA FÍSICA:

Control Files

Contêm dados sobre o próprio BD, também conhecidos como metadados, que são informações sobre a estrutura física. Sua leitura é essencial para que o software do banco de dados consiga abrir os arquivos de dados.

Estes arquivos podem ser multiplexados para dar mais segurança, mas somente um será utilizado como primário.

Os Control Files (arquivos de controle) também guardam informações utilizadas pelo RMAN (Recovery Manager), solução de backup da Oracle.

Data Files

Arquivos de armazenamento final dos dados dos usuários ou das aplicações no BD.

Lembrando o post “Estrutura Física e Lógica”, um banco de dados pode ter múltiplos tablespaces que, cada um, pode estar armazenado em um ou mais arquivos de dados. No entanto, um arquivo é associado a um único tablespace.

Redo Log Files (on line)

Se um banco de dados parar por qualquer motivo, desde que não ocorra perda de arquivos de dados, a instância poderá voltar ao estado que estava antes do travamento aplicando os Redo Log Files.

Para uma transação ser completada e retornar uma confirmação que está ok para o usuário, o processo LGW0 precisa gravá-la no arquivo de log de redo.

ARQUIVOS ADICIONAIS:

Parameter File

Defini a configuração da instância na inicialização do BD. Entre outras coisas este arquivo contém informações de:

1. Localização dos arquivos;

2. Configurações do SGA;

3. Número de usuários que podem se conectar.

Password File

Arquivo que guarda informações de autenticação do SYSDBA e SYSOPER para administração remota.

Backup Files

Cópias de segurança utilizadas para a recuperação de banco de dados quando o arquivo original é danificado.

Archive Log Files

O processo ARC0 faz o armazenamento contínuo dos Red Log Files nos Archive Log Files, com estes arquivos têm-se um histórico das alterações de um BD. Usando o backup mais este histórico pode-se recuperar um datafile perdido.

MULTIPLEXAÇÃO

A multiplexação de um arquivo para diversos discos é uma forma de proteger o BD de falhas de mídia.

Pode-se:

1. Usar um sistema automatizado com RAID ou o ASM (produto da Oracle);

2. Multiplexar manualmente, que é fazer o Oracle gravar em diversos locais arquivos de:

a. Control Files;

b. Log de redo;

c. Archive Log Files.

Artigo 3 da série “Arquitetura em posts”

Processo Servidor

O servidor Oracle cria um processo servidor por usuário quando configurado em modo dedicado. Este processo está representado em amarelo na parte de cima do diagrama.

Cada Processo Servidor atende um único usuário e tem sua própria PGA, área que contém a memória da sessão, este processo ainda executa certas atividades como classificação, mesclagem ou junção.

No modo compartilhado não há processo servidor dedicado, o cliente se conecta com o processo dispatcher (despachante = aceita múltiplas conexões concorrentes) que faz a conexão com o BD através de processos servidores compartilhados que mantém as informações da sessão na SGA.

Processos Background

Uma instância precisa de cinco processos obrigatórios para funcionar, estes estão representados em verde no diagrama acima, e pode usar vários processos opcionais, como o ARC0, representado em amarelo no diagrama. São exemplos destes processos:

PMON

Se um usuário se desconectar de forma anormal este processo cuidará de encerrar o processo servidor deste usuário.

SMON

Utilizado na recuperação da instância em caso de falhas. Entre outras funções, é este processo que aplica os redo log files nos arquivos de dados quando a instância volta de uma situação de falha.

CKPT

O processo Checkpoint auxilia na diminuição o tempo de recuperação da instância.

Em certas condições, como o redo log switch (alternância de arquivo de log de redo), o CKPT atualiza nos datafiles e control files o SCN (system change number) e é com este número que será possível aplicar corretamente os redos log files nos datafiles numa situação de falha.

DBW0

Grava os blocos modificados (dirty blocks) do Database Buffer Cache nos datafiles.

LGW0

Grava o Redo Log Buffer no disco.

ARC0 (opcional)

Quando o modo archive está ativado, este processo faz o arquivamento dos redo log files quando ocorre switch do arquivo de log.

Cada BD deve ter, no mínimo, dois arquivos de redo log para que possa ocorrer alternância entre eles.

Processos Escravos

Esta classificação é citada pelo autor Thomas Kyte, e trata dos processos que executam trabalhos em nome de processos background ou Server. São eles:

I/O Slaves

Usado para emular gravação assíncrona em dispositivos que não suportam este tipo de gravação, como unidades de fita.

Parallel Query Slaves

Processo que possui a habilidade de pegar um comando SQL e transformar em vários planos de execução que possam ser feitos simultaneamente, conseguindo com isso aumentar a velocidade através do paralelismo. No final, os resultados de cada plano são mesclados e geram o resultado final do SQL.

Nota do autor: como classificação de tipos de processos, o item Processos Escravos não encontra amparo nos materiais oficiais da Oracle, por isso não o considere como válido para a prova de certificação.

Artigo 2 da série “Arquitetura em posts”

A parte azul do diagrama representa a estrutura de memória no Oracle, que contêm:

1. System Global Area (SGA): Compartilhada por todos os processos;

2. Program Global Area (PGA): Exclusiva de cada de processo.

No diagrama ainda temos representados processos servidores que são criados dinamicamente para atender usuários, e processos background que realizam tarefas específicas na administração e controle do BD.

Database Buffer Cache

Armazena em memória os blocos de dados recuperados do banco de dados e é onde os dados são trabalhados. Esta é uma área importante para o desempenho do BD, pois o correto dimensionamento minimizará gravações e leitura em disco.

Redo Log Buffer

Aqui ficam as informações de redo antes de serem gravadas no arquivo físico.

Estas informações servem para recuperação da instância em caso de falha. Além disso, um usuário só recebe retorno de sucesso em uma operação após o redo ter sido gravado em disco.

Shared Pool

Divide-se em dois subcaches:

1. Biblioteca: para códigos SQL e PL/SQL;

2. Dicionário de dados.

No cache de biblioteca, se um código consta no cache, a análise sintática e o plano de execução serão aproveitados; se o código não consta no cache, os procedimentos serão feitos e armazenados.

No cache de dicionário de dados estão os metadados essenciais para o funcionamento do BD (como os objetos e privilégios de usuários), estes ficam armazenados num conjunto de tabelas possuídas pelos esquemas SYS e SYSTEM.

Streams Pool

São estruturas para a utilização do Oracle Streams, recurso da versão Enterprise do Oracle, que permite a gerênci e o compartilhamento de dados e eventos em um ambiente distribuído.

Java Pool

É usado em cada sessão pela Java Virtual Machine Oracle para executar os códigos Java da mesma maneira que o SQL e o PL são executados no shared pool.

Large Pool

Certas operações precisam de grandes blocos de memória, é este recurso que reserva estas áreas no momento que as operações necessitam. Um aplicativo que comumente usa esta área é o RMAN.

Artigo 1 da série “Arquitetura em posts”

Enquanto o nosso laboratório está sendo montado, aproveito para falar de teoria.

Neste artigo vou tratar as relações e os conceitos da estrutura lógica e física do Oracle que é representada na figura abaixo.

Instance

Na instância são executados processos e espaços em memória, estes permitem ao Oracle cumprir com seu papel de manter a integridade, confidencialidade e disponibilidade dos dados armazenados.

A instância fica alocada na memória compartilhada (shared memory) e é a combinação do System Global Area (SGA) com os processos background Oracle.

Por ser fundamental no funcionamento do banco de dados (BD), a arquitetura e a descrição dos caches e processos da instância serão tratados em posts posteriores, por enquanto fiquemos com a visão geral que a instância é usada para gerência e acesso ao banco de dados.

Database

Segundo Loney e Bryla, “database é uma coleção de dados em disco em um ou mais arquivos em servidor de banco de dados que coleta e mantém informações relacionadas”.

Para um banco de dados (database) ser usado ele precisa ser montado, ou seja, associado a uma instância. Antes disso, os dados estão inacessíveis a qualquer usuário ou aplicação.

Separar a instância do banco é apenas uma forma didática de explicar, pois, na prática, esta separação não ocorre. No entanto, pode acontecer de haver múltiplas instâncias rodando na mesma máquina, cada uma associada ao seu banco de dados físico.

Nota do autor: costuma existir uma confusão entre banco de dados (database) e o servidor de BD. Pode-se dizer que o servidor de BD é a associação do banco de dados com a instância.

Schema

Representa a coleção de vários objetos de um usuário de banco de dados como, por exemplo, tabelas, índices, seqüências, sinônimos etc. São associados a um banco de dados na razão de vários esquemas para um BD.

Tablespace e Datafile

Um banco de dados é armazenado logicamente em uma ou mais tablespaces que, por sua vez, é armazenada fisicamente no disco em um ou mais arquivos para cada tablespace.

Segment

Os objetos do Banco (tabelas, índices, etc) são armazenados como segmentos. Existem diferentes tipos de segmentos, como:

- Data segments (segmento de dados): armazena os dados das tabelas não clusterizadas. Para tabelas particionadas, cada partição tem seu segmento de dados.

- Index segments: segmentos de índices. Vale a regra da partição.

- Undo segments (de undo): a informação deste segmento é usado para gerar a leitura consistente e, durante o recovery, o rollback de informações não “comitadas”.

- Temporary segments (temporários): usadas quando um comando SQL precisa de uma área temporária para completar a execução.

A relação é de um ou mais segmentos para um tablespace.

Extent

Cada segmento contém um ou mais extents, que são grupos de blocos de dados contíguos (ou adjacentes).

Por exemplo, quando se cria uma tabela, o BD aloca um número inicial de extents para o segmento, quando estes extents enchem, o BD automaticamente aloca um número incremental de extents. (Estes valores são configuráveis pela clausula STORAGE do comando CREATE TABLE ou ALTER TABLE ou podem ser otimamente dimensionados pelo Oracle).

É importante notar que cada extent só pode estar em um data file.

DB Block e OS Block

Blocos de banco de dados é o menor nível de granularidade e é onde as informações são armazenadas.

O DB Bloco é um múltiplo do OS Block (bloco do sistema operacional) e o tamanho é definido por uma variável (DB_BLOCK_SIZE) no momento da criação do tablespace.