cursor_sharing=similar grief on 10.1.0.3 / win32

  • From: Paul Drake <bdbafh@xxxxxxxxx>
  • To: oracle-l <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 18 Feb 2005 19:13:29 -0500

10.1.0.3 EE on w2k3 EE (32 bit)
dual 3.6 GB Xeon, hyperthreading enabled.
8 GB mem

had cursor_sharing=exact ... was trying to get by without resorting to
setting it otherwise.
shared pool was set to 320M to get child latches to kick in to # of CPUs.
was blowing thru shared memory like crazy (count(1) from v$session = 168)
tried cursor_sharing=SIMILAR. death.
cpus pegged at 100% (3 physical, 2 logical) on just the oracle.exe process.
tried to get a systemstate dump. too sluggish.
Fortunately I keep a copy of Stephan Haisely's paper on "I think my
database is hung!"
(in this case I know that it was kindasorta hung. it would eventually
allow me to connect).
hanganalyze did succeed in executing ... waiting for the server OS to
come back up to start the forensics.

hanganalyze worked at level 3.
systemstate dump didn't come back - gave it 45 minutes before the
server was cycled.

If you were using cursor_sharing=SIMILAR in 9.2 - be very careful in 10.1.
will likely be opening an iTAR on this on Monday.

Paul

-- 
#/etc/init.d/init.cssd stop
# f=ma, divide by 1, convert to moles.
--
//www.freelists.org/webpage/oracle-l

Other related posts:

  • » cursor_sharing=similar grief on 10.1.0.3 / win32