SQL em Oracle > Introdução > A arquitectura do SGBD Oracle
A arquitectura do SGBD Oracle |
|
A figura abaixo ilustra a arquitectura de um SGBD Oracle:
O ambiente onde corre uma base de dados Oracle é constituído por um conjunto de ficheiros em disco (Data files), um conjunto de processos (Background Processes, Server Processes e User Processes), uma área de memória partilhada por esses processos (SGA - System Global Area) e um Listener.
- "Data files" - são ficheiros armazenados no disco do servidor, onde o Oracle armazena os dados e as estruturas de controlo da base de dados;
- "SGA" - área de memória do servidor utilizada para armazenar dados partilhados pelos vários utilizadores da base de dados. Armazena dados, informação de controlo e instruções SQL. A sua dimensão pode variar entre alguns Mega e vários Giga. Funciona como um buffer, pelo que se aplica o principio, quanto maior a sua dimensão, menor o tempo de resposta da BD;
- "User process" - processo que executa o código do utilizador e faz os pedidos ao Oracle. Pode ser o SQL*Plus ou um programa Java. Pode correr no próprio servidor mas normalmente corre na máquina cliente. Comunica com um Server process;
- "Server process" - processo que recebe a missão de satisfazer os pedidos de um user process. Corre na mesma máquina que a base de dados (no servidor). É iniciado quando um user process abre uma ligação e termina quando a ligação é fechada. Interpreta os pedidos do cliente e executa-os, lendo os dados dos data-files ou da SGA e gerindo o envio dos resultados para o cliente. Numa configuração standard existe um server process para cada user process. Se houver problemas de memória no servidor o server process pode ser partilhado (em timesharing) por vários user processes;
- "Background processes" - são vários processos que correm concorrentemente no servidor, cada um com uma missão específica, como por exemplo: a escrita dos dados alterados na SGA para os data files, a verificação de consistência da base de dados ou a limpeza de recursos em memória não utilizados;
- "Listener" - recebe um pedido de ligação de um cliente, determina um porto de comunicações livre e lança um server process para tratar do user process. A partir daqui todo o diálogo se processará entre o user process e o server process;
Suponha que um utilizador vai submeter a seguinte transacção:
select * from employees
where employee_id=:1
for update of salary;
update employees
set salary=:2
where employee_id=:1;
commit;
|
A sequência de operações é a seguinte:
- O cliente process envia a instrução ”Select ... for update;” para o server process;
- O server process procura na Shared Pool (parte da SGA que armazena instruções SQL) uma instrução SQL idêntica à que vai ser executada. Se não encontrar vai compilar a nova instrução (parsing) e armazena-a na Shared Pool. A compilação consome CPU, enquanto que o armazenamento na Shared Pool utiliza um latch (semáforo interno do SGBD Oracle);
- O server process procura na Buffer Cache (parte da SGA que armazena blocos de dados) os dados que necessita. Esta operação consiste num Logical Read. Se encontrar os dados estes têm que ser movidos para o fim da fila LRU (Least Recently Used), operação que requer um latch;
- Se o server process não encontrar os blocos na Buffer Cache tem que os ir buscar aos data files. Esta operação chama-se Physical Read e requer uma ou mais leituras de I/O;
- Quando encontra os dados os blocos que os contêm são colocados na Buffer Cache, o que requer a utilização de um latch. Como se trata de um select for update, os dados recebem um lock que, enquanto estiver activo, inibe outro server process de os modificar;
- O server process envia os dados para o cliente. A velocidade desta operação depende de:
- Capacidade do servidor em retirar todos os dados;
- Desempenho da rede;
- Capacidade do cliente em receber e processar os dados;
-
Terminado o “select for update” vamos submeter o update;
Esta instrução segue os mesmos passos da anterior até ao ponto 5. Muito provavelmente os dados já estão em memória e portanto não são feitas leituras em disco;
Uma cópia de todos os blocos selecionados para update é guardada nos segmentos de rollback. Os blocos são depois alterados. Isto é feito na Buffer Cache e portanto requer latches.
Os blocos alterados em memória ficam dirty pois ainda não foram escritos no respetivo datafile;
- As alterações são replicadas na Redo Buffer. É usado um formato de escrita sequencial e resumido;
-
O comando update termina na etapa anterior, o que leva o utilizador a executar o terceiro comando: COMMIT;
O SGBD tem que escrever em disco antes de concluir o commit. Como a escrita no datafile é lenta o SGBD tem que garantir que todo o conteúdo da Redo Buffer passa para disco;
O Log Writer escreve o conteúdo da Redo Buffer no Redo Log File ativo. Só depois disso é confirmado o commit e libertados os locks. Quando o Redo Log File ativo enche o SGBD começa a escrever no outro;
- Se a base de dados estiver em Archive Mode o processo Archiver corre em background. Quando um Redo Log File fica inativo o seu conteúdo é copiado para outra localização. O SGBD fica assim com uma cópia das alterações, o que permite fazer recover de dados. Um Redo Log File não pode ser reutilizado se não for arquivado, pelo que a base de dados pode parar por estar à espera do processo Archive;
- Os blocos dirty são escritos para disco pelo processo Database Writer que está sempre em background. Este processo acorda quando:
- O espaço ocupado pelos dirty blocks é necessário para outros blocos;
- Ocorre um checkpoint: por timeout ou por mudança de Redo Log File;
- O SGBD efectua um checkpoint a intervalos regulares de tempo ou quando ocorre uma troca de Redo Log File;
O checkpoint obriga a que todos os blocos alterados na buffer cache (dirty) sejam escritos nos respectivos data files. Este evento pode provocar contenção na escrita em disco;
A execução por timeout destina-se a garantir que os blocos dirty são escritos no sitio certo passado algum tempo (definido pelo DBA);
Topo
Realizado por Turtle Learning ®. Última alteração em 2011-02-26