Otimizando Bancos de Dados Oracle com Database Smart Flash Cache

•
 
Olá pessoal,

     Hoje vou comentar sobre um recurso muito bom que surgiu no Oracle Database 11GR2 e que chama-se Database Smart Flash Cache (DSFC). Ele serve para otimizar a performance de um Banco de Dados (BD) quando a memória RAM disponível no Servidor é insuficiente para atender a demanda da Buffer Cache, criando uma nova área de memória chamada Flash Cache, que ao invés de armazenar seus dados em memória RAM, armazena-os em disco(s) SSD (Solid State Disk).

     Ao utilizar DSFC, a Flash Cache funciona como uma extensão da Buffer Cache e permite armazenar dados que não caberiam ou que consumiriam muito espaço nela. Isso permite evitar o I/O físico que seria gerado caso a Buffer Cache estivesse cheia, pois neste caso ocorreriam leituras/escritas físicas diretas nos datafiles, que estão armazenados em discos rígidos tradicionais. O grande segredo para ganhar desempenho utilizando DSFC é que evita-se o I/O físico nos discos rígidos substituindo-os por I/O nos discos SSD, que apesar de serem bem mais caros e de menor capacidade, são também mais rápidos (média de 2x à 3x mais rápidos). Mas tome cuidado! Apesar de gerar menos I/O, o consumo de CPU irá aumentar. Outro ponto que devemos nos atentar para obter boa performance com DSFC é utilizar somente DRAM SSD e não Flash SSD. Jamais utilize Flash SSD!

  

     É importante ressaltar que o I/O na Flash Cache (em discos SSD) é menos eficiente do que o I/O na Buffer Cache (em memória RAM), portanto, devemos utilizar DSFC somente quando identificarmos depois de um bom diagnóstico prévio (conhecimento que pode ser adquirido nos treinamentos Performance Tuning for Oracle DBAs), que o uso da Buffer Cache não está sendo suficiente, que não há mais memória RAM disponível no Servidor para aumentar a SGA (e consequentemente a Buffer Cache), e quando temos discos SSD no Servidor, disponíveis para a Flash Cache.
     

     DSFC é bom para uso em ambientes OLTP e ambientes com Oracle RAC, e está disponível somente para o Oracle Database Enterprise Edition (versão 11GR2 ou superior) e Sistemas Operacionais (SO) Enterprise Linux ou Solaris (mais um motivo para você evitar instalar Oracle em SO Windows). 

     Após habilitar DSFC, devemos configurar individualmente cada objeto (tabela ou visão materializada) que desejamos armazenar na Flash Cache. Uma dica é configurar apenas aqueles objetos grandes e/ou objetos que não são utilizados constantemente, e que poderiam gerar I/O físico nos discos rígidos. Em um benchmark realizado no Oracle White Paper "Optimizing Oracle Database Performance on Oracle Linux with Flash" (ver referências), o ganho de desempenho ao habilitar DSFC foi de 228% no tempo de resposta das instruções SQL que foram executadas durantes os testes.

     DSFC introduz no BD 2 novos parâmetros (ver Imagem 01), que devem ser configurados para utilizar o recurso: 

  
          1- DB_FLASH_CACHE_FILE: identifica o dispositivo flash (raw device, arquivo em um disco SSD ou ASM disk group). No Oracle DB 11GR2  (patchset 11.2.0.4 ou 11.2.0.3 + Patch 12949806) é possível especificar somente 1 dispositivo flash, mas no 12C já é possível utilizar múltiplos dispositivos. Em ambientes RAC, cada nó deve possuir o seu próprio dispositivo;

  
          2- DB_FLASH_CACHE_SIZE: identifica o tamanho máximo de armazenamento flash. Indica-se configurar entre 2 à 10 vezes o tamanho da SGA.

 Segue abaixo um roteiro para vermos um exemplo de como habilitar DSFC e configurar um objeto para que seus dados sejam armazenados na Flash Cache:

1- Habilitando a Flash Cache:

    Conectado na instância do BD, com privilégios de DBA, execute o comando abaixo para habilitar o dispositivo flash, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter system set db_flash_cache_file = '/tmp/teste.fc' scope=spfile; 

2- Configurando o tamanho da Flash Cache:

    Conectado na instância do BD, com privilégios de DBA, execute o comando abaixo para configurar o tamanho da Flash Cache, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter system set db_flash_cache_size = 100M scope=spfile; 

3- Reinicie o BD:

    Execute os comandos abaixo para reiniciar o BD e permitir que as configurações efetuadas nos itens anteriores passem a vigorar:

    SQL> shutdown immediate;

    SQL> startup;

4- Configure um objeto para que ele utilize a Flash Cache:

    Execute o comando abaixo para que uma tabela seja armazenada na Flash Cache, substituindo o texto em cor cinza pelo valor desejado:

    SQL> alter table schema.table storage (flash_cache keep);


Referências:
   - Optimizing Oracle Database Performance on Oracle Linux with Flash, An Oracle White Paper, November 2013;
   - Oracle Database Smart Flash Cache, An Oracle White Paper, September 2010;
   - Oracle flash_cache tips, IT Tips by Burleson Consulting, September 5,  2012

Blogger voltando com força total

Comunicado!

Fui obrigado a me ausentar por problemas pessoais e também para focar na certificação MCTS (Microsoft Certified Technology Specialist) SQL Server 2008, que graças a Deus conquistei.
Os estudos já estão em cima da atualização para a certificação MCSA SQL Server 2012. (Falarei em posts posteriores dos caminhos para quem quer se certificar ou atualizar suas certificações.)

O Blogger voltará com força total. Novidades na área de administração de banco de dados, B.I, Big Data, dicas de administração, tunning e certificação. Um conteúdo mais trabalhado criado com todo carinho.

Aguardem...

Hudson L. Santos

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.