Both systems were set to force in the init.ora file to answer the original question. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157
________________________________ From: Action Request System discussion list(ARSList) on behalf of Tony Worthington Sent: Wed 4/9/2008 2:09 PM To: [email protected] Subject: Re: Database cursor sharing ** Sorry -- I usually reference my source. :-) Guess I wasn't thinking rtfm... lol White Paper Oracle's Cursor Sharing for BMC® Remedy® Products January 2007 *67831* -- Tony Worthington Sr. Technical Analyst Kohl's Department Stores [EMAIL PROTECTED] 262-703-5911 William Rentfrow <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 04/09/2008 01:50 PM Please respond to [email protected] To [email protected] cc Subject Re: Database cursor sharing ** I'm checking this...what document is this from? The server config guide? ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tony Worthington Sent: Wednesday, April 09, 2008 1:24 PM To: [email protected] Subject: Re: Database cursor sharing ** Strange that it would alter to both exact and force when having the system set to force in one operation. Are you seeing the alter sessions right next to each other or are there various inserts in between? Exact is used when inserting into long raw. Have you verified that both of your awr reports are reporting the same values in the init.ora section? I know you mention you've checked a gazillion times ... but it might be in the spfile and not be recognized by the db. We've also had cursor sharing changes not stick over db restarts. init.ora Parameters Parameter Name Begin value End value (if different) ----------------------------- --------------------------------- -------------- cursor_sharing FORCE ---- "Inserts into a Long Raw column while cursor_sharing is enabled can cause the BMC Remedy Action Request System® (AR System®) server thread to hang. Such inserts are commonly done as part of the Email Engine activity when attachments are included in email messages. To avoid any impact from this issue, AR System server code explicitly disables cursor_sharing (that is, sets it to exact) when doing such an insert into a Long Raw column. However, it first needs to know that the current setting is not already exact. To get the current setting, the AR System server looks in the ar.conf file, where the cursor_sharing setting must be set to reflect the init.ora settings from Oracle. If the ar.conf file does not reflect the init.ora settings, then the AR System server assumes the value is already exact and, therefore, will not reset it when doing inserts into Long Raw columns. ---- -- Tony Worthington Sr. Technical Analyst Kohl's Department Stores [EMAIL PROTECTED] 262-703-5911 William Rentfrow <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 04/09/2008 01:15 PM Please respond to [email protected] To [email protected] cc Subject Database cursor sharing We have two systems - both on Solaris logical servers, both on the same box. Both have remote Oracle databases. (7.1 001 for Solaris w/Oracle, IM 7.03) Dev = faster response time (saving an Incident takes 9 seconds) QA = very slow response time (saving an Incident takes 65 seconds). These two systems are - as far as we know - identical. However, when debugging the system we have found that the fast (dev) system is executing the following oracle server side parameters during a save: ALTER SESSION set CURSOR_SHARING = EXACT ALTER SESSION set CURSOR_SHARING = FORCE This is NOT happening on the QA server. Both servers have the "Oracle-Cursor-Sharing: FORCE" parameter set in the ar.conf file and the corresponding appropriate setting is established in Oracle (and we've checked these like 9000 times). Anyone know what setting/config would make Remedy do this to Oracle? William Rentfrow, Principal Consultant [EMAIL PROTECTED] C 701-306-6157 O 952-432-0227 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
