SHUTDOWN: waiting for active calls to complete

[Teck Sim]

I did a shutdown immediate on the database, and it took like 1/2 hour to complete the shutdown, with a message in my alert_xxx.log:

SHUTDOWN: waiting for active calls to complete

I was wondering what it is actually waiting for?

Please help with the above interpretation.
Thanks in advance.

[Mark Greene_1]

What database, and what version? What size box and what version of HP-UX is running on it?

mark

[Teck Sim]

Oracle Apps 10.7 SC16.1, Oracle734 for HP-UX 11.
Memory: 64108K (32216K) real, 128476K (96324K) virtual, 261388K free Page# 1/8
Thanks.

[Hai Nguyen_1]

Teck,

I guess that the DB is waiting for active remote SQL's to drop tcp/ip connections.

While you are shutting down the DB, on another window try this command below:

# ps -ef | grep oracle | grep -i local

If you see some displayed, it means that there are still active connections to the DB.

Hai

[Jeanine Kone]

It means that there is a connection to the database that is "active". I.E. it is actually doing something, not just sitting there idle. A shutdown immediate will wait for the active transactions to complete before it shuts down.

If you have a GUI took such as OEM (DBA studio), you can easily look at the current sessions and see their status (and most likely also who it belongs to and what sql command is actually being executed).

[Ricardo Bassoi]

Hello,

This can hapen when others users are conected to your system, in this case to the database.
Please check if others users were login when you try to shutdown.

[Jean-Luc Oudart]

1st, check for any client connections,processes can be owned or not by oracle depending if your using NET8 connection or not, and in this case who started the (specific) listener process.
You may have to kill these remaining client processes.
If you face a long transaction, this has to rollback (so how long took that transaction so far ?).
Shutdown abort will stop surely shut down the DB but you will have to re-start + shutdown the database to be in a clean situation.
Again if you have a long transaction , this will take a long time to rollback.

Jean-Luc

[T G Manikandan]

It can take long time as it has to
rollback long running transactions on the database.

Also the SMON process has to clean up the extents.

when the shutdown is given the extents are removed from the used extents tables and put on the free extents table

you can query the fet$ and uet$ to check whether fet$ is increasing and uet$ is decreasing.

select count(block#) from fet$
select count(block#) from uet$

If the value of uet$ is decreasing then it is the SMON cleaning up the extents.

If this is the case avoid creation of more temporary extents by increasing the value of
initial and next values of the extent size on the temporary tablespaces.


Also query your v$session to check the processes run by the user.
Might be any batch job is crarried on.

Is this happening regularly or on rare occasions?

Thanks