Red Gate – Overview

Acredito que é praticamente impossível existir um DBA de SQL Server que nunca tenha ouvido falar dos produtos da Red Gate Software. Mas vamos a um overview de alguns produtos que considero interessantes, e nos próximos artigos, vou demonstrar o funcionamento destas ferramentas.

SQL Prompt Pro:
Oferece recursos como o intellisense de T-SQL, snippets, formatação do script, entre outras funcionalidades. Totalmente integrado com o SQL Server Management Studio e possui algumas funções também integradas com o Visual Studio.

O que é intellisense e snippets? Intellisense é aquele “autocomplete” que quando você escreve “SELECT * FROM” e já aparecem os nomes das tabelas do banco de dados para você selecionar. Snippets é aquele recurso que permite configurar atalhos para alguns comandos, exemplo, escrever “sl” e já aparecer “SELECT”.

SQL Compare Pro (também para Oracle):
Basicamente permite comparar a estrutura de dois bancos de dados e gerar um script para sincronizar a estrutura deles, além de outras operações mais complexas.

A função básica desta ferramenta é semelhante ao Schema Compare do Visual Studio, mas com muito mais possibilidades e recursos (comparação de arquivos de backup, snapshot, scripts).

SQL Data Compare Pro (também para Oracle):
Permite comparar a massa de dados de dois bancos de dados, e gerar o script para sincronizar esta massa de dados, também oferecendo recursos para outras operações mais complexas.

A função básica desta ferramenta é semelhante ao Data Compare do Visual Studio, mas com muito mais possibilidades e recursos.

Considerações finais

Também há várias outras ferramentas para SQL Server, como o SQL Source Control (controle de versão de documentos e script para SQL Server), SQL Monitor (monitor de desempenho e alertas) e SQL Doc (documentação do banco de dados), e outras para Visual Studio, Oracle e Exchange.

Mais informações:
http://www.red-gate.com/

Visual Studio 2010 – Data Compare

Dando sequência ao artigo anterior, vamos á comparação de dados entre dois bancos de dados com o Visual Studio 2010 Premium ou Ultimate e também entender como ajustar o script gerado pelas ferramentas Data e Schema Compare.

Também no menu Data do Visual Studio, temos a opção “New Data Comparison”:

Informamos os bancos de dados a serem comparados:

Na próxima tela informamos as tabelas e visões a serem comparadas:

Obs.: Lembre-se que se não houver uma chave única ou primária entre as tabelas, não será possível compará-las.

Obs.: Comparações em bancos de dados de produção podem levar muito tempo ou prejudicar o desempenho, então defina bem o escopo dos dados e em que momento esta operação será realizada.

Processo de comparação concluído, temos as diferenças entre os dados dos dois bancos de dados, onde na primeira aba teremos os dados com mesma chave e valores diferentes:

Na segunda aba, o que só estão no banco Source e serão adicionados no Target (se não desmarcados):

Na Terceira, os que somente estão no Target e serão excluídos:

Por fim, registros iguais ou semelhantes:

Após informar o que irá ou não ser replicado para o banco de dados Target, aplique as alterações:

Ou abra o script para edição:

Permitindo ajustar o script de forma a evitar qualquer conflito não resolvido pelas ferramentas Data e Schema Compare:

Com estas funcionalidades de comparações estruturais e de dados, o Visual Studio começa ganhar importância não somente para os desenvolvedores e testers, mas também para os DBAs.

Espero que estas duas features estejam presentes nos próximos SQL Server Management Studio!

F# no SQL Server

Boa noite pessoas!

No artigo desta semana, estarei demonstrando a criação de funções UNSAFE em um ambiente de integração CLR com o SQL Server. Um detalhe importante é o uso do F#, uma das novas linguages suportadas pelo Visual Studio 2008 e 2010. 

Para aqueles que desejam aprender um pouco mais sobre F#, abaixo segue o link de um artigo muito bom do Ted Neward:
http://msdn.microsoft.com/pt-br/magazine/cc164244.aspx

Microsoft F# May 2009 CTP

