The Opera Summary

O novo recurso de Intellisense do SQL Server 2008 Management Studio pode trazer ganhos expressivos de produtivdade para desenvolvedores e DBAs, mas pode também diminuir a produtividade quando não está atualizado.

Quando novos objetos ou campos são criados, alterados ou excluídos, dentro ou fora do ambiente do Management Studio, o cache do Intellisense não é atualizado automaticamente. Quanto mais alterações são feitas no banco, mais desatualizado fica o Intellisense, e quanto mais desatualizado, menos útil ele é.

Para atualizar o cache do Intellisense, basta usar a opção Edit | Intellisense | Refresh Local Cache, mas eu prefiro o atalho de teclado CTRL+SHIFT+R. A atualização se dá em background e nenhuma mensagem será exibida quando a atualização é finalizada.

Foi disponibilizado ontem o download do SQL Server 2008 SP1. Para a decepção de muitos, não há praticamente novas funcionalidades, mas a boa notícia é que há muito poucas correções críticas no produto. A lista de correções afeta principalmente (a) uma situação de erro muito específica na instalação em cluster; (b) uma situação específica quando se usa a opção OPTION (RECOMPILE), que não é nem uma boa prática; (c) uma questão de botões ausentes na interface da versão em chinês do utilitário de execução de pacotes; (d) um detalhe de protocolos habilitados quando se repara a instalação de uma instância e (e) na instalação do SQL Express, a atribuição incorreta do nome padrão da instância.

Correções são sempre bem-vindas, mas dificilmente algum dos problemas solucionados no SP1 devem ocorrer em 99.9% dos ambientes. O que é uma ótima notícia.

Para o SQL Server, isso é mais uma prova da estabilidade e confiabilidade do produto. Ele foi lançado oficialmente em agosto/2008, o Service Pack saiu primeiro como CTP em 23/02/09 e só teve a versão oficial liberada ontem, e mesmo assim, com pouquíssimas correções, em cenários muito específicos e pouco críticos.

As novas funcionalidades do SP1 são a habilidade de consolidar o SP1 na instalação do produto e de permitir a desinstalação apenas do Service Pack através da opção “Adicionar/Remover programas” do Painel de Controle. Em relação ao Report Builder, ele agora pode ser acessível através do OneClick.

Já faz algum tempo que temos utilizado o SQL Server 2008 em nossa empresa. Desde setembro de 2007, quando tivemos nosso primeiro contato no Solid Quality Summit LATAM em Sampa, temos explorado versões CTP e os novos recursos sempre nos pareceram muito instigantes. Quando a versão RTM saiu em agosto de 2008, imediatamente passamos a utilizar o SQL Server em larga escala. Vale a pena ressaltar alguns recursos que na minha opinião fazem uma diferença especial no 2008.

