Fala galera, estou escrevendo este post sobre a diferença dos tipos de conexões que temos no SQL Server Integration Services (ou SSIS para os intimos, rs) porque nas ultimas 3 semanas me perguntaram sobre isso 2 vezes. Então para poder tirar a duvida de quem precisar, agora fica mais facil.

Quando iniciamos um novo projeto de SSIS no BIDS (BI Development Studio) podemos identificar algumas pastas lógicas na Solution Explorer do projeto. As duas pastas que mais são utilizadas é a Data Sources e a SSIS Packages. A pasta SSIS Packages é onde os pacotes contendo o Workflow de atividades que trabalharão no processo de ETL são organizados logicamente, e a pasta Data Sources é onde as conexões globais ficam armzenadas.

Neste exemplo, vou utilizar o pacote chamado Package.dtsx que já vem criado na pasta SSIS Packages e criar os dois tipos de conexões, uma local exclusiva para o pacote e outra global para todos os pacotes do projeto. Veja as pastas e o pacote default:

Para ver as conexões, é preciso adicionar um controle DataFlow dentro do ControlFlow no pacote, isso pode ser feito arrastando o controle da toolbox para a área de design do ControlFlow. Depois de adicionado o DataFlow, clicando 2 vezes nele, a aba superior muda e permite editar as configurações do DataFlow selecionado. Veja a imagem com o controle DataFlow dentro do Controlflow. E do lado a imagem do DataFlow ainda vazio depois de receber o duplo clique.

O controle DataFlow possui uma área de Connection Manager na região inferior da área de design. Nesta área ficam todas as conexões locais do pacote, vamos adicionar uma nova conexão clicando com o botão direito e indo até o item específico da conexão que deseja realizar.

Neste exemplo, vamos adicionar uma “New ADO.NET Connection…”. Depois de selecionar este ítem no menu, uma tela com todas as conexões que estão em cache na máquina de desenvolvimento são apresentadas. Do lado esquerdo são as conexões e do lado direito são os detalhes do que foi selecionado.

Será criada uma “New…” conexão, para apontar para o SQL Server 2008 R2 em uma conexão local e vamos ver como ela fica apresentada no Connection Managers do pacote.

Após a configuração, mais um item aparece na lista das conexões em cache, é nesta lista que selecionaremos a conexão que será utilizada para trabalhar no Workflow sendo uma origem ou um destino no processo que será executado.

Após a seleção, a conexão ficará exposta na Connection Managers do pacote, veja que o nome não é muito amigavel, é possível renomear clicando com o botão direito na conexão e apontando para “Rename” ou através do atalho F2. A mudança do nome não impacta o cache de conexões, somente o item que está na sessão de Connection String. Vou renomear esta conexão para “SQL 2008 R2 – Local”.

Agora que já criamos uma conexão local, vamos criar uma conexão global para o projeto. Para isso, vá até a Solution Explorer, encontre a pasta Data Sources, clique com o botão direito na pasta e aponte para New Data Source…

Quando a tela é aberta, reparamos que é uma tela que já conhecida, é a tela de cache de conexões. Como é só pra exemplo, vou selecionar qualquer uma delas diferente da selecionada anteriormente. A unica diferença é que no final escolhemos um nome para a conexão. Neste caso, como estou me conectando a uma conexão do SQL Azure Database,  vou chamar de “SQL Azure – Global”.

Veja que agora temos dois lugares que podem existir conexões. As conexões locais e as globais. As locais foram aquelas criadas diretamente no pacote e as globais são essas criadas na pasta Data Sources do projeto. Agora é chegada a hora de adicionar a conexão global ao pacote e utilizá-la como e quando for necessário. Para isso, clique com o botão direito na área de Connection Managers e aponte para “New Connection From Data Source…” isso permitirá selecionar qualquer conexão que esteja na pasta lógica Data Sources da Solution Explorer. Após adicionado, repare que o ícone das conexões são diferentes, isso serve justamente para identificar visualmente qual conexão é de cada escopo. O cilindo com uma conexão em baixo significa que é uma conexão local enquanto o cilindo com quatro setas apontando para todos os lados significa uma conexão global.

As duas principais diferenças entre os dois tipos de conexões, é que quando utilizamos conexões locais elas ficam somente nos pacotes e se for necessário utilizar a mesma conexão em outro pacote, ela terá que ser configurada novamente nele, já na conexão global é só utilizar a referência do Data Sources em todos os pacotes. A outra diferença é que se for preciso alterar alguma conexão, alterar a que está no Data Sources lhe dá o trabalho de realizar isso somente em um lugar e todas as referências são automaticamente atualizadas. Já quando se tem uma conexão em cada pacote, se você possuir 20 pacotes em seu projeto, terá que alterar 20 vezes a mesma coisa!

Fala galera, como prometido na palestra sobre SQL Azure Database, dia 10/04/2010 no Marília Tech Day 2010, vou escrever o artigo! A idéia será utilizar aquele mesmo arquivo TXT de nomes para importar dados através do SSIS (SQL Server Integration Services) escrevendo no SQL Azure Database.

