Change Tracking – O que é? Como Usar?
Olá pessoal,
Hoje comentarei sobre um recurso velho no SQL Server (desde o 2008) mas que vejo pouco utilizado e que muitas vezes os desenvolvedores fazem algumas coisas “mirabolantes” para ter resultados similares.
O Change Tracking (CT) e o Change Data Capture (CDC) são ferramentas de suporte a sincronização. O CDC abordarei no próximo post.
Os cenários em que o CT se aplica são aqueles cenários onde você trabalha com aplicações offline, aplicações ocasionalmente conectadas ou aplicações que não necessitam conhecer em tempo real que houve atualização nos dados.
O Change tracking lhe garante a informação sobre qual linha foi modificada (linha inserida, coluna atualizada, deletada, etc.). O seu “irmão” Change Data Capture armazena todo o histórico do dado modificado (por essa razão pode ser vista como uma solução mais custosa).
Em cenários de DW ambas tecnologias podem ajudar a identificar as linhas que sofreram modificação para que seja extraído do sistema transacional somente as linhas que foram modificadas e assim diminuir a carga sobre os sistemas transacionais fontes (CT e CDC são features do SQL Server, no SQL Server 2012 há a possibilidade de utilizar o CDC para Oracle – Instalador externo presente na mídia do SQL Server 2012).
SQL Saturday #284 – Porto Alegre
Olá pessoal,
Hoje estamos tendo a edição #284 do SQL Saturday (Porto Alegre).
Fiz uma apresentação sobre MDX (ainda há muito chão para ele mesmo com o DAX), e aqui disponibilizo os materiais.
Obrigado a todos os presentes! :)
Whitepaper de Performance Tuning para o Modelo Tabular do SSAS 2012
Olá pessoal,
Este post é apenas para informar que já foi lançado o Performance Guide para o modelo tabular do Analysis Service 2012. Recebi já muitas perguntas sobre ele e aqui está.
Performance Tuning of Tabular Models in SQL Server 2012 Analysis Services
http://msdn.microsoft.com/en-us/library/dn393915.aspx
Enjoy!
PS: Esse post ficou algum tempo nos drafts, o guide já saiu há alguns meses e em breve teremos atualização para cobrir servidores NUMA.
Data Explorer Release de Maio
Olá a todos!
Sexta-feira passada foi lançada publicamente mais uma build (May Release) do Data Explorer.
O Data Explorer é um add-in para o Excel para você realizar transformações nos dados de uma forma facilitada (self-service) e passível também de integração com o PowerPivot para análise.
Essa versão de maio contém diversas novidades que podem ser acompanhadas no blog do time de produto do Data Explorer:
http://blogs.msdn.com/b/dataexplorer/archive/2013/05/13/data-explorer-may-update-is-available-now.aspx
Essa ferramenta tem muito potencial, principalmente nos cenários em que a utilização do Integration Services (SSIS) poderia aumentar muito a complexidade da solução.
Fica a dica ;)
Thiago Zavaschi
Analysis Services Internals – Formula e Storage Engines (e como funciona o cache?)
Olá pessoal!
O tópico de hoje é para servir de base a todos que desejam conhecer um pouco mais de como o servidor do Analysis Services (SSAS) trabalha por trás dos panos.
Existem diversos mecanismos internos que são responsáveis / interagem no processamento de uma query que é enviada ao servidor de análise (o processo detalhado de execução de uma query vou abordar em um tópico futuro específico): XMLA Listener, Formula Engine, Storage Engine e assim por diante.
Esse post abordará sobre o que é e para que servem a Formula e a Storage Engine.
Sharepoint e Reporting Services – O que é suportado?
Olá pessoal, depois de um longo e tenebroso inverno (leia-se: muito trabalho aqui no time de engenharia) estou de volta e pretendo postar sobre os casos com que lido e continuar algumas séries de posts antigas aqui do blog.
O ponto que quero abordar hoje é sobre a suportabilidade da integração do SharePoint com o Reporting Services.
É de senso comum de quem trabalha com as tecnologias de Business Intelligence da Microsoft saber que o Reporting Services pode ser configurado para trabalhar de modo autônomo (modo nativo) ou em modo integrado ao SharePoint. No entanto nem sempre fica claro quais são as restrições de versões para essa compatibilidade.
Por exemplo: Posso usar o Reporting Services do SQL Server 2008 R2 com o SharePoint 2010? E com o SharePoint 2013? E se for o SQL Server 2008? E a versão dos Add-ins?
Este post serve para elucidar estes casos. Este post é baseado no seguinte pedaço do books online (em inglês): http://msdn.microsoft.com/en-us/library/dc6a3372-db26-43f0-b7aa-f725acc635c2
SSIS Package Configuration (XML File) – Trocando a Connection String entre Servidores
Olá!
Uma dúvida comum que sempre surge quando vou atender um caso de SQL Server Integration Services (SSIS) é:
“Ok Thiago desenvolvi 100 (leia-se muitos) pacotes no SSIS, porém toda a vez que vou fazer o deploy destes pacotes em homologação e produção eu tenho que ficar mudando as connection strings. Como proceder?”
O SSIS tem um mecanismo para ajudar neste sentido chamado SSIS Package Configuration, onde é possível salvar a suas configurações em um arquivo XML, variável de ambiente ou até mesmo em uma tabela do SQL Server que contenha os valores.
No artigo de hoje vou abordar apenas a configuração através de arquivo XML.
Mas então, como fazer?
Desenvolva seu pacote normalmente. Utilizando os Data Sources de desenvolvimento e associando os respectivos Connection Managers a eles da forma que for necessária ao seu fluxo.
Agora o que precisamos fazer é criar um arquivo de configuração XML que conterá os dados que os data sources utilizarão ao invés do que você configurou previamente.
Esta configuração você fará para o primeiro pacote e depois reutilizará o mesmo arquivo de configuração para os demais pacotes.
SQL Server Analysis Services – Query Log 2000 x 2005+
Olá pessoal,
Estando no time de suporte premier da Microsoft recebo muitos chamados de clientes que desejam migrar seu Analysis Services do 2000 para versões mais recentes como o 2008 R2 e 2012.
Uma dúvida comum é sobre as diferenças entre a versão 2000 e as demais.
Hoje falaremos das principais diferenças do query log do SSAS 2000 para os SSAS posteriores.
O SSAS possui capacidade de logar informações sobre as queries que são disparadas contra o servidor (não estou falando do Profiler (traces) e nem do Flight Recorder (que também é um trace)) conhecido como query log.
O SSAS não armazena evetivamente a query executada, porém armazena informações sobre quais atributos e measures foram utilizadas, que mais tarde pode ser utilizada pelo wizard de otimização baseado em uso.
O SSAS 2005 (e os posteriores) não loga as queries na tabela de log de queries por padrão. Para fazer o log você deve explicitamente ativar esse recurso nas propriedades do SSAS.
A partir do SSAS 2005 não é possível utilizar o Access como repositório para o log de queries. Obrigatoriamente você terá de usar uma database do SQL Server para isso.
O SQL Server não precisa residir no mesmo computados que o SSAS.
O Analysis Services não utiliza mais o registro do windows para armazenar suas propriedades. Todas as propriedades do servidor SSAS que controlam o comportamento do query log são acessíveis através do Management Studio ou através da modificação do arquivo de configuração do SSAS.
O formato (campos e tipos de dados) da tabela de log mudou. Se você utiliza para algum outro fim, você precisará ajustar seus scripts personalizados.
Para maiores informações sobre como configurar o query log do SSAS segue o link (em inglês):
http://technet.microsoft.com/en-us/library/cc917676.aspx
Obrigado!
Gestão de Memória no Reporting Services
Olá pessoal :)
Uma dúvida muito comum que recebo é: posso por o meu servidor de relatórios (Reporting Services) no mesmo servidor de base de dados (database engine). A resposta é: claro que pode…. tecnicamente, mas dependendo da demanda, não é uma boa estratégia quando o objetivo é performance.
O foco aqui será a questão da gestão da memória RAM, mas o fato de usar o mesmo servidor também tem impacto na parte de processamento (vamos deixar isso para um post futuro abordando arquitetura :) ).
É fato que a engine relacional do SQL Server utiliza toda a memória disponível para ele, seja com cache de dados, planos e etc. A questão é que o Reporting Services também tenta fazer isso. E a velha máxima persiste: dois corpos não podem ocupar o mesmo local no espaço ao mesmo tempo.
Ok.. ok… traduzindo: a mesma porção de memória não pode ser ocupada por dois processos ao mesmo tempo.
SQL Server Reporting Services – Trace Log e HTTP Log
Olá!
Assim como a engine do SQL Server e muitos outros produtos (Microsoft ou não), estes possuem um log de trace sobre o que acontece com o aplicativo/serviço, não acontece diferente no Reporting Services.
Os arquivos de trace log do Reporting Services variam de acordo com a versão do SQL Server. Até o SQL Server 2005 (onde ainda tinhamos dependência do IIS para o SSRS) haviam 4 tipos de arquivos de log que por padrão são limitados a 32MB por arquivo e são automaticamente deletados após 14 dias. Estes arquivos são texto plano, então qualquer editor de texto consegue abrir.