Para esta demonstração, estarei utilizando o Visual Studio 2008 com Microsoft F# May 2009 CTP, esta distribuição do F# além de ser bem diferente das primeiras, possui uma boa integração com o Visual Studio. Abaixo o link para download:
http://www.microsoft.com/downloads/details.aspx?FamilyID=7bb32f32-9fac-4f34-ad56-b0bda130cf00&displaylang=en

Criando um assembly CLR com F#:

Após instalar o CTP, além dos templates convencionais do Visual Studio 2008, haverá três modelos para trabalhar com o F#, o que utilizarei será o “F# Library”:

Continuar lendo

Publicando Assemblies e Funções CLR no SQL Server

Boa noite pessoas!

Com este artigo, vou demonstrar como publicar manualmente no SQL Server as funções que tenham sido desenvolvido em um projeto SQL-CLR. Visto que não foram de tanta utilidade os links que eu enviei para aqueles que me questionaram por email, eu acredito que este artigo ajudará resolver estas necessidades.

Antes de iniciar com a demonstração, é necessário que entendam que o Visual Studio/.NET Framework gera o Assembly CLR (uma DLL, como preferir), que será necessário ser incorporada (referenciado) às outras Assembly já presentes no banco de dados. Antes de incorporar este Assembly, será necessário que seja habilitado o suporte/integração CLR presente no SQL Server (isso é uma configuração que vale para toda a instância do SQL Server e já foi demonstrada no artigo “Habilitando CLR no SQL Server”).

O Assembly é incorporado á um banco de dados e não a toda a instância do SQL Server, desta forma, se quiser utilizar este assembly em outro banco, será necessário incorporar o assembly a este outro banco.

Todas as funcionalidades (stored procedures, funções…) do Assembly deverão ser referenciadas também no banco de dados, pois não são automaticamente criadas quando é incorporado o assembly.

 

Publicando Assemblies CLR no SQL Server

Para publicações manuais, é recomendável optar pela opção “Release”, feito isso, clique na opção build do projeto.

Você poderá encontrar o Assembly CLR do projeto na pasta “bin\Release” do projeto. Para chegar até esta pasta mais rapidamente, você pode clicar com o botão direito sobre o projeto e chamar o item “Open Folder in Windows Explorer”.

 

Na pasta de release, você encontrará o assembly de seu projeto, agora mova este arquivo para uma pasta dentro do servidor de banco de dados.

No SQL Server, precisaremos referenciar o Assembly CLR ao banco de dados. Para executar este procedimento, é possível optar pelo SQL Server Management Studio, onde clicando com o botão direito em “Databases\[Nome do banco de dados]\Programmabiliby\Assemblies”, chamando o item “New Assembly” (conforme a figura abaixo), será aberto o painel de configurações para o novo assembly.

Conforme a figura abaixo, informe o caminho para seu banco de dados e algumas configurações adicionais, que algumas vezes podem ser necessárias.

Ou se preferir, é possivel criar este novo assembly de forma semelhante por código, conforme o exemplo:

CREATE ASSEMBLY [CS_SQL] FROM 'D:\CS_SQL.dll'
WITH PERMISSION_SET = SAFE

Pronto, agora você possui seu assembly dentro de seu banco de dados.

 

Para criar as referencias às funções do Assembly CLR dentro do banco de dados, utilizarei o seguinte exemplo, onde é criada uma função SQL que possui características semelhantes as da função CLR por ela referenciada em EXTERNAL NAME.

CREATE FUNCTION [dbo].[Pitagoras](@ab [float], @bc [float])
RETURNS [float]
AS
EXTERNAL NAME [CS_SQL].[UserDefinedFunctions].[Pitagoras]
GO

Feito isso, basta testar.

SELECT dbo.Pitagoras(3,2) AS Resultado;

 

Para finalizar esta série sobre CLR, no próximo artigo estarei trabalhando outra opção de integração CLR, ainda “unsafe”, mas uma opção interessante para trabalhar com cálculos pesados.

 

Artigos relacionados:

Habilitando CLR no SQL Server:
https://sqlfromhell.wordpress.com/2009/09/19/habilitando-clr/

