Path: newssvr20.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!in.100proofnews.com!tdsnet-transit!newspeer.tds.net!newspeer.radix.net!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews1.google.com!not-for-mail From: wangbin@start.com.au (wangbin) Newsgroups: comp.databases.oracle.server Subject: Re: How to identify whether or not client session get ORA-1652 of TEMP in RAC. Date: 10 Nov 2003 23:42:03 -0800 Organization: http://groups.google.com Lines: 35 Message-ID: <2d15bd69.0311102342.79638850@posting.google.com> References: <2d15bd69.0311051955.736efc8f@posting.google.com> NNTP-Posting-Host: 203.48.79.199 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1068536524 11148 127.0.0.1 (11 Nov 2003 07:42:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Nov 2003 07:42:04 +0000 (UTC) Xref: newssvr20.news.prodigy.com comp.databases.oracle.server:247430 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 "Jonathan Lewis" wrote in message news:... > Have a look at resumable sessions and the 'after suspend' > trigger. A 'real' 1652 will then put the session that has a > problem into suspension and fire the after suspend trigger. > Give it a timeout of (say) 10 seconds so that it really > crashes the end-user afterwards, but make sure it logs > the problem. It is possible that a 'spurious' 1652 that > can be resolved by extent reallocation will not cause a > suspension. > > Test carefully. I haven't tried setting sessions resumable > en masse, so there may be odd side-effects - especially > on a RAC system. > > -- > Regards > > Jonathan Lewis > http://www.jlcomp.demon.co.uk >