1 of 1 people found this helpful
I used to get this error message when run the ETL first time. To overcome,
There should be stop_etl.nsh, run this command:
stop_etl.nsh -s 1 -v 81
Change -v to exact verion.
Quick method is to reboot the reporting server and rerun the ETL, it should work fine.
Which version of BDSSA are you using ?
Could you try stopping the Blreports process and then stop and start the ETL script.
Have you logged into the Metadata Navigator to see if there are any running sessions and/or errors?
Siddu's suggestion of running the stop_etl.nsh script is the best one. The order of steps I would suggest are:
1. log into metadata navigator
2. drill down into the failed domains (look for the red stop sign)
3. check errors starting at the lowest level into the drill down. Many of these should be in the KB, based on the message you supplied we already know what it is.
4. run stop_ETL.nsh (stop_ETL.nsh -s1 -v 81/82/83 (depending on BSA version))
5. search on reports server for LCK files, these should be removed by the stop_ETL.nsh script, but always good to check.
Hope this helps and have a great day!
Can you please provide an updated status on this issue with your ETL?
Thanks for all the respond
I have tried rebooting both the app server and the reporting server
But still got the same behavior
I am working on 8.2.03
So i tried running the stop script directly on the reporting "stop_etl.nsh -s 1 -v 82"
I killed any process names nsh or java (the java kept coming back)
and yet the Run ETL is still failing complaining another instance of run_etl is running
I am unable to login to te Metadata Navigator as i have no idea what the BL_READERuser password is
I will see if i can find it somehow
Is there a way to change it ?
Also where should i check for any lock files ?
you can reset the BL_READER password by doing this:
(this is in the context of the 'blrptadmin' utility)
is the stop etl actually successful ? what is the output of that run ?
After you change the BL_READER password, please let us know what scenario if is failing on. There is a lck file, but the proper way to deal with that is by using the stop_etl.nsh script on the reports server, manually deleting the lock file will not handle the database changes that need to be done.
What type of DB do you have? Oracle or SQLServer?
The stop script end successful (when i am running it locally):
ddapsbbdsap01% stop_etl.nsh -s 1 -v 82
Site Id: 1
OM Version: 82
Navigating to ETL path...
Navigating to ETL path - Completed.
Removing orphaned exstat files.
Finished removing orphaned exstat files.
Checking lock file for Site Id: 1
Lock file props.lock does not exist.
USER ACTION REQUIRED:
Please terminate any run_etl processes and its related processes for site id: 1
You may use windows Task Manager for the same.
Likely processes could be those with image name nsh.exe and java.exe.
Please exercise caution while terminating the processes, to ensure that this
current session is not terminated.
Terminated all ETL related system processes (Y/N)? :y
You have entered: Y
Proceeding with Stop ETL
Proceeding with Database Reset.
Stop ETL is successful.
It keep failing as a job in blade with the same output (as if it is waiting for my respond)
I changed the password , and most of the list is green
Only failures i can see are :
JOB_PROPERTY SUPERVISOR 19/04/2013 03:03:08 19/04/2013 03:03:11 7000 2.0
3_PROPERTY SUPERVISOR 19/04/2013 03:02:54 19/04/2013 03:03:13 50000 18.0
0_BSARA_ETL SUPERVISOR 19/04/2013 03:00:13 19/04/2013 03:14:10 50000 836.0
so i relized each is a chile of the other
The message of the JOB_PROPERTY failure was :
java.lang.Exception: Error: No value to affect to this variable for DefDate:2011-04-28 11:46:47.0
Can you drill down further into this scenario? There is most likely additional information that we'll need further down.
I worked with Tal in a webex and determined that there was an old LCK file that had been renamed but the extension was left LCK. After renaming the file to .lck.old, we ran the stop_etl.nsh, got a clean stop and then ran RBAC.properties ETL successfully.
Alan was able to locate a unwanted LCK file
And things back to normal