Susan,
I'm certainly not implying that you haven't looked here, but you didn't' mention whether or not you've looked at your escalations or escalation log. I've had escalations cause a cascading effect that was recurring and hard to catch. Gp George Payne Assistant Director, User Services Information Technology Services University of Texas at Austin 512.232.7513 ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Monday, July 02, 2007 10:16 PM To: arslist@ARSLIST.ORG Subject: Re: ARS 7.0.1P2 arerror 94 - database timeouts Susan, I would look at interactions between Remedy and other applications and/or plugins with things like LDAP. If your plugins were locking up threads (i.e. waiting for connection or response, timing out, etc.), it seems like that would cause your thread count to increase. I don't remember what version of ARS you upgraded from, but it's possible that API parameters have changed between that version and 7.x. Rick ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer Sent: Monday, July 02, 2007 7:43 PM To: arslist@ARSLIST.ORG Subject: ARS 7.0.1P2 arerror 94 - database timeouts ** Hi everyone, Upgraded to ARS v7.0.1P2 last Wednesday. Went remarkably well, although we didn't attempt to do Approval, Assignment or Flashboards at this time. We did do the mail engine which we haven't done anything with. Since we upgraded near two times a day (except Sat/Sun) the threads to the database increase from a normal 7 to 15 within a 5 min period (likely less) and we reach a point where we get error 94 database timeout errors. We restart the AR Server services and everything goes back to normal. I do have an open support ticket and we really don't want to go there. So I'm trying to figure out what could be causing it. We did develop 343 errors after the install and I've been trying to fix them (filter action count errors). Of course everything is not going as described in the KB that was provided. One thing I've found interesting is that on Thur, Fri and Mon this phenomena occurred between 3:30-4:00 pm. So I've looked through the sql logs looking for clues. No errors in the arerror.log before the timeout occurs. There's been about the same number of users on each time, but that same number has been basically been working all day. It's not like it is a slow build up, say a new thread added every 5 minutes, its like zoom they're added. It is only LIST threads, the FAST threads remain steady with no increase. There's no unusual queries going on from what I could see in the sql logs. No changes were made to the application, its HD V5.0 customized about 85%. I'm told there's no errors in the Oracle 10g logs. We did the upgrade from 9 to 10 last Wednesday also. Although I don't know where to look its probably something I should poke around in. It almost seems to me like something happens to the connection to the database which is on a SAN. But I don't know how to show that. Of course, everyone points to Remedy. What I find odd is that a restart of services takes everything immediately back to normal. I've seen in the arerror.log occasional thread drops but they appear to be directly related to the 343 errors and are at different times, not even near the db timeout occurrences. So if anyone has seen anything like this or has another perspective I'm not looking at, I'd appreciate your help. Thanks in advance, Susan Susan Palmer ShopperTrak ARS 7.0.1P2 Oracle 10g Windows 2003 __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
