Arquivo da tag: sql

Um olhar sobre alguns bancos de dados NoSQL

Fonte: Mikayel Vardanyan/IMasters

Texto original disponível em http://blog.monitis.com/index.php/2011/06/06/a-look-at-some-nosql-databases-mongodb-redis-and-basho-riak/

Em um artigo anterior, falei sobre o NoSQL e algumas ferramentas para serem usadas com ele. Neste artigo, daremos uma olhada no MongoDB, no Redis e no Riak.

O MongoDB combina o melhor dos armazenamentos chave-valor, documentos de bancos de dados, bancos de dados (ou database?) de objeto e sistemas de gerenciamento de bancos de dados relacionais (RDBMS). Isso significa que o MogoDB executa o sharding automaticamente (como com armazenamentos chave-valor), permite documentos de schema dinâmicos baseados em JSON, e oferece uma rica linguagem de query na forma de RDBMS. Além disso, o MongoDB oferece auto-sharding (o sharding de dados novos e pré-existentes é feito automaticamente) e um recurso de implementação MapReduce.

Dê uma olhada mais de perto no cluster MongoDB, e você verá que ele é feito de vários tipos de servidores:

  • Servidores shard que armazenam dados
  • Servidores de configuração que armazenam a configuração
  • Servidores router que recebem e roteiam as solicitações
  • Uma thread de servidor usando MapReduce

Alguns fatos adicionais sobre MongoDB: é uma ferramenta de armazenagem distribuída orientada a documentos e usa a linguagem de implementação C++. Com o progresso do schema, documentos do tipo JSON são armazenados, e schemas dinâmicos podem ser usados. Entre as companhias que usam o MongoDB encontramos: Shutterfly, Evite e The New York Times. Impressionante! Uma das coisas bacanas das quais gosto a respeito desse produto é a existência de uma interface web bastante boa, que permite testar o MongoDB em seu browser – mas usando uma shell JavaScript.

O Redis não é um simples armazenamento chave-valor, porque suporta uma variedade de valores em diferentes estruturas de dados, tais como listas e conjuntos de binary-safe strings, bem como conjuntos ordenados, que contêm uma pontuação de números float. No ano passado, o VMWare se tornou patrocinador do Redis.

Ele possui uma orientação chave-valor, e sua linguagem de implementação é ANSI C. Entretanto, o Redis não é distribuído. Sob seu schema, Redis oferece um armazenamento chave-valor, usando um nome-chave de servidor para armazenar e recuperar valores. Como MongoDB, o Redis tem uma lista impressionante de clientes – incluindo Python, Twisted Python e a nova linguagem do Google, Go. O Redis é open source, e há uma página muito bacana que oferece um tutorial Redis que permite experimentá-lo diretamente de seu browser usando JavaScript. Descubra-a em http://try.redis-db.com.

Riak é um banco de dados híbrido fabricado pela BashoTecnologies, mas é baseado no Amazon Dynamo. Funciona como um banco de dados (tradução de database?) orientado para documentos, e também com um armazenamento chave-valor distribuído. É tolerante a falhas e faz escalas linearmente. É direcionado para uso em aplicativos web. Como o Cassandra, não tem um controlador central, e assim não tem um ponto único de falhas.

O Riak é um armazenamento de chaves/valor plenamente distribuído, e implementa o MapReduce.

O design do Riak inclui três elementos básicos: buckets, chaves e valores. Os dados são organizados em buckets, que são pouco mais do que flat namespaces para agrupar logicamente pares chave/valor. Os buckets podem armazenar os dados diretamente ou através de links para outro bucket. Todos os nós no cluster têm o mesmo papel. O sharding de dados (existentes ou novos) é feito automaticamente entre os nós.

O Riak vem tanto em versão comercial quanto em versão open source. Roda em Unix, mas não em sistemas Windows. Ele é distribuído, um sistema tanto de documento quanto de armazenamento chave-valor, e sua linguagem de implementação é Erland, juntamente como alguma coisa de C e de JavaScript.

O Riak tem uma estrutura simples e não usa tipos de dados específicos. Os valores associados às chaves são objetos. O Riak interage com clientes via JSON sobre a interface HTTP; tem drivers para Erlang, Python, Java, PHP, JavaScript e Ruby; e, finalmente, uma interface de cliente que suporta o Protocol Buffers, do Google. A base de clientes do Riak inclui a Comcast.

SQL Server 2012: Grandes melhorias no T-SQL

Fonte: Jonathan Allen , traduzido por Mário Henrique/InfoQ

O dialeto SQL do SQL Server 2012, o Transact-SQL, vem com melhorias importantes, incluindo suporte para funções ANSI FIRST_VALUE e LAST_VALUE, paginação de resultados de alto nível usando FETCH e OFFSET e suporte a funções de parsing e de formatação do .NET.

Fetch e Offset

Atualmente, muitos desenvolvedores de SQL Server que desejam implementar paginação de resultados no lado do servidor precisam utilizar técnicas “imperativas” de programação, como carregar os resultados em uma tabela temporária, numerar as linhas e então selecionar o intervalo de interesse. Há também desenvolvedores que utilizam ROW NUMBER e OVER; outros utilizam cursores.

O SQL Server 2012 resolve essa limitação e permite mais consistência no uso, adicionando suporte declarativo para a paginação de resultados, através das novas opções OFFSET e FETCH NEXT do Transact-SQL. Mas note que atualmente não há otimização de performance; o SQL Server está fazendo a mesma coisa que os desenvolvedores fariam manualmente.

Clause Windowing

Às vezes, os desenvolvedores precisam escrever consultas que identificam diferenças entre linhas. Por exemplo, pode-se estar interessado na quantidade de tempo entre o timestamp de uma linha e outra. Isso é fácil de fazer utilizando cursores, mas o desempenho e elegância dessa solução deixam a desejar. É possível ainda utilizar uma subquery executada linha a linha, mas isso é extremamente custoso. Pode-se ainda implementar tudo no lado do cliente mas isso não funcionaria se o cliente for uma ferramenta de geração de relatórios, por exemplo.

No SQL Server 2012, agora é possível acessar diretamente a linha anterior utilizando a função LAG. O analisador de consultas SQL retém a linha anterior na memória, de forma que não há necessidade de uma subquery. Isso resulta em melhor desempenho. A função LAG aponta para a linha anterior, mas é possível utilizar um offset para ter acesso a linhas anteriores. A função LEAD é equivalente a LAG, mas trabalha com linhas posteriores à que está sendo lida. As funções LAG e LEAD, que são parte do padrão ANSI, eram um pedidas pelos desenvolvedores desde a implementação da sintaxe OVER no SQL Server 2005. As funções FIRST VALUE e LAST VALUE também estão disponíveis no SQL Server 2012.

Reflection

Anteriormente, para testar quais os resultados seriam retornados por stored procedures ou consultas SQL, utilizava-se o comando SET FMTONLY. Esse comando permitia aos desenvolvedores visualizar as colunas retornadas, sem a necessidade de executar uma consulta SQL. Mas a informação se limitava apenas às definições das colunas resultantes da execução da consulta.

Com a nova procedure sp describe first result set, os desenvolvedores podem obter informações detalhadas a respeito de quais resultados seriam retornados pela consulta. Essas informações incluem tipos de dados, tabelas ou colunas-fonte e outras informações importantes, também disponíveis nas telas de gerenciamento dinâmico, sys.dm exec describe first result e sys.dm exec describe first result set.

Código Defensivo

Tradicionalmente, os desenvolvedores ficam à mercê de seus colegas quando utilizam stored procedures. Sem garantias em relação ao que será retornado, falhas acidentais se tornam uma preocupação. O T-SQL não oferece formas de prevenir esses erros, mas é possível minimizá-los utilizando a opção RESULT SETS.

Quando usada, a opção RESULT SETS faz com que a procedure armazenada retorne uma estrutura específica de dados. Se os resultados da procedure forem diferentes do requisitado, a opção retorna um erro. Considerando que se trata de um erro em tempo de de execução, recomenda-se aos desenvolvedores que utilizarem essa opção se assegurem de que os erros sejam depurados antes do código ir para produção.

Tratamento de Erros

O T-SQL tem suporte para TRY-CATCH desde 2005, porém o suporte THROW não existia até agora. Sem argumentos, THROW funciona da mesma maneira que em C# ou VB. Isto é, THROW retorna uma exceção e mantém o log de informação capturada sobre o erro, o que é muito útil.

Quando utilizada com argumentos, THROW é similar à RAISERROR, exceto por não suportar números de erros em sys.messages e a severidade é sempre 16. Além disso, os erros não detectados por THROW sempre terminam a execução.

Parsing e Conversões

O T-SQL agora suporta a função PARSE que inclui a opção de especificar uma “culture”. Esta deve contar com suporte pelo framework .NET. Há também uma nova função TRY_CONVERT que, assim como TRY_PARSE, retorna null quando a conversão falha. Já a função FORMAT utiliza a formatação de strings do .NET. Apesar de mais lenta que as funções nativas como STR, é mais flexível.

Funções de Data e Hora

O processamento de data e hora no T-SQL recebeu melhorias. A função EOMONTH retorna o último dia do mês, dado importante para relatórios. As funções xxxFROMPARTS permitem construir valores de data/hora utilizando um conjunto de parâmetro em vez de apenas uma string. Há suporte para os tipos de dados Date, DateTime, DateTime2, DateTimeOffset, SmallDate e Time.

Outras funções

A função Choose do Access e Visual Basic agora está presente no T-SQL. Sob determinadas circunstâncias, pode ser utilizada como uma versão simplificada de CASE. Também está presente a função IIF.

A função CONCAT pode ser utilizada para concatenar strings. Além de tornar mais fácil a portabilidade de código de outras linguagens, essa função possui um tratamento de exceção diferente do operador +. Itzik Ben-Gan escreve:

O operador + de concatenação devolve NULL para inputs NULL. A função CONCAT converte inputs NULL em strings vazias antes da concatenação. Embora esta não seja uma boa solução, é possível fazer a mesma coisa utilizando a função COLAESCE, substituindo entradas NULL por strings vazias.

