We have had this issue before with the oracle RAC. There is a setting in oracle called "max_commit_propagation_delay" that must be set to zero. If not there will be a delay between all of the nodes when synchronizing data/schema changes. What was happening with us was that node 1 would get the update but because we had a load balanced connection it may query the data from node 3. Our dba had a delay set between the node synchronization. So we would query node 3 for the data and Remedy would not be able to find it.
It seems to me that this may be happening in your environment. Thanks, Sean -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Joe Martin D'Souza Sent: Sunday, October 16, 2011 4:13 PM To: [email protected] Subject: Re: Oracle-RAC and ARS Issues? John's note struck an odd thought.. What are the chances some developer has the wrong server configured to the wrong IP address on his host file on one of his laptop or PC he works from (If you'll or he is not using DHCP), thus sending some of the development to the wrong machine from one of them? Its unlikely anyone would do that mistake, but not an impossibility.. Joe -----Original Message----- From: John Peto Sent: Sunday, October 16, 2011 3:22 PM Newsgroups: public.remedy.arsystem.general To: [email protected] Subject: Re: Oracle-RAC and ARS Issues? Hi JD, I'd say RAC with one node running is very close to a stand alone db... Post restore I presume if you don't make any admin changes - the problem doesn't happen? If that's the case then it's got to be worth putting SQL logging whilst you make changes, and until the problem occurs. Either Remedy isn't issuing the full SQL statements, or the db is silently not applying them (both sound a little crazy). If Remedy is issuing the correct SQL, then I'm thinking that dev and test are getting mixed up, i.e. admin changes made on dev, some of the SQL goes to dev RAC, some goes to test RAC, Remedy wouldn't complain - niether would the respective dbs (initially) - The whole things sounds crazy, but it would only take a load balanced VIP to get messed up or a tns.ora update to go bad. There's many ways to check this at db level - but with no db support at all, I'd add a script to cron (assuming unix) to output netstat|grep 1521 to a file every few minutes and look for any IPs that aren't as per the tns entry for your SID. Since the problem is crazy - I'm hedging that the explanation is crazy :-) JP _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
