Cannot shutdown database normal!!!
Fredrik Librand
I have a serious problem with an oracle instance 7.3.4 on Windows NT 4.
The instance is new and I have moved (imported) an existing database into
it. Everything is well so far, but the database cannot be shutdown (normal
or immediate). When trying it just hangs and nothing further happens. In
order to start it up again i have to do "shutdown abort". Shutdown abort
always works. If I have done "startup mount" a shutdown is possible. I
have talked to Oracle support and tried their immediate advice, such as
taking the DB off archivelog mode. No other users are logged on and
starting up in restricted mode doesn't help. The Alert log shows no
errors.
Has anyone had this problem? Any help would be greatly appreciated!
Fredrik Librand
Database Administrator
Ekonomi+Teknik Förlag AB
fredrik...@nojunkmail.et.se (Please remove nojunkmail. to
get real address)
Jerry Gitomer
In my last job we had the same problem. In our case we were using
a PC in the computer room as though it were a console for the NT server
located in the server room. It turns out that as far as Oracle
was concerned our "console" was really a terminal with its own
session. We were able to do a shutdown normal or immediate from
the server's keyboard and screen, but not from anyplace else.
regards
Jerry Gitomer
------------------------------------------------------
Fredrik Librand wrote in message <01be76af$810782a0$c89734c2@frli>...
Sean Leahy
I had the same problem. My issue was that SMON was busy cleaning up temp
extents, which is part of the normal shutdown operation. It took 12 hours,
but it shut down. I had to tune my temp segments and Sort Areas better.
See if you have any temp objects in you temp tablespaces.
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
Jens Kieffer-Olsen
Sean Leahy wrote in message ...
>
>
>I had the same problem. My issue was that SMON was busy cleaning up temp
>extents, which is part of the normal shutdown operation. It took 12 hours,
>but it shut down. I had to tune my temp segments and Sort Areas better.
>See if you have any temp objects in you temp tablespaces.
It's advisable to use a large NEXT extent size for the temporary tablespace,
1MB or even the sort_area_size. Also run an alter tablespace ... coalesce
at regular intervals.
--
Jens Kieffer-Olsen
Jan Syssauw
there is an event (i forgot the number) which can be set
that dumps information at shutdown.
This should help resolving your case.
Regards
Jan
Jurij Modic
<dst...@post4.tele.dk> wrote:
> It's advisable to use a large NEXT extent size for the temporary =
>tablespace,
> 1MB or even the sort_area_size. Also run an alter tablespace ... =
>coalesce
> at regular intervals.
I'm affraid neither of those two advices are realy good advices for
temporary tablespaces.
As for the "large NEXT extent": the optimal size of the NEXT
tablespace parameter depends on the nature of the most usual events
that require the temporary segments, but the more important guideline
is that NEXT should be the same as the INITIAL and that PCTINCREASE
should be set to 0.
And as for the "coalescing the temporary tablespace": with the
INITIAL, NEXT and PCTINCREASE set as mentioned above, you should never
perform the coalescing of the temp tablespace, as the performance of
the operations requiring sorts will degrade until enough equaly sized
temp extents will be allocated again.
>--
>Jens Kieffer-Olsen
HTH,
Jurij Modic <jmo...@src.si>
Certified Oracle7 DBA (OCP)
================================================
The above opinions are mine and do not represent
any official standpoints of my employer
Richardsons
startup the database and run the following command in svrmgrl/sqldba
"alter database backup controlfile to trace"
shutdown abort
edit the trace file in the udump directory (or where your init parameter
has defined user_dump_dest, for
current query the following before shutdown " select value from
v$parameter where name='user_dump_dest' "
remove your current control files.
start svrmgrl and run this file. Your database controlfiles should be
rebuilt and the database recovered.
In most cases this will probably solve the problem.
Rich.