Oracle: Criando campo como chave primário e de sequencial automático

Pessoal, boa tarde!
Hoje vamos falar de uma coisa bem simples, mas que faz uma grande diferença na hora de inserir registros na tabela. Quando queremos criar um sequencial, mas não podemos criar em cima de um campo que será índice.

Para esses casos, vai uma dica,  criar um campo que será PK e que será um sequencial da tabela.
Para continuar no exemplo, iremos criar uma tabela Funcionário, como mostra o Script abaixo:


create table FUNCIONARIO (
FUNC_SEQ NUMBER(10),
NOME VARCHAR2(10),
SALARIO NUMBER(17,2),
CODIGO NUMBER);


Vamos alterar a nossa tabela para receber a Chave Primária.

alter table FUNCIONARIO add constraint PK_FUNCIONARIO primarykey (FUNC_SEQ);


Agora vamos criar uma sequência:

CREATE SEQUENCE FUNC_SEQ MINVALUE 1 MAXVALUE 9999999999
INCREMENT BY 1 START WITH 1;

Essa sequência irá até o valor “9999999999”, já que o tamanho do campo vai até 10.


Após ter criado essa sequência, iremos criar uma TRIGGER para alimentar o campo Func_Seq com a sequência criada.

CREATE O RREPLACE TRIGGER FUNC_TRG BEFORE INSERT ON FUNCIONARIO
FOR EACH ROW
BEGIN
<<COLUMN_SEQUENCES>>
BEGIN
IF :NEW.FUNC_SEQ IS NULL THEN
SELECT FUNC_SEQ.NEXTVAL INTO :NEW.FUNC_SEQ FROM DUAL;
END IF;
END COLUMN_SEQUENCES;
END;  

Toda vez que inserirmos algum registro, não será necessário incluir um valor para o campo Func_Seq.
Exemplo:
INSERT INTO FUNCIONARIO(NOME, SALARIO, CODIGO)
VALUES (‘JOSE’, 1500, 2);

Com a nossa Trigger, ele já irá atribui de forma automática o novo valor para campo Func_seq.
Galera, eu sei que é bem simples, mas as vezes nos ajuda bastante.

Abraços.

Indices (o poder da busca). Parte II

Indicies clusterizados vs Índices não clusterizados

Índices clusterizados:

     Cada tabela só pode conter apenas um índice clusterizado.
     Os índices clusterizados fornecem uma ordem de classificação para o armazenamento de dados dentro de uma tabela, mas não fisicamente pois, geraria grande volume de I/O (Entrada e saída de disco).
      Em geral toda tabela deve ter um indicie clusterizado, normalmente definimos como chave primaria.

     Um dos principais objetivos de um indicie clusterizado é eliminar os ponteiros de encaminhamento. Lembra-se da estrutura B-Tree? Caso não tenha lido, recomendo o artigo: Estrutura B-Tree, resumindo, as informações são armazenadas nas folhas e para que o SGDB busque as informações, são 'rastreadas' pelas chaves de indicie que é o numeral que indica o numero da linha em questão.
 
      Existem algumas restrições para os indicies clusterizados: Podem ter 900 Bytes na chave de indicie e no máximo 16 colunas. 
Por padrão, o SQL Server cria indicie clusterizado exclusivo para a chave primaria.

Índices não clusterizados:

      Os índices não clusterizados não impõem uma ordem de classificação na tabela. Podem-se criar vários indicies não clusterizados dentro de uma tabela e como os índices clusterizados, podem ter no máximo 900 Bytes na chave de índice e no máximo 16 colunas.

    Se existe um índice clusterizado na tabela, o índice não clusterizado possuem ponteiros que apontam para o índice a chave de cluster. Se não existe índice clusterizado, o indicie não clusterizado aponta para a linha de dados na tabela. Isto faz com que seja feita mais uma operação necessária para localizar dados dentro de uma linha na tabela degradando um pouco a desempenho em comparação a tabela existir um índice clusterizado.


Performance:

    Podemos imaginar que podemos então encher uma tabela com índices já que são tão formidáveis assim.
Não é bem por ai, cada linha adicionada em uma tabela ou excluída, fará com que o SGDB reconstruía o indicie na arvore B-Tree. Se houver um estouro de pagina, haverá a divisão de níveis e o SGDB terá que recalcular e alocar as chaves de indicies nas paginas da estrutura B-Tree.

    Embora sejam eficientes para consultas SQL, temos esta restrição de recriação de estrutura de dados B-Tree quando ocasionamos operações de INSERT, UPDATE, DELETE.

   Nos bancos OLTP isso pode ser bastante prejudicial devido à quantidade de transações no banco, então cada índice criado temos que analisar suas intenções dentro da tabela e ver se realmente ele é necessário e testar o qual o ganho que podemos ter.
    Dentro de bancos OLAP, como o nível de transações são baixos e a inserção de dados é normalmente através de operações em lote e agendada em horários com baixa incidência de consultas, é bastante interessante ter vários índices nas colunas mais acessadas.

Indices (o poder da busca). Parte I

    Para falarmos dos indicies primeiramente precisamos entender a estrutura de busca de um SGDB à informação.
     A estrutura de busca por indicies das principais ferramentas de SGDB do mercado usa uma arquitetura de busca mais conhecida com B-Tree. 
     A arquitetura de busca B-Tree se baseia em um conceito de paginas de alocação de dados.
