-
Originally posted by adewri
No thats not true at all..... Oracle can run even if it cannot write to alert.log file.
hmmm oh really?
Note:1055297.6 Subject: ORA-03113 ON STARTUP NOMOUNT
"If Oracle cannot write to the alert log for any reason, the instance will crash."
Ok maybe the note is dated but I have seen many instances where the db would not open or would crash with a change in permission to where oracle writes the alert log to or perhaps a change in mount point
steve
I'm stmontgo and I approve of this message
-
Originally posted by stmontgo
hmmm oh really?
Note:1055297.6 Subject: ORA-03113 ON STARTUP NOMOUNT
"If Oracle cannot write to the alert log for any reason, the instance will crash."
Ok maybe the note is dated but I have seen many instances where the db would not open or would crash with a change in permission to where oracle writes the alert log to or perhaps a change in mount point
steve
That is true if you are trying to start the instance and there is no space in the filesystem where the trace file is being written to.
But if an instance is running and space is full it will still keep running unless the next time it tries to write to the alert log file(I have seen this situation before but never faced a crash cause we increased the space). Though after reading that note, im not sure what will happen when it tries to write (Technically it should not crash, rather throw some other error message on screen when performing tasks that usually get logged in the alert log file).
Amar
"There is a difference between knowing the path and walking the path."
-
Well i just did a simple test...
I renamed the bdump to bdumpold on running DB and tried creating tablespace, and was able to create it. Did log switch many times. Every thing is fine. I was even able to do a shutdown... though it did take a long time...
Though startup seems to be in a hanging state right now... will you know about it in the morning...
Last edited by adewri; 11-03-2003 at 04:09 PM.
Amar
"There is a difference between knowing the path and walking the path."
-
Well guess what it did get started....
Amar
"There is a difference between knowing the path and walking the path."
-
Adewri, if you renamed the bdump directory then your instance simply created a new alert_sid.log in default bdump destination. Check O_H\rdbms\trace (or whatever the default for your OS is) and you'll find it started to write into a new alert.log. And this doesn't happen only at startup, it happens during normal database operation if the initial bdump destination is no longer available or is full.
This also goes to prasadvd - check your OS's default bdump destination to see if oracle has created a new alert.log there.
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
Originally posted by jmodic
Adewri, if you renamed the bdump directory then your instance simply created a new alert_sid.log in default bdump destination. Check O_H\rdbms\trace (or whatever the default for your OS is) and you'll find it started to write into a new alert.log. And this doesn't happen only at startup, it happens during normal database operation if the initial bdump destination is no longer available or is full.
This also goes to prasadvd - check your OS's default bdump destination to see if oracle has created a new alert.log there.
That was the first thing i checked... but no could not find any trace file in O_H\rdbms\trace. No nothing. Had there been any trace file generated then shutdown and startup would not have taken sooo long time. Shutdown took about 5 Mins and startup around 7 Mins. When i rename bdumpold to bdump, shutdown took less than 10 secs and startup less than 30 secs....
BTW OS is windows XP prof. Oracle9i 9.2.0.3.0
Amar
"There is a difference between knowing the path and walking the path."
-
Originally posted by adewri
BTW OS is windows XP prof. Oracle9i 9.2.0.3.0
Hm, that's interesting - I tested on W2K, Oracle9i 9.0.1.?.? and after renaming the initial bdump directory (during normal database operations) it created new alert file in rdbms\admin\trace.
Jurij Modic
ASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?
-
Originally posted by jmodic
Hm, that's interesting - I tested on W2K, Oracle9i 9.0.1.?.? and after renaming the initial bdump directory (during normal database operations) it created new alert file in rdbms\admin\trace.
Yep thats more confusing.. as i was trying it on unix after renaming.
see what i got...
Code:
oracle():/oracle9i/app/product/admin/...> mv bdump/ bdumpold
oracle():/oracle9i/app/product/admin/...> c
SQL*Plus: Release 9.2.0.3.0 - Production on Tue Nov 4 12:59:20 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to an idle instance.
idle> startup
ORA-00449: background process 'CKPT' unexpectedly terminated with error 7446
ORA-07446: sdnfy: bad value '' for parameter .
idle> exit
Disconnected
oracle():/oracle9i/...> ls
bdumpold cdump create pfile udump
oracle():/oracle9i/...> mv bdumpold/ bdump
oracle():/oracle9i/...> c
SQL*Plus: Release 9.2.0.3.0 - Production on Tue Nov 4 13:00:26 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to an idle instance.
idle> startup
ORACLE instance started.
Total System Global Area 471559784 bytes
Fixed Size 736872 bytes
Variable Size 436207616 bytes
Database Buffers 33554432 bytes
Redo Buffers 1060864 bytes
shutdown immediate
Database mounted.
Database opened.
idle> Database closed.
Database dismounted.
ORACLE instance shut down.
idle>
Where as on windows i was able to startup the instance... even after renaming the bdump file and no trace ...
Last edited by adewri; 11-04-2003 at 03:53 AM.
Amar
"There is a difference between knowing the path and walking the path."
-
it crashes in linux
Code:
mv bdump bdumpold
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 4 11:51:40 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
sys@LNX920>alter system switch logfile;
System altered.
[oracle@rac1 lnx920]$ ll $ORACLE_HOME/rdbms/log
total 0
sys@LNX920> alter system switch logfile
alter system switch logfile
*
ERROR at line 1:
ORA-00449: background process 'LGWR' unexpectedly terminated with error 7446
ORA-07446: sdnfy: bad value '' for parameter .
-
Originally posted by pando
it crashes in linux
Code:
mv bdump bdumpold
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 4 11:51:40 2003
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
sys@LNX920>alter system switch logfile;
System altered.
[oracle@rac1 lnx920]$ ll $ORACLE_HOME/rdbms/log
total 0
sys@LNX920> alter system switch logfile
alter system switch logfile
*
ERROR at line 1:
ORA-00449: background process 'LGWR' unexpectedly terminated with error 7446
ORA-07446: sdnfy: bad value '' for parameter .
see windows is better!! (oh god, I have finally lost it completely)
I'm stmontgo and I approve of this message
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|