14 de mar. de 2013


Olá pessoal!

Existem algumas formas de se analisar os scripts submetidos ao banco de dados Oracle quanto a sua performance.  Uma dessas formas é através de uma view do esquema SYS chamada V_$SQLAREA, ou através do sinônimo público V$SQLAREA que está setado para a tabela.

Bom, de qualquer forma, nesse objeto existem informações interessantes para o acompanhamento dos scripts submetidos ao servidor de banco, mesmo que eles não tenham sido concluídos com sucesso.

A consulta é a seguinte:

SELECT *
  FROM (  SELECT ROUND ( ( (cpu_time / 1000000) / 60), 2) AS "Tempo total de CPU",
                 executions AS "Quant. exec.",
                 rows_processed AS "Quant. linhas proc.",
                 disk_reads AS "Leituras no disco",
                 first_load_time AS "Primeira utilização",
                 last_load_time AS "Última utilização",
                 parsing_schema_name AS "Usuário analisado",
                 sql_text AS "SQL exec."
            FROM v$sqlarea
           WHERE parsing_schema_name NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'DBSNMP')
        ORDER BY 1 DESC)
 WHERE ROWNUM <= 10;

Nesse caso, a seleção da consulta mais externa (cláusula where) faz com que o retorno sejam de apenas os 10 scripts com maior tempo total de CPU (garantido no sort da consulta interna), mas podemos alterar esse valor ou retirar a condição. Na seleção da consulta mais interna, retirei os usuários de controle do DBA e do próprio SGBD Oracle, para que a análise possa ser feita apenas por aplicações e pessoas.

Vou explicar rapidamente as informações da projeção (cláusula select):

"Tempo total de CPU" – nesse “campo” é retornado o tempo total de CPU gasto para executar todas as vezes o script em questão. Fiz uma continha para exibir o tempo em minutos;

"Quant. exec" – nesse “campo” é retornado a quantidade de vezes que o SQL em questão foi executado desde sua primeira vez que foi submetido;

"Quant. linhas proc." – nesse “campo” é exibido a quantidade total de linhas processadas em todas as execuções da SQL em questão;

"Leituras no disco" – nesse “campo” é retornado a quantidade total de leituras realizadas no disco;

"Primeira utilização" – informa a data e hora da primeira utilização da SQL em questão, ou pelo menos a mais recente das “primeiras vezes”;

"Última utilização" – informa a data e hora da última utilização da SQL em questão;

"Usuário analisado " – informa qual o usuário da instância Oracle que realizou a SQL;

"SQL exec." – informa o script SQL submetido.

Grande abraço e até a próxima!!

Raphael Fernandes, quinta-feira, março 14, 2013

6 comentários

13 de mar. de 2013


Muito bom dia a todos!

Hoje vou falar sobre um comando SQL que não vejo muita gente usar mas que é bem poderoso. Esse comando é o MERGE.

Vejo muito código em PL/SQL da seguinte forma:
DECLARE
   var_existe   NUMBER (4) := 0;
BEGIN
   SELECT COUNT (cod)
     INTO var_existe
     FROM tabela
    WHERE cod = :par_cod;

   IF var_existe > 0 THEN
      --Significa que existe valor para o parametro buscado (par_cod)
      UPDATE tabela SET campo = :par_campo WHERE cod = :par_cod;
   ELSE
      --Significa que NÃO existe valor para o parametro buscado
      INSERT INTO tabela  VALUES (:par_cod, :par_campo);     
   END IF;
  
END;

Abstraindo o nome da tabela e seus campos, e levando em consideração à estrutura do bloco de código, basicamente o que é feito é um teste se um determinado valor (:par_cod) existe na tabela, caso exista, será realizada uma alteração (UPDATE) caso contrário será inserido um registro com aquele código (INSERT).

Agora vou falar um pouco sobre o MERGE e depois associar o comando com o bloco PL/SQL acima. 

Segundo Watson, O merge foi introduzido no SQL com o padrão SQL1999, e implementado no Oracle a partir da versão 9i. No Oracle Database 10g o comando foi aprimorado para entrar em conformidade com o padrão SQL2003.

O propósito principal do comando merge é justamente o mesmo do bloco lógico apresentado anteriormente. Uma operação merge não faz nada que não possa ser feito com as instruções INSERT, UPDATE e DELETE – mas com uma passagem pelos dados de origem, ela pode fazer as três coisas. Código alternativo sem MERGE iria exigir três passagem pelos dados, uma para cada comando.

Os dados de Origem para uma instrução MERGE pode ser uma tabela ou uma sub-consulta qualquer. A condição usada para encontrar linhas correspondentes no destino é similar a uma cláusula WHERE. As cláusulas que atualizam, inserem ou excluem linhas são semelhantes aos comandos update, insert e delete. Alguns autores e profissionais  de banco de dados afirmam que o MERGE é o mais complicado dos comandos DML, porém um dos mais poderosos.

