| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: login delay with 9.2.0.5
With delays this long (30 seconds) you should be able to trivially partition
the delay between sqlnet recognition and oracle rdbms login processing by
tailing the listener log file. I'm pretty sure it still buffer flushes
plenty frequently enough to see if a significant portion of your login chain
time is before the rdbms is even involved.
This observation won't solve your problem, but it will help tell you where to look for it.
Btw you may want to see if you've developed a bottleneck on appending to the listener log file. I don't know whether clutter and delays seeking to the end of long log files to write are really a problem any more, since long ago when they were I adopted a practice of having dated subdirectories and cycling logs. Having adopted that practice (which is well worth the near zero cost of having it just for organizational purposes), I no longer get data whether those old problems continue to exist.
good luck
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Paul Baumgartel
Sent: Thursday, July 22, 2004 2:53 PM
To: oracle-l_at_freelists.org
Subject: Re: login delay with 9.2.0.5
You can't trace the whole instance, but you can create a login trigger that starts tracing using DBMS_SUPPORT (note: this package is not installed by default; log in as SYS and run $ORACLE_HOME/rdbms/admin/dbmssupp.sql, then grant execute on DBMS_SUPPORT either to PUBLIC or one or more individual users first):
create or replace trigger trace_all
after logon on schema
begin
DBMS_SUPPORT.START_TRACE(waits=>true,binds=>false);
end;
/
Do this for one or two users, then TKPROF (with WAITS=YES) the trace files and inspect the output. Then disable the trigger. I do this all the time and it works very well.
Of course, if the delay occurs before the trigger fires, this won't help you!
PB
--- "Adams, Matthew (GE Consumer & Industrial)" <MATT.ADAMS_at_GE.COM>
wrote:
> This last weekend we upgraded an Oracle Apps=20
> instance from 8.1.7 to 9.2.0.5.0.
>
> Now sqlplus logins can take as long as 30 seconds=20
> and we're seeing peformance degradation pretty much=20
> across the board.
>
> It's a sun 6800 with 20 Cpus and 40G of ram. =20
> Machine does not appear to be bottlenecked on hardware
> at any point. Don't see any obvious problems anywhere.
>
> I can't set event 10046 for the whole instance, but I would=20
> very much like to know why logins are taking so long.
>
> Any suggestions?
>
> Matt
>
> ----
> Matt Adams - GE Appliances - matt.adams_at_appl.ge.com
> That's what's cool about working with computers.=20
> They don't argue, they remember everything and they=20
> don't drink all your beer. - Paul Leary, 1991
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jul 22 2004 - 14:22:27 CDT
 |
 |