Oracle Database – Entendendo sua Arquitetura (Parte 1)

Olá pessoal!  O tema a ser abordado. neste e no próximo post, será sobre a arquitetura Oracle – foco para certificação OCA.  Iniciarei um breve overview sobre alguns conceitos básicos em sistemas de banco de dados. Espero que apreciem…

INTRODUÇÃO

Há muito, os bancos de dados e seus repectivos sistemas gerenciadores são essenciais em nosso cotidiano. A tecnologia empregada neste nicho têm um impacto importante no crescente uso dos sistemas computacionais. Portanto, deve-se ter em mente a diferença entre os termos “Banco de Dados ou DataBase” e “SGBD – Sistema Gerenciador de Banco de Dados ou DBMS – DataBase Management System”.

Banco de Dados ou Database é uma coleção de informações relacionadas representando algum aspecto do nosso mundo real, às vezes chamado de minimundo ou universo de discurso (UoD – Universe of Discourse) [Navathe].

Sistema Gerenciador de Banco de Dados é um sistema de software de uso geral que facilita o processo de definição, construção, manipulação e compartilhamento de bancos de dados entre os diversos usuários e  aplicações, além da proteção dos dados [Navathe].  A figura abaixo ilustra os conceitos abordados e ao lado um breve descritivo dos mesmos.
 

Definição: Envolve a especificação dos tipos, das estruturas e restrições dos dados a serem armazendos; Toda esta definição ou informação descritiva do banco de dados será também armazenada pelo SGBD na forma de um catálogo ou dicionário de dados, chamado de metadados.

Construção: Processo de armazenamento dos dados em algum meio controlado pelo SGBD.

Maninpulação: São funções como consulta para recuperação de dados especificos, atualização do BD afim de refletir as mudanças no minimundo e a geração de relatórios com base nos dados.

Compartilhamento: Recurso pelo qual permite que os ususários e aplicações acessem-no simultaneamente.

Aplicações: Estas podem ser classificadas em três categorias: orientadas à transações; de suporte à decisão; e para a Internet. São programa de software que interagem com um banco de dados para acessar e manipular dados. O acesso ao BD dar-se-á ao enviar uma consulta (query) ou solicitação de dados ao SGBD.

Proteção:  Engloba-se a proteção do sistema contra defeitos e falhas de hardware e software e proteção de segurança contra acesso não autorizado e malicioso.

Basicamente, um SGDB é constituido pelos seguintes elementos:

- kernel code (código do Kernel): Código que gerencia a memória e armazenamento para o SGBD.

- Repositório de metadados (Repository of metadata): Repositório usualmente conhecido como Dicionário de Dados (Data Dictionary), é um conjunto somente–leitura de tabelas que fornecem informações sobre o banco de dados.

- Linguagem de consulta (Query language): Linguagem que permite que os usuários e aplicações acessem os dados.

Os principais modelos de  SGBDs - sistemas de gerenciamento de banco de dados foram definidos nas décadas de 1960  e 1970, vejamos:

- Modelo Hierárquico: Principal modelo de dados, simbolizado pelo IMS da IBM  em 1965, organizava os dados em uma estrutura de árvore formando uma hierarquia de registros; semelhante à estrutura de um file system num relacionamento do tipo um – para – muitos; veja a figura ao lado.

Era muito restritivo e qualquer mudança na sua estrutura de dados exigia muito esforço de reprogramação. Além disso, o acesso dos programas e/ou aplicações ao banco de dados era feito via interfaces de baixo nivel de programação, usando-se a linguagem Assembler.

- Modelo Rede: Proposto por Carles Bachman (General Eletric) em 1964, é  semelhante ao modelo hierárquico, exceto pelo fato de ter registros de dados associados formando conjuntos de dados nas interseções num relacionamento do tipo muitos - para – muitos, conforme observamos na figura  ao lado.

- Modelo Relacional: O pesquisador da IBM Edgar Frank Codd publicou em 1970 um paper intitulado "Relational Model of Data for Large Shared Data Banks" ("Modelo de dados relacional para grandes bancos de dados compartilhados"), definindo este modelo derivado da Teoria dos Conjuntos Matemáticos.  O modelo relacional de Codd armazena os dados por linhas e colunas, em tabelas.

Uma tabela (relação) é uma representação bidimensional de linhas (tuplas) e as colunas (atributos). Cada linha em uma tabela tem o mesmo conjunto de colunas. Neste modelo, as tabelas (relações) são acessadas via uma linguagem de alto nivel chamada SQL (Structure Query Language), criando um maior nível de abstração, de modo que os usuários não precisavam mais conhecer a estrutura fisica dos dados; apenas dizer o que queriam e não mais o como. Veja o exemplo abaixo:

