Categorias
SQL Server Troubleshooting Virtual PASS BR

SSIS – Proxy Account Permission

[bing_translator]

A utilização de Proxy Account para execução de pacotes SSIS dentro do SQL Server Agent é um procedimento para utilização de usuários que não são SYSADMIN executarem pacotes com outras credencias que não é a da conta de serviço do SQL Server Agent.

Existem varias referencias de como criar e utilizar Proxy Account porem eu passei por um problema com a utilização desse cenário.

Cenario:

Um pacote SSIS , que está armazenado em file system, com uma funcionalidade que deve ler um arquivo EXCEL em uma pasta compartilhada na rede e carregar os dados para outro lugar usando um login Windows.

A pasta compartilhada está em um domínio (Domínio A) e a servidor de Integration Services está em outro domínio (Domínio B)

Problema:

Tudo parecia perfeito, credencial criada, proxy account criada e associada corretamente , job criado correto porem na hora de executar o job o seguinte erro era apresentado:

Error:

Code: 0xC0202009

Source:  Excel Source [705]

Description: SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.

End Error

Error:

Code: 0xC02020E8

Source: Excel Source [705]

Description: Opening a rowset for “Plan1$” failed. Check that the object exists in the database.

End Error

Error:

Code: 0xC004706B

Source:  SSIS.Pipeline

Description: “component “Excel Source” (705)” failed validation and returned validation status “VS_ISBROKEN”.

End Error

A primeira tentativa de solucionar foi validar a mensagem de erro que dizia que ao abrir a “Plan1$” a operação falhou! Abri o pacote, verifiquei todas a conexões, tentei alterar algumas configurações do pacote e nada adiantou, tudo correto!

Solução:

Depois de um tempo pude perceber que o primeiro erro não estava na falha ao tentar abrir o arquivo “Plan1$” e isso era consequência.

Comecei a analisar a primeira mensagem: Description: SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.

Após pesquisar um pouco na internet achei o seguinte artigo:

http://blogs.msdn.com/b/dataaccesstechnologies/archive/2009/11/10/ssis-error-code-dts-e-oledberror-an-ole-db-error-has-occurred-reasons-and-troubleshooting.aspx

Quando cheguei ao item C apareceu um luz no fim do túnel para mim. Porem agora o problema era saber qual pasta dar permissão.

Nesse momento fui validar as variáveis de ambiente para tentar descobrir onde ficaria a pasta TEMP que o artigo dizia que deve ter permissão.

SSIS-ProxyAccountPermission - 01

 

 

 

 

 

 

Imagem 01

Agora sim!!! Tinha todas as informações e concedido acesso de leitura e escrita para o usuário do proxy account nessa pasta especifica. Hora de testar o JOB e adivinhem: mesmo erro novamente! Sinceramente não sabia o motivo do erro, pois uma vez que dei permissão na pasta e tudo o que o artigo falava estava correto, não sabia o motivo de não funcionar .

Sem saber o que fazer, surgiu a ideia de usar o Process Monitor (sysinternal) para tentar validar o que estava acontecendo no Windows. Depois de algum tempo analisando o processo e o erro consegui achar a seguinte informação:

SSIS-ProxyAccountPermission - 02

 

Acesso negado em um pasta!!! Mais uma vez uma luz apareceu porem sem saber o motivo do processo usar o usuário “Default” e a pasta “Temporary Internet Files”.

Enfim, para resolver o problema concedi permissão de escrita e leitura dentro da pasta “C:\User\Default\AppData\Local” para o usuário do Proxy Account e executei novamente o JOB que dessa vez terminou com sucesso!!!

Não sou especialista em SSIS para entender o funcionamento interno, porem somente com uso da ferramenta Process Monitor foi possível verificar o que realmente o processo fazia e onde ele precisava de permissão.

Referencias:

http://www.mssqltips.com/sqlservertip/2163/running-a-ssis-package-from-sql-server-agent-using-a-proxy-account/

http://blogs.msdn.com/b/dataaccesstechnologies/archive/2009/11/10/ssis-error-code-dts-e-oledberror-an-ole-db-error-has-occurred-reasons-and-troubleshooting.aspx

http://technet.microsoft.com/en-us/sqlserver/ff686764.aspx

Categorias
SQL Server Virtual PASS BR

Eu devo utilizar as DMV?

Você já deve ter ouvido falar nas DMV, mas voce já utilizou alguma?