Vejamos a figura abaixo:

   
Nota-se claramente que temos 3 níveis, dai o nome B-TREE. Cada nível tem a denominação:

     Primeiro nível: Raiz;
     Segundo nível: Intermediário;
     Terceiro nível: Folhas.

      Em especial no SGDB SQL Server, cada página pode possuir até 8.060 Bytes de dados.
      Se guardarmos um valor de índice INT, (lembrando que para coluna de valor  INT são alocados 4 Bytes), teremos uma conta simples: 8.060 / 4 = 2.015 linhas que será armazenado em cada folha. Caso ultrapasse este valor, 2.016 linhas serão alocadas mais uma folha e a distribuição dos dados entre elas como podemos ver observando a figura de baixo para cima os valores de 1 a 500.

      Na primeira folha foi alocado 1 a 250, quando necessitou do alocamento do valor 201, subitamente quebrou-se a quantidade de dados suportados por uma pagina (8.060 Bytes), assim sendo, foi-se necessário adicionar mais uma pagina de dados para alocar o valor 251. Logo acima, foi criado mais um nível contendo as entradas para os níveis subsequentes. Como se fossem ponteiros onde teremos o ponteiro para o lado esquerdo informando: "Ei, do meu lado esquerdo temos os valores de 1 até 250, e do meu lado direito temos os valores de 251 em diante".. E assim sucessivamente.
  
      É muito difícil de que um SGDB tenha dados suficiente de índice para montar os três níveis, pela simples conta:
      Se cada nível pagina de folha consegue alocar 2.015 entras, ou seja, no nível abaixo temos para cada pagina podemos alocar 2.015 folhas temos a multiplicação de 2.015 folhas por 2015 entradas de dados do nível acima, dando o valo de 4.060.255. Ou seja, só é necessário apenas duas paginas para encontrar qualquer dado entre 1 a 4060255 linhas em uma tabela. "Isso mesmo, apenas duas paginas para 4 milhões de linhas".

     Este tipo de estrutura permite que o SGDB encontre linhas em tabelas extremamente grandes muito rapidamente.
     Como podemos notar a estrutura B-Tree de índices funciona praticamente como índice de um livro ou dicionário. Você abre o começo do livro, procura pela palavra/assunto que deseja e verifica a pagina que está palavra/assunto está. É muito mais ágil do que percorrer todo livro em busca da palavra/assunto que lhe convém.

Próximo post continuaremos com Índices e seus tipos.
Até..

Entendendo a arquitetura ORACLE

Temos no produto Oracle uma instancia e um banco. Claro, você pode usar varias instancias para acessar um banco de dados Oracle o que ocorre no Real Aplication Cluster ou cluster de aplicativos reais. Também é possível editar links para a instancia acessar outros bancos Oracle, mas iremos focar no um-para-um, ou seja, uma instancia para um banco.

Estrutura da instancia: Memória e Processos.

Uma instancia Oracle consiste em um bloco de memória compartilhada, conhecida como SGA (System Global Área) a que possui basicamente três elementos obrigatórios: Pool compartilhado, cachê de buffer do banco e o buffer de log. Opcionalmente poderá ter pool extenso, Java pool e um pool de streams.

O Pool compartilhado:

No pool compartilhado iremos abordar dois componentes de sua estrutura: O cachê da biblioteca de dados e o cachê de dicionário de dados.

O cachê de biblioteca de dados consiste em armazenar as instruções SQL na sua forma interpretada. Ajuda no desempenho para evitar que se interprete sempre instruções mais usadas no banco. Quando um usuário fornece uma instrução para o banco, ela será armazenada no cachê de biblioteca de dados para que seja usada posteriormente pelo mesmo usuário ou por outros evitando assim processos para a interpretação da mesma.

O cachê de dicionário de dados armazena objetos, descrições de tabelas, índices usuários e outras definições de metadados.

Cachê de buffer do banco:

O cachê de buffer do banco de dados é uma área onde são executados as instruções SQL. Antes dos dados irem para parte física são armazenados na cachê de buffer aguardando uma confirmação para acesso ao disco. Isto evita E/S em disco desnecessário alem de ser uma segurança para os dados.

Buffer de log:

Usado para armazenamento de todas as modificações aplicadas aos dados presentes no cachê de banco de dados. Está parte da memória só é usada quando os dados armazenados no cachê de banco são manipulados.

Pool extenso:

Uma área opcional a ser criada. Usada automaticamente por vários processos que de uma forma tomaria a memória do pool compartilhado. O gerenciador de recuperação (Recovery Manager, RMAN), também usará o pool extenso para seus processos de E/S.

Pool Java:

Requerido para instanciar os objetos do Java.

DICA Exame:  Os três principais elementos da instancia Oracle são: Pool compartilhado, cachê de buffer do banco e pool de log.

SMON Monitor de sistema,

Função de habilitar as conexões entre o banco e a instancia.

PMON Monitor de processos,

Procura e organiza sessões de usuários, mantendo até mesmo historio de sessão caso desconexão imprevista de algum usuário para que o mesmo ao se conectar novamente, volte aos seus processos.

DBWn Escritor do bano de dados,

Escreve as atualizações do cachê de buffer do banco para o disco fisico. Normalmente o Oracle mantém essas atualizações no mínimo de nível possível para evitar assim E/S o que ajuda substancialmente o desempenho do banco.

LGWR Escritor de logs,

Envia todas as modificações que foram feitas entre o cachê de buffer de banco para o disco, atualizando os redo on-line. Ao efetivar uma modificação com o COMMIT, será escrito nos arquivos de redo log on-line a modificação que foi realizada e a partir daí efetivada no banco físico. Isso garante um auto backup onde podemos dizer que o Oracle efetivamente garante que seus dados não serão perdidos.

CKPT checkpoint.

De tempos em tempos o banco atualiza os arquivos de cachê do banco de dados para o disco, este processo é feito pelo CKPT.