Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!rip!news.webusenet.com!feed2.newsreader.com!newsreader.com!newshosting.com!news-xfer2.atl.newshosting.com!newspeer.monmouth.com!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail From: "Jonathan Lewis" Newsgroups: comp.databases.oracle.server Subject: Re: How to identify whether or not client session get ORA-1652 of TEMP in RAC. Date: Tue, 11 Nov 2003 20:52:40 -0000 Lines: 60 Message-ID: References: <2d15bd69.0311051955.736efc8f@posting.google.com> <2d15bd69.0311102342.79638850@posting.google.com> NNTP-Posting-Host: jlcomp.demon.co.uk X-Trace: news.demon.co.uk 1068584074 15180 158.152.75.41 (11 Nov 2003 20:54:34 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 11 Nov 2003 20:54:34 +0000 (UTC) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Priority: 3 X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MSMail-Priority: Normal Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:247468 Watch out for the latching. When a session is resumable, it records every call in a view called v$resumable_session (or similar) which has to be a latch-protected area of the SGA. Consequently you might see latch contention in a highly concurrent system - but I haven't checked to see which latch it might be. -- Regards Jonathan Lewis http://www.jlcomp.demon.co.uk The educated person is not the person who can answer the questions, but the person who can question the answers -- T. Schick Jr One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html ____Belgium__November (EOUG event - "Troubleshooting") ____UK_______December (UKOUG conference - "CBO") Three-day seminar: see http://www.jlcomp.demon.co.uk/seminar.html ____UK___November The Co-operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html "wangbin" wrote in message news:2d15bd69.0311102342.79638850@posting.google.com... > Thanks Jonathan. It works. Amazing. I even don't need "after suspend" > trigger. > > Without resumable, 1652 will been generated in alert.log whenever > reassignment happens. When I enable resumable with a timeout of 1, > only 'real' 1652 apears in alert.log, the reassignment ones disappear. > So all I need is an "LOGON ON" trigger to enable resumable. > > Well, I'm not sure about the side-effects. I will put it into test env > see how it goes. > > Regards, > Bin >