Atachando um arquivo de Banco de dados MDF sem o Arquivo de Log no SQL Server

Olá a todos.

Após um pequeno tempo sem escrever no Blog, trago mais um artigo com uma necessidade que tive e então, resolvi compartilhar.
Recentemente necessite anexar um Banco de dados no Servidor SQL Server que trabalho, porém, somente foi entregue para mim o arquivo MDF e sem o arquivo de LOG para que eu pudesse atachá-lo junto.
Para enfatizar este artigo, usarei como exemplo o arquivo MDF sem os LOGs da base de Dados AdventureWorksDW2012, que por sua vez pode ser baixado no seguinte endereço:
– AdventureWorksDW2012: http://msftdbprodsamples.codeplex.com/downloads/get/165405

Normalmente faríamos este processo utilizando as seguintes sequências de telas:

Figura 1 – Selecionando a Opção de Attach no Banco de Dados

Figura 2 – Selecionando o arquivo MDF do Banco de dados que iremos atachar.

Desta forma, ao selecionarmos nosso banco de dados, conforme veremos na Figura 3 abaixo, o mesmo somente terá o arquivo MDF sendo informado, onde, para o Arquivo de Log, aparece uma mensagem ao lado direito da indicação do caminho do arquivo, informando que o mesmo não fora localizado.

Se tivéssemos o arquivo LOG disponível no computador/servidor, bastaria somente informarmos seu local de origem.

Figura 3 – Apresentando o arquivo MDF sem o Log informado.

Para resolvermos este problema, poderemos agir de duas formas, sendo a primeira:

– Removendo via Tela do SSMS a informação do arquivo de Log, selecionando o mesmo na tela que estamos utilizando para atachar o arquivo, conforme a Figura 4 demostra.

Figura 4 – Removendo o arquivo de Log pelo SSMS

– Executando uma query com a Procedure sp_attach_single_file_db, que espera receber dois parâmetros:

• @dbname nvarchar(128): Nome do Banco de Dados
• @physname nvarchar(260): Caminho de origem do arquivo MDF do Banco de Dados

No final, a query será interpretada da seguinte forma:

EXEC sp_attach_single_file_db @dbname=’AdventureWorksDW2012′,@physname=’D:\Software\SQL Server\MSSQL11.SQLBI01\MSSQL\DATA\AdventureWorksDW2012_Data.mdf’

GO

Figura 5 – Executando a query que irá atachar o banco de Dados AdventureWorksDW

Após, o banco de dados será criado e já estará disponível no SSMS, conforme Figura 6 abaixo.

Figura 6 – Banco de Dados criado e disponível no SQL Server

Só como Observação, este bancp de Dados do AdventureWorksDW é um modelo utilizado nos estudos do ambiente de BI da Microsoft, estando também disponível na versão do SQL Server 2008 R2.

Bons estudos.

Como foi o evento CEA: Uninove TechDay Windows 8 SQL 2012

Pessoal, o evento CEA: Uninove TechDay Windows 8 SQL 2012 foi bacana.

Os alunos compareceram em peso na sala de aula. Tivemos sorteios de brindes com perguntas voltadas tanto para BI Microsoft quanto para Windows 8 (aproveitando, utilizei o SQL Server 2012 e suas Features instalado no Windows 8 Pro).
Seguem umas fotos para conferirem.

Desta forma, encerrei 2012 com a certeza de que muitas novidades virão, além de muitos outros eventos.
Agradeço ao meu amigo Idevar Junior pelo convite feito e pelos próximos que surgirão.

Até mais.

Microsoft lança o Service Pack 1 do SQL Server 2012

Recentemente a Microsoft lançou o Service Pack 1 do SQL Server 2012. Esta versão contém correções para problemas que foram relatados através de comentários dos clientes.
Como novidade, destaques para acessos a BI Self-service, através de ferramentas como o Excel 2013, utilizando tecnologias “in-memory”.

Seguem o link para que a versão 64 Bits do Service Pack possa ser baixada:
http://download.microsoft.com/download/3/B/D/3BD9DD65-D3E3-43C3-BB50-0ED850A82AD5/SQLServer2012SP1-FullSlipstream-ENU-x64.iso

Para a versão 32 Bits do SQL Server, podemos baixar acessando o link:
http://download.microsoft.com/download/3/B/D/3BD9DD65-D3E3-43C3-BB50-0ED850A82AD5/SQLServer2012SP1-FullSlipstream-ENU-x86.iso

As atualizações estão disponíveis para todas as versões do SQL Server 2012.

Até a próxima.

CEA: Uninove TechDay Windows 8 SQL 2012

Pessoal, antes tarde do que nunca, mas segue ai o cronograma do Evento no qual participarei com mais uma palestra de SQL Server e Business Intelligence.

Nome do evento: CEA: Uninove TechDay Windows 8  SQL 2012

Link do Evento: https://msevents.microsoft.com/cui/EventDetail.aspx?culture=pt-BR&EventID=1032536574&IO=0kNR6QCrtVJDxtBbfh5uKg%3d%3d

Neste evento, falaremos de Windows 8 e SQL Server 2012, com suas Features de BI.

Até mais.

Instalando o Catálogo SSISDB do SQL Server Integration Services 2012

Para trabalharmos com Projetos do Integration Services, necessitamos conhecer o Catálogo SSISDB, onde na versão do SQL Server 2012, passamos a gerenciar nossos arquivos e projetos do SSIS dentro do SQL Server Management Studio 2012, podendo então administrar, alterar e executar estes mesmos pacotes.

Na nova versão do Integration Services, podemos implantar nossos projetos no servidor do Integration Services, que nos permitirá gerenciar e executar tais pacotes, além de configurarmos a execução em nossos ambientes.

Temos também nesta nova versão, suporte a dois modelos de implantação:

• Modelo de Implantação de Projetos: nos permite implantar nossos projetos no servidor do Integration, no qual o projeto é a unidade de implantação, onde parâmetros são usados para atribuir valores as propriedades do Pacote. Desta forma, um projeto contém pacotes e parâmetros, que por sua vez são implantados no Catálogo do SSISDB na instância que selecionamos no momento da Instalação do Servidor;
• Modelo de Implantação de Pacotes: neste modelo, o pacote é a unidade de implantação, onde as configurações são usadas para atribuir valores para as propriedades do pacote. Além disso, os pacotes e suas configurações são copiados no sistema de arquivos em outro computador, onde os pacotes também serão salvos no banco de dados MSDB ou em uma instância do servidor SQL Server;