SQLol 0.3.1 é disponibilizado

Com informações de Under-Linux

Fonte: IMasters

A versão 0.3.1 do SQLol foi liberada. Ele é um utilitário de segurança, altamente configurável desenvolvido para “testbed” de injeção SQL. Ele permite que o usuário explore falhas de injeção de SQL e uma grande quantidade de controle sobre a manifestação da vulnerabilidade com a qual estiver trabalhando. O SQLol também vem com um conjunto de desafios, relacionados a tarefas que realizem algum tipo de injeção de SQL.

Na nova versão, a 0.3.1, que vem sob o nome de código “Hello My Future Girlfriend Edition”, houve a remoção da funcionalidade para a apresentação de valores via GET / POST cookie. Além disso, a injeção via GET / POST / Cookie deve funcionar independentemente, devido ao uso de $ _REQUEST; mudança do arquivo moreChanged database config, para utilizar o padrão MySQL e localização por default.

O SQLol está hospedado no Github e disponível para download.

Heroku lança serviço de provisionamento exclusivo para PostgreSQL

A Heroku mudou a estratégia do seu serviço Heroku Postgres. A partir de agora o serviço provê uma infraestrutura para armazenamento de bases de dados PostgreSQL, independente da solução PaaS (Platform as a Service) utilizada. O Heroku Postgres é uma plataforma disponibilizada com o conceito SQL Database-as-a-Service; a proposta é que os desenvolvedores implementem suas aplicações com o PostgreSQL sem se preocupar com questões como disponibilidade e desempenho, uma vez que estas serão resolvidas pela própria infraestrutura do Heroku.

O Heroku Postgres foi disponibilizado em 2007, mas até agora era oferecido somente como um serviço agregado à plataforma de nuvem da Heroku. O serviço estava disponível apenas para os clientes que desenvolviam e implantavam suas soluções web utilizando o PaaS da empresa. Com a nova estratégia, desenvolvedores têm a opção de utilizar o serviço em conjunto com a plataforma de cloud computing da Heroku ou não. Isso possibilita o desenvolvimento utilizando outra solução PaaS, um ambiente de cloud diferente, ou até utilizando um máquina local.

Segundo a equipe da Heroku, as principais vantagens em utilizar o serviço são a disponibilidade e a capacidade de processamento, além da segurança dos dados:

O Heroku Postgres tem suportado com sucesso 19 bilhões de transações clientes diariamente. A segurança e a durabilidade dos dados são a prioridade número um do serviço. Um conjunto de tecnologias chamado Continuous Protection foi desenvolvido para evitar qualquer tipo de perda de dados, mesmo em caso de falhas catastróficas.

Atualmente são oferecidas seis opções de planos para contratação do serviço. Os preços variam de acordo com o tamanho do cache escolhido, começando em 200 dólares por mês e chegando a US$ 6.400 mensais. Todos os planos incluem backup dos dados, monitoramento 24×7, 2 terabytes de espaço em disco, entre outras funcionalidades.

O Heroku Postgres também fornece uma API para que os clientes utilizem o serviço através da linha de comando ou via website. Para os interessados em mais detalhes, foi disponibilizado material com um guia introdutório, documentação detalhada, tutoriais e artigos sobre o serviço.

Fonte: Eder Magalhães/InfoQ

10 técnicas para otimização de instruções SQL

Neste artigo vou apresentar dez técnicas de otimização de instruções SQL. Elas não são específicas de um banco de dados e podem ser aplicadas em qualquer SGBD que utilize SQL e até bancos de dados NoSQL.

Também destaco que estas são apenas sugestões de técnicas que podem ser aplicadas, pois o processo de tuning de instruções SQL, ou seja, otimizar uma instrução para que ela seja executada mais rapidamente, é complexo, demorado, depende de cada cenário e exige uma boa dose de experiência. Contudo, quanto mais nos esforçarmos e focarmos na otimização, melhores serão os resultados.

Outro ponto importante, que é preciso destacar, é que estas técnicas podem ser aplicadas às quatro principais instruções SQL: SELECT, INSERT, UPDATE e DELETE. Como dito anteriormente, algumas delas também são válidas para os bancos de dados NoSQL, um vez que, apesar da linguagem SQL não ser empregada, muitos dos conceitos são os mesmos (geração de plano de execução, uso de índices, métricas, etc).

1. Use bem os índices

Um dos principais fatores que impacta no desempenho de uma instrução SQL é o uso de índices, principalmente em instruções que empregam tabelas com muitos dados. Este é um fator tão importante, que a mera criação de um índice pode reduzir drasticamente a quantidade de passos internos na execução de instruções SQL.

Neste momento surge uma pergunta: como começar a analisar e criar os índices adequados? Infelizmente, não existe uma única resposta para esta pergunta. Mas para ajudar o leitor que não tem muita experiência no uso de índices, montei o seguinte fluxograma apresentado abaixo. Este diagrama é apenas uma sugestão genérica e deve ser utilizado somente como ponto de partida para aqueles que possuem pouca experiência. Obviamente, a cada criação de índice devem ser realizados diversos testes.

2. Explore o paralelismo

Atualmente, vivemos em uma era onde os microprocessadores são dominados por múltiplos núcleos. Até dispositivos móveis como smartphones, tablets e consoles portáteis estão recebendo microprocessadores com múltiplos núcleos. Mas isso não quer dizer que as aplicações estejam preparadas para obter o máximo de desempenho proporcionado por este hardware.

Sendo assim, é recomendável sempre procurar explorar o paralelismo em banco de dados. Apesar desta preocupação ser relativamente recente, e talvez um pouco mais comum para quem trabalha com programação, a exploração de paralelismo deve ser considerada quando for necessário otimizar instruções SQL.

Infelizmente, existem poucos recursos para a manipulação, ou aplicação direta de conceitos de programação paralela direto no banco de dados. Entretanto, é possível utilizar algumas técnicas para explorar o paralelismo na execução de instruções SQL,. dependendo, principalmente, do banco de dados a ser utilizado. Por exemplo: tanto o Oracle, quanto o SQL Server possuem diversos operadores utilizados internamente no plano de execução para mostrar se o plano escolhido utilizou, ou não paralelismo. Outro exemplo é a técnica apresentada no meu artigo de capa da revista SQL Magazine número 91, chamado Processamento paralelo de instruções SQL, disponível em neste aqui.

3. Saiba trabalhar com condições de pesquisa dinâmica

Imagine a seguinte situação: uma aplicação permite ao usuário escolher diversos campos para pesquisar na base de dados. Estes campos são apresentados através de elementos de um formulário como campos de texto, checkbox, combo e outros. Se o valor de algum campo for preenchido, este valor será montado em uma string, cujo conteúdo será utilizado para montar uma cláusula WHERE na instrução SELECT, que será encaminhada para o banco de dados. Este cenário é muito comum tanto em aplicações desktop, como em aplicações web.

Deixando as preocupações com SQL Injection de lado, como garantir que instruções SELECT dinâmicas possam ser executadas com um bom desempenho? Bem, como esta situação é muito comum, há uma técnica chamada condições de pesquisa dinâmica que pode auxiliar a criação da instrução SELECT visando tanto a flexibilidade proporcionada pela escolha dinâmica de filtros, quanto pelo desempenho.

Para quem trabalha com o SQL Server, existe alguns artigos escritos por Erland Sommarskog e que abordam esta técnica. Eles estão disponíveis neste link. Os conceitos apresentados podem ser adaptados para outros bancos de dados sem grandes problemas.

4. Conheça bem o modelo de dados

Quando se trabalha com uma instrução SQL, como SELECT, INSERT, UPDATE e DELETE é extremamente importante tem um bom conhecimento do modelo de dados. De fato, o modelo pode impactar muito no desempenho da instrução, devido aos joins que são realizados, os filtros na cláusula where e outros fatores.

Já escrevi diversos artigos aqui no iMasters abordando questões de desempenho que tratam do modelo de dados: como eliminar tabelas desnecessárias, tipagem de dados correta e até a análise de modelos de dados do WordPress. Destaco também um artigo em inglês para o site SQLServerCentral.com, onde apresento algumas dicas para quem trabalha com modelos de dados grandes (com muitas tabelas e relacionamentos).

5. Quebre uma instrução SQL complexa em várias

Durante a minha carreira tenho encontrado muitos desenvolvedores com uma mania um tanto quanto esquisita: tentar montar relatórios utilizando uma instrução SELECT, por mais complexa que ela seja.

Ora, a instrução SELECT possui diversas cláusulas e opções que permitem realizar muitas operações de uma vez só, como filtros, ordenação, agregação, cálculos e outros. Porém, quanto mais operações uma única instrução SELECT realiza, mais complexa ela se torna. Aliás, recomendo o ótimo formatador online de instruções SQL, chamado SQL Online Formater, para auxiliar na melhora do visual de instruções SQL complexas e ajudar a compreendê-las. Este formatador está disponível em aqui.

Voltando ao assunto, a mania de fazer tudo em uma única instrução SELECT é considerada preciosa, e muitas vezes mais ajuda do que atrapalha. Faz muito sentido dividir as operações necessárias para se obter o relatório desejado em mais de uma instrução SELECT, pois assim fica mais fácil de dar manutenção no código, pode-se aplicar outras otimizações, gerenciar melhor o acesso a recursos (locks) e também fazer uso de opções de cache, criptografia e permissões do banco de dados. Uma dúvida pode surgir neste caso: como vou fazer minha aplicação/gerador de relatório utilizar mais de uma instrução SELECT para obter os dados que preciso?

Bem, neste caso existem algumas opções. A utilização de stored procedures é uma delas, mas pode ser utilizadas funções e views. Além das vantagens citadas também existem opções específicas de stored procedures e objetos programáveis do banco de dados que podem ser úteis, como criptografia, uso de parâmetros, opções de cache, entre outras.

6. Empregue os conceitos de teoria de conjuntos

Uma das técnicas de otimização mais disseminadas e, ouso a dizer, repetidas à exaustão, envolve trocar o processamento linha a linha (cursor) por operações baseadas em conjunto (set-based). Com certeza esta técnica é válida, mas não devemos parar por aí.

