Arquivo da categoria ‘SQL Server 2012’

Performance e Otimização de Aplicações Através do Banco de Dados

Neste artigo o principal objetivo será mostrar os passos para a obtenção de uma melhor performance da Aplicação através do Banco de Dados.

Acho que todos que trabalham na área de desenvolvimento de sistemas, já sofreram com a “lentidão” do sistema na hora de realizar a busca de dados no Banco de Dados. O problema pode estar em alguns fatores físicos (problema de conectividade ou de hardware) ou em fatores lógicos (Erros na Aplicação ou mal desempenho do Banco de Dados).

Os problemas mais comuns são causados por:

  • Erro de Comunicação;
  • Erros na aplicação;
  • Erros nas queries;
  • Problemas no hardware;
  • Modelagem de dados incorreta;
  • Recursividade/Duplicidade de dados;

Tais problemas não podem em hipótese alguma tornarem-se comuns dentro do seu ambiente. Por isso segue uma lista das soluções da qual você deve tomar para evitar a continuidade de tais problemas.

1) Modelagem do Banco de Dados:

Uma má performance geralmente é resultado de uma modelagem ruim. É importante se preocupar com a modelagem, pelo menos até a 3FN (Terceira Forma Normal).

2) Tuning de Aplicação, Lei do 80/20 dos Bancos de Dados:

Por mais que os desenvolvedores reclamem do servidor de banco de dados, em 80% dos casos o problema está na aplicação e em 20% no SGDB. Não que a aplicação seja ruim em si, mas ela pode não usar o SGDB de forma eficiente. Existem várias formas de se obter os mesmos dados de forma ineficiente. Pior, uma consulta que funcionava bem num SGDB pode ter uma performance catastrófica em outro SGDB. Infelizmente isto pode ocorrer também com migrações para outra versão do mesmo SGDB. Mesmo assim, a culpa ainda não é do SGDB. A aplicação que tem (infelizmente) de adaptar às especificidades de cada fornecedor e cada versão. Somente otimize o SQL depois que tiver certeza que o código está correto.

3) Lei do 80/20 da informática

Cerca de 20% dos parâmetros de configuração do seu SGDB são utilizados em 80% do tempo. Aprenda a manejar bem estes parâmetros antes de mais nada. A maioria dos outros parâmetros são utilizados em ocasiões específicas e não tem um impacto tão forte no desempenho. Normalmente o tuning do SGDB começa por estes parâmentros mais importantes, os demais só são utilizados se você conhece especificidades da sua aplicação que sugerem o seu uso, caso contrário são deixados em seus valores padrão.

4) Conheça o perfil das suas aplicações

A forma como a sua aplicação utiliza o seu SGDB é de suma importante para o DBA. Existem alguns padrões que lhe indicam caminhos já trilhados por outros. Sendo assim identificar o tipo de carga que a aplicação projeta sobre o banco de dados é muito importante. Aqui alguns tipos clássicos:

  • OLTP ou On Line Trasactional Processing: consiste na maior parte da carga das aplicações corporativas atuais. É caracterizado por um grande volume de pequenas transações conconrretes e alto volume de gravações. As cargas OLTP são as que tem o desempenho de disco mais crítico.
  • BI ou Business Inteligence: consistem num universo paralelo com diversas tecnologias como Data Mining, OLAP, Data Warehouse, Data Mart e Balanced Scored Card. A questão é que quando falamos em BI, o banco de dados sempre acaba de um jeito ou de outro, tendo que suportar consultas enormes, com grande quantidade de dados e cálculos complexos. As cargas de BI exigem muita velocidade em leitura de disco, memória para ordenações e uso intenso do processador.
  • Sites Web Dinâmicos: os sites dinâmicos são aqueles que armazenam o seu conteúdo num banco de dados. Desta forma um único acesso numa página web pode representar uma dúzia de pequenas leituras no banco de dados. As cargas de sites web são caracterizadas por um enorme número de conexões simultâneas realizando pequenas leituras.
  • Operações em lote ou batch: são cargas de trabalho intensas no banco de dados que podem durar várias horas para se completar e tem um grande impacto na performance. São comuns tanto em aplicações OLTP (cálculo de uma folha de pagamento, fechamento de ano fiscal, etc), como em BI (carga de grandes tabelas vindas de fontes externas). As cargas em lote sempre são alvos de estudos cuidadosos tem o potencial de crescer rapidamente em tempo de execução até inviabilizar os negócios da empresa.