Para começar, vamos abrir o BIDS (Business Intelligence Development Studio), que está dentro da pasta do SQL Server 2008:

Após a abertura do BIDS, inicie um novo projeto de “Business Intelligence Projects” utilizando o tipo “Integration Services Project”. O nome que vou salvar meu projeto é “txtParaAzure”. Veja estas opções na imagem abaixo:

Ao iniciar o projeto, quatro abas superiores são apresentadas na área de desenvolvimento do processo: Control Flow, Data Flow, Event Handlers e Package Explorer. Não vou falar sobre as abas que não utilizaremos, vou falar apenas da Control Flow e Data Flow. A aba Control Flow é responsavel por criar as execuções do pacote, é dentro desta área que são colocados os objetos “macro”, neste exemplo, vamos inserir um Data Flow Task. Pode possuir um ou mais destes objetos (Data Flows Task), que são os responsaveis reais por realizar o ETL (Extration, Transformation and Loading – Extração, Transformação e Carregamento). É no Data Flow que informamos qual é a origem e o destino dos dados que serão processados. Veja as abas superiores e o item do Data Flow na toolBox (à esquerda). Ele será arrastado para dentro do Control Flow e irá controlar o processo.

Após arrastar o item Data Flow Task para o Control Flow, dê dois cliques no item e vamos analisar o toolbox desta área. Repare que os ítens do toolbox foram modificados para se adequar à área Data Flow. As sessões da toolbox são “Data Flow Sources” (objetos referentes à origem dos dados), “Data Flow Transformation” (objetos referentes à transformação dos dados) e “Data Flow Destinations” (objetos referentes à destino dos dados). Os dois grupos que sempre serão usados em um projeto de SSIS serão os de Origem (Data Flow Sources) e de Destino (Data Flow Destinations). O grupo de transformação (Data Flow Transformations) pode ser usado ou não, vai depender da sua necessidade.

Bom, sabendo que os ítens mínimos para se criar um fluxo no SSIS são Origem e Destino, vamos adicionar esses itens e fazer as conexões. A origem será um arquivo TXT, para isso, vou adicionar o “Flat File Source”. Encontre esse objeto na toolbox à esquerda e arraste para a área de design.

Depois, como o destino será um banco de dados na nuvem, vou adicionar um “ADO NET Destination”. Mesmo processo, encontre o objeto na toolbox e arraste para a área de design. Repare que os ítens estão um na sessão de Origem e outro no Destino.

Para se criar o fluxo do processo, visto que podem existir diversas atividades de origens e destinos acontecendo em um mesmo fluxo, é necessário criar uma ordem lógica dos acontecimentos. Para isso, vamos selecionar o item que será processado primeiro (Origem) e arrastar a setinha verde para o item seguinte (Destino). Neste caso, selecionamos o item “Flat File Source”, arrastamos sua setinha verde e ligamos no “ADO NET Destination”. Reparem que existem duas setas na origem, a seta verde segue o fluxo quando não ocorrer problema no processamento, já e a seta vermelha é utilizada como caminho quando o fluxo do processamento der algum problema. Geralmente a seta vermelha segue para um ítem que permite enviar um e-mail ou salvar a mensagem do erro em um arquivo de texto para análise posterior. Neste exemplo, vou apenas mostrar a seta verde.

Agora que já foram criados os fluxos do trabalho, vamos criar as conexões que servirão para orientar a origem e o destino dos dados. Para isso, clique com o botão direito na Origem e depois selecione Edit…

Uma tela com as opções para se carregar um arquivo são apresentadas. Vamos configurar para ler o arquivo nomes.txt que criamos no post: Plataforma de BI dentro do SQL Server 2008 – prt 6 

Após clicar no Edit, uma tela se abrirá para selecionar qual será a conexão, como ainda não criamos a que será utilizada, clique no botão New… e configure as opções do arquivo que será lido.

A configuração inicial será somente colocar o Nome e a Descrição, e selecionar o arquivo de origem. A primeira caixa de texto é referente ao Nome, a segunda à Descrição e o botão Browse… para localizar o arquivo.

Agora que o arquivo foi carregado, vá até o item Advanced na lista da esquerda, selecione a Column 1 e clique no botão Delete. Na mesma tela, selecione a Column 0 e modifique a propriedade OutputColumnWidth para 100. Clique em Ok até voltar para a tela inicial.

Após fazer a configuração dos dados de origem, repare que o objeto não está mais com um x dentro. Isso representa que ele está configurado com uma determinada fonte de dados. Comparando com o destino, que ainda não foi configurado, fica facil de ver o x. Agora é a hora de configurar o destino dos dados, vamos então fazer o mesmo processo com o destino, clique com o botão direito e selecione Edit…

Uma tela para selecionar a conexão é apresentada, vamos clicar em New… e ir para uma segunda tela. Nesta segunda tela, uma lista com as conexões existentes é apresentada, novamente clique em New… e agora sim, configure a conexão. Neste caso, vou configurar meu servidor do SQL Azure Database, mas poderia ser qualquer outro SGBD que você utilize.