Atualmente, diversos dialetos do padrão SQL (Pl/SQL, T-SQL, etc) possuem operadores que são muito parecidos com as operações de conjuntos união, intersecção e diferença, como os operações UNION, INTERSECT e MINUS, respectivamente. Em muitas situações vale a pena pensar em termos de conjunto para montar uma instrução SQL otimizada. Por exemplo: para atualizar determinado conjunto de linhas, podemos pensar em obter todas as linhas desta tabela e retirar as linhas desta outra tabela. Neste caso deve-se considerar utilizar o operador MINUS.

O mais importante desta técnica não é, necessariamente, empregar este, ou aquele operador, ou joins; e sim mostrar que é possível pensar de maneira diferente em relação ao processo normal e muitas vezes já viciado na cabeça do desenvolvedor. A teoria de conjuntos, matematicamente falando, é muito poderosa e com alto grau de expressão. Saber aplicá-la quando se trabalha com instruções SQL pode fazer muita diferença, principalmente quando se busca obter desempenho.

7. Tenha casos de uso confiáveis para a instrução a ser otimizada

Quando se está modificando uma instrução SQL que já funciona corretamente, e se deseja melhorar seu desempenho, é praticamente obrigatório elaborar testes antes da modificação, pois assim é fácil determinar se a(s) modificação(es) implementada(s) quebraram, ou não a funcionalidade existente.

Por exemplo: suponha que uma instrução SELECT receba três parâmetros de filtro e, com certos valores A, B e C retorne, X linhas e T segundos. Guarde em algum lugar esta informação indicando que para os valores A, B e C dos respectivos parâmetros, estas X linhas são retornadas em T segundos. Este é um caso de testes simples e é conveniente armazenar outros valores para os três parâmetros, as linhas que eles retornam e o tempo de execução.

Depois que estas informações são armazenadas você já pode começar a otimizar a instrução SELECT. A cada nova técnica empregada verifica-se se houve um ganho de tempo de acordo com os valores dos parâmetros armazenados nos casos de teste e nas linhas retornadas.

Este procedimento pode parecer básico, mas isso é de extrema importância quando se está trabalhando com otimizações de instrução SQL e, infelizmente, poucas pessoas fazem isso de maneira pragmática e metódica no dia a dia.

8. Modifique ou exclua poucos dados por vez

Praticamente todos bancos de dados relacionais suportam o conceito de transações, sejam elas implícitas na instrução que modifica os dados (INSERT, UPDATE e DELETE), ou explícita pelo uso de comandos, como BEGIN TRANSACTION, ou similares . E para implementar este recurso há a necessidade de utilização de um log, que pode receber o nome de Transaction Log, Redo Log File, ou qualquer outro.

Utilizar log de transações gera uma implicação importante, que deve ser levada em consideração pelo desenvolvedor: o seu preenchimento. Geralmente, os bancos de dados possuem recursos manuais e automáticos para controlar como o log de transações é preenchido e limpo, porém fica a cargo do desenvolvedor saber que uma transação muito longa, ou seja, que afete muitas linhas, vai gerar um impacto significativo no log e também afetar o desempenho da instrução. Em poucas palavras: use transações curtas para se obter um bom desempenho, pois assim o log será preenchido de forma mais adequada e também serão minimizados os recursos de locks (ou qualquer outro mecanismo de controle de concorrência) necessários para a execução da instrução. Cabe ao desenvolvedor descobrir quando é pouco e quando é muito (em relação à quantidade de linhas por instrução) de acordo com o seu ambiente e modelo de dados.

Para ficar fácil de entender, basta imaginar a analogia do consumo do um bife. Você não vai querer comê-lo todo de uma vez (o que pode causar uma grande indigestão). É preciso cortá-lo em pedaços menores e abocanhá-los um por vez.

9. Cuidado com a recursividade

Trabalhar com recursividade em instruções SQL ainda é um desafio muito grande para diversos desenvolvedores. Apesar de já existirem soluções consolidadas, com muito tempo de mercado e até presentes no padrão SQL, não é raro encontrar instruções SQL não otimizadas para se trabalhar com recursividade. Além disso, ainda há a opção dos bancos NoSQL, que também permitem trabalhar com estruturas hierárquicas, em árvore, ou qualquer combinação entre elas de diversas maneiras.

De acordo com padrão SQL, existem um recurso chamado CTE (Common Table Expression), que permite manipular recursivamente partes de uma instrução SQL. Apesar de nem todos os bancos de dados implementarem este recursos em seus dialetos SQL, como o padrão sugere, ainda sim é possível fazer uso de CTEs em diversas situações. Do ponto de vista de entendimento prepare-se para encontrar instruções SELECT complexas e de difícil compreensão quando se emprega CTE. Do ponto de vista de desempenho, é muito fácil cair em uma recursão que realiza mais instruções do que uma solução interativa e, além disso, faz um uso excessivo da pilha interna que controla a recursividade.

Devido à estes fatores, deve-se utilizar com muita cautela soluções recursivas implementadas diretamente no SQL, principalmente pelo fato de já existirem diversos algoritmos e técnicas de manipulação de estruturas de dados otimizadas, testadas, conhecidas e estudadas para se realizar operações em estruturas hierárquicas.

10. Mantenha-se atualizado para aprender novas técnicas

Esta última técnica muitas vezes é menosprezada por profissionais mais experientes. Assim como o modelo de dados e as características do dado em si podem mudar a qualquer momento, os bancos de dados também evoluem (apesar do padrão SQL mais ou menos estacionado há algum tempo).

E isso quer dizer que as técnicas de otimização também devem evoluir. Algo que hoje é válido pode não ser mais depois de um curto período de tempo. Por exemplo, em certas versões de um banco de dado,s diversos livros, sites, blogs e vídeos indicavam que determinada técnica era melhor para otimizar o desempenho naquele momento. Mas com novas versões de bancos de dados, algumas destas técnicas não fazem mais sentido.

Por isso é importante ter sempre a consciência do contexto da técnica que está sendo aplicada. Muitas vezes o banco de dados é o mesmo, porém houve uma mudança na característica dos dados (seletividade, ordem, modelo, tipo de dados, etc) que tornaram certa otimização obsoleta e que não mais obtém o desempenho de outrora. Devido a isso, é sempre importante manter-se atualizado em relação não apenas ao que o mercado de banco de dados apresenta, mas também em relação ao ambiente na qual seus dados estão sendo manipulados.

Para finalizar, gostaria de fazer um pedido aos leitores: estou participando de um concurso que premiará as melhores histórias de otimização de desempenho. Bem, a minha entrada se chama “A day in a DBA Life” e os leitores que gostarem dela podem me ajudar clicando no botão “I Like this Story” nesta página (é preciso se logar no Facebook para votar).

Fonte: Mauro Pichiliani/IMaster

Além de MySQL – Ramificando o banco de dados popular

Embora MySQL seja um dos programas mais populares, muitos desenvolvedores sentiram necessidade de ramificá-lo em outros projetos, cada um oferecendo sua própria especialidade. Essa necessidade, junto com o medo de que a Oracle irá desacelerar o crescimento do produto principal, levou à criação de muitos subprojetos e ramificações de interesse para desenvolvedores.

Introdução

MySQL é um dos programas de software livre mais populares da história. É o backbone de banco de dados de milhares de websites e pode-se dizer que detém o crédito (junto com Linux®) pelo crescimento explosivo da Internet nos últimos 10 anos.

Então, se o MySQL é tão importante, por que está aumentando o número de ramificações de alto perfil do produto MySQL principal? Como MySQL é software livre e gratuito, desenvolvedores sempre puderam pegar o código, modificá-lo conforme a necessidade e distribuir por conta própria. Por muito tempo, não havia nenhuma ramificação do MySQL em que um desenvolvedor confiasse em seu próprio ambiente de produção. No entanto, isso está mudando rapidamente. Várias ramificações estão recebendo muita atenção.

Este artigo irá discutir três ramificações populares do MySQL que estão atraindo atenção: Drizzle, MariaDB e Percona Server, incluindo o mecanismo XtraDB. Este artigo irá discutir brevemente os motivos para cada ramificação e suas metas e se o seu uso em seu ambiente de produção. Quando terminar de ler este artigo, você deve e star apto a responder à pergunta “Esses produtos de ramificação do MySQL são uma boa solução para o meu ambiente?”.

Por que ramificar?

Por que o MySQL precisa ser ramificado? Essa é uma pergunta legítima. Milhares de websites dependem dele e parece ser uma solução boa para muitas pessoas. No entanto, como acontece com frequência, o que é bom para muitas pessoas não é bom para todas as pessoas. Alguns desenvolvedores são incentivados a melhorar as coisas para suas próprias necessidades. O que poderia ser melhor do que transformar uma solução ótima numa solução perfeita?

Vamos examinar em melhores detalhes o que essas ramificações queriam mudar. Algumas ramificações acharam que o MySQL estava se tornando muito inchado e estava oferecendo muitos recursos que nunca iam interessar aos usuários, sacrificando simplicidade e desempenho. Se as pessoas estavam perfeitamente felizes com o MySQL 4, simplificado, por que deveriam lidar com a complexidade que foi incluída no MySQL 5? Para essa ramificação, uma ramificação do MySQL seria mais simples e mais rápida — oferecer menos recursos, mas torná-los extremamente rápidos, tendo em mente um público alto, nesse caso websites de alta disponibilidade.

Para outras ramificações, MySQL não estava oferecendo novos recursos suficientes ou os estava incluindo muito devagar. Eles talvez achassem que o MySQL não estava acompanhando seus mercados alvos de websites de alta disponibilidade executando em processadores com vários núcleos com muita RAM. Como sabem as pessoas familiarizadas com MySQL, ele oferece dois diferentes mecanismos de armazenamento — MyISAM e InnoDB. Essa ramificação achava que nenhum dos dois mecanismos de armazenamento oferecia exatamente o que eles queriam, por isso criaram um novo mecanismo perfeitamente adequado para seus objetivos.