5) Tuning de I/O Físico:

Arquivos de Banco de Dados precisam estar com o tamanho correto e em um local que prove um mínimo de I/O.

6) Elimine Contenção de Dados:

Eliminar ao máximo eventos que realizam contenção de dados, chamados de Wait Events ou Eventos de Espera. Pode-se classificá-los em dois tipos:
Físico: Evento espera disco rígido ou de uma quantidade de memória disponível ou de acesso a rede, por exemplo, para que seja concluído.
Lógico:Evento espera recursos computacionais para que seja concluído. Como por exemplo:Lock O mecanismo de lock (trava), é um conceito aplicados à MultiUsuário, onde quando é iniciada uma transação, o usuário irá travar o banco para ele até que a transação se efetivada(commit) ou rejeitada(rollback).

Latch É um mecanismo de alocação de estruturas na memória SGA (System Global Area) serializado e desenhado para que sejam alocados por curtos períodos de tempo. Ele controla os vários processos que desejam acessar áreas compartilhadas da SGA, permitindo que somente um processo de cada vez acesse a estrutura requisitada, evitando corrupção da memória, ou seja, mantendo a integridade.

7) Melhorar os comandos de busca
7.1) Padronização

Garanta que os comandos sejam escritos absolutamente iguais para facilitar a reutilização no banco de dados. O re-parsing no banco de dados pode ser evitado para cada uso subseqüente.

Ex:

SELECT * FROM EMP;

É diferente de:

Select * From Emp;

SELECT * from EMP;

Procure trazer do banco de dados somente as informações necessárias, e por mais que a linguagem SQL não seja case sensitive, busque sempre padronizar suas pesquisas. Lembre-se: Se você não precisa da informação contida em uma coluna específica, não é preciso trazê-la.

Procure otimizar primeiro os SQL mais críticos. Não gaste tempo otimizando códigos que nunca ou raramente serão usados.

7.2) Utilização de Índices

Use índices, mas não os crie em demasia. Muitos índices podem resultar em um efeito adverso na performance. Lembre-se de escolher o tipo de índice mais adequado a cada situação. O critério básico para escolha de índices é a seletividade. Quando o banco de dados resolve uma consulta, freqüentemente, ele precisa percorrer mais registros do que aqueles realmente retomados pela consulta. Os registros percorridos que forem rejeitados representam o trabalho perdido. Quanto menor for o trabalho perdido, mais perto estaremos da performance ótima para resolver a consulta.

Portanto, o melhor índice para uma consulta é aquele que apresenta a maior seletividade.Construa os índices a partir das restrições dos SELECT (cláusula WHERE); Lembre-se que as comparações usando “<>”, “NOT”, “NULL”, “LIKE” podem invalidar o índice.

7.3) Não faça nada muito complexo caso desnecessário

Realize a divisão das queries complexas em queries menores. Evite lógicas complexas de negócio no SQL. A lógica deve ficar no código fonte. Lembre-se que: SQL não é uma linguagem procedural.

7.4) Evitem comandos SORT (Ordenação ou Agregação)

Use os comandos que produzem sort (Group By, Order By, Distinct, etc.) somente quando necessário. No sort, o banco recupera todas as informações necessárias primeiro e depois as ordena.

7.5) Mude a maneira de pensar

Os comandos “EXIST” e “NOT EXIST” possuem menor custo do que os comandos “IN” e “NOT IN” na maior parte dos casos. Quando a maioria dos filtros estiver na sub-query o comando “IN” se torna mais eficiente.

Procure usar “EXISTS” ao invés de “DISTINCT”.

Use:
SELECT dept_no, dept_name
FROM dept d
WHERE
EXISTS (SELECT ‘X’
FROM emp e
WHERE e.dept_no = d.dept_no);