Criando funções CLR para o SQL Server:
https://sqlfromhell.wordpress.com/2009/09/26/funcoes-clr/

Debug de funções CLR no SQL Server:
https://sqlfromhell.wordpress.com/2009/10/03/debug-clr/

Debug de funções CLR no SQL Server

Boa noite pessoas!

Para tratar uma dúvida que surgiu a respeito do debug (acompanhando a execução) de funções CLR-SQL, neste artigo realizarei uma breve demonstração, com a qual espero responder boa parte dos questionamentos relacionados.

Debug de funções CLR no SQL Server

Continuando com o mesmo exemplo do artigo anterior, colocarei um breakpoint na linha “double AB = ab.Value”.

Para quem não conhece o lendário breakpoint, ele é uma ferramenta utilizada para pausar a execução do código, no momento em que a instrução será passada para o servidor, tornando possível observar os estados das variáveis naquele “momento”.

Para inserir um breakpoint, basta clicar sobre a margem esquerda do código que aparecerá o breakpoint (bolinha vermelha), como no exemplo abaixo:

Na pasta “Test Scripts” do projeto, existe um arquivo SQL (ou você pode criar o seu), o qual eu alterarei para executar o seguinte comando SQL:

SELECT dbo.Pitagoras(3,2) AS Resultado;

Após salvar as alterações, executarei o debug deste arquivo clicando com o botão esquerdo sobre o mesmo e chamando o item “Debug Script”, conforme a figura abaixo.

Se você preferir, é possível optar pelo item “Set as Default Debug Script”, permitindo chamar a execução deste arquivo com o botão F5 ou clicando sobre o botão de debug (semelhante a um botão de “play” na cor verde).

Caso aparecer uma mensagem de erro por falta de privilégios/acessos no SQL Server, este problema pode ser resolvido se você executar o Visual Studio como Administrador do sistema (se a conexão for Windows Authentication) ou utilizando um usuário com mais privilégios (se a conexão for SQL Authentication).

Se houver algum bloqueio de seu firewall, você receberá um aviso, desta forma será necessário que selecionar uma das opções “Unblock remote debugging…”.

clr_out3_3

Feito todos os procedimentos, será possível acompanhar o debug da função no SQL Server, como observado na figura abaixo (para prosseguir utilize o botão F10 ou F11).

As mensagens e os resultados fornecidos pelo SQL Server podem ser verificadas na janela de Output, “Show output from: Debug”, conforme verificado abaixo.

Obrigado pelos emails e comentários relacionados aos artigos de CLR, principalmente pelas críticas!

A respeito das dúvidas, fiquem a vontade de perguntar, estarei respondendo sempre que eu puder!

Para o próximo artigo, já estou preparando um material para explicar como se “instala” estas funções CLR no SQL Server.

 

Posts relacionados:

Habilitando CLR no SQL Server:
https://sqlfromhell.wordpress.com/2009/09/19/habilitando-clr/

Criando funções CLR para o SQL Server:
https://sqlfromhell.wordpress.com/2009/09/26/funcoes-clr/

Habilitando SQL Authentication e o usuário “sa”:
https://sqlfromhell.wordpress.com/2009/05/24/habilitando-sql-authentication-e-o-usuario-sa/

Criando funções CLR para o SQL Server

Olá pessoas!

Continuando a série de posts sobre a integração CLR, vamos a um exemplo prático de como criar suas próprias funções CLR para o SQL Server. Para esta demonstração, você necessitará do Visual Studio 2005 ou 2008, nas edições Professional ou superior.

 

Criando funções CLR para o SQL Server

Após abrir o Visual Studio, crie seu projeto conforme a figura abaixo:

Nesta demonstração estarei utilizando um projeto Visual C#, mas poderia ser feito com VB, C++ (gerenciado) ou J# (sem opção de debug diretamente no servidor). O template utilizado será o “Visual C#\Database\SQL Server Project”.

Depois de escolher o template informe o nome que o projeto terá, que será o mesmo do Assembly no servidor.

Configure corretamente o banco de dados que você se conectar. Não se esqueça de habilitar a configuração de integração com CLR do servidor com o qual você estará trabalhando (ver. Habilitando CLR no SQL Server).

