Usuário com melhor resposta
Executanto Pacote do Integration Service via Aplicação

Pergunta
-
Tenho um Package no Integration Services onde inicialmente passava parâmetros via procedure e realizava a chamada por lá. Ao fazer isso a execução da procedure demorava em média 5 minutos, o que achei muito pois quando executo manualmente o integration ele demora em média 40 segundos.
Sendo assim resolvi chamar via aplicação para ver se o retorno é mais rápido, achei alguns exemplos onde se utilizam a DLL Microsoft.SQLServer.ManagedDTS.dll e utilizo o seguinte código :
Dim pkgLocation As String
Dim pkg As New Package
Dim app As New Application
Dim pkgResults As DTSExecResult
pkgLocation = _
"\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\" & _
"Package.dtsx"
pkg = app.LoadPackage(pkgLocation, Nothing)
pkgResults = pkg.Execute()
Console.WriteLine(pkgResults.ToString())
Console.ReadKey()Quando executo as classes Package, Application e DTSExecResult elas perdem referência. Alguém pode me ajudar?
Esta é a minha primeira pergunta aqui! espero que esteja fazendo de maneira correta e no lugar correto! rsrs
Muito obrigado!
sexta-feira, 12 de julho de 2013 20:40
Respostas
-
Entendi, no caso quando você fala pra eu processar isso diretamente no SQL Server é para eu deixar de fazer as importações pelo Integration e fazer via SQL mesmo?
Porque queria desvincular esse processo da importacão, pois quando eu faço via aplicação ela fica esperando um retorno do sql travando a aplicação.
Então queria deixar a aplicação livre para uso enquanto os arquivos vão sendo importados.
Ai estou tentando chamar o pacote via aplicação para desvicular do SQL para ver se é mais rápido do que o retorno da XP_CMDShell
Muito obrigado!
- Marcado como Resposta Junior Galvão - MVPMVP, Moderator quarta-feira, 29 de janeiro de 2020 13:45
quinta-feira, 18 de julho de 2013 17:50
Todas as Respostas
-
Tenho um Package no Integration Services onde inicialmente passava parâmetros via procedure e realizava a chamada por lá. Ao fazer isso a execução da procedure demorava em média 5 minutos, o que achei muito pois quando executo manualmente o integration ele demora em média 40 segundos.
Sendo assim resolvi chamar via aplicação para ver se o retorno é mais rápido, achei alguns exemplos onde se utilizam a DLL Microsoft.SQLServer.ManagedDTS.dll e utilizo o seguinte código :
Dim pkgLocation As String
Dim pkg As New Package
Dim app As New Application
Dim pkgResults As DTSExecResult
pkgLocation = _
"\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\" & _
"Package.dtsx"
pkg = app.LoadPackage(pkgLocation, Nothing)
pkgResults = pkg.Execute()
Console.WriteLine(pkgResults.ToString())
Console.ReadKey()Quando executo as classes Package, Application e DTSExecResult elas perdem referência. Alguém pode me ajudar?
Esta é a minha primeira pergunta aqui! espero que esteja fazendo de maneira correta e no lugar correto! rsrs
Muito obrigado!
domingo, 14 de julho de 2013 14:41 -
Alfeu,
O que voce diz com perder a referencia? Creio que essa duvida seja de programação (Conhecimento minimo) e não consegui compreender.
Em relação ao pacote, tente colocar um debug no meio do mesmo fazendo um insert em uma tabela. Uma duvida, como está o ProtectionLevel de seu pacote?
Fabrizzio A. Caputo
Certificações:
MCT
MCC
Oracle OCA 11g
MCTS SQL Server 2008 BI
MCITP SQL Server 2008 Implementation and Maintenance
MCITP SQL Server 2008 Developer
ITIL V3 Foundation
Blog Pessoal: www.fabrizziocaputo.wordpress.com
Email: fabrizzio.antoniaci@gmail.comsegunda-feira, 15 de julho de 2013 11:42Moderador -
Quando digo perdendo referência é quando eu executo o projeto e as classes Package, Application e DTSExecResult
não são mais reconhecidas pelo projeto. E onde eu crio objeto dessas classes eu nao consigo usar, como no caso onde exemplifiquei com o código à cima.
Estou tentando chamar o package do integration via aplicação porque fiz via procedure e achei muito lento o retorno. É normal isso?
Muito obrigado!
segunda-feira, 15 de julho de 2013 13:06 -
Alfeu,
Quanto a perder as referencias, creio que o pessoal de dev deve te ajudar melhor ou alguem que tenha um certo conhecimento sobre o assunto.
Impossivel dizer se via procedure é mais lento ou rapido, depende de sua programação, do que esta sendo feito na proc ou no pacote, o estado do servidor. Proc não é mais rapida nem mais lenta que o pacote, existem muitas variáveis que podem fazer com que seja melhor ou pior.
Fabrizzio A. Caputo
Certificações:
MCT
MCC
Oracle OCA 11g
MCTS SQL Server 2008 BI
MCITP SQL Server 2008 Implementation and Maintenance
MCITP SQL Server 2008 Developer
ITIL V3 Foundation
Blog Pessoal: www.fabrizziocaputo.wordpress.com
Email: fabrizzio.antoniaci@gmail.comsegunda-feira, 15 de julho de 2013 13:14Moderador -
Sim, eu concordo com você. Quando eu executo no pacote ele demora cerca de 30 segundos. Quando executo na procedure ele demora cerca de 5 min.
SELECT @FILENAME = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\Arq_Mov_Entr_RF',
@CAMINHOARQUIVO = (select DESC_CAMINHO from [AUX].[TB_ARQUIVOS_IMPORTADOS_TESTE] WHERE IDARQUIVO = @idarquivo),
--@CAMINHOARQUIVO = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\ENT_00292858000258_072012.txt',
@strLocation = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\'
SELECT @Cmd = 'DTexec /FILE "' + @strLocation + 'Package.dtsx" /MAXCONCURRENT 1 /CHECKPOINTING OFF /REPORTING EW' + ' /SET \Package.Variables[User::FileName].Properties[Value];' + @FILENAME + ' /SET \Package.Variables[User::IDARQUIVO].Properties[Value];' + CONVERT(VARCHAR(20),@idarquivo ) + ' /SET \Package.Variables[User::NomeArquivo].Properties[Value];' + @CAMINHOARQUIVO
EXEC @ReturnCode = xp_cmdshell @CmdÉ só isso que eu faço dentro da proc.
Vou postar também essa pergunta para o pessoal de DEV.
Obrigado Fabrizzio!
segunda-feira, 15 de julho de 2013 13:41 -
Alfeu,
Para termos um melhor posicionamento, por gentileza, você poderia pegar o código que esta utilizando e rodar dentro do Management Studio?
Pois se através do Package não esta tendo problemas, eu entendo também que em relação ao SQL Server não temos problemas, ao meu ver o que esta acontecendo é o tempo de resposta para que o XP_CMDShell leva para retornar para a sua procedure dentro da aplicação.
Um detalhe porque você esta atividando o MaxConcurrent?
Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
terça-feira, 16 de julho de 2013 21:09Moderador -
CREATE PROCEDURE [dbo].[TESTE] --@strLocation VARCHAR(500),
@idarquivo int
/*
Exec TESTE @idarquivo = 35
*/
AS SET NOCOUNT ON
DECLARE @Cmd VARCHAR(4000),
@ReturnCode INT,
@Msg VARCHAR(1000),
@CAMINHOARQUIVO VARCHAR(500),
@FILENAME VARCHAR(500),
@strLocation VARCHAR(500)
--SELECT @CAMINHOARQUIVO = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\072012.txt'
SELECT @FILENAME = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\Arq_Mov_Entr_RF',
@CAMINHOARQUIVO = (select DESC_CAMINHO from [AUX].[TB_ARQUIVOS_IMPORTADOS_TESTE] WHERE IDARQUIVO = @idarquivo),
--@CAMINHOARQUIVO = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\ENT_00292858000258_072012.txt',
@strLocation = '\\Brsaopmeysql03\Clientes\CAT_Valida_Layout_Mov_Entrada\CAT_Valida_Layout_Mov_Entrada\'
--SELECT @CAMINHOARQUIVO '@CAMINHOARQUIVO'
SELECT @Cmd = 'DTexec /FILE "' + @strLocation + 'Package.dtsx" /MAXCONCURRENT 1 /CHECKPOINTING OFF /REPORTING EW' + ' /SET \Package.Variables[User::FileName].Properties[Value];' + @FILENAME + ' /SET \Package.Variables[User::IDARQUIVO].Properties[Value];' + CONVERT(VARCHAR(20),@idarquivo ) + ' /SET \Package.Variables[User::NomeArquivo].Properties[Value];' + @CAMINHOARQUIVO
EXEC @ReturnCode = xp_cmdshell @Cmd
IF @ReturnCode <> 0
BEGIN
SELECT @Msg = 'ERROOOO'
--EXEC msdb.dbo.sp_send_dbmail @recipients = @EmailAddress ,
-- @body = @Msg, @subject = 'SSIS Execution Failure'
ENDJunior é exatamente isso, o retorno dessa procedure demora demais. Sendo que no integration vai muito rápido.
Não sei se essa demra é normal, não sei se é melhor fazer via aplicação.
Esse Maxcurrent eu sinceramente não sei nem pra que que serve. Eu nunca tive a oportunidade de fazer nada no integration, então to fazendo e apanhando, ai peguei isso de um script da internet.
Muito obrigado pela ajuda!
quinta-feira, 18 de julho de 2013 14:36 -
Alfeu,
Entendo que via aplicação você estará sempre dependendo do retorno do XP_CMDShell para o SQL Server e posteriormente do SQL Server para aplicação.
Talvez uma grande possibilidade é processar isso diretamente no SQL Server.
Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
quinta-feira, 18 de julho de 2013 17:25Moderador -
Entendi, no caso quando você fala pra eu processar isso diretamente no SQL Server é para eu deixar de fazer as importações pelo Integration e fazer via SQL mesmo?
Porque queria desvincular esse processo da importacão, pois quando eu faço via aplicação ela fica esperando um retorno do sql travando a aplicação.
Então queria deixar a aplicação livre para uso enquanto os arquivos vão sendo importados.
Ai estou tentando chamar o pacote via aplicação para desvicular do SQL para ver se é mais rápido do que o retorno da XP_CMDShell
Muito obrigado!
- Marcado como Resposta Junior Galvão - MVPMVP, Moderator quarta-feira, 29 de janeiro de 2020 13:45
quinta-feira, 18 de julho de 2013 17:50 -
Alfeu,
Isso mesmo, tente implementar este procedimento diretamente no SQL Server, trabalhando com sua Stored Procedure direto no Banco de Dados, procurando até mesmo eliminar o uso do xp_cmdshell e se for o caso trabalhar com o Jobs para realizar importação dos dados através do comando BCP.
Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]
quinta-feira, 25 de julho de 2013 13:37Moderador