Além disso, algumas ramificações têm como objetivo ser uma substituição de “entrada” (“drop in”) para o MySQL, na qual é possível simplesmente entrar na ramificação e não precisar escrever uma linha de código. A ramificação usa o mesmo código e interfaces que o MySQL, o que torna a transição o mais fácil possível. Outra ramificação afirma não ser compatível com MySQL e exige alterações no código. Cada ramificação também é muito diferente no nível de maturidade, com algumas afirmando estar prontas para produção, e outras afirmam estar longe desse objetivo no momento.

Por fim, há incerteza sobre como será o destino do MySQL com a Oracle. A Oracle comprou a Sun, que comprou MySQL, e agora a Oracle controla o produto MySQL, e lidera o desenvolvimento da comunidade na produção de novos produtos concluídos. Como a Oracle já tem um banco de dados comercial, há a preocupação de que a empresa pode não colocar recursos suficientes no MySQL para mantê-lo na ponta. Portanto, muitas ramificações também são resultado do medo subjacente de que o MySQL, o banco de dados grátis e de software livre líder, pode receber menos recursos, ciclos de release mais lentos e suporte mais caro.

XtraDB

XtraDB não é um produto independente, mas ainda é considerado uma ramificação de MySQL. XtraDB é, na verdade, um mecanismo de armazenamento para bancos de dados baseados em MySQL. Seria considerado um mecanismo de armazenamento adicional além do padrão MyISAM e InnoDB que já são parte do MySQL. MySQL 4 e 5 é instalado com cada tabela usando o mecanismo de armazenamento padrão MyISAM. InnoDB também é uma opção relativamente nova para mecanismo de armazenamento, e administradores e desenvolvedores de banco de dados podem escolher os tipos de mecanismo por tabela quando configuram o banco de dados. A principal diferença entre esses dois mecanismos de armazenamento é que MyISAM não oferece suporte transacional, mas InnoDB oferece. Outras diferenças são pequenas diferenças de desempenho, com InnoDB oferecendo pequenas melhorias de desempenho em relação a MyISAM, e mais confiabilidade e segurança ao lidar com perda de dados em potencial. Como InnoDB parece ser o mecanismo de armazenamento mais adequado para melhorias futuras, MySQL alterou o mecanismo padrão para InnoDB em vez de MyISAM a partir do release 5.5.

Construindo sobre essas vantagens, o mecanismo de armazenamento InnoDB foi ramificado em um novo mecanismo chamado XtraDB. Qual é a idade desse mecanismo de armazenamento? Ele foi lançado pela primeira vez há menos de 3 anos pela Percona. Portanto, é relativamente nova. Foi projetado especificamente para lidar com websites de alta disponibilidade modernos executando em servidores modernos. Foi projetado para executar em servidores com uma dúzia ou mais de núcleos e muita RAM (32 GB e mais). Esses são o tipo de servidores que qualquer empresa pode comprar de uma empresa de gerenciamento de servidores, e, portanto, um banco de dados deve ser projetado para aproveitá-los ao máximo.

A ramificação XtraDB tinha outro objetivo — ser uma substituição simples de entrada para o mecanismo de armazenamento InnoDB, de modo que usuários poderiam simplesmente alternar seu mecanismo de armazenamento sem ter que alterar o código do aplicativo subjacente. XtraDB tinha que ter compatibilidade retroativa com o InnoDB, além de fornecer todos os novos recursos e melhorias que eles queriam incluir. Eles atingiram esse objetivo.

Qual é a velocidade do XtraDB? Um teste de desempenho que eu encontrei diz que ele oferece 2.7x mais transações por minuto que o mecanismo InnoDB integrado no MySQL 5.1 (consulte Recursos). Certamente não é algo que pode ser ignorado, especialmente considerando que pode ser usado imediatamente.

Percona

XtraDB oferece ótimas melhorias sobre mecanismos de armazenamento MySQL integrados, mas não é um produto independente, e não é algo que se possa colocar em uma instalação MySQL existente. Portanto, se você quiser usar esse novo mecanismo de armazenamento, é preciso usar um produto que o ofereça.

Percona Server é esse produto, lançado pela Percona, empresa líder em consultoria de MySQL. É um produto de banco de dados independente que oferece aos usuários a capacidade de retirar sua instalação do MySQL e colocar o produto Percona Server, e assim obter a vantagem do mecanismo de armazenamento XtraDB. Afirma ser totalmente compatível com MySQL, portanto em teoria nenhum código precisaria ser alterado no software. Isso é, certamente, uma enorme vantagem. É ótimo para controle de qualidade quando você está procurando por uma melhoria de desempenho rápida. Portanto, um bom motivo para considerar Percona Server é aproveitar o mecanismo XtraDB com o menor número de alterações possível no código principal.

Além disso, eles são os autores originais do mecanismo de armazenamento XtraDB. A Percona lançou o código como software livre, de modo que ele pode ser encontrado em outros produtos, mas os criadores originais do mecanismo são as mesmas pessoas que criaram este produto. Usem essas informações como quiser.

Aqui estão as afirmações feitas para o Percona Server, retiradas do website deles:

  • Escalabilidade: lida com mais transações; faz ajuste de escala em servidores eficientes
  • Desempenho: Percona Server com XtraDB é extremamente rápido
  • Confiabilidade: resiliência a corrupção, replicação com segurança contra quebra
  • Gerenciamento: backup on-line, importação/exportação de tabela on-line
  • Diagnóstico: perfil e instrumentação avançados
  • Flexibilidade: tamanho de página variável, gerenciamento de buffer pool melhorado

A afirmação final da equipe do Percona é que o produto é o “mais próximo dos releases oficiais MySQL Enterprise da Oracle”, assim se diferenciando de outras ramificações que alteraram o código MySQL principal subjacente. Um ponto negativo do Percona Server é que eles gerenciam o código por si mesmos e não aceitam contribuições de desenvolvedores externos sem revisá-la antes, o que garante que eles controlem os recursos colocados no produto.

MariaDB

Outro produto que oferece o mecanismo de armazenamento XtraDB é o produto MariaDB. É muito semelhante ao produto Percona, mas oferece mais alterações no código subjacente para tentar obter ainda mais melhorias de desempenho em relação ao MySQL padrão. Utiliza o mecanismo XtraDB diretamente da Percona, portanto não á diferenças subjacentes nos mecanismos de armazenamento que cada um emprega, já que usam exatamente o mesmo.

Além disso, MariaDB oferece os mecanismos de armazenamento padrão oferecidos pelo MySQL, MyISAM e InnoDB. Portanto, na prática, pode ser considerado um superconjunto de MySQL, oferecendo tudo que o MySQL oferece e mais. Também afirma ser uma substituição de entrada para o MySQL, portanto pode ser instalado com o conhecimento de que não serão necessárias alterações no código subjacente ao passar o MySQL para o MariaDB.

Por fim, e talvez o mais importante, o criador chefe do MariaDB é Monty Widenius, o criador original do MySQL. Monty formou uma empresa para gerenciar o desenvolvimento do MariaDB, chamada Monty Program, que contrata desenvolvedores para criar e melhorar o produto MariaDB. Isso pode ser algo bom e ruim: é bom porque eles lideram os recursos e correções de erros no Maria, mas pode causar problemas porque a empresa não está focada em receita, mas sim em produto. Empresas que não geram receita não duram para sempre.

Drizzle

O último produto que iremos examinar é o Drizzle. Ao contrário dos outros dois produtos finalizados que examinamos, o Drizzle apresenta grande diferença em relação ao MySQL e até mesmo afirmam que o produto não é uma substituição simples para o MySQL. Eles estão tentando fazer mais mudanças importantes no MySQL e tem como objetivo fornecer uma ótima solução para o problema da alta disponibilidade, mesmo que isso signifique alterar aspectos do MySQL com os quais estamos acostumados.

No FAQ da empresa, a leitura das questões reforça os objetivos subjacentes. Eles não estavam satisfeitos com as alterações feitas no núcleo do MySQL após o release 4.1, afirmando que muitos desenvolvedores não queriam aquela sobrecarga adicional. Eles admitem que seu produto não é sequer um banco de dados de relação compatível com SQL. Isso é realmente diferente do MySQL.

Então, com uma mudança tão drástica em relação ao MySQL familiar, por que deveríamos considerar esse produto? Exatamente por esses motivos — é uma grande reescrita dos mecanismos do MySQL, com os recursos que foram considerados não ideais removidos, e com grande parte do código sendo reescrita para ser otimizada, chegando a ponto de trocarem C por C++ no código. E não acaba aí: esse produto tem um mercado alvo específico em mente com seu design — servidores com vários núcleos e muita RAM, máquinas de 64 bits executando Linux, servidores usados em computação em nuvem, servidores hospedando websites, servidores obtendo dezenas de milhares de ocorrências por minuto. É um mercado bem específico. É específico demais? Lembre-se do quanto esse tipo de empresa gasta com seus bancos de dados atualmente — se ela pode instalar Drizzle em vez de MySQL e cortar os custos com servidor pela metade, isso é muito dinheiro!

Então todos deveriam estar usando Drizzle, certo? Espere, pois, como eles destacam repetidamente, não é compatível com MySQL. Portanto, se você tem uma plataforma MySQL existente, haveria muitas alterações a serem feitas no código para fazer com que ele funcione corretamente no seu ambiente.

Embora exija mais trabalho para executar e não pareça ser tão rápido e fácil de usar como Percona ou MariaDB, eu incluo Drizzle porque, embora ele possa não ser sua escolha hoje, em alguns anos será provavelmente a escolha de algumas pessoas. Como o objetivo deste artigo é informar sobre as ferramentas que você usará no futuro, essa é uma boa oportunidade de mostrar esse produto. Muitos especialistas de DB líderes acham que o Drizzle será a escolha de instalações de alta disponibilidade em cinco anos.

Drizzle é 100% software livre e recebe contribuições abertamente de desenvolvedores. Não há uma empresa subjacente financiando o desenvolvimento, como no MariaDB, e não é fechado para contribuições de fora, como Percona. Está em uma boa posição para crescimento e novos recursos, que ele pode precisar, dado seu escopo de reescrever grande parte do MySQL.