1. Intellisense - O Management Studio (SSMS) agora sugere o preenchimento dos comandos que são digitados, no mesmo estilo do Visual Studio. Você digita SELECT * FROM e ele já mostra uma lista de schemas. Depois de escolher a tabela e voltar para o SELECT, ele mostra uma lista dos campos da tabela. Erros de sintaxe são sublinhados em vermelho e parênteses que abrem e não fecham são destacados. Qualquer situação de erro sublinhada em vermelho será detalhada ao passar o mouse. O Intellisense já era possível no 2005 com produtos de terceiros (o da Red Gate custa 195 dólares...) e dá uma enorme produtividade no dia-a-dia de qualquer DBA. Pra usar o Intellisense não basta ter o cliente do SQL 2008, ele precisa também estar conectado a uma instância de 2008.
2. Comando MERGE - Sou um grande fã desse novo comando e já fiz um post aqui só sobre esse assunto. Ele gera muita economia de código em projetos de BI, principalmente na construção do Data Warehouse. Através de um único comando, pode-se resolver diversas situações de sincronização de dados. Em nossos projetos de BI, o uso do comando MERGE está trazendo uma redução drástica no tempo de desenvolvimento e teste das rotinas de carga. Além disso, o código fica mais claro e limpo.
3. Backup comprimido - É uma prática comum configurar planos de backup mantendo um certo número de backups de dias anteriores, para aumentar o nível de proteção e permitir uma recuperabilidade mais ampla e ágil se necessário. No entanto, com o crescimento dos bancos de dados e o uso cada vez mais comum de discos SAS ou Fiber Channel de alto desempenho (o que significa menor capacidade), a área de disco disponível para backup não comporta tantos backups, embora os bancos por aí tenham superado facilmente a casa das centenas de gigabytes. O backup comprimido com um fator médio de compressão de 5 pra 1 ajuda a manter os backups seguros e duradouros. Infelizmente, esse recurso não está disponível na versão Standard, mas nem tudo é perfeito...
4. Reporting Services - Definitivamente, o membro da família Microsoft BI que mais recebeu atenção no SQL 2008 foi o Reporting Services. Os novos componentes incorporados de gráfico e gauge da Dundas são muito superiores aos rudimentares controles de gráfico do SSRS 2005. O novo Tablix deixa o design dos relatórios muito mais flexível. O designer ficou muito mais produtivo com os ribbons no estilo do Offfice e os novos editores de propriedade por contexto. O SSRS não depende mais do IIS, o que representa um ganho arquitetural revolucionário. O Report Designer é uma aplicação stand-alone que permite que os usuários editem seus próprios relatórios (enfim!)
5. Suporte a GIS - Agora o SQL Server suporta dois tipos de dados: GEOMETRY e GEOGRAPHY, tudo compatível com os padrões da OGC (Open Geospatial Consortium). Com isso, podem ser armazenadas informações geográficas, tais como mapas, pontos e áreas. E os campos com esses tipos de dados ainda podem ser indexados, dando um excelente desempenho para buscas diversas. Isso pode ser usado, por exemplo, em aplicações gerenciais que mostram indicadores de negócio através de cores e ícones em cima de mapas.
6. FILESTREAM - Este novo tipo de dados permite que os dados binários de um campo e registro sejam automaticamente direcionados para um arquivo numa partição NTFS. O mais interessante é que todo o gerenciamento desse arquivo é automática. Se o registro for excluído, o arquivo também será. No backup do banco, os arquivos também vão junto e são restaurados no mesmo caminho com a restauração do backup.
7. Estabilidade - até o momento, não tivemos um único problema de instabilidade do SQL 2008. O fato de o produto não ter recebido nenhum Service Pack desde seu lançamento em agosto é um excelente sinal de que pode-se esperar uma boa estabilidade das versões RTM do SQL Server.

Se vocês ainda não testaram o SQL Server 2008, baixem a versão trial de 180 dias (6 meses!) da versão Enterprise:

http://www.microsoft.com/sqlserver/2008/en/us/trial-software.aspx

Um bom começo é usar o cliente do SQL 2008 pra administrar instâncias de versões anteriores. Depois, pode-se partir para o upgrade das instâncias.

A Microsoft já divulgou sobre o que devemos esperar da nova versão do SQL Server, prevista para lançamento no primeiro semestre de 2010. O Kilimanjaro é o codinome do novo SQL Server, que terá como parte integrante (e principal) o Gemini, um conjunto de novos recursos de BI voltados para Office e Sharepoint.

A palavra-chave para o próximo SQL Server será Business Intelligence (BI). Poucas mudanças serão feitas no engine do SQL Server e poucas melhorias de gerenciamento serão introduzidas, mas a grande maioria dos novos recursos será focada em BI. O intuito do Gemini é prover um conjunto de add-ins para o Office para criar o conceito que a Microsoft está chamando de "Self-service BI". O objetivo é trazer BI para perto dos usuários, para que eles próprios possam usá-lo sem o auxílio direto de profissionais de TI. Veja o anúncio da Microsoft aqui.

Já o Madison deverá ser um produto comercializado à parte. Ele será o resultado da compra da DATAllegro pela Microsoft. Será possível o tratamento de grandes volumes de dados para Datawarehouses, tais como centenas de terabytes, e serão introduzidos recursos como o processamento distribuído de consultas em vários servidores.