Caso o banco de dados não existir, você pode criar um novo informando somente o nome do banco de dados. Se você tiver as permissões, ele será criado após confirmar a seguinte mensagem:

Caso aparecer uma mensagem de erro por falta de privilégios/acessos no SQL Server, este problema pode ser resolvido se você execute o Visual Studio como Administrador do sistema (se for Windows Authentication) ou utilizando um usuário com mais privilégios (se for SQL Authentication).

Para permitir visualizar a execução do Assembly em tempo de execução, você pode habilitar a opção de debug, ao aparecer a seguinte mensagem.

Mas evite realizar debug diretamente em um servidor utilizado por outras pessoas alem de você, principalmente se for um servidor de produção, visto a exclusividade que será dada pelo servidor ao seu Assembly quando estiver em debug.

No projeto (janela Soluntion Explorer), será possível identificar três referências padrões do projeto, primeiramente a System, responsável por todas as estruturas fundamentais da .Net Framework, a System.Data, responsável pelo ADO.Net, por fim a System.XML, responsável neste projeto por manipular os objetos na comunicação entre o Assembly CLR e o SQL Server.

Agora, na janela Solution Explorer, você terá toda a estrutura de sua solução, como as classes CLR, referências e scripts para testes. Para criar uma função (user-defined function), clique com o botão direito do mouse sobre o seu projeto e na opção Add, escolha o tipo de “item” que você deseja criar, no caso “User-Defined Function…” ou se preferir “New Item…” para ir à janela de seleção do “item”.

Na janela de criação de um novo item, caso não esteja selecionado, selecione o template que você utilizará (user-defined function) e informe o nome a ser utilizado para sua função.

Criado o nosso primeiro item, teremos a seguinte estrutura de código:

// As bibliotecas padrões
using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
// A classe que será responsável por armazenar as funções desenvolvidas.
public partial class UserDefinedFunctions
{
    // Função modelo.
    [Microsoft.SqlServer.Server.SqlFunction]
    public static SqlString Pitagoras()
    {
        return new SqlString("Hello");
    }
};

Para demonstrar o comportamento das funções CLR no SQL, a partir da função modelo, desenvolvi um método que recebe como argumento duas variáveis SqlDouble (equivalente ao float do SQL Server), dentro do escopo do método transformei estas variáveis em variáveis do tipo double e realizei o calculo de Pitágoras sobre elas, retornando por fim o resultado deste cálculo como uma variável do tipo SqlDouble.

    // Função alterada.
    [Microsoft.SqlServer.Server.SqlFunction]
    public static SqlDouble Pitagoras(SqlDouble ab, SqlDouble bc)
    {
        double AB = ab.Value;
        double BC = bc.Value;
        double AC = Math.Sqrt((AB * AB) + (BC * BC));
        return new SqlDouble(AC);
    }

 

Publicando o assembly no SQL Server

Para realizar a publicação de seu assembly CLR no servidor, clique com o botão direito sobre o projeto, em seguida clique na opção “Properties”.

Na aba “Database”, você terá a connection string utilizada para conectar ao banco de dados, o nível de permissão utilizada e um espaço para definir o usuário do banco de dados responsável pelo assembly (como padrão “dbo”).

Realizado os ajustes clique novamente com o botão direito sobre o projeto e chame a opção “Deploy”.

Agora conecte-se no seu banco de dados e execute o seguinte comando SQL:

SELECT dbo.Pitagoras(3,2) AS Resultado;

Se tudo foi executado corretamente, você terá como resultado:

Se o calculo estiver errado no meu exemplo, é porque devo ter faltado à aula de trigonometria na época do colégio.

Estes foram os passos necessários para desenvolver suas funções no SQL, utilizando CLR. Acredito que o post esteja bem detalhado e exemplificado. Mas qualquer dúvida ou comentário, estejam a vontade em me contatar.

No próximo post, estarei trabalhando como testar estas funções em tempo de execução (debug).

 

Post relacionado:

Habilitando CLR no SQL Server:
https://sqlfromhell.wordpress.com/2009/09/19/habilitando-clr/