Revista MSDN Magazine Edição 08 -Microsoft SQL Server 2005, codename Yukon

A nova versão do Microsoft SQL Server terá várias inovações nas mais diversas áreas, tais como novas instruções T-SQL, melhorias nos serviços de Reporting Services, Data Mining, Notification Services e novas ferramentas de gerenciamento. Na próxima versão, o SQL Server poderá processar stored procedures, user-defined functions, triggers, aggregates e user-defined types escritas em linguagens modernas e orientadas a objetos compatíveis com o CLR do .NET Framework, como VB.NET, C# e Managed C++. Os novos serviços disponíveis na próxima versão do SQL Server incluem Service Brocker, User Defined Types, suporte nativo para XML e XSD e XQuery, entre outros. Neste artigo, fornecerei uma visão geral de cada um dos novos recursos da próxima versão do Microsoft SQL Server.

Integração com o CLR do .NET Framework

O código gerado pelos compiladores da plataforma Microsoft .NET se beneficiam das funcionalidades do Common Language Runtime (CLR). Os programas desenvolvidos para usar os recursos do CLR (denominados programas de código gerenciado) usam recursos como: integração entre linguagens de desenvolvimento, gerenciamento de erros com suporte a múltiplas linguagens, segurança de código, controle avançado de versão, facilidades no processo de instalação, modelo simplificado de integração de componentes, suporte à depuração, relatórios de performance, além de muitos outros.

Com a nova versão do SQL Server, os desenvolvedores não estarão mais limitados apenas ao Transact SQL (T-SQL) para extrair e manipular dados. O T-SQL foi criado há quase uma década e é ótimo para acesso a dados, porém é uma linguagem estruturada, com várias limitações que complicam ou impossibilitam tarefas simples como acesso a recursos externos ao banco de dados (por exemplo, Web Services e acesso a arquivos em disco) por meio de instruções T-SQL. Com a integração com o CLR, tarefas avançadas (tais como manipulação de imagens ou validações de dados em servidores remotos) podem ser realizadas com extrema facilidade no contexto de uma trigger ou stored procedure que utilize linguagens orientadas a objetos, como VB.NET, C# ou Managed C++.

O uso da CLR será possível em stored procedures (procedimentos armazenados), user-defined functions (funções definidas pelo usuário) e triggers (disparadores). Isso significa que será possível desenvolver uma stored procedure em código VB.NET, C#, Managed C++ ou qualquer outra linguagem compatível com o CLR (linguagens estas já familiares para vários desenvolvedores). A manipulação desses processos será feita acessando-se o contexto de execução de cada procedimento e, em seguida, adicionando-se, removendo-se ou modificando-se dados por meio de objetos semelhantes aos existentes no atual ADO.NET. Veja na Listagem 1 o exemplo de uma stored procedure escrita em C#.

        using System;

        using System.Data.SqlServer;


        namespace MeuAssemblyCLR

        {

        public class AcessoDadosPubs

        {

        public AcessoDadosPubs(){}

        public static int GetNumeroDeAutores()

        {

        int nRows;

        SqlCommand sqlCmd = SqlContext.GetCommand();

        sqlCmd.CommandText = "SELECT COUNT (*) AS 'Numero de Autores' FROM AUTHORS";

        nRows = (int)sqlCmd.ExecuteScalar();

        return nRows;

        }

        }

        }
        

Após a criação da dll assembly, é preciso registrar o assembly no banco de dados. Uma vez feito isto, é possível criar uma stored procedure apontando para uma determinada função dentro do assembly com a instrução CREATE PROCEDURE.

        CREATE ASSEMBLY MeuAssemblyCLR

        FROM 'MeuAssemblyCLR.dll'

        GO

        CREATE PROCEDURE

        GetNumeroDeAutores AS EXTERNAL NAME

        MeuAssemblyCLR:[MeuAssemblyCLR.AcessoDadosPubs]::GetNumeroDeAutores

        GO

        DECLARE @numeroDeAutores INT

        EXEC @numeroDeAutores = GetNumeroDeAutores

        PRINT @numeroDeAutores
        

Note que, apesar de o código interno da stored procedure ser escrito em código gerenciado, é necessário que seu resultado seja consultado via T-SQL como qualquer stored procedure escrita em T-SQL.

