We have a scheduled nightly import that kicks off at just about midnight. Last night the ETL was kicked off while another import was still in progress. Now both appear to be hung
DSS-SAM console shows this- (slightly modified to remove timestamp data)
Logfile created on *******
ETL is already running
And the log file of the ETL that was running is stopped at the
Warehouse: loading computer dimension
just prior to the final bulkload
Is there a way to manually stop the ETL that was kicked off automatically?
Use the task manager to kill the etl.exe process. If etl.exe doesn’t appear in the list or if killing it doesn’t resolve your problem, kill the ruby.exe processes. If that doesn’t resolve it, you might have to restart your server. If that’s not possible, you can contact customer support and they should be able to help you.
I am trying to better understand how the Scheduled Imports function, as I am still having issues with them. We were able to clear the 2 hung imports and manually start a new import last Friday. However, the regularly scheduled imports that had been functioning are no longer working. Last night I was running an import and watching processes in the Task Manager. I saw the ETL.exe running for a while and using a lot of CPU, but maybe a 1/4 of the way through the import it simply goes away from the running processes. I didn’t stick around through the entire import (it took 7+ hrs to complete) to see if it ever comes back.
The other thing I noticed is that while viewing the scheduled task in an explorer window while the import is running, the “Status” column will briefly show “Running” then go blank. I am assuming that this is due to whatever Schedule is set up on the task, i.e. My task is scheduled “Every 10 minutes” for 3 hours every day, so for 3 hours the task checks to see if it is running, displays that it is running, then sleeps for the scheduled time and checks again. But if it is checking the task to see what state it is in- why would it not run it if it is past the start time, and the schedule sees that it is not running?
Any insights/ details I can read up on relating to into how this scheduled import functionality works would be appreciated.
I think you should open a PMR to try to diagnose what appears to be two issues: 1) hanging imports, 2) scheduled task no longer working. It seems like some sleuthing is going to be needed trace the issues in your environment. Our support team can help.
In the meantime, here’s a bit of info to clarify the process…
Import is a multi-stage process triggered by a manual click on the Run Now button or automatically at the scheduled time. The Windows scheduled task is set to run a batch script every 5 minutes, which simply checks the TEM SUA import schedule. If it’s time to run the import, then the batch script kicks off few things, starting with the ETL.exe, which orchestrates the connection to the core TEM server database (BFEnterprise) and TEM server file system (typically the Upload Manager directory where the results of the SAMScanner files are stored) and grabs the data it needs and places it into local temp files on disk on the TEM SUA server. From there, scripts process the files, for example, creating rollups in the TEM SUA database, correlating to the TEM SUA catalog, etc. The scheduled task only needs to trigger the batch file, which will only trigger the ETL if the schedule says to. The ETL.exe might not run the entire time the import because there are ruby scripts that do a lot of the file processing work.
Hope that helps, but feel free to get a support case open so we can help with your specific issues.
So it sounds to me like you are saying there is an issue with the windows scheduled task somehow not getting the correct information from the TEM SUA scheduled time that it is time to run. On the Windows side of things I can log into the box, open the scheduled task and see that it will show a “running” status, but that never seems to translate into the import getting kicked off. I can manually click the “Run Now” button in the console, and the import runs just fine, so I know that is working. I am going to tweak a couple of parameters and see what happens tonight.