Re: SHUTDOWN: waiting for logins to complete.

From: Joel Garry <joel-garry_at_home.com>
Date: 20 Nov 2002 17:04:10 -0800
Message-ID: <91884734.0211201704.71295dc8@posting.google.com>

irfan_pk_at_hotmail.com (Md Irfan) wrote in message news:<c42168e7.0211192338.3a69a495_at_posting.google.com>...
> 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

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  _____________________

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

Received on Wed Nov 20 2002 - 19:04:10 CST