A integração com o CLR é uma das principais novidades do SQL Server Yukon. Essa integração é resultado de anos de trabalho dos times de SQL e Visual Studio, e é extremamente benéfica. Ela estará presente em toda a plataforma do novo SQL Server Yukon, e não só nas funções que o usuário usa com mais freqüência. Por exemplo, a nova interface com o usuário, o SQL Workbench (que integrará o antigo Query Analiser e o Enterprise Manager), é toda criada na plataforma .NET por meio de código gerenciado. O próprio núcleo do SQL Server usa os recursos da CLR em várias áreas para gerenciar memória e manipular XML.

Novos recursos T-SQL

Com todas as novidades e recursos relacionados à integração com o Framework .NET, muitos podem pensar que a Microsoft está planejando descontinuar o T-SQL, o que é totalmente fora de cogitação. Na verdade, o T-SQL continua sendo a melhor opção para acesso direto a dados, como você deve ter notado nos exemplos anteriores (todo o acesso aos procedimentos que usam .NET são feitos por instruções T-SQL). Foram criadas novas instruções T-SQL, e algumas foram atualizadas e estendidas nesta nova versão do banco de dados. A revisão feita nas instruções T-SQL no SQL Server Yukon tornou-o mais compatível com o padrão ANSI-99 SQL. Dentre as muitas novas instruções T-SQL, destacam-se os operadores PIVOT e UNPIVOT, APPLY, blocos de tratamento de erros TRY/CATCH, recursos para consultas recursivas ou Common Table Expressions (CTE) e melhoria nas instruções TOP. Como o conteúdo dessas instruções é vasto, não irei abordá-las em mais detalhes neste artigo. No entanto, você pode conseguir informações mais detalhadas no Books Online do SQL Server Yukon.

Service Broker

O SQL Server Service Broker é uma nova parte do núcleo do servidor SQL Server responsável por enviar, receber e processar mensagens assíncronas enviadas de um banco de dados a outro, pela mesma instância do banco de dados ou por instâncias diferentes, seja na mesma máquina ou em máquinas diferentes. A tarefa de enviar e receber mensagens assincronamente, de maneira confiável e ordenada, pode ser agora delegada ao Service Broker, deixando o desenvolvedor livre para as tarefas realmente pertinentes às regras de negócio da aplicação.

O uso de aplicações que se comunicam ou agendam tarefas por mensagens não tem nada de novo. Por exemplo, um uso comum de mensagens pode ser um pedido que precise de aprovação de um gerente para ser efetuado. A aplicação posiciona o pedido em uma fila de mensagens gerenciadas pelo Service Broker, as quais esperam pela aprovação do gerente. Uma vez aprovadas, as mensagens seguem e são inseridas no banco de dados de acordo com as regras de negócio definidas pelo desenvolvedor.

No entanto, o Service Broker não é apenas um “agendador” de tarefas. Ele possui recursos extremamente úteis que permitem aumentar significativamente a performance de uma aplicação. Um desses recursos é chamado de Activation (ativação). Para constatar sua utilidade, imagine a seguinte situação: um serviço de Website leva um tempo variável para processar um pedido. Se uma requisição que usualmente levaria 10 segundos é iniciada e, logo após, outras 10 requisições de 1 segundo são colocadas na fila, os últimos dez clientes precisariam esperar o término da primeira tarefa para ter uma resposta. Com os recursos de Activation do Service Broker, novas linhas de processamento de pedidos são dinamicamente criadas ou fechadas de acordo com a demanda, o que significa que as requisições de 1 segundo não precisariam necessariamente ser executadas na ordem da fila. Quando uma nova mensagem é recebida, o Service Broker verifica se existe alguma instância de stored procedure processando uma mensagem do mesmo tipo. Se existir, ele a utiliza para processar a nova mensagem, economizando assim os recursos que seriam necessários para instanciar uma nova stored procedure. Se as mensagens chegarem mais rapidamente do que a stored procedure conseguir processá-las, serão criadas dinamicamente novas instâncias da stored procedure para distribuir o trabalho de maneira uniforme, como na Figura 1.

O Service Broker também possui recursos transacionais que fazem com que as mensagens aguardem na fila quando um serviço (por exemplo, o de processamento de pedidos) se torna indisponível. Essas transações podem aguardar horas, dias ou até anos, mesmo que o serviço de banco de dados seja reiniciado.

Recursos como transações distribuídas, conversação assíncrona de aplicações, formatação de mensagens via XML e “contratos” entre aplicações são outras novidades do Service Broker.

XML & XQuery

A próxima versão do SQL Server, codename Yukon, traz o suporte a XML extremamente melhorado. O novo tipo de dados XML permite inserir e manipular XML em campos do banco de dados da mesma forma que se manipula um inteiro ou texto, com melhorias como validação de schemas XSD e consultas com a nova linguagem XQuery.