Primeiramente, DMV é o nome mais comum para views (Dynamic Management Views) e functions (Dynamic Management Functions). DMVs são metadados que ficam armazenadas no schema sys, iniciam com sys.dm_* e permitem explorar o comportamento interno do SQL Server com comando SELECT.

As DMVs foram implementadas no SQL Server 2005 e hoje já são popularmente conhecidas, mas eu ainda vejo algumas pessoas lutarem contra elas e continuarem utilizando formas antigas de recuperar informações internas do SQL Server, por exemplo: Utilizar a stored procedure de sistema SP_WHO ou SP_WHO2 para trazer informações do que esta acontecendo e quais processos estão sendo executados na instancia.

Essas procedures  de sistemas são uteis e trazem algumas informações que você com certeza pode identificar o que está acontecendo em seu ambiente porem, na minha visão, elas tem limitações extremas e trazem poucas informações.

Com as DMVs você pode ser mais especifico em procurar um problema ou informação, não dependendo de um conjunto de resultado pré-estabelecido que não pode ser modificado.

As DMVs contem muitas informações adicionais que não fazem parte de procedures de sistemas e com detalhes riquíssimos onde podemos cruzar informações entre varias DMVs e obter um diagnostico preciso sobre o que você procura.

Em uma breve conversa com alguns DBAs da minha equipe, percebi  que o fato de que alguns deles não usarem as DMVs é por falta de conhecimento e por “preguiça”… Sim a comodidade de escrever poucas palavras e não escrever um SELECT é o principal ponto que encontrei…

Mas vamos lá… Por que eu devo utilizar as DMVs?

Na minha opinião é pelo fato delas conterem muitas informações relevantes para N tipos de situações, seja uma simples consulta de propriedades até um diagnostico completo de  problemas. Com as DMVs a facilidade de informação está ao nosso lado, então porque desperdiçar?

Conhecer todas as DMVs é um desafio, mas basta começar à conhece-las que você irá se acostumar facilmente e isso acontecerá porque as DMVs estão categorizadas em grupos específicos baseados nas áreas que a informação é exposta.

Algumas dessas áreas são:

dm_exec_* 

Nessa sessão você tem informação relacionada a execução de código e conexão associada.  Por exemplo: sys.dm_exec_session voce tem informação sobre as sessões existentes na instancia.

Aqui vale a pena um atenção especial! Na minha opinião essa sessão deve ser bem explorada pois tudo o que esta sendo executado na sua instancia pode ser encontrado aqui.

dm_db_*

Nessa sessão você tem informação sobre detalhes do database e seus objetos. Por exemplo: sys.dm_db_missing_index_details você tem informações detalhadas sobre índices ausentes

dm_io_*

Nessa sessão voce tem informação sobre atividade e I/O. Por exemplo: sys.dm_io_pending_io_requests retorna uma linha para cada solicitação de I/O pendente.

dm_os_*

Nessa sessão você tem informação em baixo nível do sistema. Por exemplo: sys.dm_os_schedulers que retorna uma linha para cada scheduler.

dm_tran_*

Nesse sessão você tem informação sobre transações corrente. Por exemplo: sys.dm_tran_active_transactions você tem informação sobre transações da instância.

E assim por diante!! Para obter mais informações sobre as DMVs acesse o link: http://technet.microsoft.com/en-us/library/ms188754.aspx

Complemento:

A Microsoft SQL Server DMV/DMF Cheat-Sheet

SQL Server 2008 System Views poster is now available for download!

O link abaixo achei super interessante, pois monstra uma forma diferente de visualizar as DMVs!!!

The SQL Server 2012 Periodic Table of Dynamic Management Objects

Categorias
How To SQL Server Troubleshooting Virtual PASS BR

Aumentar o numero de arquivos do Errorlog e limitar o seu tamanho físico

O log de erro do SQL Server (ERRORLOG) contem muitas informações geradas pelo SQL Server como mensagens, alertas, eventos críticos, auditoria, informações geradas a partir dos usuários entre outras. O log de erro é um ótimo lugar para encontrar informações sobre o que está acontecendo com seu ambiente.

O ErrorLog é inicializado cada vez que a instancia do SQL Server é iniciada ou quando o log de erro é reciclado. Se a instancia não tem sido reiniciada por um longo tempo, o arquivo de log de erro pode crescer consideravelmente dificultando a seu leitura em uma possível analise.