Gráfico de comparação

Aqui está um resumo dos três produtos de ramificação MySQL mencionados neste artigo.

Produto Preços Objetivo Recurso Principal Pronto para Produção?
Percona Server Grátis Fornece um wrapper para mecanismo de armazenamento XtraDB e ferramentas de análise adicionais XtraDB Sim
MariaDB Grátis Estendeu MySQL para incluir XtraDB e outras melhorias de desempenho XtraDB Sim
Drizzle Grátis Oferece grandes melhorias de escalabilidade e desempenho em relação ao MySQL Alta disponibilidade Sim

Conclusão

Este artigo discutiu três novas ramificações do produto MySQL que intencionam resolver alguns problemas identificados com o MySQL. Os três são grátis e são produtos de software livre. É preciso pesar as vantagens e desvantagens de usá-los em relação ao que o MySQL já oferece. Eu acredito que, para quase todos que leem este artigo, MySQL será ainda a escolha preferencial para suas necessidades de bancos de dados. Eu duvido que muitos leitores deste artigo sejam proprietários de websites que recebem 1.000.000 de ocorrências por hora. Quero destacar isso novamente — MySQL ainda é um produto incrível que é um banco de dados perfeitamente adequado para a maioria dos casos de uso.

No entanto, para vocês que acham que seu site requer mais alta disponibilidade, escalabilidade e desempenho do que o MySQL pode oferecer atualmente, um desses três produtos pode ser a solução que vocês procuram. No futuro, se você acha que seu site irá se tornar uma ideia de um bilhão de dólares, deve-se considerar começar com um desses três produtos e assim resolver esses tipos de problemas antes mesmo que eles comecem.

Por fim, o motivo principal dessas ramificações do MySQL é alterar alguns recursos subjacentes do MySQL, sendo que os autores acharam que não podiam esperar que o MySQL fizesse isso. Além disso, o espectro da Oracle ronda sobre o futuro do MySQL, e muitos desenvolvedores, incluindo o desenvolvedor original do MySQL, estão preocupados sobre o futuro do produto e se a Oracle irá mostrar a devoção ao produto que um banco de dados de ponta exige. Na minha opinião, todas essas preocupações são válidas, e, por esse motivo, você deve manter esses três produtos em mente enquanto caminhamos para o futuro.

Recursos

Aprender

Obter produtos e tecnologias

  • Como você está interessado no desenvolvimento de banco de dados, talvez queira experimentar o produto gratuito IBM DB2 Express-C.
  • Experimente outro software IBM sem custo. Faça o download de uma versão de avaliação, faça login em uma versão de avaliação on-line, trabalhe com o produto em um ambiente de simulação ou acesse-o por meio da nuvem. Escolha dentre mais de 100 versões de avaliação de produtos IBM.

Fonte: Michael Abernethy/IBM

Utilizando Invisible Index no Oracle 11g

Saudações, pessoal! Neste artigo, conheceremos a funcionalidade do invisible index, que é uma feature do Oracle Database 11g

Introdução

A feature invisible index foi introduzida no Oracle Database 11g, portanto está presente desde o release 1 do produto. Essa feature torna um índice invisível para o otimizador, ou seja, o índice não será utilizado durante a composição do plano de execução. Diferentemente de um unusable index, ele será mantido pelo banco, logo, ele continuará sofrendo atualizações, inserções e deleções.

O uso

Difícil apontarmos exatamente todas as situações em que esse recurso é aplicável, porém de cara temos duas situações:

Testar o comportamento de uma aplicação antes do drop de um índice. Imaginem que você tem ím indice de 300 Gb (acreditem eles podem existir). Depois de monitorá-lo, você conclui que pode dropá-lo, pois durante o período de monitoração ele não foi usado. Nesse momento é que entra o invisible index, ele se torna mais uma opção de garantir que não teremos nenhum problema se droparmos o índice.Tenha em mente, um índice de 300Mb eu crio rapidamente, mas um índice de 300 Gb pode demorar horas, então, você pode tornar o índice invisível ao otimizador, aguardar um tempo seja ele qual for e depois disso dropá-lo.

SQL> alter index idx_tb_clientes invisible;
SQL> drop index idx_tb_clientes;

Nossa segunda opção é exatamente o contrário. Posso criar um invisible index e testar no nível de sessão se o novo índice será benéfico ou não.


SQL> create index idx_tb_clientes_nome on tb_clientes (nome) invisible;
SQL> alter session set optimizer_use_invisible_indexes=true;
SQL> explain plan for select * from tb_clientes where nome ='DANIEL DE OLIVEIRA';

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3752082546

----------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                      |     1 |    67 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TB_CLIENTES          |     1 |    67 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_TB_CLIENTES_NOME |     1 |       |     1   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("NOME"='DANIEL DE OLIVEIRA')

Note
-----
   - dynamic sampling used for this statement

18 rows selected.

O resto da aplicação continua trabalhando sem utilizar o novo índice.

Manipulação

Aqui, as técnicas para a manipulação do invisible index.

SQL> alter index nome_do_indice invisible;
SQL> alter index nome_do_indice visible;
SQL> create index nome_do_indice on nome_da_tabela (coluna) invisible;

Considerações

O parâmetro que determina do comportamento do invisible index se chama optimizer_use_invisible_indexes, o default é FALSE, ou seja,

o otimizador não utilizará invisible indexes na composição de um plano de execução, se alterarmos seu valor para TRUE, o otimizador

passará a utilizar invisible indexes na composição de planos.

Esse parâmetro pode ser alterado no nível de sessão:


SQL> alter session set optimizer_use_invisible_indexes=true;

A prática

Vamos consolidar a teoria. Nesse exemplo, vamos simular uma situação em que eu tenho um índice (idx_tb_clientes_id), mas eu não quero que o otimizador o utilize para compor um plano.

Criação do ambiente

