Reindexar Banco de Dados SQL SERVER

O que é indexar, reindexar e por que é importante?

Imagine uma biblioteca, onde existam vários livros e muitos estudantes utilizam essa biblioteca diariamente, pegando livros das estantes para ler.

Para facilitar o estudante encontrar o livro, os livros estão organizados em estantes que são separadas por áreas, como humanas, exatas e assim por diante.

Isso se compara a um índice no Banco de Dados, onde a biblioteca é o banco(tabela) e os livros são os registros, e o fato de estarem organizados(indexados) facilita na hora de encontrar um registro.

Porém, os estudantes quando pegam um livro não podem devolver novamente no mesmo lugar, pois poderiam cometer algum erro e estragar a ordem dos livros, então deixam-no sobre uma mesa para que a pessoa responsável organize quando puder, para que esses livros não fiquem indisponíveis quando outro estudante precisar deles, a pessoa responsável mantém uma lista com todos os livros que estão sobre a mesa, para que caso o estudando não localize o livro, ela veja se o mesmo não está sobre a mesa.

Da mesma forma, ela mantém uma lista para livros novos que chegaram e ainda não foram organizados nas estantes e para livros que foram retirados do acervo. E assim que possível, ela reorganiza os livros para que fiquem na ordem novamente deixando mais rápida a busca.

Contudo, este trabalho não pode ser feito o tempo todo, pois os estudantes teriam que ficar esperando que ele se completasse para que então pudessem pegar os livros que estão procurando.

O fato de reindexar uma tabela se compara ao ato de recolocar os livros nas estantes novamente e eliminar as listas paralelas, ou seja, quando inserimos, atualizamos ou deletamos um registro, o índice fica desfalcado desses registros, é como se eles estivessem em uma lista separada, porém a reindexação não pode ser feita o tempo todo e automaticamente, pois necessitária que quem estivesse tentando acessar a tabela em questão precisasse esperar o termino da reindexação.

por isso é importante de tempos em tempos que façamos a reindexação das tabelas do nosso banco de dados, assim deixaremos o acesso aos dados mais rápido.

bom, para reindexar uma tabela no SQL SERVER, precisamos executar o seguinte comando:

DBCC DBREINDEX ('NOME_DA_TABELA', '', 80)

Onde o primeiro parâmetro se refere ao nome da tabela, o segundo ao nome do índice(opcional) e o terceiro é o percentual de cada index em relação ao armazenamento dos dados.

Para reindexar um banco inteiro, basta utilizar a sotored procedure SP_MSFOREACHTABLE que é responsável por percorrer todas as tabelas do banco e executar um comando designado.

EXEC SP_MSFOREACHTABLE @command1= "DBCC DBREINDEX ('?', '', 80)"

Pronto, todas as tabelas do seu banco estarão reindexadas e provavelmente haverá melhora na performance do mesmo.

Obs: Se possível realize está operação quando não houver usuários utilizando o banco. pois bloqueia o acesso a tabela até que o índice seja refeito.

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.