Ao invés de:

SELECT DISTINCT dept_no, dept_name
FROM dept d, emp e
WHERE
d.dept_no = e.dept_no;

Toda vez que houver função na coluna, o índice não será usado.

Use: WHERE cargo = rtrim(1);

Ao invés de:

WHERE rtrim(cargo) = 1;

Evite comparar dados incompatíveis. O SQL Server converte automaticamente os campos char e number, mas evite utilizar este recurso.

8) Finalizando

Fica válido que quando falamos dos conceitos de performance do banco de dados, devemos lembrar que sua Base de Dados está ligada diretamente ao seu SGBD (Sistema Gerenciador de Banco de Dados), e muitas vezes algumas regras de desempenho se aplicam exclusivamente à forma na qual o SGBD foi desenvolvido. Por isso podemos ter resultados de performance diferentes quando realizamos testes com mais de um SGBD.

Espero que tenha ajudado a entenderem um pouco mais sobre performance da Banco de Dados. Foram passados alguns conceitos básicos sobre desempenho do banco de dados, como no ultimo artigo segue uma lista de links onde pode-se aprender mais sobre o assunto:

http://www.macoratti.net
http://www.oracle.com
http://imasters.com.br
http://msdn.microsoft.com
https://www.soe.ucsc.edu
http://www.devmedia.com.br
http://docs.oracle.com
http://www.linhadecodigo.com.br

Este artigo tem como principal objetivo mostrar os principais objetos de Banco de Dados Oracle e SQL Server.

Lembrando que o estudo de banco de dados vai muito além do que será comentado aqui.

OBJETOS BÁSICOS:

Constraint – é uma regra com a qual os dados devem estar em conformidade. O nome da restrição é opcional. Tipos de Constraint:

  1.     NOT NULL – Não permite valores nulos;
  2.     PRIMARY KEY – Atribui uma chave primária à um ou mais campos de uma tabela;
  3.     UNIQUE KEY – Atribui à um ou mais campos a integridade de que os valores são únicos;
  4.     FOREIGN KEY – Atribui à um campo a integridade de referencia a outra tabela;
  5.     CHECK – Atribui uma regra de validação para a inserção de um campo;
  6.     DEFAULT – Atribui um valor padrão quando for inserido um valor nulo;

Tables – As tabelas são os objetos principais em um modelo relacional, pois são elas que armazenam e organizam os dados de forma lógica dentro do banco de dados. Uma tabela écomposta por tuplas (linhas ou registros) e colunas(atributos).

Exemplo:

  • ORACLE

    
    CREATE TABLE Sample_Oracle
    ( Sample_Id NUMBER(6) ,
    Sample_First_Name VARCHAR2(20) ,
    Sample_Last_Name VARCHAR2(25) CONSTRAINT Sample_Last_Name_NotNull NOT NULL,
    Sample_Email VARCHAR2(65) CONSTRAINT Sample_Email_NotNull NOT NULL,
    Sample_SignUp_Date DATE DEFAULT SYSDATE CONSTRAINT Sample_SignUp_Date_NotNull NOT NULL ,
    Sample_Salary NUMBER(8,2),CONSTRAINT Salary_Min_Check CHECK (salary > 0) ,
    CONSTRAINT Sample_Email_UniqueKey UNIQUE (Sample_Email),
    CONSTRAINT Sample_id_PrimaryKey PRIMARY KEY (Sample_id)) ;

  • SQL Server

     CREATE TABLE Sample_SQLServer
    ( Sample_Id NUMBER(6) ,Sample_First_Name NVARCHAR(20) ,
    Sample_Last_Name NVARCHAR(25)  NOT NULL,Sample_Email NVARCHAR(65) NOT NULL,
    Sample_SignUp_Date DATETIME  NOT NULL  DEFAULT GETDATE() ,
    Sample_Salary DECIMAL(8,2),
    CONSTRAINT Salary_Min_Check CHECK (salary > 0) ,
    CONSTRAINT Sample_Email_UniqueKey UNIQUE (Sample_Email) ,
    CONSTRAINT Sample_id_PrimaryKey PRIMARY KEY (Sample_id)) ;