Por padrão, os logs de erro de SQL Server são mantidos na subpasta de Log do SQL Server e há sete logs de erro do SQL Server. Quando o arquivo de log de erros é recriado, o log anterior é renomeado para Errorlog.1 e próximo log anterior (Errorlog.1) é renomeado para Errorlog.2 e assim por diante.

Aumentando o numero de arquivos

Para aumentar o numero de arquivos do ErrorLog do SQL Server, você deve se conectar a uma instancia e clicar com botão direito em SQL Server Log e depois em “Configure”.

Errorlog1

Figura 1

Depois habilite a única check box disponível e aumente o numero de log de erro que pode chegar até 99 arquivos.

Errorlog2

Figura 2

Para saber o caminho fisicamente onde os arquivos de log de erro estão armazenados você pode utilizar esse T-SQL para ajuda-lo.

SELECT SERVERPROPERTY(‘ErrorLogFileName’);

Abaixo o SCRIPT para a alterar a quantidade de ErrorLog :

USE [master]

GO

EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’NumErrorLogs’, REG_DWORD, 99

GO

Novidade no SQL Server 2012

No SQL server 2012 existe uma nova opção para os arquivos de ErrorLog que é o limite por tamanho!
Podemos a partir de agora limitar o tamanho fisico do arquivo do ErrorLog 🙂
Com o comando abaixo limitamos o tamanho do arquivo em 5MB

USE [master];

GO

EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’,N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’ErrorLogSizeInKb’, REG_DWORD, 5120;

GO

Na minha visão, essa opção é muito util quando temos grandes problema ou incidicio de problema eventos são gravados no errorlog. Com esse limitador de tamanho podemos ter a facilidade de abrir um arquivo de errorlog em um troubleshooting ou ate mesmo controlar o espaço em disco caso seja necessario!

Reciclar o ErrorLog

Para reciclar os arquivos de log de erro do SQL Server devemos executar a seguinte procedure de sistema:

sp_cycle_errorlog

Essa procedure deve ser executada diretamente na database master.

Essa procedure fecha o arquivo de log de erros atual e altera os números de extensão de log de erros, simulando um reinício da instancia.

Assim como log de erro do SQL Server o log de erro do SQL Server Agent é um ótimo lugar para buscar informações sobre o que está acontecendo com o SQL Server Agent. Porém, não é possível aumentar a quantidade de arquivos do log de erro do SQL Server Agent, sendo fixado em um total de 10 arquivos, com 1 arquivo corrente (SQLAGENT.OUT) e 9 arquivos de log (SQLAGENT.1 até SQLAGENT.9)

Da mesma maneira que acontece com o log de error do SQL Server o log de erro do SQL Server Agent é inicializado quando a instancia é iniciada ou quando o log de erro é reciclado.

Para reciclar os arquivos de log de erro do SQL Server Agent devemos executar a seguinte procedure de sistema:

sp_cycle_agent_errorlog

Essa procedure deve ser executada diretamente na database msdb.

Referencia:

Limit the size of the error log

Categorias
SQL Server Troubleshooting Virtual PASS BR

Erro ao instalar SQL Server 2012 em cluster – There was an error to lookup cluster resource types

Ao tentar instalar o SQL Server 2012 em um cluster recebi o seguinte erro:

error01-SQL2012-Cluster

There was an error to lookup cluster resource types. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 4104. Description: Error code 0x86D80018.

Depois de muito pesquisar e pouco encontrar sobre o problema, resolvi envolver a equipe de SO para me ajudar.

Tentamos entendender o que o SQL Server estava fazendo achamos algo realmente estranho.

Ao listar os tipos de recursos do cluster tivemos uma surpresa.

error02-SQL2012-Cluster

Um tipo de recurso chamado: SQL Server(2008A)

Como e porque esse recurso foi criado é um mistério, mas esse tipo de recurso não fazia nenhum sentido para nós.

Após validar que nenhum outro recurso dependia desse recurso bizarro tivemos a certeza que poderíamos apaga-lo.

Para remover esse recurso via Failover Cluster Administrator:

  • Clique com o botão direito no nome do cluster
  • Selecione propriedades e acesse a guia Resource Types
  • Selecione o recurso e clique em Remove

error03-SQL2012-Cluster

Depois disso a instalação finalizou com sucesso!!

Categorias
SQL Server Virtual PASS BR

Uma forma simples de visualizar Cached Plan

Recentemente estava assistindo alguns vídeos no Pluralsights e um código usado em um vídeo do Dan Sullivan para demonstrar Cached Plan me chamou a atenção.