Todos os objetos que são armazenados no catálogo SSISDB, incluem tanto os projetos, quanto pacotes e parâmetros. Os objetos, configurações realizadas e os dados que estão no catálogo SSISDB, podem também ser consultados e exibidos no banco de dados SSISDB, onde poderemos chamar Procedures usando a interface de usuário.

Além disso, como em outros bancos de dados, o SSISDB dá suporte a espelhamento e replicação e alta disponibilidade através do AlwaysOn.

As estruturas dos objetos que fazem parte do Catálogo SSISDB, consistem em:

• Pasta (Folder)
  • Uma pasta contém um ou mais projetos e ambientes no Catálogo do SSISDB.
• Projeto (Project)
  • Cada projeto pode conter vários pacotes, sendo que os projetos e pacotes poderão conter parâmetros e referentes a ambientes.
• Ambiente (Enviroment)
  • Os ambientes contêm variáveis, onde seus valores poderão ser usados quando os pacotes são executados ou validados no Integration Services.
• Parâmetros (Parameters)
  • Os parâmetros são usados para atribuir valores a propriedades do pacote em tempo de execução, sendo que para definirmos o valor do pacote ou parâmetro.
• Variáveis de Ambientes
  • Utilizado para especificar a referência entre o projeto e o ambiente de Servidor, onde poderemos usar Procedures para criar ou excluir as referências, além de indicar se o ambiente pode ser localizado na mesma pasta que o projeto ou em pastas diferentes.

CRIANDO O CATÁLOGO NO SQL SERVER

Para criarmos o Catálogo no SQL Server, primeiramente devemos localizar a opção Integration Services Catalogs e após, clicarmos com o Botão direto do mouse. Será aberta uma janela suspensa, no qual teremos que selecionar a opção Create Catalog, conforme mostra a imagem abaixo.

                       Figura 1 – Criando o Catálogo do SSISDB

Em seguida será apresentada uma nova tela, na qual criaremos uma senha que será responsável por criptografar os dados que serão contidos neste Catálogo. A senha protege a chave do banco de dados que é usada para criptografar os dados do catálogo.  Salve a senha em um local seguro. É recomendado fazer o backup da chave. A figura 2 abaixo demostra esta tela configurada.

 Figura 2 – Criando a senha de Criptografia de acesso aos dados do Catálogo SSISDB

Por padrão, a integração com o CLR já está habilitada. Esta integração permite trabalharmos com Procedures utilizando a Integração do CLR (código gerenciado, utilizado na integração com as linguagens do .NET).

Após informar a Senha, clique em Ok.

Desta forma, será criado o catálogo SSISDB e também, o banco de dados SSISDB, conforme apresentado na figura 3 abaixo.

Figura 3 – Catálogo e Banco de Dados SSISDB criado

Bom, ainda dentro do Catálogo do SSISDB, poderemos criar Pastas para organizar nossos projetos, conforme comentado acima. Da mesma forma como criamos o Catálogo, ao clicarmos com o botão direito do Mouse, poderemos selecionar a opção Create Folder, onde em seguida será aberta uma tela, conforme apresentada na figura abaixo, onde poderemos incluir o nome da Pasta que estamos criando, assim como sua descrição.

Figura 4 – Criando uma Pasta no Catálogo do SSISDB

Dentro deste diretório, serão criadas duas novas estruturas de pastas: Projects e Enviroment.

Obs.: Só lembrando, as descrições de Projects e Enviroment estão descritas acima.

Enfim, em outro artigo eu irei criar um Projeto de Integration Services no Visual Studio, que terá um Processo de ETL funcionando e que após, irá fazer um Deploy para dentro do Catálogo SSISDB com seus respectivos Itens sendo preenchidos.

Bons estudos e até a próxima.

Diferenças entre SEQUENCES x IDENTITY no Microsoft SQL Server 2012

Bom, a pedido dos colegas que viram o Artigo Utilizando Sequences no Microsoft SQL Server 2012, resolvi criar um novo artigo que faz uma comparação entre o uso de SEQUENCE x IDENTITY no Microsoft SQL Server 2012.

Uma das diferenças entre SEQUENCE e IDENTITY está no fato de que as SEQUENCES são acionadas sempre quando forem necessárias, sem dependência de tabelas e campos no banco, onde pode ser chamada diretamente por aplicativos.

Outra diferença está que nas SEQUENCES, nós podemos obter o novo valor antes de usá-lo em um comando, diferente do IDENTITY, onde não podemos obter um novo valor. Além disso, com o IDENTITY não podemos gerar novos valores em uma instrução UPDATE, enquanto que com SEQUENCE, já podemos.

Com SEQUENCES, podemos definir valores máximos e mínimos, além de termos a possibilidade de informar que a mesma irá trabalhar de forma cíclica e com cache, além de podemos obter mais valores em sequencia de um só vez, utilizando para isso a procedure SP_SEQUENCE_GET_RANGE, onde então é permitido atribuirmos os valores individuais para aumentar então o desempenho no uso da SEQUENCE.

Uma das grandes utilidades em IDENTITY que vejo ser muito valiosa está no fato de podermos trabalhar com o mesmo na utilização de TRANSAÇÕES de INSERT, pois, só iremos gerar um próximo valor a partir do momento que o comando for executado, ou seja, que a transação for aceita, ao contrário de uma SEQUENCE, que uma vez chamado seu próximo valor, mesmo que ocorra um erro de transação, o valor é alterado.

Abaixo, tenho um exemplo d0 Script feito e a Imagem 1 apresentando este Script que possa nos dar uma ideia do que estou falando. Este Script irá criar duas tabelas com a mesma estrutura, sendo que o que as diferenciará será, claro que o nome, e seus campos de chave primária.

CREATE DATABASE Artigos

GO

USE Artigos

GO

CREATE TABLE TBL_UsoIDENTITY

(

ID_Uso INT IDENTITY(1,1),

DSC_Desc NVARCHAR(30) NOT NULL,

CONSTRAINT ID_Uso_IDENTITY_PK PRIMARY KEY (ID_Uso)

)

GO

CREATE TABLE TBL_UsoSEQUENCE

(

ID_Uso INT,

DSC_Desc NVARCHAR(30) NOT NULL,

CONSTRAINT ID_Uso_SEQUENCE_PK PRIMARY KEY (ID_Uso)

)

GO

Imagem 1 – Script que criará as tabelas de exemplo

Na Imagem 1 acima, percebem que na linha 9, do campo ID_Uso da tabela TBL_UsoIDENTITY, criamos o campo descrevendo que o mesmo será do tipo Inteiro e em seguida, terá o IDENTITY. Esta é a forma que já conhecíamos nas versões anteriores do SQL Server.