A sintaxe do MERGE, em sua forma básica é a informada na Figura 1.
Figura 1 - Estrutura do comando MERGE. (Fonte: Orale Corporation)

Na Figura 1, as operações DML não estão especificadas, então seguem algumas imagens complementares.

Na Figura 2, é apresentada a sintaxe para realizar um UPDATE na linha para o caso de correspondência (MATCHED) na comparação realizada no comando.

Essa mesma estrutura apresentada na Figura 2 pode ser utilizada para a exclusão de linhas na tabela em questão.
Figura 2 - UPDATE/DELETE no MERGE caso a comparação realizada corresponda. (Fonte: Orale Corporation)

Para o caso de não existir uma correspondência na comparação realizada no comando, um INSERT pode ser realizado conforme apresentado na Figura 3.
Figura 3 - INSERT no MERGE caso a comparação realizada não corresponda. (Fonte: Orale Corporation)

Em ambas as situações, Figura 2 e 3, existem um trecho chamado “where_clause, que nada mais é que uma cláusula WHERE normal, no formado: WHERE condição.

Na Figura 1, existe um trecho chamado “error_loggin_clause”, que possui sua sintaxe conforme Figura 4. Sua utilidade é para o caso de erros na execução do comando MERGE. O registro na tabela de log será efetivado caso ocorra algum problema. Para se criar uma tabela para o log do Oracle usa-se o pacote DBMS_ERRLOG.CREATE_ERROR_LOG. Como não é nosso foco principal não abordarei profundamente a questão, mas recomendo a leitura do assunto para um entendimento melhor (é interessante).
Figura 4 - Tratamento de erros no comando MERGE. (Fonte: Oracle Corporation)

Aplicando a sintaxe acima ao nosso bloco lógico citado no início do post temos o seguinte:
MERGE INTO tabela t
     USING (SELECT :par_cod AS cod FROM DUAL) t_aux
        ON (t.cod = t_aux.cod)
WHEN MATCHED THEN
   UPDATE SET campo = :par_campo
WHEN NOT MATCHED THEN
   INSERT     VALUES (:par_cod, :par_campo);

Fiz uma simulação de consulta utilizando a tabela DUAL, apenas para depois testar se o valor “passado por parâmetro” (par_cod) existe na tabela.

A sintaxe está bem simplificada, mas é bastante potente e mais performático em relação ao bloco apresentado anteriormente.

Fica a dica: avaliem se em algum script seu existe uma situação que possa ser utilizado o MERGE e faça um teste. Vale o aprendizado!

Espero conseguido passar o conhecimento!

Grande abraço e até a próxima...

Referências:

Watson, John; Ramklass, Roopesh (2010) – OCA Oracle Database 11g – Fundamentos I SQL – Manual do Exame 1z0-051. Editora: ALTABOOKS.

Oracle Corporation – MERGE. Disponível em http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9016.htm. Acessado em 13/03/2013.

Raphael Fernandes, quarta-feira, março 13, 2013

Sem comentários

12 de mar. de 2013


Pessoal,

No final do ano de 2012, prestei concurso para o DataPrev o qual me classifiquei em 18º do Nordeste. As provas foram de responsabilidade do Instituto QUADRIX e é sobre uma das questões que caíram na prova que quero comentar. A questão subjetiva da prova para o cargo de ANALISTA DE TECNOLGIA DA INFORMAÇÃO – Perfil: BANCO DE DADOS; era a seguinte:

Uma característica do RDBMS ORACLE é a separação entre a estrutura física e a lógica de armazenamento.

Explique o porquê ou qual a principal vantagem dessa separação entre as estruturas física e lógica.

Descreva a composição de cada uma das estruturas, física e lógica, e os respectivos componentes dentro de cada estrutura.”.


Para falar sobre o assunto, mais uma vez vou recorrer ao meu “amigo” John Watson.

O banco de dados consistem em três tipos de arquivos: arquivo de controle, arquivos de redo log e os arquivos de dados.
O BD Oracle fornece uma abstração completa do armazenamento lógico para o físico, ajudando muito na redução da carga de tarefas freqüentes de um DBA. Essa divisão do Oracle ajuda no gerenciamento e organização das informações.

Para iniciar o assunto, vamos entender basicamente alguns conceitos: tablespace e datafiles (arquivos de dados). Os dados são armazenados logicamente em segmentos e fisicamente em arquivos de dados. A entidade tablespace abstrai os dois – um tablespace pode conter vários segmentos e ser composto por muitos datafiles. Não existe uma relação direta entre um segmento e um datafile.
Segue um exemplo para criação de tablespace com dois datafiles associados (em sua forma básica):

CREATE TABLESPACE TBS_1MD DATAFILE
  '/opt/oracle/oradata/workspace/tbs1md_01.dbf' SIZE 2048M AUTOEXTEND OFF,
  '/opt/oracle/oradata/workspace/tbs1md_02.dbf' SIZE 2048M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;