Gostei e resolvi compartilhar, e fiz uma alteração apenas para incluir o nome da database.

create function SqlAndPlan (@handle varbinary(max)) 
returns table 
as 
return 
select 
  sql.text 
 ,db_name(qp.dbid) dbname -- eu adicionei essa informação 
 ,cp.usecounts 
 ,cp.cacheobjtype 
 ,cp.objtype 
 ,cp.size_in_bytes 
 ,qp.query_plan 
from 
 sys.dm_exec_sql_text (@handle) as sql
cross apply sys.dm_exec_query_plan(@handle) as qp
join sys.dm_exec_cached_plans as cp 
     on cp.plan_handle = @handle
go

Primeiramente é criado uma função auxilizar para retornar informações plano de execução, onde é passado como parâmetro o plan_handle que uma referencia ao plano de execução em si e também uma referencia ao texto que causou a construção do plano de execução.

clip_image002

Com essa função podemos obter informações uteis, porem temos que ter o plan_handle especifico. Isso é interessante se queremos saber o cached plan de um unico plano de execução, porem, se quiseremos saber todos os cached plan e contidos na instancia, como fazemos? Teremos que passar um a um?

Não! Vamos criar uma view que irá percorrer todos os plan_handle e usar a função SqlAndPlan criada acima para obter as informações.

create view PlanCache
as
select
   sp.dbname -- eu adicionei essa informação 
  ,sp.text
  ,sp.usecounts
  ,sp.cacheobjtype
  ,sp.objtype
  ,sp.size_in_bytes
  ,sp.query_plan
from
  sys.dm_exec_cached_plans as cp
CROSS APPLY SqlAndPlan(cp.plan_handle) as sp

go

Caso tenha alguma sugestao de melhoria no codigo, 
por favor, compartilhe.

[]’s

 

Referências:

Pluralsight – http://pluralsight.com

sys.dm_exec_sql_text – http://msdn.microsoft.com/pt-br/library/ms181929.aspx

sys.dm_exec_query_plan – http://msdn.microsoft.com/pt-br/library/ms189747(v=sql.110).aspx

sys.dm_exec_cached_plans – http://msdn.microsoft.com/pt-br/library/ms187404.aspx

Categorias
SQL Server

CDC no SQL Server 2012 na prática…

Com a chegada do SQL Server 2012 melhorias foram realizadas e novidades implementadas e é uma dessas novidades que apresentarei.

No SSIS alguns novos componentes foram implementados para facilitar a utilização do CDC (Change Data Capture):

clip_image001 Esse componente se encontra no Control Flow e ele que irá realizar todo o controle necessário acessar as informações através do Log Sequence Number (LSN) . Mais informação sobre o CDC Contral Task acesse o link.

http://msdn.microsoft.com/en-us/library/hh758674.aspx

clip_image002 Esse componente se encontra dentro do Data Flow e ele irá realizar a leitura dos seus dados. Mais informação sobre o CDC Source acesse o link.

http://msdn.microsoft.com/en-us/library/hh758686.aspx

clip_image003 Esse componente se encontra dentro do Data Flow e ele irá separar seus dados de acordo com as opções escolhidas dentro do CDC Source. Mais informações sobre o CDC Splitter acesso o link.

http://msdn.microsoft.com/en-us/library/hh758656.aspx

Preparação do Ambiente

O CDC tem inúmeras utilidades, mas uma delas é ajudar no processo de carga de um ambiente de Data Warehouse e esse foi o cenário que escolhi.

1º Passo – Criação dos databases

Irei utilizar 3 databases simulando um ambiente de carregamento de dados em um DW.

 1: CREATE DATABASE EXEMPLO_CDC

 2: GO

 3: CREATE DATABASE STAGING

 4: GO

 5: CREATE DATABASE DW_EXEMPLO_DCD

 6: GO

2º Passo – Preparando os databases

O database EXEMPLO_CDC ira servir como databases OLTP, onde todos os dados transacionais serão mantidos e é nele que temos que habilitar o CDC.

 1: USE EXEMPLO_CDC

 2: GO

 3: EXECUTE sys.sp_cdc_enable_db

 4: GO

Para mais informações sobre a stored procedure de sistema acesse o link http://msdn.microsoft.com/en-us/library/bb510486