Contudo, a partir da linha 15 do Script na Imagem 1, verificamos a criação da tabela TBL_UsoSEQUENCE, que traz o mesmo campo ID_Uso, seguido do seu tipo, porém, sem nenhuma declaração mais.

Percebam também que ambos os campos são PRIMARY KEY, cada uma com seu respectivo nome.

Bom, conforme eu tinha falado no artigo Utilizando SEQUENCES no SQL Server 2012, os objetos SEQUENCES não estão vinculados a tabela. Este vinculo irá ocorrer, por exemplo, se utilizando de PROCEDURES.

Vamos ver a diferença na prática. Para isso, irei criar mais ScriptS para dar um exemplo do que estou falando.

Vou criar a SEQUENCE dbo.SEQ_Artigo, com o Script abaixo:

USE [Artigos]

GO

CREATE SEQUENCE dbo.SEQ_Artigo

START WITH 1

INCREMENT BY 1

NO CACHE

NO CYCLE

GO

Imagem 2 – Script gerado para criar uma SEQUENCE

Com a SEQUENCE criada, irei agora fazer um novo Script para criar duas PROCEDURES, cada uma para trabalhar com as tabelas criadas anteriormente. Inclusive, segue o Script para criação da primeira Procedure.

USE [Artigos]

GO

CREATE PROCEDURE [dbo].[PRC_USANDO_IDENTITY]

@DSC_Desc NVARCHAR(30)

AS

DECLARE @ValorDIVIDE NUMERIC(3);

BEGIN TRANSACTION

BEGIN TRY

INSERT INTO dbo.TBL_UsoIDENTITY

VALUES

(

@DSC_Desc

);

SET @ValorDIVIDE = 10 / 0;

COMMIT TRAN

END TRY

BEGIN CATCH

ROLLBACK TRANSACTION

SELECT

ERROR_NUMBER() AS ErrorNumber

,ERROR_MESSAGE() AS ErrorMessage;

END CATCH

Imagem 3 – Criando a Procedure vinculada a Tabela TBL_UsoIDENTITY

Vamos agora explicar o que está ocorrendo dentro desta PROCEDURE:

Se vocês olharem bem, eu tenho a declaração de uma BEGIN TRANSACTION, sendo que possuo dentro desta transação um comando de INSERT na tabela TBL_UsoIDENTITY. Não estou passando nenhuma valor para o campo ID_Uso, pois, pelo fato dele ser IDENTITY, automaticamente irá gerar/incluir os campos . Antes porém, além da declaração do parâmetro de entrada, tenho também a declaração de uma variável chamada @ValorDIVIDE do tipo NUMERIC. Após realizar o INSERT, tenho esta mesma variável setada com uma operação de DIVISÃO, que conforme verão, será feita pelo número 10 / 0. Contudo, sabemos que não existe divisão por zero, ocasionando um erro dentro da PROCEDURE e um ROLLBACK da transação.

Resumindo: Este comando de INSERT não será efetivado dentro da Tabela.

Agora, vou criar uma Procedure que irá ser vinculada a Tabela TBL_UsoSEQUENCE e que irá tentar INSERIR informações dentro desta tabela. Para isso, segue mais um Script:

USE [Artigos]

GO

CREATE PROCEDURE [dbo].[PRC_USANDO_SEQUENCE]

@DSC_Desc NVARCHAR(30)

AS

DECLARE @ValorDIVIDE NUMERIC(3);

BEGIN TRANSACTION

BEGIN TRY

INSERT INTO dbo.TBL_UsoSEQUENCE (ID_Uso, DSC_Desc)

VALUES

(

NEXT VALUE FOR dbo.SEQ_ARTIGO,

@DSC_Desc

);

SET @ValorDIVIDE = 10 / 0;

COMMIT TRANSACTION

END TRY

BEGIN CATCH

ROLLBACK TRANSACTION

SELECT

ERROR_NUMBER() AS ErrorNumber

,ERROR_MESSAGE() AS ErrorMessage;

END CATCH

GO

Imagem 4 – Criando a Procedure vinculada a Tabela TBL_UsoSEQUENCE

Da mesma forma, vamos explicar esta PROCEDURE:

Se vocês analisarem o Script na Imagem 4, verão que eu estou utilizando uma variável chamada @ValorSEQUENCE e atribuindo a ela o resultado do comando NEXT VALUE FOR dbo.SEQ_ARTIGO (que é a SEQUENCE criada anteriormente), indicando assim para PROCEDURE buscar o próximo valor de sequencia da SEQUENCE. Este valor, será inserido dentro do campo ID_Uso, que pelo fato de não ser mais IDENTITY, necessita ser descrito no comando, e da mesma forma, incluo a variável @ValorDIVIDE e tento fazer uma divisão por ZERO e como não existe divisão por zero, apresenta um erro e a transação sofre um ROLLBACK.

Contudo, o valor da SEQUENCE foi alterado, não sendo mais o valor 1 iniciado no momento que a criamos.

Mas, vamos ver isso na prática. Execute os Scripts abaixo:

EXEC [dbo].[PRC_USANDO_IDENTITY] ‘Teste de IDENTITY’

GO

EXEC [dbo].[PRC_USANDO_SEQUENCE] ‘Teste de SEQUENCE’

GO

Percebam o erro da informação de Divisão por zero sendo retornado, pois, tratamos esse erro com um TRY CATCH.

Imagem 5 – Executando as Procedures

O Conteúdo de ambas as tabelas não foi aferido, pelo fato de ser executado um ROLLBACK. Porém, a SEQUENCE utilizada pela PROCEDURE PRC_USANDO_SEQUENCE não estará mais com o seu valor inicial igual a 1.

Para confirmar isso, execute o Script abaixo a veja o resultado semelhante ao da Imagem 6:

SELECT NAME, CURRENT_VALUE FROM SYS.SEQUENCES

GO

SELECT IDENT_CURRENT(‘dbo.TBL_UsoIDENTITY’)

GO

Imagem 6 – Verificando o valor atual da SEQUENCE e IDENTITY utilizados no exemplo

Com isso, percebemos que para vermos o valor de uma SEQUENCE devemos executar um SELECT na VIEW chamada SYS.SEQUENCES, sendo que temos um objeto totalmente apartado de uma Tabela. No caso do IDENTITY, para verificarmos seu valor, executamos um outro SELECT, porém, utilizando a função IDENTITY_CURRENT e passando a tabela que desejamos consultar o último IDENTITY.