Tenho observado diversas críticas em relação ao um ciclo de lançamento muito curto (2-3 anos) para versões de um produto de infra-estrutura tão crítico como o SQL Server. No entanto, as ferramentas automáticas de upgrade têm sido cada vez mais eficientes e o modo de compatibilidade configurável por banco de dados tem ajudado a migrar para as novas versões com impactos reduzidos. Vale a pena sempre conferir a versão mais nova do Upgrade Wizard do SQL Server antes de iniciar qualquer migração.

Estive recentemente adotando uso em massa do comando MERGE, novidade do SQL Server 2008, que facilita enormemente o trabalho de sincronização de dados entre tabelas. Para projetos de construção de Data Warehouses, ele economiza muitas linhas de código e simplifica muito a lógica da sincronização de dados.

Vamos direto para um exemplo prático. Suponha uma tabela Empresa de destino:

create table Empresa (
  id int not null identity(1,1)
  ,CodigoEmpresa char(2) not null
  ,NomeEmpresa varchar(100) not null
  ,CodigoFilial char(2) not null
  ,NomeFilial varchar(100) not null
  ,constraint PK_Empresa primary key (id)
)

A origem dos dados está em um arquivo SIGAMAT.EMP, de estrutura DBF, como ocorre no Sistema Microsiga. A consulta a seguir retorna os dados da origem, diretamente do arquivo DBF:

select m0_codigo as codigoEmpresa, m0_nome as nomeEmpresa, m0_codfil as codigoFilial, m0_filial as nomeFilial
from OPENROWSET('MSDASQL','Driver={Microsoft dBASE Driver (*.dbf)}; DefaultDir=C:\DBF\; SourceType=EMP','select * from sigamat')

O comando MERGE para sincronizar o destino de acordo com os dados da origem fica assim:

MERGE Empresa AS dst
USING (select m0_codigo as codigoEmpresa, m0_nome as nomeEmpresa, m0_codfil as codigoFilial, m0_filial as nomeFilial from OPENROWSET('MSDASQL','Driver={Microsoft dBASE Driver (*.dbf)}; DefaultDir=C:\DBF\; SourceType=EMP','select * from sigamat')
) AS src
  ON (dst.codigoEmpresa = src.codigoEmpresa and dst.codigoFilial = src.codigoFilial)
  WHEN MATCHED THEN UPDATE SET dst.NomeEmpresa = src.nomeEmpresa, dst.nomeFilial = src.nomeFilial
  WHEN NOT MATCHED BY SOURCE THEN DELETE
  WHEN NOT MATCHED THEN INSERT VALUES(codigoEmpresa, nomeEmpresa, codigoFilial, nomeFilial);

Logo em seguida ao comando MERGE é definida a tabela de destino, criando um alias (apelido), neste caso dst. Em seguida, a cláusula USING define a origem dos dados, que é a consulta ao DBF mencionada acima. Também é importante identificar a origem por um apelido, neste caso src.

A cláusula ON identifica o critério de JOIN entre origem e destino, no caso pelos campos de código de empresa e código de filial.

A cláusula WHEN MATCHED indica o que deve ser feito caso haja uma correspondência entre origem e destino (no caso, normalmente se deseja atualizar um ou mais campos).

A cláusula WHEN NOT MATCHED BY SOURCE indica o que deve ser feito quando o registro existe no destino mas não existe na origem. Quando se deseja manter o sincronismo, é preferível excluir o registro no destino, como é o caso deste exemplo.

A cláusula WHEN NOT MATCHED indica o que deve ser feito quando o registro não existe no destino. Em geral, deve-se inserir dados.

Pode-se também usar a cláusula opcional OUTPUT, para mostrar a ação executada usando a palavra-chave $action e exibindo campos das tabelas virtuais inserted e deleted, que possuem a mesma estrutura dos dados manipulados.

Este é um exemplo bastante simples, embora bastante prático e útil em nossos projetos de BI com Microsiga. O comando MERGE possibilita o tratamento de sincronização de dados em diversos outros cenários mais complexos.