Indexes – Em bancos de dados, um índice é uma estrutura de dados que melhora a velocidade de operações de recuperação ou alteração de dados em uma tabela.
Exemplo:

  • ORACLE

    CREATE INDEX Sample_Name_Index ON Sample (Sample_Name)
    TABLESPACE SampleSpace

* TableSpace – Uma unidade de armazenamento que contém as estruturas lógicas do banco.

  • SQL SERVER

    CREATE CLUSTERED INDEX Sample_Name_Index ON Sample (Sample_Name)

*No SQL Server, existem basicamentes dois tipos de índices:

  1. Index Clustured: Geralmente criado quando criamos uma PimaryKey. Possui uma ordenação a nível de tabela.
  2. Index Non-Clustered: Possui uma ordenação a nível de pagina possui as mesmas restrições dos index clustered

View – Tabela Virtual ou Lógica gerada apartir de uma Consulta. É possivel aplicar todos os comando DML(Data Manipulation Language) em uma View [Select | Insert | Update | Delete].
Exemplo:

  • ORACLE & SQL Server

    CREATE VIEW Sample_View  AS
    SELECT * FROM Sample

Materialized View(Oracle) – As Materialized Views podem inicialmente ser confundidas com tipos de views, porém apresentam algumas diferenças significativas. É obtida através de uma consulta, mas os dados resultantes da Materialized View são armazenados em uma tabela física, pode ser tanto cópias locais quanto remotas (Bancos Diferentes). É muito utilizado para BI (Business Inteligence).
Exemplo:

  • ORACLE

    CREATE MATERIALIZED VIEW LOG ON Samples
    WITH ROWID, SEQUENCE (Sample_Id)
    INCLUDE NEW VALUES
     
    CREATE MATERIALIZED VIEW
    BUILD IMMEDIATE
    REFRESH FAST ON COMMIT
    AS SELECT * FROM Sample

Indexed View (SQL Server) – Segue o mesmo conceito de uma Materialized View no Oracle. Indexar uma View, os dados são armazenados em uma tabela virtual e são atualizados sempre que os dados de suas tabelas originais são alterados. As Views indexadas são recomendadas, quando os dados das tabelas que são utilizadas nas Views não sofrerem muitas alterações. No caso de existirem muitas alterações nos dados das tabelas, o tempo de processamento para montar o Index da View pode ser maior que o tempo para fazer a consulta sem Index às tabelas.
Exemplo:

  • SQL SERVER

     
    CREATE VIEW Sample_View  AS
    SELECT * FROM Sample
     
    CREATE CLUSTERED INDEX Sample_Indexed_VIew ON Sample_View (Sample_id)

Sequences (Oracle) – As sequências são um recurso largamente utilizado no Oracle, pois é muito comum que sistemas utilizem números sequenciais (por exemplo, para atribuir um código a um funcionário). Muitos bancos de dados oferecem um tipo de dado autonumerado que pode serutilizado na definição da coluna (no momento da criação da tabela), porém o Oracle não possui esse tipo. Em contrapartida, o Oracle oferece o objeto sequence, que fornece omesmo tipo de funcionalidade, diferenciando-se apenas pelo fato de que é um objeto independente da tabela.
Exemplo:

  • ORACLE

    CREATE SEQUENCE Sample_Id_Sequence
    START WITH 1
    INCREMENT BY 1
    MAX VALUE 999
    NOCYCLE
     
    INSERT INTO Sample (Sample_id, Sample_Name) VALUES (Sample_Id_Sequence.nextval, ‘Alfredo Henrique’)

 Identity (SQL Server) – A finalidade incrementar um valor a cada nova inserção.
Exemplo:

  • SQL SERVER

    CREATE TABLE Sample
    ( Sample_id Numbe(6) NOT NULL Indentity (1,1),
    Sample_Name  VARCHAR (50) NOT NULL)
     
    INSERT INTO Sample (Sample_Nome) VALUES (”Alfredo Henrique’)
