Eu tenho um pacote SSIS simples que carrega um arquivo fictício que contém 100.000 linhas. Cada linha tem cerca de 4k de comprimento, uma coluna int e uma coluna de texto longo. Estou tentando testar o TF610 ao carregar esses dados em uma tabela com um índice clusterizado.
No meu pacote SSIS, meu fluxo de controle tem uma tarefa Executar SQL para habilitar o TF610 e, em caso de sucesso, vá para minha tarefa de fluxo de dados que carrega o arquivo simples na tabela. Ambos os Destinos Executar SQL e OLE DB usam a mesma Conexão.
Se eu iniciar um perfil durante a execução do pacote SSIS e observar os comandos, posso ver DBCC TRACEON(610) executado e as operações INSERT BULK começam a ser disparadas. Ambos estão usando o mesmo PID, então estou assumindo que é a mesma sessão.
Porém, quando verifico o comprimento do registro de log, a inserção NÃO está sendo minimamente registrada.
Se eu habilitar o TF610 globalmente e executar o mesmo pacote SSIS, embora a transação seja minimamente registrada.
Devo estar fazendo algo errado ao ligar o TF610 no meu pacote SSIS mas não consigo descobrir o que...
E assim, para forçar a mesma sessão a ser usada, em seu gerenciador de conexões, nas configurações de Propriedades, você pode definir
RetainSameConnectionparaTrueforçar uma única conexão para seu pacote em vez de usar um pool.Só porque está reutilizando o mesmo ID de sessão não significa que seu sinalizador de rastreamento ainda está definido. Se o SSIS foi desconectado e reconectado, ele pode obter o mesmo SPID, mas não é mais a mesma sessão. Posso reproduzir isso facilmente no SSMS abrindo uma nova janela de consulta, definindo o sinalizador de rastreamento e fechando rapidamente a janela e abrindo uma nova (obtenho o mesmo spid). Quando verifico o sinalizador usando
DBCC TRACESTATUD(610);, ele não está mais definido.Você pode ter que encontrar uma maneira de definir o sinalizador de rastreamento dentro da tarefa de fluxo de dados ou defini-lo globalmente durante o pacote.