SQL em Oracle > Introdução > A arquitectura do SGBD Oracle
A arquitectura do SGBD Oracle tl_logo2.jpg

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.

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:

  1. O cliente process envia a instrução ”Select ... for update;” para o server process;
  2. 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);
  3. 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;
  4. 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;
  5. 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;
  6. O server process envia os dados para o cliente. A velocidade desta operação depende de:
    1. Capacidade do servidor em retirar todos os dados;
    2. Desempenho da rede;
    3. Capacidade do cliente em receber e processar os dados;
  7. 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;
  8. As alterações são replicadas na Redo Buffer. É usado um formato de escrita sequencial e resumido;
  9. 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;
  10. 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;
  11. Os blocos dirty são escritos para disco pelo processo Database Writer que está sempre em background. Este processo acorda quando:
  12. 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);

bthome.gifTopo


Realizado por Turtle Learning ®. Última alteração em 2011-02-26