Após configurar, volte até a primeira tela da configuração e informe qual será a tabela que vai escrever a informação.

Após selecionar a tabela na combo de tabelas, clique no item Mappings à esquerda e faça a ligação entre a Column0 (Origem) e o nome (Destino). Essa configuração irá representar qual informação se liga na outra. Após ligar as colunas, é só dar OK.

O processo está quase concluído, só precisa executar (apertando F5) e aguardar o final do processamento. Se tudo estiver configurado corretamente, as caixinhas ficarão todas verdes, isso significa que foram executadas com sucesso. Caso alguma fique vermelha, ela não chegou a concluir todo o processamento.

Para confirmar a inclusão de todos os dados do arquivo TXT para o SQL Azure Database, vou fazer uma consulta simples para me retornar a quantidade de registros na tabela.

Com esse processo do SSIS funcionando, foi possível migrar dados de um arquivo TXT para o SQL Azure Database. O arquivo TXT foi só uma das possiveis origem de dados, podendo ser qualquer uma que estivesse dentro do grupo Data Flow Sources na toolbox da aba Data Flow.

Fala galera, hoje recebi um e-mail do time da Azure Platform (envolve: Windows Azure, SQL Azure Database e AppFabric). O e-mail me deixou bem contente, agradeceu a ajuda que demos nos feedbacks da versão de CTP e nos informou que a data oficial de lançamento do Azure no Brasil será dia 09/04/2010.

Quem tiver seus projetos na versão CTP e quiser migrar pra versão RTM (terá que pagar, é claro!), poderá fazer a migração até o dia 09/05/2010. Terá um mês pra fazer isso, é tempo suficiente. Depois dessa data, se não fizer a migração, continuará tendo acesso read-only até o dia 10/06/2010, depois disso já era!

Os outros países que terão a versão CTP migrada pra RTM são:

Austrália / Brasil / Chile / Colômbia / Costa Rica / Chipre / Republica Tcheca / Grécia / Hong Kong (China) / Hungria / Israel / Luxemburgo / Malásia / México / Peru / Filipinas / Polônia / Porto Rico / Romênia / Trinidad e Tobago / Finlândia.

São ótimas notícias para nós que gostamos de tecnologia e adoramos ter essa flexibilidade que temos em Cloud Computing. :)

Fala galera, é sexta-feira de madrugada minha esposa está tomando banho e eu estou escrevendo este post. É o sexto da série e provavelmente o útimo que escreverei com minhas idéias, a partir de agora vou esperar as duvidas de vocês para escrever mais posts sobre esses comparativos.

Neste post, vou falar sobre Alta Disponibilidade e Escalabilidade.

Quando se pensa em Alta Disponibilidade, estamos pensando em 24X7 (24horas 7 dias por semana). A Plataforma Azure é baseada em SQL e Windows Server, e é flexivel o bastante para para variar com relação à carga ou uso. O serviço replica os dados em diversos servidores diferentes para manter os dados redundantes e disponíveis para seu negócio, haja o que houver. No caso de um dos servidores cair, o Azure automaticamente faz o loadbalance e aponta para outro server.

Já com relação à escalabilidade, esse é um ponto bem positivo pra Plataforma Azure no ponto de vista da facilidade de se escalar (aumentar o desempenho) sua própria solução. No SQL Server, depois de particionar seus dados, a escalabilidade é automática e o banco vai crescendo de acordo com sua necessidade. Pela forma de licenciamento, você só pagará pelo que armazenar “economizando dinheiro”, e caso precise fazer um downgrade (diminuir o desempenho) de seu ambiente, é possivel fazer quando achar necessário.

Bom, foram 6 posts sobre diversas informações relacionadas à SQL Server e SQL Azure Database. Com certeza terão assuntos que vocês gostariam que fossem discutidos e não foram. Deixo o espaço dos comentários ou o meu twitter @DiegoNogare aberto para que possam enviar suas dúvidas e terei o maior prazer em responder.

Fala galera, estou voltando a postar depois do MVP Summit 2010…

Na comparação de hoje falarei sobre o modelo de dados relacional.

O SQL Azure será bem familiar à todos os DBAs e DEVs (de banco) no quesito de armazenamento, porque é bem parecido com o SQL Server on-premise, usando T-SQL. Por conceito, o SQL Azure é como uma instância do SQL Server, só que com algumas restrições (vocês se lembram, né?!).

Em cada servidor de SQL Azure, você pode criar diversos bancos de dados, e em cada banco pode criar várias tabelas, views, stored procedures, índices, e vários outros objetos. Este modelo de dados faz um bom uso do design e codificação dos bancos que já temos on-premises e simplifica o processo de migração para a nuvem por serem bem similares e suportarem quase tudo um do outro.

Só lembrando que o SQL Azure Database são servidores virtuais e não correspondem exatamente como um SQL Server local (que é físico)! Então não tentem ter o mesmo desempenho, é muito pouco provável que consiga chegar próximo!

Se alguém tiver duvida sobre alguma coisa entre o SQL Azure e o SQL Server, me mande que eu terei um prazer enorme em responder.