Procedures – São blocos de comandos PL/SQL que podem ser chamados por um nome, e que podem ser compilados e armazenados. Isso proporciona a possibilidade de reutilização do bloco de comandos. As procedures podem ter parâmetros definidos na sua criação, e consequentemente utilizados dentro do bloco de comandos. Procedures não precisam obrigatoriamente ter algum valor de retorno.
Exemplo:
 

  • ORACLE

    CREATE OR REPLACE PROCEDURE SP_Sample_UpdateProcedure
    ( @Sample_Name VARCHAR2(25), @Sample_id NUMBER (6))
    IS
    ExceptionValue EXCEPTION
     
    BEGIN
     
    IF (@Sample_id <> NULL) THEN
    UPDATE Sample SET Sample_Name = @Sample_Name;
    ELSE
    RAISE ExceptionValue;
    END IF;
     
    EXCEPTION
    WHEN ExceptionValue THEN
    RAISE_APPLICATION_ERROR(-20999,’ATENÇÃO! Operação INVÁLIDA’, FALSE);
     
    END SP_Sample_UpdateProcedure

  • SQL SERVER

    CREATE PROCEDURE SP_Sample_UpdateProcedure
    ( @Sample_Name VARCHAR2(25), @Sample_id NUMBER (6))
    AS
    BEGIN
     
    IF (@Sample_id <> NULL) THEN
    UPDATE Sample SET Sample_Name = @Sample_Name;
    ELSE
    RAISEERROR (,’ATENÇÃO! Operação INVÁLIDA’, 16, 1);
     
    END

Outros Objetos

Synonyms – Este recurso tem como objetivo proporcionar a possibilidade de criar apelidos para um ou mais objetos que façam parte deste sinônimo. Sua utilização facilita em muito o desenvolvimento de scripts, quando se existe a necessidade de utilizar objetos em locais distintos armazenados no Banco de Dados. Com esta alternativa o Banco acelera a busca de objetos criados.
É possível utilizar Tables, Views, Funções Scalar, Funções In-Line, Stored Procedure, Extended Stored Procedure, Assembly e Filtros de Replicação, sendo necessário que estes objetos existam fisicamente no servidor SQL Server, caso contrário a criação ou alteração deste sinonimo é cancelada.

Packages – São objetos que organizam logicamente um conjunto de objetos( procedures ou functions, por exemplo) que pertencem a um mesmo grupo. Os pacotesfacilitam a organização e o acesso aos objetos que os compõem. Um package é composto porduas partes: as especificações (specification) e corpo do pacote (body).
Até o SQL Server 2000 era possível a criação de Packages atrás do serviço de Data Transformation Services (DTS). Mas no SQL Server 2005 e 2008 o DTS não é mais suportado, sendo assim, a Microsoft adicionou uma ferramenta chamada SQL Server Business Intelligence Development Studio, responsável em criar projetos para importação/exportação de dados entre diversas fontes de dados, possibilitando a integração de informações.

Functions – São, assim como as Procedures, blocos de comandos que podem ser chamados através de um nome e são reutilizáveis. Além disso, também aceitam parâmetros definidos em sua criação. Devem ter sempre o retorno de um valor.

Este artigo apresentou alguns dos objetos básicos de um Banco de Dados. Caso esteja interessado em adquirir mais conhecimento no assunto seguem algumas fontes:

Algumas Novidades no SQL Server 2012

Publicado: 21 de agosto de 2012 por Prof @Virtualiza Cooperativa em SQL Server 2012

E ae pessoal, tudo bem?! Um breve artigo sobre algumas novidades do Sql Server 2012.

O SQL SERVER 2012 foi constituído dentro de 3 pilares(Missão Critica, Percepções Inovadoras e A Nuvem nos seus termos), dentro desses 3 pilares temos os 12 principais pontos

Ambientes de Missão Critica

Desempenho Ultra-rápido

Segurança e conformidade

Mais tranquilidade, mais parceiros

Produtividade na equipe de Desenvolvimento

