Just an FYI, that parameter is obsolete in Oracle 11g R2. Tauf Chowdhury | Forest Laboratories, Inc. Service Portfolio Manager Infrastructure – Service Management Office: 631.858.7765
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Garrison, Sean (Norcross) Sent: Monday, October 17, 2011 9:40 AM To: [email protected] Subject: Re: Oracle-RAC and ARS Issues? 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" ********************************************************************** This e-mail and its attachments may contain Forest Laboratories, Inc. proprietary information that is privileged, confidential or subject to copyright belonging to Forest Laboratories, Inc. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
