Notifications
Clear all
Topic starter
For the last several weeks on Thursday mornings our DTS stalls with Unexpected Fatal Database Errors. After much trouble shooting and verification of other services that may be interferring we have not found resolution to this issue. The files coming in have and additional file labeled Pending Dispersal.
Adding to the difficulty of resolving this issue, it only occurs on Thursday am around 6:00 EST. We have checked other services and functions that might be occurring at this time and have scheduled them earlier or later but this does not resolve the issue.
ANY THOUGHTS?
Posted : May 3, 2012 6:07 am
You've probably already checked this but the most likely causes are your database actually restarting itself (would show in the alert log and highly unlikely as it would disonnect your EMR users for the most part) or a network hiccup that is causing a call from DTS to your database to time out and DTS to register it as a disconnect.
Posted : May 3, 2012 7:41 am
These are good thoughts that I will pass on to our IT guys. They have likely checked this but perhaps not. Since this error seems to occur only once a week and early in the morning before any users are logged in, it is possible because no one would be around to notice the disconnect. Thanks.
Posted : May 3, 2012 8:50 pm
sounds like your EMR server database is restarting. if your IT team have windows update setup for every Thursday. This is most likely the reason. IF emr database goes down, DTS will give you a fatal error when failing to reach the EMR database
We have our DTS set to go down before any of our scheduled Database downtime and to come backup automatically after the Database has been mounted back.
I can help you will this. just let me know.
Posted : May 7, 2012 9:07 pm
Thank you for your response. We have checked for all scheduled tasks being performed around this time and moved them to another time so not to conflict. IT continues to check logs to see if anything is updating that is causing the database to restart but they have not found anything. I am passing on your response to them to see if they are stoppong the DTS before scheduled database downtime. They may already be doing this but I think this is an excellent suggestion so if they are not, they should be. Thanks again.
Posted : May 8, 2012 7:06 am
Thank you everyone for your response to this post. They were very helpful. I would like to add that we have found our "smoking gun". It took weeks of intense sleuthing. The culprit was a job that V.O.W had set to run every Thursday morning at 6:00am. This could not be seen by our IT team and was not reported by V.O.W. when asked if they were running anything. This service was affecting the Centricity Database which was then causing the DTS to error making it unable to disperse the files. This job was consistently running for about 40 minutes every Thursday morning and was undetected by anyone but V.O.W. Until the DTS was reset, none of the files coming via DTS would resolve. This ended up affecting other processes as well. Like most of you we suspected some type of scheduled service was causing the issue from the beginning. Unfortunately the lack of full disclosure about this service from V.O.W. wasted much time and money looking for other sources of the issue. If anyone else finds themselves in this situation, I would be happy to pass your contact information on to our IT staff to give you more detail on the resolution of this issue. Thanks again for your help and support CHUG!
BTW:The SQL job is called “Truncate CPS” with a description of “Truncate WorkSta, LogLocks, AppSession tables.”
Posted : May 18, 2012 6:38 am
