Btw, what have you found out that work differently in logon triggers than in regular triggers (leaving out the table row related stuff)? Tanel. ----- Original Message ----- From: "Tanel Põder" <tanel.poder.003@xxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Wednesday, February 18, 2004 1:30 PM Subject: Re: restrict connections to some instances in RAC > Waleed, > > The logon trigger unhandled exception handling behaviour is dependent on > whether the user trying to log on does have the "administer database > trigger" privilege or not. If she doesn't, then user gets an error message > and nothing is written to trace files. If she does have the priv, then she > is let in anyway and an error is written to trace. > > I have tested it in 10g, 9i and I believe it works the same way in 8i as > well. > > Tanel. > > > ----- Original Message ----- > From: "Khedr, Waleed" <Waleed.Khedr@xxxxxxx> > To: <oracle-l@xxxxxxxxxxxxx> > Sent: Tuesday, February 17, 2004 4:06 PM > Subject: RE: restrict connections to some instances in RAC > > > > Thanks. I use dbms_job to spawn a proc to kill the session.=20 > > > > The connection continues normally when I raise unhandled exception in = > > the > > logon trigger. > > A trace file gets generated that shows that some problems took place = > > and > > that the database connection is continuing with its connection. > > Actually I found that the a lot of things get ignored or behave = > > differently > > in logon triggers, and it seems to me that it's designed this way. > > > > Did you test this "unhandled exception" in logon triggers? What Oracle > > release? > > > > Thanks > > > > Waleed > > > > -----Original Message----- > > From: Tanel P=F5der [mailto:tanel.poder.003@xxxxxxx] > > Sent: Friday, February 13, 2004 5:10 PM > > To: oracle-l@xxxxxxxxxxxxx > > Subject: Re: restrict connections to some instances in RAC > > > > > > Hi, are you sure you are actually killing the session, because you = > > can't > > kill your own session with alter system kill session. But anyway, any > > unhandled exception in logon trigger will prevent users without = > > 'administer > > database trigger' from logging in. > > > > One more thing you could do to direct clients to correct instances, is = > > using > > different service names for different client types and assigning the = > > service > > names to relevant instances. But the logon trigger should remain there, = > > just > > in case (if you aren't doing excessive logons all the time). > > > > Tanel. > > > > ----- Original Message ----- > > From: "Khedr, Waleed" <Waleed.Khedr@xxxxxxx> > > To: <oracle-l@xxxxxxxxxxxxx> > > Sent: Friday, February 13, 2004 7:01 AM > > Subject: restrict connections to some instances in RAC > > > > > > > Is there a clean way to restrict connections for certain users to = > > specific > > > instances in RAC environments? > > > > > > What I have now is a logon trigger that kills the session. > > > > > > Thanks > > > > > > Waleed > > > ---------------------------------------------------------------- > > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > > ---------------------------------------------------------------- > > > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > > > put 'unsubscribe' in the subject line. > > > -- > > > Archives are at //www.freelists.org/archives/oracle-l/ > > > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > > > ----------------------------------------------------------------- > > > > ---------------------------------------------------------------- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > ---------------------------------------------------------------- > > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > > put 'unsubscribe' in the subject line. > > -- > > Archives are at //www.freelists.org/archives/oracle-l/ > > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > > ----------------------------------------------------------------- > > ---------------------------------------------------------------- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > ---------------------------------------------------------------- > > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > > put 'unsubscribe' in the subject line. > > -- > > Archives are at //www.freelists.org/archives/oracle-l/ > > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > > ----------------------------------------------------------------- > > > > > ---------------------------------------------------------------- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > ---------------------------------------------------------------- > To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx > put 'unsubscribe' in the subject line. > -- > Archives are at //www.freelists.org/archives/oracle-l/ > FAQ is at //www.freelists.org/help/fom-serve/cache/1.html > ----------------------------------------------------------------- > ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------