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"


CONFIDENTIALITY NOTICE: 
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of 
the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify 
us immediately at 262-703-7000.

CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the 
right to retrieve and read any message created, sent and received.  Kohl's 
reserves the right to monitor messages by authorized Kohl's Associates at any 
time
without any further consent.

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to