O Oracle Database, em todas as suas versões, é uma implmementação de um SGBDR - Sistema de Gerenciamento de Banco de Dados Relacional – o qual está de acordo com o paradigma relacional. Ele é a interface entre os usuários/aplicações com a base de dados (ou banco de dados).  A figura abaixo mostra, de forma resumida, os players em uma solução de gerenciamento de banco de dados Oracle Database 11g em uma organização.

ARQUITETURA ORACLE

A arquitetrua é subdividida em duas estruturas: a física, que abrange os arquivos físicos armazenados no disco;  a lógica, que abrange memória, armazenamento lógico e estruturas lógicas do banco de dados.  

Em um servidor Oracle Database, os dois componentes que o compõe são: a Instância e o Banco de dados. Em outras arquiteturas concorrentes, como o Microsoft SQL Server e o IBM DB2, estes termos são utilizados sem qualquer distinção por seus respectivos usuários. Isto se dá porque nelas, uma coleção de bancos de dados que compartilham recursos de memória comuns são referenciados como instância.

INSTÂNCIA x BANCO DE DADOS 

Na terminlogia Oracle, o termo “Instância” refere-se as estruturas de memórias e aos processos (ou processos background - background processes). Ela é  criada temporariamente na memória RAM e na(s) CPU(s) para permitir o acesso ao banco de dados. O “time to live” de uma instância se dá enquanto sua  permanência na memória, podendo ser inicializada ou parada.  Já, o termo “Banco de Dados” refere-se aos arquivos físicos que o  compôe.

Há dois tipos de arquiteturas de instância Oracle: a de instnância única e a distribuida.

- Arquitetura de instância única: encontrada em um ambiente simples onde a relação é um-para-um, ou seja,  um banco de dados é acessado por uma só instância. A figura ao lado ilustra esta arquitetura;

- Arquitetura distribuida (RAC - Real Application Cluster): Fornece a opção  para dimensionar aplicações além da capacidade de um único servidor, provendo um ambiente de computação para o Banco de dados Oracle executar todos os tipos de aplicações corporativas de base em um conjunto de servidores em cluster (grupo de sistemas de computadores independentes, conhecidos como nós,  trabalhando juntos como um único sistema). 

Neste ambiente, a relação é de muitos-para-um, pois um  banco de dados em cluster é um único banco de dados que pode ser acessado por diversas instâncias, onde cada instância é executada em um servidor (nó do cluster) distinto. 

A figura ao lado mostra esta arquitetura.

Esta solução de arquitetrua distribuida será abordada, em profundidade,  em um post oportuno. 

Voltando à arquitetura de instância única, vemos na figura abaixo a representação simplificada de uma concexão entre um usuário e um banco de dados no servidor de Banco de Dados Oracle.  Neste processo há interagibilidade entre os seguintes componentes:  usuário, processo do usuário, processo do servidor, instância e banco de dados.

Do lado do Cliente (Front-end):

1- No host local o usuário interage com um processo de usuário conectando-se a um processo servidor no server;

2- Quando a conexão entre o processo do usuário com o processo do servidor é estabelecida, em geral, através  de uma LAN, o protocolo Oracle Net é utilizado sobre o TCP. Neste momento, os processos tanto do usuário quanto do servidor se interagem.

Do lado do Servidor:

3- O processo de servidor interage com uma instância.

4- A instância interage com o banco de dados.

Por segurança, nenhum processo do usuário interagirá diretamente com o banco de dados, sendo sempre mediado pelo processso do servidor. 

ESTRUTURAS DE MEMÓRIA 

O Oracle utiliza a memória física do servidor, criando estruturas lógicas, para armazenar diversas informações tais como:

- Códigos executáveis;

- Informações sobre cada sessão;

- Informações de processos individuais associados ao banco de dados;

- Informações compartilhadas entre os processos;

- Os dados em cache.

As estruturas de memória, criadas em um ambiente Oracle, contém as seguintes áreas:

SGA – System Global Area – Sistema de Área Global):  Grupo de estruturas de memória read/write compartilhada por todos os Processos Backgrounds e Processos Servidores; contêm dados e informações de controle para uma instância de banco de dados Oracle. Cada instância tem a sua própria SGA.

PGA -  Program Global Area – Área de Programa Global: Região da memória  não-compartilhada, que contém dados e informações de controle exclusivamente para uso por um processo. O PGA é criado pela banco de dados Oracle, quando um processo é iniciado. PGA existe para cada processo servidor e processo background.

UGA – User Global Area - Área do Usuário Global: A UGA é a memória associada a uma sessão do usuário.

Software Code Area - Área de Código de Software: é uma área utilizada ​​para o armazenamento do código executável que está ou será executado. O código do Banco de Dados Oracle é armazenado em uma área de software que normalmente é em um local exclusivo e/ou protegido.