Agora crie uma tabela e habilite o CDC para esse objeto.

 1: CREATE TABLE [dbo].[CATEGORIA]

 2: (ID INT NOT NULL IDENTITY PRIMARY KEY,

 3: NOME_CATEGORIA VARCHAR(100) NOT NULL)

 4:

 5: EXECUTE sys.sp_cdc_enable_table

 6: @source_schema = N'dbo',

 7: @source_name = N'CATEGORIA',

 8: @role_name = N'cdc_admin',

 9: @supports_net_changes = 1

 10: GO

 11:

Para mais informaçõe sobre a stored procedure de sistema acesso o link

http://msdn.microsoft.com/en-us/library/bb522475.aspx

 1: INSERT INTO [dbo].[CATEGORIA] VALUES

 2:  ('CATEGORIA 1')

 3: ,('CATEGORIA 2')

 4: ,('CATEGORIA 3')

 5: GO

 6:

 7: USE DW_EXEMPLO_CDC

 8: GO

 9: CREATE TABLE [dbo].[CATEGORIA_DESTINO]

 10: (ID INT NOT NULL PRIMARY KEY,

 11: NOME_CATEGORIA VARCHAR(100) NOT NULL)

 12:

Criando Pacote

Para esse exemplo irei criar dois pacotes, o primeiro de carga inicial ou carga completa e o segundo de carga incremental.

Pacote Inicial

Nesse pacote iremos criar uma carga completa dos dados. A primeira tarefa a se realizar é utilizar o componente CDC Control Task.

Algumas configurações importantes devem ser feitas nesse componentes.

  • CDC control operation: Utilize a opção Mark Initial load start. Esta operação é usada no começo de um pacote da carga inicial para registrar o LSN atual no banco de dados de origem antes de o pacote da carga inicial começar a ler as tabelas de origem.
  • Crie uma variável, User::CDC_State, para armazenar o estado da operação do CDC. O botão New faz isso automaticamente.
  • Utilize a opção Automatically store in a database table para persistir o estado do CDC.
  • Crie uma nova tabela para armazenar o estado do CDC. Clique em New e o assistente irá te fornecer um código para ser executado. Esta tabela será usada para rastrear as informações de carga CDC, de modo que você só pegar as novas alterações a cada vez que o pacote de carga incremental é executado
  • State Name: O nome associado ao estado persistente. Esse nome é usado para verificar a linha de estado na tabela de estado.

clip_image004

Figura 1

Proxima tarefa é iniciar seu Data Flow que nesse exemplo é bem simples.

clip_image005

Figura 2

Despois de realizar todos as manipulações de dados temos que novamente colocar o componente de CDC Control Task porem com uma modificação. Altere a opção CDC control operation para Mark initial load end

clip_image006

Figura 3

Seu pacote deverá parecer como a figura 4.

clip_image007

Figura 4

Pacote Incremental

Nesse momento irei utilizar o banco de dado STAGING para criar duas tabelas: CATEGORIA_DESTINO_DELTE e CATEGORIA_DESTINO_UPDATE. O motivo dessas tabelas é realizar as operações de UPDATE e DELETE de uma forma performática.

 1: USE STAGING

 2: GO

 3:

 4: IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[CATEGORIA_DESTINO_DELETE]') AND type in (N'U'))

 5: BEGIN

 6:     SELECT TOP 0 * INTO [dbo].[CATEGORIA_DESTINO_DELETE]

 7:     FROM [DW_EXEMPLO_DCD].[dbo].[CATEGORIA_DESTINO]

 8: END

 9:

 10: IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[CATEGORIA_DESTINO_UPDATE]') AND type in (N'U'))

 11: BEGIN

 12:     SELECT TOP 0 * INTO [dbo].[CATEGORIA_DESTINO_UPDATE]

 13:     FROM [DW_EXEMPLO_DCD].[dbo].[CATEGORIA_DESTINO]

 14: END

No pacote inclua o componente CDC Control Task com as seguintes configurações:

  • Crie ou configure uma conexao para o database de origem.
  • Configure o CDC Control Operation para Get processing range
  • Crie uma nova varial de estado (CDC_state)
  • Crie ou configure uma conexao para o database de destino
  • Selecion a tabela de estado que foi crianda anteriormente pelo pacote inicial ([dbo].[cdc_states])
  • Configure State name – Este nome deve ser igual ao que foi usado no pacote inicial (CDC_State)

clip_image008

Figura 5

Volte ao Control Flow e inclua um Data Flow e ligue-o no CDC Control Task;