Entrentanto, se executarmos o Script abaixo, verificaremos que a possibilidade de inserir valores para a SEQUENCE mesmo fora de uma PROCEDURE, conforme é mostrado na Imagem 7, abaixo:

SELECT NEXT VALUE FOR dbo.SEQ_ARTIGO;

GO

Imagem 7 – Atribuindo um valor para a SEQUENCE fora de uma PROCEDURE

Enfim, em alguns casos é interessante se utilizar IDENTITY e em outros, SEQUENCE. O ideal é analisarmos nossa estrutura de tabelas e informações para vermos se realmente queremos armazenar as informações com Autonumeração gerada pelo IDENTITY ou pelo controle de Numeração de uma SEQUENCE.

Bons estudos.

Usando C# no Microsoft Integration Services

Com o lançamento do Microsoft SQL Server 2005, passamos a conhecer uma nova ferramenta, que veio com o propósito de incluir a Microsoft como um dos grandes players do Mercado, no que diz respeito ao universo de BI (Business Inteligence). Desta forma, passamos a falar do Microsoft SQL Server Integration Services (também conhecido como SSIS).

Desde 2005 para cá, particularmente eu posso falar que a Ferramenta amadureceu o suficiente para se destacar frente a outras demais ferramentas de ETL (Extract, Transform and Load – Extrair, Transformar e Carregar).

Este processo diz respeito a unificar informações de Bases de Dados transacionais, que são informações que estão em nossas bases de dados e que são gravados pelos Sistemas desenvolvidos em .NET, Java, Delphi e etc., e enviá-las para uma base de dados histórica, sendo esta conhecida como Data Warehouse (DW). Esta base é modelada de uma forma diferente da qual conhecemos, sendo que as Bases de Dados Transacionais pregam a ideia de Normalização dos Dados e a base de Dados do Data Warehouse (DW), trabalha com a ideia de “desnormalização” destes dados.

Em siglas, esta diferença pode ser considerada ao falarmos dos ambientes OLTP (Online Transaction Processing) e OLAP (Online Analytical Processing).

Mas o intuito deste artigo não é falar especificamente sobre a Arquitetura que envolve um processo de BI (onde a Microsoft possui uma suíte completa de ferramentas) e sim, apresentar como o Microsoft SSIS (SQL Server Integration Services) se encaixa dentro desta arquitetura.

Estou utilizando a Versão do Microsoft SQL Server 2012, que quando instalado cria um Shell do Microsoft Visual Studio na versão 2010, que possibilitará trabalharmos com projetos do Integration Services.

Aqui no micro que estou preparando este artigo, possuo a versão do Microsoft Visual Studio 2010 completo.

Figura 1 –Template de Projetos do Integration Services no Shell do Visual Studio 2010

Porém, mesmo utilizando o Visual Studio e tendo o Microsoft SQL Server (versões 2005, 2008/2008 R2 e 2012) instalados no micro de Desenvolvimento, muitos dos colegas que trabalham com estas plataformas não utilizam as ferramentas instaladas. Mesmo os colegas que estão iniciando no universo de BI com a plataforma da Microsoft, se perguntam como fazer atividades como: Utilizar IF, ELSE no Integration Services.

Figura 2 – Um Projeto do Integration Services aberto no Visual Studio 2010.

Bom, vamos iniciar nosso exemplo deste artigo.

Antes de mais nada, aos colegas que não conhecem o SSIS, prepararei logo mais um artigo específico para apresentar outros detalhes da Ferramenta.

Com o Visual Studio aberto, iniciaremos nosso estudo criando um projeto do Integration Services, dando para o mesmo o nome de: Usando DOT_NET_SSIS.

No SQL Server 2012, temos o Banco de Dados AdventureWorks e a tabela Product, que será utilizada para nosso artigo.

Na tela principal temos Abas, onde cada uma delas possui uma Funcionalidade Específica, de acordo com cada Aba selecionada. A Figura 3 apresenta com detalhe a Aba inicial Control Flow com seus respectivos Itens da ToolBox.

Figura 3 – Aba Control Flow do Visual Studio com seus respectivos Itens da ToolBox.

Bom, a ideia do artigo é apresentar a utilização do Item Execute SQL Task para selecionarmos alguns produtos da Tabela Product do Banco AdventureWorks, no qual trabalharemos com produtos que possuam a Lista de Preços de valores entre 50 e 100 (Dólares, Reais ou qualquer outra, como quiserem).

Porém, para pegarmos estes registros da Tabela de Produtos, temos primeiro que nos conectar no Banco e após, fazermos este Select.

O Item Execute SQL Task ao ser anexado nos fornece a opção de conectarmos ao Banco de dados do SQL Server, conforme apresentado na Figura 6.

Figura 4 – Adicionando o Execute SQL Task para executar o Script no Banco de Dados.

Para nosso exemplo, criei uma conexão no qual posso utilizar em todo o Projeto, ou seja, uma conexão Global. A Figura 7 abaixo demostra o lugar onde a mesma fora criada.

Figura 5 – Criando uma conexão Global para o projeto

Em sequência, criei o seguinte Script abaixo para realizar tal tarefa, onde este Script retorna todos os registros dentro da Tabela, conforme a Figura 8 apresenta.

SELECT * FROM Production.Product

Figura 6 – Retorno da Execução da Query apresentada no Script, dentro do SQL Server 2012.

A consulta retorna 504 registros onde a ideia do artigo será exportarmos Produtos com os valores menores que 100 para um arquivo TXT específico e os Produtos de valores maiores para um segundo arquivo TXT.

Para a consulta que retorna Produtos com valores de Lista de preço menores que 100, gravaremos no arquivo ProdutoMenor100.txt, onde os Produtos com Lista de preço maior que 100, serão gravados no arquivo ProdutoMaior100.txt (por conveniência particular, vou gravar ambos os arquivos no Disco C:\).

Bom, vamos voltando ao nosso exemplo.