SQL> set pages 300
SQL> set lines 300
SQL> create table tb_clientes (ID NUMBER(10),NOME VARCHAR2(50),ENDERECO VARCHAR2(50));
SQL> insert into tb_clientes values (1,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (2,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (3,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (4,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (5,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (6,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (7,'MARIA DA SILVA','RUA RUI BARBOSA 169');
SQL> insert into tb_clientes values (8,'DANIEL DE OLIVEIRA','RUA PRUDENTE DE MORAIS 1524');
SQL> commit;
SQL> create index idx_tb_clientes_id on tb_clientes(id);

Verificando se o índice idx_tb_clientes_id está visível pelo otimizador

SQL> select index_name,table_name,visibility
SQL> from user_indexes
SQL> where table_name='TB_CLIENTES';
INDEX_NAME                     TABLE_NAME                     VISIBILIT
------------------------------ ------------------------------ ---------
IDX_TB_CLIENTES_ID             TB_CLIENTES                    VISIBLE

Sim , ele está visível.

Verificando se o otimizador está sendo utilizado para compor planos de execução

SQL> explain plan for select * from tb_clientes where id =3;
SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3101714416

--------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                    |     1 |    67 |     2   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TB_CLIENTES        |     1 |    67 |     2   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_TB_CLIENTES_ID |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("ID"=3)

Note
-----
   - dynamic sampling used for this statement

18 rows selected.

Sim, ele está sendo utilizado.

Tornando o índice idx_tb_clientes_id invisível pelo otimizador

SQL> alter index idx_tb_clientes_id invisible;

Verificando se o índice idx_tb_clientes_id está visível pelo otimizador

QL> select index_name,table_name,visibility
SQL> from user_indexes
SQL> where table_name='TB_CLIENTES';
INDEX_NAME                     TABLE_NAME                     VISIBILIT
------------------------------ ------------------------------ ---------
IDX_TB_CLIENTES_ID             TB_CLIENTES                    INVISIBLE

Verificando novamente se o otimizador está sendo utilizado para compor planos de execução

SQL> explain plan for select * from tb_clientes where id =3;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 2382977096

---------------------------------------------------------------------------------
| Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |             |     1 |    67 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TB_CLIENTES |     1 |    67 |     4   (0)| 00:00:01 |
---------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("ID"=3)

Note
-----
   - dynamic sampling used for this statement

17 rows selected.

Não, agora o otimizador deixa de utilizar o índice idx_tb_clientes_id e faz um table access full. Esse foi um simples exemplo em um ambiente pequeno, o conceito e a aplicabilidade sempre vão além.

Conclusão

Como vimos, a feature invisible index torna a manutenção de índices mais flexível, diminuindo os riscos de perda parcial no nível de resposta de uma aplicação, rotina, ou o que for. A dica que dou é sempre a mesma, em qualquer ambiente de produção, sempre, Desenvolver, Testar, Homologar e Implementar.

Um forte abraço e até a próxima.

Fonte: João Paulo Spaulonci/IMasters

Utilizando o processo Flashback Data Archive

Neste artigo, conheceremos o funcionamento do Flashback Data Archive, que é uma feature do Oracle Database 11g. Ele é também uma estrutura lógica para o armazenamento de informações históricas para uma ou mais tabelas e, em seguida, armazenar esse histórico em uma ou mais tablespaces. As informações nas tabelas serão retidas de acordo com uma política de retenção definida no Flashback Data Archive. Quem realiza essa tarefa é novo processo background FBDA, que trabalha lendo o dado de UNDO no buffer cache. Caso o dado de UNDO não esteja no buffer cache, então ele o lê nos segmentos de UNDO. Depois disso ele consolida as linhas necessárias e escreve no Flashback Data Archive – supondo que o período de retenção seja de 10 dias, toda a informação depois do décimo dia, será deletada.

Os índices originais das tabelas não são mantidos no flashback data archive, pois partimos da premissa de que o dado que será recuperado vai ser utilizado para propósitos diferentes do dado atual da tabela. Para suprir essa demanda, é possível criar índices específicos para a tabela que está no modo Flashback Data Archive.

O uso

Uma das situações mais críticas pelas quais passei foi quando tive que retornar o dado que tinha acabado de atualizar. O analista me mandou um script com uma correção; eu executei e depois da execução ele percebeu o erro. A solução foi ler os dados que ainda estavam na retenção da UNDO. Essa técnica de leitura dos segmentos de UNDO é aplicável quando o erro é percebido rapidamente, pois a ela é cíclica. E isso significa que o dado pode ser reescrito.

Outra técnica que pode ser utilizada é a configuração do banco em Flashback (presente na versão 10g). Porém, as duas técnicas apresentam limitação, já que a retenção do dado está limitada em relação à atividade do banco e à configuração do tempo de retenção. E quem tem uma UNDO retention de 5 anos?

Com o Flashback Data Archive podemos alterar esse comportamento. Nele, podemos definir um período de retenção em dias, meses, ou até mesmo anos e nos preocuparmos somente com espaço. Fazendo uma definição bem pobre, podemos dizer que o Flashback da Archive é a nossa UNDO sem a expiração em horas.

Pré-requisitos

  • Gerenciamento automático da UNDO: Init parameter UNDO_MANAGEMENT= ‘AUTO ‘;
  • Grant Flashback Archive Administer para o usuário que administra o Flashback Data Archive;
  • O banco não precisa estar em archive log mode;
  • Uma tablespace normal separada para o flashback data archive.

Construindo o ambiente

SQL> conn sys as sysdba
SQL> create tablespace tbsd_vendas datafile  '+dg1 ' size 1g;
SQL> create tablespace tbsd_flash_archive datafile  '+dg1 ' size 1g;
SQL> create user vendas identified by a default tablespace tbsd_vendas;
SQL> grant unlimited tablespace to vendas;
SQL> grant resource to vendas;
SQL> grant create sequence to vendas;
SQL> grant flashback archive administer to vendas;
SQL> grant create session to vendas;
SQL> conn vendas/a
SQL> create flashback archive flashvendas tablespace tbsd_flash_archive quota 500m retention 1 year;
SQL> create sequence seq_pedidos start with 1 increment by 1 nocache;
SQL> create table tb_pedidos (id number(5), cliente number(19), produto number(10), qtde number(5), horario date) tablespace tbsd_vendas;
SQL> alter table tb_pedidos flashback archive flashvendas;
SQL> begin
for r in 0..100 loop
insert into tb_pedidos values (seq_pedidos.nextval,1234,900,10,sysdate);
end loop;
commit;
end;
/

Neste artigo, conheceremos o funcionamento do Flashback Data Archive, que é uma feature do Oracle Database 11g. Ele é também uma estrutura lógica para o armazenamento de informações históricas para uma ou mais tabelas e, em seguida, armazenar esse histórico em uma ou mais tablespaces. As informações nas tabelas serão retidas de acordo com uma política de retenção definida no Flashback Data Archive. Quem realiza essa tarefa é novo processo background FBDA, que trabalha lendo o dado de UNDO no buffer cache. Caso o dado de UNDO não esteja no buffer cache, então ele o lê nos segmentos de UNDO. Depois disso ele consolida as linhas necessárias e escreve no Flashback Data Archive – supondo que o período de retenção seja de 10 dias, toda a informação depois do décimo dia, será deletada.

Os índices originais das tabelas não são mantidos no flashback data archive, pois partimos da premissa de que o dado que será recuperado vai ser utilizado para propósitos diferentes do dado atual da tabela. Para suprir essa demanda, é possível criar índices específicos para a tabela que está no modo Flashback Data Archive.

O uso

Uma das situações mais críticas pelas quais passei foi quando tive que retornar o dado que tinha acabado de atualizar. O analista me mandou um script com uma correção; eu executei e depois da execução ele percebeu o erro. A solução foi ler os dados que ainda estavam na retenção da UNDO. Essa técnica de leitura dos segmentos de UNDO é aplicável quando o erro é percebido rapidamente, pois a ela é cíclica. E isso significa que o dado pode ser reescrito.

Outra técnica que pode ser utilizada é a configuração do banco em Flashback (presente na versão 10g). Porém, as duas técnicas apresentam limitação, já que a retenção do dado está limitada em relação à atividade do banco e à configuração do tempo de retenção. E quem tem uma UNDO retention de 5 anos?

Com o Flashback Data Archive podemos alterar esse comportamento. Nele, podemos definir um período de retenção em dias, meses, ou até mesmo anos e nos preocuparmos somente com espaço. Fazendo uma definição bem pobre, podemos dizer que o Flashback da Archive é a nossa UNDO sem a expiração em horas.

Pré-requisitos

Gerenciamento automático da UNDO: Init parameter UNDO_MANAGEMENT= ‘AUTO ‘;

Grant Flashback Archive Administer para o usuário que administra o Flashback Data Archive;

O banco não precisa estar em archive log mode;

Uma tablespace normal separada para o flashback data archive.

Construindo o ambiente

SQL> conn sys as sysdba

SQL> create tablespace tbsd_vendas datafile ‘+dg1 ‘ size 1g;

SQL> create tablespace tbsd_flash_archive datafile ‘+dg1 ‘ size 1g;

SQL> create user vendas identified by a default tablespace tbsd_vendas;

SQL> grant unlimited tablespace to vendas;

SQL> grant resource to vendas;

SQL> grant create sequence to vendas;

SQL> grant flashback archive administer to vendas;

SQL> grant create session to vendas;

SQL> conn vendas/a

SQL> create flashback archive flashvendas tablespace tbsd_flash_archive quota 500m retention 1 year;

SQL> create sequence seq_pedidos start with 1 increment by 1 nocache;

SQL> create table tb_pedidos (id number(5), cliente number(19), produto number(10), qtde number(5), horario date) tablespace tbsd_vendas;

SQL> alter table tb_pedidos flashback archive flashvendas;

SQL> begin

for r in 0..100 loop

insert into tb_pedidos values (seq_pedidos.nextval,1234,900,10,sysdate);

end loop;

commit;

end;

/

O caso

Vamos simular a necessidade de encontrar o valor referente ao campo qtde, da tabela tb_pedidos – referente ao id 27, no dia 19/10/2011 às 19:32:37. Para isso iremos realizar um update alterando o seu valor de 10 para 36.

SQL> select to_char(sysdate, 'dd/mm/yyyy hh24:mi:ss ') as horario from dual;

HORARIO
-------------------
19/10/2011 19:32:37

SQL> select * from tb_pedidos where id=27;

        ID    CLIENTE    PRODUTO       QTDE HORARIO
---------- ---------- ---------- ---------- ---------
        27       1234        900         10 19-OCT-11

SQL> update tb_pedidos set qtde=36 where id=27;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from tb_pedidos where id=27;

        ID    CLIENTE    PRODUTO       QTDE HORARIO
---------- ---------- ---------- ---------- ---------
        27       1234        900         36 19-OCT-11

Vejam que o valor foi alterado para 36. Com a tabela alterada, depois das 19:32:37, vamos descobrir agora o seu valor no horário 19:32:37.

SQL> select * from tb_pedidos as of timestamp to_timestamp( '19/10/2011 19:32:37 ', 'dd/mm/yyyy hh24:mi:ss ') where id=27;

        ID    CLIENTE    PRODUTO       QTDE HORARIO
---------- ---------- ---------- ---------- ---------
        27       1234        900         10 19-OCT-11

Pronto. O valor do campo qtde para o id 27, no horário 19:32:37, era 10. Com essa informação posso reconstruir o dado.

Gerenciando o flashback data archive.

  • Podemos alterar a retenção do Flashback Data Archive:
  • SQL> alter flashback archive flashvendas modify retention 3 year
  • Podemos aumentar o seu espaço:
  • SQL> alter flashback archive flashvendas modify tablespace tbsd_flash_archive quota 800m
  • Podemos expurgar os seus dados:
  • SQL> alter flashback archive flashvendas purge before timestamp(systimestamp – interval ’10 ‘ day)

Podemos dropá-lo:

  • SQL> alter table tb_pedidos no flashback archive
  • SQL> drop flashback archive flashvendas

Restrições

Uma tabela onde o Flashback Data Archive está ativado não pode sofrer:

  • Adição de partições, subpartições e movimentação;
  • Conversão de colunas do tip LONG para LOB;
  • Drop table;
  • Incluir cláusula UPGRADE TABLE com, ou sem a cláusula INCLUDING DATA.

Transparent schema evolution

O Flashback Data Archive suporta na release 11gR2:

  • Drop de colunas e partições;
  • Modificação e renomeação de colunas;
  • Renomeação de tabelas;
  • Truncate de tabelas e partições.

O Flashback data archive suporta na release 11gR1:

  • Adição de colunas

Conclusão

Recomendo a aplicação desse recurso para as tabelas mais críticas do negócio. Mesmo tendo algumas restrições, ainda temos considerável grau de flexibilidade na manutenção de tabelas em modo Flashback Data Archive. Reforço que somente a leitura deste artigo não é o suficiente para uma implementação em produção. Recomendo a leitura de material adicional e a máxima de sempre: para implementação em qualquer ambiente de produção, sempre desenvolver, testar, homologar e depois implementar.

Referências Bibliográficas

ORACLE University. Oracle Database 11g New Features for Administrators: 19-Flashback Technology, Log Miner, and Data Pump Enhacements. California USA. 2.1 ed. Setembro 2010. v.II, p.212-230

Disponível em aqui. Acesso em: 19 out. 2011.

Fonte: João Paulo Spaulonci/IMasters

Atualizações do PostgreSQL corrigem problemas de segurança

Os desenvolvedores do PostgreSQL lançaram updates que englobam todos os ramos do banco de dados SQL open source. As versões 9.1.1, 9.0.5, 8.4.9, 8.3.16 e 8.2.22 do PostgreSQL corrigem uma falha de segurança que resultava em senhas enfraquecidas, e vários bugs encontrados em versões anteriores, incluindo problemas de corrupção de dados.

De acordo com os desenvolvedores, as atualizações corrigem uma vulnerabilidade no código de encriptação Blowfish, usado por contrib/pg_crypto e que poderia causar o enfraquecimento de senhas encriptadas. O mesmo problema foi recentemente diagnosticado e corrigido no PHP 5.3.7 (CVE-2011-2483).

Outras mudanças incluem melhorias ao lidar com erros SSL, correções para login SSPI, VACUUM, para um vazamento de memória no final de um índice GiST, entre outras.

Mais detalhes sobre os updates, incluindo uma lista completa das modificações, podem ser encontrados nas notas de lançamento das versões 8.2.22, 8.3.16, 8.4.9, 9.0.5 e 9.1.1.

Informações postadas originalmente em: The H

Fonte: IMaster

Escolhendo a ferramenta certa para o banco de dados NoSQL

Meu Deus, existem tantas ferramentas para armazenamento do NoSQL por aí. É quase tão ruim quanto as marcas de bebidas esportivas, ou de água. Você notou que alguns supermercados imensos têm corredores inteiros dedicados ao que bebemos?

Como um administrador ou gerente de sistemas de TI, às vezes é muito difícil comparar várias ferramentas do NoSQL. Isso envolve a consideração das suas necessidades computacionais especiais, e o alinhamento das mesmas ao que é disponibilizado no mercado, combinando o que é certo para a sua empresa e então tomando a decisão certa!

É por isso que Monitis, um serviço tudo-em-um de monitoramento de performance de redes e sistemas para sysadmins, está publicando uma série de blogs que tinham o objetivo de oferecer um guia compreensivo para a tecnologia e para as marcas do NoSQL. O objetivo é te ajudar a fazer a escolha certa que atende à necessidade específica da sua empresa.

Por que deveríamos nos importar? – você pode se perguntar. Cada vez mais, nossos clientes, que dependem da nossa habilidade de monitorar servidores e redes e de várias outras métricas-chave dia e noite a partir da nuvem, também querem nosso conselho sobre qual tipo de tecnologia de banco de dados escalável e robusto usar. Portanto, estamos sendo prestativos!

Portanto, apresentaremos pesquisas em ferramentas populares existentes de armazenamento de dados NoSQL, que têm o intuito, geralmente, de armazenar quantidades imensas de dados sem precedentes, oferecer escalabilidade horizontal e flexível, e fornecer o processamento de consultas absurdamente rápido. Também chegaremos ao âmago da questão e iremos comparar vários bancos de dados NoSQL bastante conhecidos, como Cassandra, MongoDB, CouchDB, Redis, Riak, HBase e outros.

Neste primeiro artigo, vamos discutir sobre a razão pela qual a tecnologia NoSQL é importante.

Então, o que é NoSQL?

Geralmente, o NoSQL não é relacional e foi projetado para armazenamento distribuído de dados, para dados de grande escala (p.e. o Facebook ou o Twitter acumulam terabits de dados todos os dias para milhões de usuários), e não existem fixed schemas e joins. Enquanto isso, sistemas de gerenciamento de bancos de dados relacionais (RDBMS) geram escalonamento ao deixar seu hardware cada vez mais rápido e adicionando memória. O NoSQL, por outro lado, pode tirar vantagem de “escalar para baixo” – o que significa distribuir o carregamento entre muitos outros sistemas de conveniência.

O acrônimo NoSQL foi criado em 1998 e, enquanto muitos pensam que o NoSQL é um termo depreciativo criado para tirar sarro do SQL, na verdade ele significa “Não Somente SQL – Not Only SQL”. A ideia é que ambas tecnologias (NoSQL and RDBMSs) podem coexistir e cada uma delas tem o seu lugar. Empresas como Facebook, Twitter, Digg, Amazon, LinkedIn e Google usam o NoSQL de alguma maneira – então o termo tem estado nas notícias atuais nos últimos anos.

Qual o problema com RDBMSs?

Bom, nada, na verdade. Eles apenas têm suas limitações. Considere estes três problemas com RDBMSs:

RDBMSs usam uma abordagem de normalização com base em tabela de dados, e esse modelo é limitado. Certas estruturas de dados não podem ser representadas sem adulteração dos dados, programas, ou ambos…

Elas permitem versionamento ou atividades como: Criar, Ler, Atualizar e Deletar. Para banco de dados, atualizações nunca deveriam ser permitidas, porque elas destroem a informação. Em vez disso, quando os dados mudam, o banco de dados deveria apenas adicionar outro registro e anotar devidamente o valor para aquele registro.

A performance é perdida quando o RDBMSs normaliza os dados. O motivo: a normalização pede mais tabelas, joins de tabelas, chaves e índices e, dessa maneira, mais operações internas do banco de dados para implementar as consultas. Logo logo, o banco de dados começa a crescer para o tamanho de terabytes, e é aí que as coisas começam a ficar lentas.

As quatro categorias do NoSQL

1. Armazenamento Chave-Valor

A ideia principal aqui é usar uma tabela hash na qual há uma chave única e um indicador de um dado ou de um item em particular. O modelo chave-valor é o mais simples e fácil de implementar. Mas ele é ineficiente quando você somente está interessado em consultar ou em atualizar parte de um valor, entre outras desvantagens.

  • Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
  • Aplicações típicas: Cache de conteúdo (Foco em escalar para imensas quantidades de dados, criado para lidar com carregamento massivos) logging etc.
  • Modelo de dados:Coleção de pares de chave-valor.
  • Pontos fortes: Pesquisas rápidas.
  • Fraquezas: Dados armazenados não têm schema.

2. Armazenamento Column Family

Foram criadas para armazenar e para processar grandes quantidades de dados distribuídos em muitas máquinas. Ainda existem chaves, mas elas apontam para colunas múltiplas. As colunas são organizadas por família da coluna.

  • Exemplos: Cassandra, HBase, Riak.
  • Aplicações típicas: Sistemas de arquivos distribuídos.
  • Modelo de dados: Colunas → famílias de colunas
  • Pontos fortes: Pesquisas rápidas, boa distribuição de armazenamento de dados.
  • Fraquezas: API de baixo nível.

3. Banco de Dados orientado a Documentos

Foram inspirados por Lotus Notes e são similares ao armazenamento chave-valor. O modelo é basicamente documentos versionados que são coleções de outras coleções de chave-valor. Os documentos semi-estruturados são armazenados em formatos como JSON. Bancos de dados de documentos são essencialmente o próximo nível do chave-valor, permitindo valores aninhados associados a cada chave. Bancos de dados de documentos suportam as consultas mais eficientemente.

  • Exemplos: CouchDB, MongoDb.
  • Aplicações típicas: Aplicações Web (Similar ao armazenamento chave-valor, mas o BD sabe qual é o valor).
  • Modelo de dados: Coleções de coleções de chave-valor.
  • Pontos fortes: Tolerante a dados incompletos.
  • Fraquezas: Query performance, sem sintaxe de query padrão.

4. Banco de Dados orientado a Grafos

Em vez de tabelas com linhas e colunas e a rígida estrutura do SQL, um modelo gráfico flexível é usado e que pode, mais uma vez, ser escalado através de varias máquinas. Bancos de dados NoSQL não fornecem uma linguagem query declarativa de alto nível como o SQL para evitar tempo extra em processamento. Em vez disso, executar o querying nesse banco de dados é um modelo de dados específico. Muitas das plataformas NoSQL permitem interfaces RESTful nos dados, enquanto outras oferecem query APIs.

  • Exemplos: Neo4J, InfoGrid, Infinite Graph.
  • Aplicações típicas: Redes Sociais, Recomendações (Foco em modelar a estrutura dos dados – interconectividade)
  • Modelo de dados: Grafo de Propriedades – Nós.
  • Pontos fortes: Algoritmos gráficos, p.e. caminho mais curto, conectividade, relacionamentos n degrees etc.
  • Fraquezas: Tem que atravessar todo o gráfico para obter uma resposta definitiva. Não é fácil de agrupar.

Geralmente, os melhores lugares para usar a tecnologia NoSQL é onde o modelo de dados é simples; onde flexibilidade é mais importante que controle rígido sobre estruturas definidas de dados; onde alta performance deve existir; consistência de dados rígida não é necessária; e onde é fácil mapear valores complexos para chaves conhecidas.

Alguns exemplos de quando usar NoSQL

  • Logging/Arquivamento. Ferramentas de Log-mining vêm a calhar porque elas conseguem acessar logs através de servidores, relacioná-los e analisá-los..
  • Insight em computação social. Muitas empresas hoje forneceram a seus usuários a habilidade de atuar na computação social através de fóruns de mensagens blogs etc.
  • Integração de feed de dados externos. Muitas empresas precisam integrar os dados oriundos de seus parceiros. Mesmo se as duas partes conduzirem várias discussões e negociações, as empresas têm pouco controle sobre o formato dos dados que chegam a elas. Além disso, existem muitas situações em que esses formatos mudam muito frequentemente – baseado na mudança das necessidades de negócios dos parceiros.
  • Sistemas de processamento de pedidos Front-end. Hoje, o volume de pedidos, aplicações e serviços flutuando através de diferentes canais para comerciantes, banqueiros e seguradoras, fornecedores de entretenimento, logística etc é enorme. Esses pedidos precisam ser capturados sem nenhum interrupção sempre que um usuário final faz uma transação de qualquer parte do mundo. Depois disso, um sistema de reconciliação tipicamente os atualiza para sistemas de back-end, ao mesmo tempo que atualiza o usuário final com o seu status.
  • Serviço de gerenciamento de conteúdo empresarial. O gerenciamento de conteúdo agora é utilizado através de diferentes grupos funcionais da empresa, como RH ou vendas. O desafio é congregar grupos diferentes utilizando estruturas diferentes de metadados em um serviço comum de gerenciamento de conteúdo.
  • Estatísticas/análises em tempo real. Às vezes, é necessário usar o banco de dados como uma maneira de rastrear métricas de performance em tempo real para websites (visualizações de páginas, visitas únicas etc). Ferramentas como o Google Analytics são ótimas, mas não são em tempo real – às vezes, é util construir um sistema secundário que fornece estatísticas em tempo real. Outras alterativas, como monitoramento de tráfego 24/7, são uma boa opção também.

Que tipo de armazenamento devo usar?

Aqui está um breve resumo que deve te ajudar a decidir:

NoSQL

  • O armazenamento deve ser capaz de lidar com carregamentos pesados.
  • Você executa muitas operações de escrita no armazenamento.
  • Você quer um armazenamento que seja escalável horizontalmente.
  • Simplicidade é bom, como em uma linguagem query bem simples (sem joins).

RDBMS

  • Armazenamento é esperado para apresentar carregamento pesado também, mas consiste principalmente na leitura de operações.
  • Você prefere performance a uma estrutura de dados sofisticada.
  • Você precisa de uma linguagem SQL query poderosa.

Em outros artigos, voltarei a falar do assunto, te guiando através de sete bancos de dados populares do NoSQL e discutindo seus méritos e seus problemas. Fique ligado!

Texto original disponível em http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

Fonte: Mikayel Vardanyan/IMaster

Como realizar as operações CRUD em uma aplicação WPF com DataGrid usando o Linq to SQL

Neste artigo eu vou mostrar como realizar as operações CRUD em uma aplicação WPF com DataGrid usando o Linq to SQL.

Abra o Visual Basic 2010 Express Edition e crie uma nova aplicação WPF com o nome: Wpf_DataGrid_Crud.

Definindo a fonte de dados

Como fonte de dados, eu estou usando um banco de dados SQL Server criado no SQL Server Management Studio com o nome Cadastro.mdf e a tabela Alunos que possui os campos: Id, Nome , Idade e Email.

Abaixo podemos ver na figura o banco de dados, a tabela e seus campos e alguns dados que eu já incluí na tabela.

Para acessar e realizar as operações CRUD, eu poderia usar um DataSet, o NHibernate, o Entity Framework, mas neste artigo eu vou usar o Linq to SQL para mostrar que, embora ofuscado pelo Entity Framework, ele ainda pode ser usado para operações simples como a deste artigo.

Quando pensamos em acesso a dados na plataforma .NET, pensamos em ADO .NET, certo?

Pois bem, como fazemos atualmente para acessar os dados em um banco relacional com ADO .NET? Geralmente efetuamos a representação das tabelas do banco de dados em classes de forma a criar uma interface para persistência das informações.

Isso é feito hoje basicamente de duas formas:

  1. Fazer o mapeamento objeto-relacional usando DataSets e o acesso a dados através de DataAdapters ou TableAdapters com ajuda dos Assistentes de configuração
  1. Fazer o mapeamento objeto-relacional através da criação das classes de negócio via código e acessando os dados usando DataReader

O LINQ To SQL tem o objetivo de reunir o melhor das duas opções, de forma que você possa fazer o mapeamento objeto-relacional criando classes que representam as tabelas do banco de dados, inclusive mapeando stored procedures como métodos e, com isso, possibilitando a criação de consultas e as alterações no banco de dados usando a sintaxe LINQ. Na verdade, as consultas criadas na ‘linguagem’ LINQ são convertidas em código T-SQL, sendo retornada uma coleção de objetos.

Agora vamos incluir a partir do menu Project->Add New Item e a partir da janela Templates o item LINQ to SQL Classes, alterando o nome para Cadastro.dbml e clicando no botão Add.

Neste momento, será exibida a janela do descritor Objeto Relacional. Expanda os objetos do banco de dados Cadastro.mdf e selecione a tabela ‘Alunos’. Arraste-a e solte-a na janela do descrito ORM.

A tabela do banco de dados será mapeada como uma classe (campos como propriedades, procedures e funções como métodos) e você terá no Descritor a classe ‘Aluno’, que representa a tabela ‘Alunos’ do banco de dados.

O arquivo Cadastro.dbml contém o arquivo XML com informações sobre o leiaute da tabela que foi mapeada e também o descritor contendo a classe gerada pelo mapeamento. Após encerrar o mapeamento, você já terá acesso aos recursos do LINQ To SQL com direito a intellisense completo das informações referentes à tabela, mesmo sem conhecer nada sobre ela. Se você abrir a janela de propriedades, verá que o arquivo cadastro.dbml será identificado pelo nome CadastroDataContext e representando o nosso contexto de acesso às classes.

Nota: Você deve definir a chave primária na tabela ‘Aluno’ para que as operações sejam processadas sem erros.

Definindo a interface

Vamos agora criar no arquivo MainWindow.xaml a interface da nossa aplicação que irá exibir os dados da tabela ‘Alunos’. Para isso, vou usar um controle DataGrid definido conforme o leiaute da figura abaixo:

O código XAML usado para definir o leiaute acima pode ser visto abaixo:

<Window x:Class=”MainWindow”

xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”

xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”

Title=”WPF – DataGrid – CRUD com LINQ To SQL” Height=”350″ Width=”525″>

<Grid>

<Grid.RowDefinitions>

<RowDefinition Height=”0.912*”/>

<RowDefinition Height=”0.088*”/>

</Grid.RowDefinitions>

<DataGrid x:Name=”dgData” Margin=”0″ AutoGenerateColumns=”False”

RowEditEnding=”dgData_RowEditEnding”

CommandManager.PreviewExecuted=”dgData_PreviewExecuted”

CanUserAddRows=”True” CanUserDeleteRows=”True”>

<DataGrid.Columns>

<DataGridTextColumn Binding=”{Binding Id}” Header=”ID” IsReadOnly=”True”/>

<DataGridTextColumn Binding=”{Binding Nome}” Header=”Nome” Width=”150″/>

<DataGridTextColumn Binding=”{Binding Idade}” Header=”Idade”/>

<DataGridTextColumn Binding=”{Binding Email}” Header=”Email” Width=”*”/>

</DataGrid.Columns>

</DataGrid>

<TextBlock x:Name=”txtStatus” HorizontalAlignment=”Left” Margin=”8,0,0,0″ Grid.Row=”1″

TextWrapping=”Wrap” VerticalAlignment=”Center”/>

</Grid>

</Window>

Agora abra o arquivo MainWindow.xaml.vb e inclua o seguinte código no evento Loaded da janela Window:

Private Sub MainWindow_Loaded(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles Me.Loaded

Dim ctx As New CadastroDataContext

Dim result = From emp In ctx.Alunos

If result.ToList().Count > 0 Then

txtStatus.Text = “Operação de leitura do arquivo.”

End If

dgData.ItemsSource = result.ToList()

End Sub

Se você executar o código agora (não se esqueça de definir os eventos: dgData_PreviewExecuted e dgData_RowEditEnding), deverá obter o seguinte resultado:

Agora, no evento dgData_RowEditEnding, vamos incluir o código para realizar a inclusão e a atualização dos dados conforme abaixo:

Private Sub dgData_RowEditEnding(ByVal sender As System.Object, ByVal e As System.Windows.Controls.DataGridRowEditEndingEventArgs)

If e.EditAction = DataGridEditAction.Commit Then

Dim contexto As New CadastroDataContext()

Dim _aluno As Aluno = TryCast(e.Row.DataContext, Aluno)

Dim dadosEncontrados = (From em In contexto.GetTable(Of Aluno)() Where em.Id = _aluno.Id).SingleOrDefault()

If dadosEncontrados Is Nothing Then

Dim tabela = contexto.GetTable(Of Aluno)()

Dim _aluno1 As New Aluno()

_aluno1.Nome = _aluno.Nome

_aluno1.Idade = _aluno.Idade

_aluno1.Email = _aluno.Email

tabela.InsertOnSubmit(_aluno1)

tabela.Context.SubmitChanges()

txtStatus.Text = “Dados Inseridos.”

Else

dadosEncontrados.Nome = _aluno.Nome

dadosEncontrados.Idade = _aluno.Idade

dadosEncontrados.Email = _aluno.Email

contexto.SubmitChanges()

txtStatus.Text = “Dados atualizados”

End If

End If

End Sub

Para excluir um registro, vamos usar o evento dgData_PreviewExecuted, incluindo nele o código abaixo:

Private Sub dgData_PreviewExecuted(ByVal sender As System.Object, ByVal e As System.Windows.Input.ExecutedRoutedEventArgs)

Dim _aluno As Aluno = TryCast(dgData.SelectedItem, Aluno)

If _aluno IsNot Nothing Then

Dim alunoEncontrado = (From em In contexto.GetTable(Of Aluno)() Where em.Id = _aluno.Id).SingleOrDefault()

If e.Command.Equals(DataGrid.DeleteCommand) Then

If Not (MessageBox.Show(“Deseja excluir este registro ?”, “Confirma Exclusão !”, MessageBoxButton.YesNo) = MessageBoxResult.Yes) Then

e.Handled = True

Else

contexto.Alunos.DeleteOnSubmit(alunoEncontrado)

contexto.SubmitChanges()

txtStatus.Text = “O registro foi excluído.”

End If

End If

End If

End Sub

Executando o projeto, iremos obter:

Atualizando dados:

Incluindo um aluno novo:

Excluindo um aluno

Assim, pudemos conferir a utilização do LINQ to SQL em uma aplicação WPF para realizar as operações CRUD em um banco de dados SQL Server. O Entity Framework seria uma escolha mais adequada pelos recursos disponíveis e por poder ser usado com qualquer banco de dados.

Fonte: José Carlos Macoratti / IMasters

Microsoft SQL Server Conectado com Hadoop

Através de um anúncio feito pela própria Microsoft, já estão disponibilizados dois conectores Community Technology Previews (CTP) para a plataforma open source map/reduce Hadoop. A tecnologia Hadoop é desenvolvida sob a égide da Apache Software Foundation para o gerenciamento e análise de grandes quantidades de dados. Os conectores permitem a transferência de dados entre o sistema Hadoop, Microsoft SQL Server 2008 R2 e SQL Server Parallel Data Warehouse (PDW).

Esses conectores permitem que grandes quantidades de dados estruturados e não estruturados, sejam manipulados pelo Hadoop utilizando sistemas de bancos de dados da Microsoft. Isso significa que os clientes podem analisar os dados não estruturados no Hadoop, e integrar os resultados extraídos desses dados para o seu produto de data warehouse.

Além disso, conectores SQOOP (Hadoop para SQL) podem fazer uma transferência de dados entre o Hadoop File System (HDFS) e os bancos de dados relacionais.

Fonte: Under-Linux