Adicione um componente de CDC Source:

  • Configure a conexão para o database de origem;
  • Selecione a tabela [dbo].[CATEGORIA]. Nessa combo box irão aparecer apenas tabelas que estão habilitadas para o uso do CDC;
  • Configure o CDC processing mode para Net. Opção que busca apenas as alterações realizadas na tabela de origem;
  • Selecione a variável CDC_State;
  • Verifique a aba Columns para ter certeza que os dados estão sendo mapiados corretamente;

clip_image010

Figura 6

OBS: O CDC processing mode é a configuração mais importante aqui, pois cada modo de processamento terá um comportamento diferente que espera uma manipulação especifica.

Adicione o componete CDC Splitter.

Agora adicione 3 componetes ADO.NET Destination, um para nova linhas (Insert), outro para linhas atualizadas(UPDATE) e o ultimo para linhas exluidas (DELETE).

O componente para novas linhas (INSERT) você deve configura-lo para carregar diretamente a tabela [dbo].[CATEGORIA_DESTINO].

Os outros componentes devem ser mapeados para inserirem linhas nas tabelas [dbo].[CATEGORIA_DESTINO_DELETE] para linhas exluidas e [dbo].[CATEGORIA_DESTINO_UPDATE] para linhas atualizadas.

Agora o seu Data Flow deve estar parecido com a figura 7

clip_image011

Figura 7

Volte para o Control Flow e adicione dois componentes de Execute SQL Task. Um para realizar o UPDATE na tabela final e outro para realizar o DELETE na tabela final. Dessa maneira temos uma lote sendo executadas em cima de um conjunto de dados e não uma única linha sendo executada em um lote.

Abaixo segue os comandos de UPDATE e DELETE que utilizei.

 1: -- Update

 2:

 3: UPDATE dest

 4: SET

 5: dest.NOME_CATEGORIA = stg.NOME_CATEGORIA

 6: FROM

 7: [dbo].[CATEGORIA_DESTINO] dest

 8: INNER JOIN [STAGING].[dbo].[CATEGORIA_DESTINO_UPDATE] STG

 9: ON STG.ID = dest.ID

 10:

 11: -- Delete 

 12:

 13: DELETE FROM [CATEGORIA_DESTINO]

 14: WHERE ID IN

 15: (

 16: SELECT ID

 17: FROM [STAGING].[dbo].[CATEGORIA_DESTINO_DELETE]

 18: )

Por ultimo temos que atualizar nosso controle do CDC. Mais uma vez utilize o CDC Control Task para realizar essa tarefa e altera a opção CDC control operation para Mark processed range.

clip_image012

Figura 8

Inclui também um componente para limpar as tabelas do STAGING realizando um TRUNCATE nas tabelas.

O seu pacote deve estar parecido com a figura 9

clip_image013

Figura 9

Executando os Pacotes

Como já temos uma carga inicial com 3 registros vamos executar o pacote Inicial para realizar a carga.

clip_image014

Figura 10

Depois de executar o pacote Inicial podemos observar que a tabela cdc_states contem a seguinte informação.

clip_image015

Figura 11

Agora se executarmos o pacote incremental nesse momento não teremos nenhuma informação nova. Por isso vamos manipular alguns dados.

 1: USE EXEMPLO_CDC

 2: GO

 3: INSERT INTO dbo.CATEGORIA VALUES

 4: ('CATEGORIA 4')

 5: ,('CATEGORIA 5')

 6: ,('CATEGORIA 6')

 7: GO

 8: UPDATE dbo.CATEGORIA set NOME_CATEGORIA = 'CATEGORIA ALTERACAO 1'

 9: WHERE ID = 1

 10: UPDATE dbo.CATEGORIA set NOME_CATEGORIA = 'CATEGORIA ALTERACAO 2'

 11: WHERE ID = 2

 12: DELETE FROM dbo.CATEGORIA WHERE ID = 3

Depois de executar os comandos acima, vamos executar o pacote incrementar.

clip_image016

Figura 12

Fazendo uma consulta no seu destino podemos ver que os dados estao corretamente carregados de uma forma simples e eficiente.

clip_image017

Figura 13

Espero poder ajudar assim como o post original me ajudou. Eu literalmente traduzi e incrementei algumas coisas, mas os créditos são do Matt Masson. Para ver o post original acesse http://www.mattmasson.com/index.php/2011/12/cdc-in-ssis-for-sql-server-2012-2/

Obrigado!