Hi we have a SSIS package that calls an execute process task.
The task accesses a saved sql file in the directory, the agent that runs our task does have permission to access all these files. Yet when the package is executed it hangs at the execute process task, no processes are running but the package still is, all the previous tasks complete successfully until it reaches the execute process task
Hi if anyone is looking for the same problem we came across the answer, the cmd window required user input and therefore could not continue with the process until the cmd process task has finished and it never does.
So in short make sure your cmd process doesnt require user input if you are deploying to SSISDB or it will hang and you cant do anything about it
Related
SSIS package is scheduled to run at a particular time. If files before the scheduled time, the load goes fine, but when file arrived late, the package fails showing error message
Process cannot access the file because it is being used by another process
Trap that specific error in the error handler, and if it occurs, have the job/package wait a while and try again until it no longer gets the error.
I have an SSIS package which has a connection to a database. I took the database down to test a scenario, but the package gives me the following error in the output window when starting the package when the DB is offline:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "DBNAME" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
I need to check the connection when the package is run and notify a user, via email, that the DB is down. How would I go about doing this?
I have the code to send the email, I just need to do the DB check when the package is run.
Use a script task. Try to open a connection to your database and if it fails then Dts.TaskResult = Dts.Results.Failure.
A great post about this issue here :
http://social.msdn.microsoft.com/Forums/sqlserver/en-US/7de0216b-3a0a-40ce-8149-f566a05010c9/ssis-check-database-connection-and-if-disconnected-send-email-alert?forum=sqlintegrationservices
Make your DB check occur outside of your package. How is the package run? Scheduled in SQL Agent or kicked off by the user? Instead of just running DTEXEC, first run a script that checks connectivity, i.e. using SQLCMD.EXE.
But really a better way is to run the package as normal then check the SSIS logs afterwards and send an appropriate message. Otherwise you'll be cooking up all different kinds of custom pre-execution checks to run.
I'm no batch script expert but here's an example of a bit of code you can use to test connectivity to a SQL Server and call another batch script if it fails, otherwise run the package with DTEXEC.
SQLCMD -S YOurServer -E -Q "SELECT ##VERSION"
IF ERRORLEVEL 1 (
CALL YourEmailScript.CMD
)
ELSE
(
DTExec /f "\\pathtodtsxfile\file.dtsx"
)
This is not production quality code. I would not recommend calling your DTEXEC in this way, it's just an example.
I finnally got it working. What I did was, create an XML file with the database settings, data source, initial catalog etc. Then added a script task, added some code to read the settings from the XML file and create a SQLConnection and connect to the DB in a try catch. If there is an error send an email, and in the finnaly closed the SQL connection.
But to get this working you HAVE to ensure that you connection has the property 'DelayValidation' set to TRUE. If not the package will fail to aquire a connection before the script task gets executed.
A strange thing is happening in SSIS 2008. I have a script component where I set a value for a user variable. The script does what it has to do and then SSIS stops running. All components turn green, so there is no error. The next component that needs to run is the execute process task where I use a CMD command to copy files (XCOPY). If I run the CMD command directly under a command prompt, it works.
Do I neeed to set some properties of the script component in order that it can go through the next component?
No there is no constraint.
My SSIS package executes 32 bit windows executable from Execute Process task. This runs fine when package is run from BIDS. But when i trigger this package from SQL Agent job it fails with error "The process exit code was "255" while the expected was "0".
I have made sure that "Run As" account for SQL Agent job has full permissions to required paths. I have also tried running SQL Agent job with 32 bit run time. Also on package level I have set Run64BitRuntime to false. But nothing helped.
I have a problem with a hang using xp_cmdshell.
The executable is called, performs its work, and exits. It is not hanging because of a ui prompt in the exe. The exe is not hanging at all. The exe disappears from the process list in task manager, and internal logging from the exe confirms that it executed the very last line in the main function
the call to xp_cmdshell does NOT return control in SQL. It hangs on that line (it is the last line of the batch). Killing the process is ineffective. It actually requires a restart of sql server to get rid of the hung process (ugh)
The hang only happens the first time it is run. Subsequent calls to the procedure with identical parameters work and exit correctly so long as the first one is hung. Once SQL is restarted, the first subsequent call will hang again.
If it makes any difference, I am trying to receive the return value from the exe -- my sql procedure ends with:
exec #i = xp_cmdshell #cmd;
return #i;
Activity Monitor is reporting the process to be stuck on a wait type of PREEMPTIVE_OS_PROCESSOPS (what the other developer saw) or PREEMPTIVE_OS_PIPEOPS (what I'm seeing on my current testing)
Any ideas?
Just came across this situation myself where I've run an invalid comment via xp_cmdshell.
I managed to kill it without restarting SQL, what I've done was to identify the process that run the command and kill it from Task Manager.
Assume your SQL was running in Windows 2008 upward:
Under Task Manager, Processes tab. I enabled the column to show Command Line of each process (e.g.: View -> Select Columns..).
If you unsure what command you've run via xp_cmdshell, dbcc inputbuffer(SPID) should give you a clue.
We had the same issue, with SQL Server 2008, also with calls involving xp_cmdshell and BCP. Killing the sql process ID didn't help, it would just stay stuck in "KILLED/ROLLBACK" status.
Only way to kill it was to kill the bcp.exe process in Windows task manager.
In the end we traced the issue down to wrong SQL in sproc that was calling the xp_cmdshell. It was by mistake opening multiple transactions in a loop and not closing them. After BEGIN/COMMIT trans issues were fixed, PREEMPTIVE_OS_PROCESSOPS never came back again.
We actually did eventually figure out the problem here. The app being called was used to automatically dump some documents to a printer when certain conditions happened.
It turns out that a particular print driver popped up a weird little window in the notification tray on a print job. So it was hanging because of a ui window popping up -- but our app was exiting properly because it wasn't our window, it was a window triggered by the print driver.
That driver included an option to turn off that display window. Our problem went away when that option was set.