Lately, we’ve had an issue with our source/target database server being shutdown unexpectedly. After the server comes back up and the database comes back online, the first call to a realtime service that was started prior to the DB server restart will fail. After the failure, the realtime service will restart and every call after that is successful.
Has anyone dealt with this? I think it makes sense that a realtime service establishes connections to it’s source and target databases upon startup. When either the source or target database is restarted, this connection probably becomes invalid. If this is true, is there any workaround?
If it is just one failure and then it restarts itself and runs fine, to me that is a workaround right there. I don’t think you are going to get any better than a single failure after an unexpected DB shutdown.
I’m of the same school of thought as far as not worrying too much about this one error. Unfortunately, this occurs in a system with four realtime jobs (each sending an email to many people upon failure). Each maintenance weekend (every two weeks) this machine is shut down and these four emails go out to the entire distribution list forcing me to not only re-send each of the realtime messages that failed, but answer questions as to what the failures were.
Am I at least correct in thinking that this database shutdown is causing the errors? Up to this point, this has just been a hunch.
My suspicion would be yes, based on experience with batch jobs. If I lose connection during a job it typically fails with either a TNS error or a generic connectivity error. Of course, my repo is on the same physical box as the target, so it might be different for you. Can you trap the specific type of error and cause the job to fail silently if it is a certain error and during a certain period? Or how about setting a “downtime” table up and have the RT jobs stop at the beginning of it and restart after it should be up again?
We currently have a stored procedure that runs upon startup of the DB server which calls each of these four realtime jobs with a generic message that I trap. We think this has been working, but apparently that isn’t a viable option for us anymore.
I love your idea of a “downtime” table. Can you start/stop a realtime service based on dates in a table?
You can’t directly start and stop real time jobs via a table, but if you have a scheduler on the DB you can wake it up, check a table and send messages or the like. Not an ideal solution, but better than a hard shutdown due to error conditions. Perhaps someone with lots of RT job experience could chime in with how they handle it?
Yes, this is a script at the end of each realtime job.
I think I know the answer to this, but were there any updates in 3.1 to address this issue? I guess the better question is after we upgrade, will we still need to use these stored procedures to force a restart of the realtime service?
I have similar issues, but in that case I can’t resend the message in order to be processed because the source message is an IDOC that has sent directly from SAP system…
In the SAP side, IDOC is on green, but Data Services didn’t processed due to a data base restart.
There is any correction on Data Services 4.X to solve this issue?
(BOB member since 2007-03-01)
(BOB member since 2004-12-17)
(BOB member since 2006-11-13)