“O sistema de nuvens é comparado ao fornecimento de luz: uma empresa mantém os servidores e aluga espaço virtual e uma transmissão de volume de dados e cobra por isso. “Se usar mais, vai pagar mais caro, se usa menos, paga pouco”. “Isso reduz custo porque elimina todo o custo de capital que seria usado para comprar um servidor e deixa todo esse dinheiro disponível para o operacional.”

Estenda os dados

Destaques no SQL Server 2012

Algumas outras novidades

Novidades no T-SQL

Sequence

Código para criação

Novas funções escalares

Novas funções de conversões, as outras continuarão essas foram adicionadas

Código para cria-las

Outras de conversão

Novas Funções de tipos temporais

Parâmetro 3 na função “EOMONTH” é a quantidade de meses que ele vai adicionar.

Novas Funções Lógicas

Novas Funções Textuais

Código das novas funções

Throw – (Tratamento de erros)

Código Throw

 


A tabela a seguir descreve as edições principais do SQL Server. Para obter mais informações, consulte Recursos compatíveis com as edições do SQL Server 2012.

Edição do SQL Server Definição
Enterprise (64 bits e 32 bits) Oferta especial, a edição SQL Server 2012 Enterprise fornece recursos de datacenter abrangentes de alta tecnologia com desempenho incrivelmente rápido, virtualização ilimitada e Business Intelligence de ponta a ponta — oferecendo altos níveis de serviço para cargas de trabalho importantes e acesso a visões de dados para usuários finais.
Business Intelligence (64 bits e 32 bits) A edição SQL Server 2012 Business Intelligence fornece uma plataforma abrangente que permite que as empresas criem e implantem soluções BI seguras, flexíveis e gerenciáveis. Ela oferece funcionalidades surpreendentes, como exploração e visualização de dados baseadas em navegador; recursos avançados de combinação de dados e gerenciamento de integração aprimorado.
Standard (64 bits e 32 bits) A edição SQL Server 2012 Standard fornece gerenciamento de dados básicos e bancos de dados BI para departamentos e pequenas empresas executarem seus aplicativos, e oferece suporte a ferramentas de desenvolvimento comuns para rede local e em nuvem — permitindo o gerenciamento eficiente de bancos de dados com mínimos recursos de TI.

As edições especializadas do SQL Server são destinadas às cargas de trabalho comerciais. A tabela a seguir descreve as edições especializadas do SQL Server.

Edição do SQL Server Descrição
Web (64 bits e 32 bits) A edição SQL Server 2012 Web é uma opção de baixo custo total de propriedade para hospedagem de sites e VAPs da Web que fornece recursos de escalabilidade, economia e capacidade de gerenciamento para propriedades da Web de pequeno a grande porte.

As edições de amplitude do SQL Server foram criadas para cenários de cliente específicos e são oferecidas GRATUITAMENTE ou a um custo irrisório. A tabela a seguir descreve as edições de amplitude do SQL Server.

Edição do SQL Server Descrição
Developer (64 bits e 32 bits) A edição SQL Server 2012 Developer permite que os desenvolvedores criem qualquer tipo de aplicativo com base no SQL Server. Ele inclui todas as funcionalidades da edição Enterprise, mas é licenciado para ser usado como um sistema de teste e desenvolvimento, e não como um servidor de produção. O SQL Server Developer é uma opção ideal para pessoas que criam e testam aplicativos.
Edições Express (64 e 32 bits) A edição SQL Server 2012 Express é o banco de dados básico gratuito, ideal para conhecer e criar aplicativos de desktop e plicativos controlados por dados de pequenos servidores. É a melhor escolha para fornecedores de software independente, desenvolvedores e interessados que criam aplicativos cliente. Se precisar de recursos mais avançados de banco de dados, o SQL Server Express pode ser perfeitamente atualizado para versões mais sofisticadas do SQL Server. A novidade do SQL Server 2012 é o SQL Server Express LocalDB, uma nova versão leve do Express que tem todos os seus recursos de programação, embora seja executada no modo de usuário e tenha uma instalação rápida e sem nenhuma configuração e uma lista curta de pré-requisitos.