No Visual Studio, após incluirmos o Item Execute SQL Task, incluiremos também mais um Item: O Script Task. Este item nos possibilita trabalharmos com Código .NET (seja C# ou VB .NET), para podermos incluir em nossa rotina, algum fluxo desenvolvido por uma destas linguagens. Imaginem vocês que para validarmos algum processo de nossa regra de negócio, necessitaríamos, por exemplo, consumir uma DLL desenvolvida em .NET ou um Método em Webservice ou WCF. Com este item, poderemos adicionar tal funcionalidade.

Com isso, arraste o Item Script Task, que nesta versão do Integration Services dentro do Shell do Visual Studio, está localizado na seguinte posição:

Figura 7 – Localizando o Script Task dentro da SSIS Toolbox

Após, de o nome para o mesmo de: ST_IF_Else, onde em seguida, clique com o Botão direto do Mouse sobre ele e selecione a Opção EDIT. Será aberta uma Tela, semelhante a da Figura 10, abaixo.

Figura 8 – Editando o componente Script Task

Conforme estão vendo na Figura 10 acima, temos a opção de selecionarmos qual linguagem estaremos trabalhando. Neste exemplo, estou utilizando a Linguagem C#, porém, poderíamos configurar a Linguagem VB .Net sem problemas, alterando nas Propriedades do Item qual Linguagem utilizaremos, conforme é apresentado na Fiura 12, abaixo.

Figura 9 – Configurando qual Linguagem utilizar como Script

A opção EntryPoint, descreve qual o método de Entrada que estaremos utilizando no Script. Podemos deixar em branco, ou então, descrever qual método iremos utilizar. Por padrão, eu deixei o método Main.

Após, temos duas opções que serviram tanto descrever quais as variáveis serão utilizadas para somente leitura e quais as variáveis serão utilizadas para somente escrita.

Bom, como estamos trabalhando com um Bloco de script que, deveremos interagir entre o SSIS e a tal linguagem de alguma forma. Para isso, poderemos utilizar variáveis para tanto levar um conteúdo para as rotinas do .NET, quanto trazer este retorno de processamento. Desta forma, poderemos interagir sem problemas com fluxos externos deste ambiente. Desta forma, clique com o botão direito do mouse sobre a área de desenvolvimento do Visual Studio e selecione a opção Variables.

Figura 10 – Selecionando as opções Variables na Tela do Visual Studio

Após, percebam que o Visual Studio abrirá uma tela, onde poderemos inserir a quantidade de variáveis que desejarmos em nosso processo. No nosso exemplo, criaremos 3 (três) variáveis, onde ainda poderemos escolher qual o Data Type estaremos utilizando e seu Valor inicial (poderemos ainda aplicar expressões para estas variáveis, mas não é o caso). Percebam também que a variável criadas trabalha sobre o escopo da Package, pois como não alterei o nome do meu Pacote do Integration Services, acabou sendo adotado o nome principal do arquivo da Package.dtsx, visível na Aba Solution Explorer do Visual Studio. Perceba também que o Data Type da Variável é do tipo Object (mais para frente o mesmo será convertido para DataSet e será utilizado no Script).

Figura 11 – Criando as variáveis que serão utilizadas no Script Task

Após criarmos a variáveL, teremos que selecioná-la nas Opções: ReadOnlyVariables. Neste caso não utilizaremos a opção ReadWriteVariables, pois realmente só iremos ler a variável       que será encaminhada do retorno do Item o Execute T-SQL Statement. Para isso, deveremos seleciona-las na opção do Editor do Script Task, conforme apresentado nas Figuras 14 e 15.

Figura 12 – Selecionando as variáveis que serão utilizadas no Script Task

Bom, não vou detalhar o que o Script em si está fazendo, porém, não posso deixar de explicar sua funcionalidade. Para os colegas que estão acostumados com o ambiente .NET na linguagem C# e/ou VB .NET, não sentirão dificuldades, pois, utilizaremos tais linguagens para codificar algum fluxo, onde poderia ser uma regra de negócio, ou uma chamada a uma DLL que tenha métodos de negócio encapsulados.

Perceba na Figura 15 a Aba de Código do Visual Studio aberta e com a descrição do Método Main, que receberá a variável ResultSet (fique a vontade para mudar este nome).

Figura 13 – Método Main do Script C#

Este método irá pegar a variável ResultSet (Figura 13) e a converte para um DataTable. Logo após, iremos varrer este DataTable em um FOR LOOP e para cada linha, verificaremos os campos ProductID, Name e ListPrice. Se o campo ListPrice for maior que 50 e menor que 75, chamaremos o método GeraArquivo_Preco50_75, que simplesmente irá criar um arquivo chamado Arq50_75.txt no Diretório C:\, se utilizando do Namespace System.IO.StreamWriter, inserindo via WriteLine os campos ProductID, ListaPreco, NomeProduto (traduzi o nome dos campos), concatenados por ponto e vírgula (“;”).

Figura 14 – Método que Gera o arquivo com os dados do Produto, Nome do Produto e Preço entre 50 e 75.

Da mesma forma, caso o campo ListPrice for maior que 75 e menor que 100, chamaremos o Método GeraArquivoPreco75_100, que da mesma forma receberá os campos ProductID, Name e ListPrice e gerará um arquivo chamado Arq75_100.txt no C:\.

Figura 15 – Método que Gera o arquivo com os dados do Produto, Nome do Produto e Preço entre 75 e 100.

Na Figura 18 abaixo, veremos os dois arquivos (na mesma janela), com seus respectivos registros, sendo que para o arquivo com Preços entre 50 e 75 é maior do que o arquivo de Preços entre 50 e 75.

Figura 16 – Mostrando os arquivos e seus respetivos conteúdos

Bom, vale lembrar que você poderá mudar o caminho do arquivo, ou até mesmo o nome do próprio arquivo, ou até quem sabe, programar outro Código em C# ou .NET, pois a intensão do artigo foi somente indicar a possibilidade de integrar o SSIS com as linguagens C# e VB .NET, utilizando para isso o Visual Studio 2010.

Bom estudo.

Utilizando FILETABLE no SQL Server 2012

Dando continuidade nas novidades que o SQL Server 2012 nos traz, vemos uma nova feature chamada: FileTable.

Mas o que isso significa?

Uma nova feature construída sobre a tecnologia do FILESTREAM, permitindo que dados BLOB sejam armazenados como arquivos individuais, porém, separados dos arquivos de um banco de dados, onde podemos usa-los como uma tabela de banco de dados com quase todas as funções de uma tabela “convencional”.

Para ser mais objetivo, podemos armazenar arquivos e documentos em tabelas do SQL Server, além acessá-las de aplicações do Windows sendo que elas estão armazenadas no Sistema de arquivos, sem que para isso seja necessária alteração nos aplicativos.

Mas você deve estar se perguntando: “Qual o benefício de se usar isto?”.

Seguem alguns:

Armazenamento dos atributos do arquivo gerado, como a Data de criação, modificação e último acesso;

1. Suporte para o gerenciamento de arquivos e de diretórios do Windows;
2. Facilidade de mover esses arquivos de dados para servidores de arquivos, mantendo a compatibilidade das aplicações que trabalham com esses dados como arquivos no sistema de arquivos;
3. Compatibilidade com outros recursos do SQL Server

No entanto, para configurar o FileTable na Instância do SQL Server, existem algumas etapas envolvidas no processo, como por exemplo a configuração do FileStream.

Para configurá-lo, e darmos andamento no processo, vamos seguir esta “receita de bolo”. Segue:

• Abra o SQL Server Configuration Manager, conforme apresentado na imagem 1.

                       

Imagem 1 – Selecione o SQL Server Configuration Manager

• Navegue até o SQL Server Services, no painel esquerdo da janela aberta, conforme apresentado na imagem 2.

Imagem 2 – Selecionando o Serviço do SQL Server

• No painel a direita, clique na instância do banco de dados sobre o qual você deve ativar o suporte do FILESTREAM e selecione a opção propriedades, conforme vemos na Imagem 3 abaixo.

Imagem 3 – Selecionando a opção Propriedades do Serviço da Instancia do Banco de Dados

• Será aberta as propriedades do SQL Server, que conterá as Abas onde poderemos configurar a opção FILESTREAM, habilitando o serviço.

Imagem 4 – Opção FileStream disponível para ser Habilitada.

Com isso, habilite a Opção do FileStream, apresentado na imagem acima, para darmos andamento na utilização do FileTable.

Observação: Você pode também alterar o nome do compartilhamento do Windows. Contudo, vou deixa-lo no padrão, ou seja, o nome do exemplo.

Agora, um fato interessante que você pode notar e que o servidor disponibiliza um compartilhamento do Windows usando o nome da Instância do Banco de dados instalado no seu Micro. Para ver este compartilhamento, abra o Explorer do seu Sistema Operacional e digite o seguinte endereço: \\127.0.0.1 e veja a o resultado, conforme imagem 5 abaixo.

Imagem 5 – Verificando o compartilhamento do Windows ao habilitar o FileStream

Nota: Se você habilitou o acesso remoto na opção Enable FILESTREAM for file I/O streaming access, poderá acessar este compartilhamento, mas ele estará vazio neste momento.

Habilitando o SQL Server para usar o FileStream

Vamos novamente seguir um passo-a-passo:

1. Abra o SQL Server Management Studio e cancele a tela de Login que será aberta.
2. Clique no botão New Query e se conecte na instância do SQL Server, a qual foi configurada nos passos anteriores.
3. Execute uma consulta com o seguinte Script:

exec sp_configure filestream_access_level, 2;

reconfigure;

Imagem 6 – Tela do Management Studio com o Script inserido

Bom, com o FileStream configurado na Instância, podemos começar a configurar o nosso exemplo de armazenamento de banco de dados de FileStream.

Para isso, na mesma tela aberta no SQL Server, abra uma New Query e execute o Script abaixo:

CREATE DATABASE FileTableSample

GO

Imagem 7 – Executando o Script de criação da base de dados

Nessa mesma janela, execute o script abaixo:

ALTER DATABASE FileTableSample

ADD FILEGROUP FileStreamG1 CONTAINS FILESTREAM;

 

Imagem 8 – Executando o Script de Alteração do Database e adicionando um grupo de arquivos FileStream para o banco de dados

 Nessa mesma janela, execute o próximo script abaixo para dar andamento no processo:

ALTER DATABASE FileTableSample

ADD FILE (

NAME = FileStream01,

FILENAME = ‘C:\Temp\FileStreamGroup1’

)

TO FILEGROUP FileStreamG1;

 

Imagem 9 – Executando o script que cria o arquivo FileTable em um respectivo diretório e definindo o armazenamento associado com o grupo de arquivos FileStream adicionado anteriormente

Nesta última etapa será necessária um comentário: Percebam que o caminho de armazenamento do FileStream é identificado conforme o nome do arquivo de configuração, sendo o mesmo um caminho válido no Sistema Operacional, ou seja, o Diretório C:\Temp deve existir e estar disponível para uso. Entretanto, a pasta FileStreamGroup1 não será preciso ser criada, pois o próprio SQL Server se encarregará de cria-la no momento da execução do Script.

Bom, com o banco de dados ajustado, precisamos configurar a forma como o banco vai apresentar e controle as iterações com os dados do FileStream.

Para isso, vamos seguir os passos abaixo:

1. Necessitamos agora definir o nome da subpasta compartilhada através do qual o FileStream irá associar o banco de dados. Para isso, necessitamos executar o script abaixo:

ALTER DATABASE FileTableSample

SET FILESTREAM ( DIRECTORY_NAME = ‘FileTableSample’ );

Imagem 10 – Definindo o nome da subpasta compartilhada

1. O próximo passo será habilitar o acesso de leitura e escrita de dados no FileStream, de acordo com o script e imagem abaixo:

ALTER DATABASE FileTableSample

SET FILESTREAM ( non_transacted_access = full );

Imagem 11 – Liberando acesso a leitura e escrito de dados no FileStream

Para terminarmos, vamos criar uma tabela neste banco de dados criado. Para tanto, segue mais um Script:

use FileTableSample

GO

CREATE TABLE TBL_FileTable AS FILETABLE

GO

Enfim, conforme verão na imagem abaixo, temos agora a tabela criada e disponível para acesso.

 Imagem 12 – Tabela FileTable criada com sucesso

Abaixo, temos em outra imagem como ficou a estrutura de arquivos dentro do Diretório que utilizamos para armazenar arquivos com o FIleStrem.

 Figura 13 – Apresentando a estrutura de arquivos criados

Bom, com isso terminamos nosso exemplo.

Vemos que com um FileTable, possuímos definido no banco de dados uma tabela, sendo que a configuração da estrutura permitirá acesso não-transacional para esta estrutura de pastas, onde poderemos arrastar e soltar arquivos dentro da pasta e até mesmo criar subpastas, sendo que tudo isso se reflete na table MyFileTable, isso quando interagímos usando Transact SQL.

Da mesma forma, quando utilizamos Transact SQL para realizar o “CRUD”, essas alterações serão refletidas na pasta associada no compartilhamento do Windows.

Bons estudos,

Cristiano Joaquim

Usando Sequence no SQL Server

Utilizando SEQUENCES no Microsoft SQL Server 2012

No último artigo, vimos que a Microsoft lançou o CTP1 da próxima versão do Microsoft SQL Server, no qual tínhamos o Codinome “Denali”.

De lá para cá, chegamos à versão Release Candidate (0) do produto, denominado como: Microsoft SQL Server 2012.

Este artigo tem o fundamento de apresentar uma das várias novidades que a próxima versão do SQL Server nos traz, como por exemplo, o uso de SEQUENCES.

As SEQUENCES são objetos usado para gerar valores de auto numeração, onde podemos definir os valores iniciais e seus incrementos.

São como qualquer outro objeto definido no schema e vinculado a um usuário, além de ter as opções do comando CREATE, ALTER e DROP SEQUENCE para gerenciamento. Além disso, podemos consulta a VIEW sys.sequences para exibição do catálogo, afim de sabermos mais sobre os objetos Sequence no banco de dados.

A diferença em relação ao conhecido IDENTITY (velho conhecido no SQL Server) se dá pelo fato de que uma SEQUENCE poder ser acionada sempre que necessária independente de tabelas e campos do banco. Entretanto, em relação à funcionalidade, a SEQUENCE mantém semelhanças com o IDENTITY.

Por padrão, uma SEQUENCE possui seu DataType definido como bitint, porém, também poderemos trabalhar com DataTypes como:

– tinyint;

– smallint

– int

– decimal

– numeric

A imagem abaixo mostra onde poderemos visualizar as SEQUENCES já criadas para nosso Banco de dados e respectivamente, criar uma nova SEQUENCE, conforme mostra a Imagem 1 e 2.

Imagem 1 – Local onde encontramos os objetos SEQUENCES

Imagem 2 – Tela de criação de uma SEQUENCE

Assim como uma Procedure, Trigger e Function, podemos também criar SEQUENCES através de linha de código do Management Studio, como apresentado na figura abaixo:

Imagem 3 – Criando uma SEQUENCE via linha de Código do Management Studio.

Na imagem acima, o comando descreve a inclusão de alguns parâmetros para a criação de uma SEQUENCE, como por exemplo:

– MINVALUE e MAXVALUE: delimitam o limite da SEQUENCE com seu respectivo valor máximo e mínimo. Caso o valor não seja inserido, será atribuído o valor do DataType escolhido.

– INCREMENT: define em quantos números serão incrementadas as sequencias. No exemplo da imagem acima, será realizado o incremento de 1 em 1.

– CYCLE: A propriedade do objeto CYCLE permite começar novamente um ciclo a partir do momento que a propriedade MINVALUE e MAXVALUE for atingida.

– CACHE: pelo fato de desempenho, o SQL Server pré-aloca os números sequencias pela propriedade CACHE, sendo que o valor padrão para esta é 15, significando que valores de 1 a 15 serão disponibilizados na memória a partir do último valor armazenado em cache.

Na Imagem abaixo, criei um Script bem simples que envolve a utilização de Sequence no SQL Server 2012 R0.

Imagem 4 – Criando os objetos que poderão ser utilizados no exemplo.

Se perceberem, não inclui os comandos MINVALUE, MAXVALUE e CYCLE na criação da SEQUENCE, visto que não quero utilizá-los no momento.

Na linha 28, temos o comando que fará o incremento da SEQUENCE dentro da Tabela.

Ao executarmos a Procedure do exemplo e a mesma incluir o registro, podemos confirmar o processamento através de um SELECT na tabela, conforme exemplo da imagem abaixo:

Imagem 5 – Executando a Procedure e verificando os valores inseridos na Tabela

Conclusão:

Neste artigo demos uma introdução sobre o que é o objeto SEQUENCE, além de como criamos e trabalharmos com ele dentro do banco de dados.

Além deste exemplo, poderíamos incluir ai um comparativo entre SEQUENCE x IDENTITY e controle Transacional com SEQUENCE. Porém, estes serão um assunto para o próximo Artigo.

Bons estudos.

Novidades no SQL Server Codinome Denali

Em Novembro de 2010 a Microsoft  lançou o CTP1 (Community Technical  Preview) da próxima versão do SQL Server com o  Codinome “Denali”.

Como sempre, junto de mais uma  versão sempre temos melhorias, assim como no exemplo da Versão do SQL Server  2000 para 2005, da versão 2005 para 2008 e desta para a última versão, SQL  Server 2008 R2.

Na versão 2005 do SQL Server 2005, muitas novidades apareceram como melhorias nas Ferramentas SQL Server Analisys Services (SSAS), SQL Server Reporting Services (SSRS) e o lançamento do SQL Server Integration Services, que substitui o velho DTS (Data Transformation Services) e de lá para cá, muitas outras melhorias ocorreram, o que não poderia ser diferente neste CTP1 disponibilizado pela Microsoft.

O SQL Server Codinome “Denali” CTP1 também trás melhorias, sendo as quais irei apresentar agora.

Tela Principal do SQL
Server Code-Named “Denali”

A versão do SQL
Server Codinome “Denali” está disponível para Downloads no seguinte Link: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=6a04f16f-f6be-4f92-9c92-f7e5677d91f9&displaylang=en
(acessado em 08/03/2011).

Abaixo, veremos o que foi aprimorado nesta versão CTP.

Novidades na Instalação do SQL Server

SQL Server Multi-Subnet Clustering: Novidade nesta versão, agora será possível configurar um Cluster de Failover do SQL Server usando nós agrupados em sub-redes
diferentes.

A ilustração abaixo representa um local com 2 Nós e outro com 2 sub-cluster
do SQL Server

O Multi-subnet Failover Cluster é um aperfeiçoamento de uma tecnologia já existente no SQL Server 2008 e Windows Server 2008 para dispersão geográfica de clusters Failover, permitindo “esticar” um cluster em múltiplos data centers para fornecer um nível maior de disponibilidade e proteção de dados.

No SQL Server “Denali”, esta configuração permite usar um cluster Failover em várias sub-redes, sendo disponível tanto para geo-clusters quanto para clusters locais, eliminando a exigência de uma VLAN e permitindo que o cluster fique online enquanto é capaz de se ligar a qualquer endereço.

Contudo, este será estudo a ser apresentado em um próximo artigo.

Como pré-requisitos de instalação do Setup do SQL Server: Power Shell 2.0, .NET
Framework 3.5 SP1 são requeridos até o momento para esta versão do SQL Server,
sendo necessário seu Download e instalação . Todos os outros pré-requisitos exigidos serão instalados pelo Setup do SQL Server depois que for selecionado os recursos e configurações na etapa inicial de Instalação. O pacote do .NET Framework 4.0 não é um pré-requisito para a instalação do SQL Server “Denali”, porém, está incluído no Windows 7 SP1 e Windows Server 2008 R2 SP1.

Database Engine

Esta versão do SQL Server Database Engine introduz novos recursos e aprimoramentos que aumentam o poder e produtividade dos arquitetos, desenvolvedores e DBAs para projetarem, desenvolverem e manterem seus Bancos de dados. Abaixo, as áreas em que o Database engine foi aprimorado:

– Melhorias de disponibilidade: Inclusão do HADR, como solução para melhorar a disponibilidade das bases de dados em ambiente corporativo. O HADR é uma solução de alta disponibilidade para recuperação de desastres, a fim de maximizar a disponibilidade de um ou mais bancos de dados. Ao ser implantado, o HADR poderá configurar um ou mais grupos de disponibilidade, onde cada grupo pode estabelecer um contexto em um conjunto de base de dados selecionados, envolvendo réplicas de disponibilidade, sendo que cada réplica possui uma cópia local de cada uma das bases de dados. Nessas
réplicas, chamadas de “réplicas primárias”, ficam mantidas uma cópia de cada banco de dados. Esta réplica faz os bancos de dados primários, disponibilizarem acessos de leitura e gravação para os usuários. Para cada banco de dados primário, outra réplica secundária é criada, mantendo uma cópia de Failover do banco de Dados sendo chamada de banco de dados secundário. No momento, este CTP do SQL Server Codinome “Denali” suporte apenas uma réplica assíncrona de bases secundárias.

·    Melhorias no gerenciamento: O SQL Server Management Studio apresenta as seguintes característica nesta versão CTP1:
           – O Editor EngineQuery traz funcionalidades aprimoradas para a
Transact-SQL e a depuração IntelliSense, sendo:
–  Depuração de Scripts Transact-SQL em execução nas instâncias
do SQL Server 2005 SP2 ou posterior;

§ Breakpoints em Transact-SQL,
suportando funcionalidades como Condição de Interrupção em uma Expressão, cujas
avaliação determina se o ponto de interrupção for invocada;

§ Contagem de ocorrências Breakpoints, especificando o número de vezes que um breakpoint é encontrado antes de ser chamado;

§ Filtro de interrupção, que limita o ponto de interrupção em computadores específicos, processos ou Threads;

§ Personalização de Pontos de Interrupção, que pode ser executado quando o ponto de interrupção for chamado;

§ Janelas de Quick Watch que suportam expressões Transact-SQL;

§ Quando se move o cursor sobre um Transact-SQL, um Pop-up Quick Info exibe o nome da Expressão e seu valor;

§ O Transact-SQL IntelliSense que introduz os novos recursos:
            ·    Validação de Breakpoint, que evita estabelecer um ponto de interrupção em um
local inválido.
            ·      Trechos de código Transact-SQL como modelos que podemos usar como ponto
de partida na construção de Transact-SQL em lotes ou em Scripts;
            ·    Transact-SQL Surround, também com modelos que podemos utilizar olhando
pontos que definem quando uma instrução Transact-SQL se encerra em um
Begin, If, While dentro do Bloco;
   § Melhorias na utilização do Full-text, utilização de querys AD-Hoc para
paginação, além de suporte a sequences e outras melhorias também disponíveis
no Transact-SQL, sendo descritas abaixo:

·  Full-Text Search, que a partir do SQL Server “Denali”, será possível configurar um índice full-text que ofereça suporte para pesquisas sobre propriedades, como exemplos de consultas sobre Autor e Título, emitidos por IFilters.
Este formulário de pesquisa é conhecido como PROPERTY SEARCHING (propriedade de busca), onde caso seja possível pesquisar a propriedade em um determinado tipo de documento, com seu filtro correspondente (IFilters) durante a indexação do full-text.

·    A Instrução EXECUTE poderá especificar os metadados que serão retornados usando o argumento WITH RESULTS SETS.

·    Implementação de paginação em consultas Ad-hoc, onde será possível especificar um intervalo de linhas a serem retornadas por uma instrução SELECT com base na linha em um ROW OFFSET e ROW COUNT VALUES que fornecermos. Isto será útil quando quisermos controlar o número de linhas enviadas para um aplicativo cliente em uma determinada consulta.

·    Uso de SEQUENCES, assim como em Bancos de dados
como ORACLE de DB2, no SQL Server “Denali” será possível utilizarmos SEQUENCES para gerarmos valores numéricos de acordo com as especificações que a SEQUENCE foi criada, operando de forma semelhante a uma coluna IDENTITY, porém, com os números de sequências sem restrições ao uso de uma tabela. O Método para criação de SEQUENCES no SQL Server “Denali” será baseado na Instrução CREATE SEQUENCE.

                 Contudo, este também será um tema que merecerá um artigo específico para ele.

·    Melhorias na segurança, que incluem novas propriedades de permissões, além de novas Funções de Servidor definidas pelo Usuário, tendo também novas formas de gerenciamento das regras do Servidor e Bases de dados.

o Estão disponíveis funções User-defined para gerenciar, adicionar e remover membros das regras do servidor, utilizando os comandos CREATE SERVER ROLE, ALTER SERVER ROLE e DROP SERVER ROLE;

Melhorias no Integration Services

A última versão do Microsoft Integration Services apresentará novos recursos que aumentaram a produtividade dos Desenvolvedores e Administradores na solução de Processos ETL e de transformação de dados, oferecendo um novo modelo de implantação e Administração na Integração dos dados, sendo que este modelo de implantação prevê a possibilidade de definir parâmetros tanto para os pacotes quanto para os projetos que passam a ser uma implantação no Integration Services.

Além disso, novas caixas de diálogo no SQL Server Management Studio e novos conjuntos de Views e Stored Procedures nos ajudarão a gerenciar, executar e monitorar pacotes em tempo real.

·      Melhorias na Usabilidade:

o O BIDS (Business Intelligence Development Studio) foi atualizado para ajudar tanto  novos quanto usuários experientes a desenvolver pacotes com mais facilidade. A Toolbox foi refinada, dando mais flexibilidade na criação de Data Flows.

Nova tela de Toolbox do Integration
Services, que nesta versão ainda utiliza o Shell do Visual Studio 2008.

Além disso, agora é possível editarmos um componente mesmo quando seu Path de input estiver desconectado, tendo o processo de reconexão e mapeamento das colunas simplificadas.

Novo componente de correção de dados, que permite ao Integration Services corrigir com mais facilidade a qualidade dos dados.

As demais ferramentas (Analysis Services, Data Quality Services, Reporting Services, Serviços de replicação e Service Broker) não sofreram atualizações, sendo oferecidas com as mesmas funcionalidades disponíveis na versão do SQL Server 2008
R2.

Enfim, vamos estudando.