A figura a seguir, nos mostra a estrutura da SGA e seus componentes:

A memória na SGA, também chamada de Shared Global Area, é alocada em unidades de grânulos (unidade de alocação de memória virtual contígua). A configuração mínima da SGA são três grânulos: um grânulo para a SGA fixa [inclui os buffers de redo]; um grânulo para o Cache de Buffer do Banco de Dados e um grânulo para o Shared Pool.

Dependendo do tamanho total da SGA, um grânulo pode ter 4 ou 16 MB. Se o tamanho da SGA for menor ou igual a 128 MB, um grânulo terá 4 MB; caso contrário terá 16 MB.

Vamos a um breve overview sobre os componentes mais importantes:

a) Shared Pool – Pool Compartilhado

Área de compartilhamento que armazena vários tipos de dados, como códigos PL/SQL analizados (parsed), parêmetros do sistema, e definições de dados.

- Library Cache – Cache de Biblioteca:
Armazena as informações sobre intruções SQL e PL/SQL mais executadas recentemente no banco de dados, permitindo o compartilhamento destas instruções. Consiste em duas estruturas:

-- Shared SQL Area: 

Armazena e compartilha o plano deexecução e a árvore de parse das instruções SQL executadas no banco de dados. Assim, na segunda vez em que uma instrução SQL idêntica é executada, ela aproveita as informações de parse (análise) disponíveis na SQL compartilhado,agilizando a sua execução.

-- Shared PL/SQL Area:  

Armazena e compartilha as instruções PL/SQL executadas mais recentemente. Funções, pacotes e triggers compilados, e nos quais foi efetuado parse, são armazenados nessa área.

- Data Dictionary cache - Cache de Dicionário de Dados: 

É um conjunto das definições mais usadas recentemente no banco de dados • Inclui informações sobre arquivos do banco de dados, tabelas, índices, colunas, usuários, privilégios e outros objetos do banco de dados. Quando o servidor necessita dessas informações, as tabelas do dicionário de dados são lidas e os dados retornados são armazenados nesta área.

b) Database Buffer Cache – Cache de Buffer do Banco de Dados:

Este componente da SGA, também conhecido como Buffer Cache (ou Cache de Buffer), é a área da memória que armazena cópias dos blocos de dados lidos/acessados a partir dos arquivos de dados.

Os ojetivos pelos quais o  Oracle Database utiliza-se do Buffer Cache são os de otimizar a I/O, manter os blocos de dados freqüentemente acessados ​​no cache de buffer, e gravar os blocos menos acessados no disco.

Um buffer é uma área da memória, na qual o gerenciador de buffer, temporariamente, armazena os blocos de dados lidos recentemente ou que estão sendo no momento.

Como pode-se observar na figura acima, o Buffer Cache é dividido em um ou mais Buffer Pools:

- Defualt: 

Este  é o local onde os blocos são normalmente armazenados em cache, tem o tamanho padrão que é de 8 KB.

- Keep: 

O objetivo  é manter objetos na memória, evitando assim as operações de I/O. Portanto, destina-se a blocos que foram e são acessados com frequência,

- Recycle: 

Destina-se aos blocos que são utlizados com pouca frequência. Este pool impedi que os objetos consumam espaço desnecessário no cache.

- nK: 

 Este tipo de pool, destina-se ao armazenamento de tablespace que usa o tamanho de bloco não-padrão de 2KB, 4KB e 16KB. O tamanho padrão que é de 8 KB.

c) Redo Log Buffer Cache:

Área que aramazena as informacões sobre alterações no banco de dados, utilizada para reconstruir alteracões realizadas no banco de dados por DML, DDL ou operacões internas.

d) Large Pool:

Área opcional, utilizada para as transações que interagem com mais de um banco de dados, buffers de mensagens para processos executando consultas paralelas, além de operacões de backup e recovery.

e) Java Pool:

Área opcional, utilizada pela Orace JVM para todos os cógidos e dados Java em uma sessão de usuário.

f) Stream Pool:

Área opcional, utilizada para guardar dados e estruturas de controle para oferecer suporte para os recursos do Oracle Streams.

As informações sobre a SGA e seus componentes, podem ser obtidas por meio de uma consulta a V$SGAINFO, conforme vemos abaixo:

PGA – (Program Global Area ou Process Global Area)

Região da memória que contém os dados e as informações de controle de um único processo do servidor ou de um único processo de segundo plano. A PGA é alocada quando um processo  é criado e desalocada quando o processo é encerrado. Ao contrário da SGA, que é compartilhada por vários processos, a PGA é uma área usada por apenas um processo.

O PGA é subdividido em diferentes áreas, porém o seu conteúdo varia de acordo com a configuração de execução da instância (servidor dedicado ou servidor compartilhado). Em geral, a memória PGA inclui estes componentes:

