SHUTDOWN: waiting for logins to complete.

Md Irfan

unread,

Nov 20, 2002, 2:38:00 AM11/20/02

to

Hello,

I get this error message every time when I try to shutdown the
database. After issuing the shutdown command every five minutes i keep
on getting the error message
"SHUTDOWN: waiting for logins to complete."
in .trc file and database doesn't shuts. I have to issue an shutdown
abort finally to shut. The DB Version is 7.3.4 running in Unix.

Regards
Irfan

xueyang

unread,

Nov 20, 2002, 3:03:24 AM11/20/02

to

if u issue shutdown command, that means shutdown normal, it will wait for
all the online user to log out first.
either inform the user to log out before u issue shutdown or try shutdown
immediate.
"Md Irfan" <irfa...@hotmail.com> wrote in message
news:c42168e7.02111...@posting.google.com...

NorwoodThree

unread,

Nov 20, 2002, 2:20:47 PM11/20/02

to

Can you post the contents in your alert.log pertaining to the shutdown
in question? I might be able to help with some clues.

I dont need the entire log, just the lines pertaining to a bad
shutdown immediate.

Connor McDonald

unread,

Nov 20, 2002, 5:20:15 PM11/20/02

to Md Irfan

Just shutdown abort (optionally prefixed with 'alter system checkpoint')

Its faster and generally guaranteed to work

hth
connor
--
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."

Joel Garry

unread,

Nov 20, 2002, 8:04:10 PM11/20/02

to

irfa...@hotmail.com (Md Irfan) wrote in message news:<c42168e7.02111...@posting.google.com>...

Do you have dblinks? I've seen this happen when other instances
elsewhere try to attach to the instance unsuccessfully, leaving this
for you to trip on when you shutdown. Also, sometimes when people
don't shutdown their clients properly. Examine your processes
carefully with ps, and compare that to v$process. Also check listener
log if you have one. You might also write a script to kill off all
oracle and user processes that don't begin with ora_ before you
shutdown.

Here's a quick-n-dirty script I wrote one day for all my instances
that begin with "R":

#!/bin/ksh
#
# @(#) kill_oracle_attaches - Kill off processes left attached to
oracle net8
#
# 07-Nov-2001 by jgarry
#
echo "Killing list:"
ps -ef|grep oracleR|grep -v grep | awk '{print "kill -9 "$2} ' >>
$$kill_orac
le_attaches
ps -ef|grep oracleR|grep -v grep
echo "[End of list]"
if [ -f $$kill_oracle_attaches ]
then chmod +x $$kill_oracle_attaches
./$$kill_oracle_attaches
fi
rm $$*

Be real careful you understand what you are killing. Run this sort of
script with output and error output to somewhere safe, so you can
figure out who is screwing you up. In fact, you might consider
modifying dbshut to keep a record of who is on when you shutdown the
db.

In one case, I discovered that things were taking exactly 30 minutes
due to the tcp timeout settings. From an email to the admin when I
figured this out:

_____________ begin inclusion _________________________

Sometimes daemons are written such that they don't handle every
possible network disconnect scenario with aplomb. What can happen on
hp/ux is that the negotiation might never complete, which is necessary
to release the port. Since the ports are hard-coded in /etc/services,
this can effectively mean the port is locked until the system reboots.
hp/ux 11.00 handles this by allowing a timeout on the negotiation
(10.20 required a very skilled unix admin to poke at the kernel...).

The evidence that this is ocurring would be seen by repeating the
command:

netstat -a|grep FIN_WAIT

where a port stays in FIN_WAIT_2 state for more than a few seconds.
The ndd parameter is supposed to be tcp_keepalive_detached_interval,
defaulting to two minutes (see ndd -h
tcp_keepalive_detached_interval)...

______________ End inclusion _____________________

jg
--
@home is bogus.
Saw a Testarossa by the side of the fwy yesterday, had rear-ended
someone - lawsuit lotto winner!

Md Irfan

unread,

Nov 23, 2002, 2:43:48 AM11/23/02

to

norwoo...@my-deja.com (NorwoodThree) wrote in message news:<ba03e2c.02112...@posting.google.com>...

Please find below the log of .trc files. Thanks for any info.

Dump file /oracle/admin/DBCH/udump/ora_dbch_13988.trc
Oracle7 Server Release 7.3.4.0.0 - Production
With the distributed, parallel query and Parallel Server options
PL/SQL Release 2.3.4.0.0 - Production
ORACLE_HOME = /oracle
System name: Prod1
Node name: Proapp
Release: 4.0
Version: 3.0
Machine: 4850
Instance name: DBCH_0
Redo thread mounted by this instance: 1
Oracle process number: 13
Unix process pid: 13988, image: oraclePKSE3_0

*** SESSION ID:(13.3275) 2002.11.19.13.20.49.000