Com o Xquery, você poderá criar filtros nas consultas em campos XML da mesma maneira que o faz com as expressões XPath. Como o novo tipo XML é nativo do banco de dados, é possível usá-lo como se ele fosse um tipo nativo SQL-99 em procedimentos como retorno de funções, parâmetros para stored procedures, como uma variável ou campo em uma tabela.

Possuir um campo XML em uma tabela do banco de dados é útil porque o campo passa por todas as validações de segurança e backup e pelos processos de replicação e validação de dados por XSD, além de ser armazenado no banco de dados e não em um arquivo no sistema de arquivos.

A Listagem 2 exemplifica como as instruções XQuery podem ser utilizadas para criar validações em campos XML e filtros em consultas.

        CREATE TABLE Livro(

        id INTEGER PRIMARY KEY,

        sumario XML CHECK (pdoc::exist('/livro/autor')=1)

        )

        GO

        INSERT Livro VALUES('')

        INSERT Livro VALUES('')

        INSERT Livro VALUES('')

        INSERT Livro VALUES('')

        GO

        SELECT id,

        xml_col::value('/livro/autor/@nome', 'varchar(50)') AS Nome

        FROM Livro

        GO
        

Performance

Um dos principais benefícios da nova integração com o CLR é o ganho de produtividade pelo uso da CLR, porém como o novo SQL Server carrega os componentes da CLR em seu próprio processo de execução, também são esperados ganhos de performance com o uso do CLR.

No que se refere ao desempenho em consultas, o time de desenvolvimento do query optimizer espera ganhos de aproximadamente 15% em relação à versão 2000 do SQL Server. Durante a fase beta (que vem acontecendo desde outubro de 2003), o principal objetivo dos times de desenvolvimento da Microsoft é deixar o produto funcional e sem bugs. Atualmente, o SQL Server Yukon tem previsão de três versões betas e duas candidatas à lançamento. Somente durante a fase de preparação do Beta 3 poderão ser constatados os reais ganhos de performance. Hoje, estamos no início da fase Beta 2, e a performance medida certamente não será a mesma de quando o produto for lançado, em 2005.

SQL Server Mobile Edition, codename Laguna

Para os desenvolvedores usuários da versão atual do SQL Server CE 2.0, a próxima versão do banco de dados para dispositivos portáteis trará diversas melhorias nos quesitos desempenho, segurança e estabilidade, bem como no uso de recursos como memória e processador, além de um novo nome: SQL Server Mobile Edition.

A nova interface de administração do SQL Server Yukon (o SQL Server Workbench) permitirá que o desenvolvedor conecte dispositivos móveis e interaja com seus bancos de dados a partir do desktop. Também será possível visualizar o Query Plan (plano de execução) do banco de dados do dispositivo móvel, o que possibilita a criação de novas estratégias de layout e consulta no banco de dados.

O recurso de múltiplos usuários, tão pedido na última versão do banco de dados, foi enfim adicionado. Além disso, recursos existentes (como transferência de dados com Merge Replication e Remote Data Access) foram melhorados com novos assistentes de publicação e sincronização, configurações finas de compactação de dados, publicação de tabelas de leitura somente e suporte real para DTS (Data Transformation Services) do lado do servidor.

No SQL Server Laguna, todo o mecanismo de consulta, paginação e compactação de dados foi totalmente reescrito. Com este novo design, o banco de dados não mais “crescerá” de forma desordenada, mas sim de maneira organizada, visando se manter no menor tamanho possível.

O novo suporte a “managed” stored-procedures e outros, criados a partir de assemblies .NET , não são suportados na nova versão do SQL Server Mobile Edition.

Conclusão

A próxima versão do Microsoft SQL Server apresenta ótimos recursos e melhorias há muito esperadas pela comunidade de desenvolvimento. O suporte nativo ao CLR melhorará a produtividade no desenvolvimento de aplicações juntamente com o novo Visual Studio Whidbey e com outras plataformas de desenvolvimento. O time de desenvolvimento da Microsoft trabalhou muito para conseguir uma taxa de disponibilidade nunca vista no banco de dados, e as novas ferramentas de backup e gerenciamento reduzirão bastante o tempo levado para recuperação de desastres. Os novos módulos revitalizados de data mining facilitarão a filtragem e exibição de informações em relatórios por meio do novo Reporting Services.

No próximo ano, já teremos disponível uma versão do Microsoft SQL Server desenhada pela Microsoft para dominar o mercado de banco de dados. Com a maioria das limitações da versão atual corrigidas, não será tarefa difícil atingir este objetivo.