Private SQL Area – Área SQL Privada: Contém dados, tais como as informações de bind e as estruturas de memória de runtime. Cada sessão que executa uma instrução SQL tem uma área SQL privada. Cada usuário que submete a mesma instrução SQL tem uma área SQL privada própria que usa uma única área SQL compartilhada. Dessa forma, é possível associar várias áreas SQL privadas à mesma área SQL compartilhada. A área SQL privada de um cursor (nome ou identificador para uma área específica da SQL privada) divide-se em duas áreas:

-- Persistent Area – Área Persistente: 

Esta área contém valores de varáveis de ligação. Um valor de variável de ligação é fornecida para uma instrução SQL em tempo de execução quando a instrução é executada. A área persistente é libertada apenas quando o cursor está fechado.

-- Runtime Area - Área de runtime: 

Criada como a primeira etapa de uma solicitação de execução. Para os comandos INSERT, UPDATE e DELETE, essa área é liberada após a execução da instrução. Para consultas, essa área só é liberada depois que é efetuada uma operação de fetch (busca de dados) em todas as linhas ou depois que a consulta é cancelada.

SQL Work Areas: 

É  uma alocação privada da memória PGA utlizada para operações com utilização intensiva da memória  como: Classificação, Junção de hash, Intercalação de bitmap, Criação de bitmap.

Session Memory:

Consiste na memória alocada para reter as variáveis de uma sessão e outras informações relativas a essa sessão.

PROCESSOS BACKGROUND 

Quando uma instância do Oracle é inicializada, vários processos em segundo plano também iniciam. Um processo em segundo plano é um bloco de código executável projetado para executar uma tarefa específica. Ao contrário do processo em primeiro plano, como uma sessão SQL*Plus ou um navegador da Web, um processo em segundo plano funciona nos bastidores.

Cada instância executa pelo menos quatro processos em background (DBWR, LGWR, SMON e PMON), podendo haver um número de processos em background adicionais.  A Figura abaixo mostra o relacionamento entre os processos em segundo plano, o banco de dados e a SGA do Oracle.  Veremos uma breve descição de cada processo.

RECO (Recuperador): 

Utilizado com a configuração de banco de dados distribuído para resolver automaticamente falhas que envolvem transações distribuídas.

PMON (Monitor de Processos):

Executa a recuperação de processo quando um processo do usuário falha. Limpa o cache de buffer do banco de dados e libera recursos utilizados pelo processo do usuário.

SMON (Monitor do Sistema): 

Executa recuperação de travamentos, quando necessário, na inicialização da instância. Limpa os segmentos temporários que não são mais utilizados e aglutina as extensões livres contíguas nas tablespaces gerenciadas pelo dicionário.

CKPT (Ponto de verificação): 

Atualiza cabeçalhos do banco de dados para registrar os detalhes de um ponto de verificação. Não grava blocos no disco.

ARCn: 

Copia arquivos de log refazer online para armazenamento de arquivos quando os arquivos estão cheios ou ocorre uma troca de logs.

DBWn (Transcritor de Banco de Dados):

Grava buffers modificados (sujos) do cache de buffer do banco de dados em arquivos de dados.

LGWR (Transcritor de Log): 

Grava todas as entradas refazer que foram copiadas para o buffer desde a última vez em que gravou em um disco.

D000 (Dispatcher):

É executado somente quando a configuração do servidor compartilhado é utilizada. Permite que os processos de usuário compartilhem processos de servidor.

LMS (Servidor do Gerenciador de Travas):

Utilizado somente no Real Application Clusters. Fornece travamento entre as instâncias no Oracle9i Real Application Clusters.

Bom pessoal, finalizo esta primeira parte. No próximo post abordarei as estruturas de armazenamento.

[]’s e Obrigado

Juliano Ramalho

Referências:

- Sistemas de Banco de Dados - 6ª Ed. Navathe; Elmasri, Ramez 

- Oracle Essentials - Oracle Database 11g – 4ª Ed. Rick Greenwald,  
- Oracle Database 11g The Complete Reference – Kevin Loney

- Oracle Database 11g DBA Handbook - Bob Bryla and Kevin Loney 

- Oracle Database 11g A Beginner's Guide - Ian Abramson, Michael Abbey, 

- Introduction to Oracle Database - Oracle® Database Concepts 11g Release 2 (11.2) 

- Oracle Real Application Clusters 11g Release 2 - Uma opção do Banco de dados Oracle – Oracle Inc. 

- Oracle Database 11g: Interactive Quick Reference Your Essential Guide to Oracle Database 11g Release 2 

- 40 anos de SGBDR – IBM developerworks – Blog do Cezar Taurion