The error was in relation to not running out of processes, it could be a case that the shutdown operation earlier was interrupted too. So the shutdown abort will abort the database, no matter whether it runs out of the # of processes or not.
Sam
Printable View
The error was in relation to not running out of processes, it could be a case that the shutdown operation earlier was interrupted too. So the shutdown abort will abort the database, no matter whether it runs out of the # of processes or not.
Sam
Hmmm, yes, looking back at the error, the user was connected to Oracle at the time shutdown was attempted, it may not have been a max number of processes. BUT, if if you do max out the processes, you still won't be able to connect to shutdown the database without first killing another process.
Cheers,
Same here Sam, easy to come into a situation when you have to manually remove the old SGA...Quote:
Originally posted by sambavan
I once played the game of startup force and got into trouble... Its not worth the trouble that you have to go through to get it back if it goes wrong!!!
This is my personal opinion. I would take a long shot and save time....
Sam
Using STARTUP FORCE is absolutely no more dangerous then using SHUTDOWN ABORT + STARTUP..... In fact , it is only a one-comand operation that performs SHUTDOWN ABORT and then starts up the database. Only a short cut to save some typing, nothing more dangerous than SHUTDOWN ABORT about it.
And Sam, I see no reason to perform step no.3 in the following sequence of statements - Oracle will do it for you automaticaly.
It would be exactly the same if you simply use:Quote:
Originally posted by sambavan
SVRMGR> shutdown abort
SVRMGR> startup mount
SVRMGR> recover database
SVRMGR> alter database open;
SVRMGR> shutdown abort
SVRMGR> startup
And it would be exactly the same if you simply use
SVRMGR> startup force
[Edited by jmodic on 10-31-2001 at 03:36 PM]