Então vamos lá!

O banco de dados Oracle é dividido logicamente por tablespaces. Numa divisão abaixo das tablespaces se encontram os segmentos, que são constituídos de extensões. Uma extensão consiste no conjunto de blocos de dados. Para o entendimento ficar mais claro, a Figura 1 exibe como se dá as a. Cada extensão somente existe em um arquivo de dados. Os blocos de dados representam a menor unidade de entrada/saída no banco de dados.
 Figura 1 - Estrutura lógica de armazenamento no banco de dados Oracle. (Fonte: LEGATTI)

Todo banco de dados Oracle tem um ou mais arquivos de dados (datafiles), onde são armazenados os dados da base de dados. Os dados das estruturas lógicas como tabelas e índices são fisicamente armazenados nos datafiles alocados para o banco de dados, conforme Figura 2.

Figura 2 - Armazenamento lógico e físico de objetos no Oracle. (Fonte: Oracle Corporation)

É importante saber, que um datafile pode ser associado a apenas um banco de dados e a uma única tablespace. Os dados de um datafile são lidos, quando preciso, durante as operações de DML no banco de dados e armazenados no cachê de memória do Oracle (na porção de blocos de dados).  Dados modificados ou alterados não são necessariamente armazenados no datafile de imediato. Para reduzir o acesso a disco e melhorar o desempenho, o dado é colocado na memória e gravado no datafile todos de uma vez como determinado pelo processos interno do Oracle chamado “database writer process”.

Continuando a falar sobre as estruturas físicas do banco Oracle, temos o Redo Log File. Todo banco de dados Oracle tem um ou mais redo log files. O conjunto de um ou mais redo log files são conhecidos coletivamente como redo log do banco de dados. A função principal desses arquivos é registrar todas as mudanças realizadas nos dados do banco. Se devido a uma falha há necessidade de se recuperar informações do banco de dados isto é possível de ser feito através dos redo log files.

Para concluir a explicação de arquivos físicos do Oracle, vou falar sobre os control files. Todo banco de dados do Oracle tem um control file que são responsáveis por guardar os registros que especificam as estruturas físicas dos arquivos, tais como: 
- Nome do banco de dados
- Nomes e localizações dos redo log files
- A data da criação do banco de dados

Assim como os redo log files os control files também podem ter cópias mantidas em mais de um disco para efeito de segurança.

É importante lembrar que a estrutura de armazenamento das informações pode ter impacto na performance do banco de dados, então deve-se planejar de forma coerente como e onde alocar os dados para evitar problemas dessa natureza.

Bom pessoal,

Essa foi a questão que caiu no concurso e minha resposta foi mais ou menos essa (obviamente sem imagens).

Por enquanto é isso!

Um abraço e até a próxima!!


Referências:

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.

LEGATTI, EDUARDO – Introdução ao conceito de Tablespaces. Postado em setembro/2011. Disponível em: http://www.oracle.com/technetwork/pt/articles/database-performance/introducao-conceito-de-tablespaces-495850-ptb.html. Acessado em: 10/03/2013.

Oracle Corportaion – Schema Objects. Disponível em: http://docs.oracle.com/cd/B19306_01/server.102/b14220/schema.htm. Acessado: 11/03/2013.

Raphael Fernandes, terça-feira, março 12, 2013

3 comentários

11 de mar. de 2013

Olá pessoal.

Estava lendo umas notícias, quando és que surge algo que me chamou a atenção. Uma reportagem que falava da Oracle e seu novo foco.

O título e a chamada para a notícia era: "A ORACLE NÃO É MAIS UMA EMPRESA DE BANCO DE DADOS - Depois de mais de 90 aquisições em uma década, empresa aumentou seu portfólio e hoje tem somente 40% de seu faturamento vindo de Bancos de Dados".

Em leitura, existe uma passagem do vice-presidente executivo da Oracle para a América Latina que diz: “a empresa tem produtos para todos os tipos de trabalho em todos os tipos de indústria”; algo que já mostra o direcionamento da empresa para novas áreas do mercado.

Em outro trecho da mesma reportagem, é afirmado que uma área que vem crescendo e ganhando bastante mercado é a de cloud computing, ou computação em nuvem, aonde a Oracle vem conseguindo um faturamento bastante elevado, chegando a passar os lucros com hardwares.

Na explicação sobre a evolução da Oracle, é abordado o fato da empresa ter realizado mais de noventa aquisições nos últimos dez anos.

Achei uma reportagem muito interessante, e recomendo a leitura!

Acessem e confiram:
http://epocanegocios.globo.com/Informacao/Resultados/noticia/2013/01/oracle-nao-e-mais-uma-empresa-de-banco-de-dados.html

Raphael Fernandes, segunda-feira, março 11, 2013

Sem comentários