-
Okay, time for me to show my complete ignorance of the actual administration side of the house.
I have made several changes to my home network recently, including moving my internet connection off my server and onto a different machine. Basically, I have no idea what change may have precipitated this error.
What just happened: I installed a game for my child (big mistake, I know) on my Win2K server. It forced a reboot when it was done. Since then, I cannot get to my database. When I try connecting through SQLPlus, on another machine or the server itself, I get:
ERROR:
ORA-01034: ORACLE not available.
I did a search in the entire Oracle directory for any .TRC files and they all pre-date the reboot, so I'm getting no trace file. I looked all over the event viewer and found nothing related to Oracle.
I did see an ISA error that said something like 'since a gateway failed, all inbound traffic will be stopped' which looked suspicious. I then turned off everything having to do with IIS / ISA / Firewall, etc., since the server is no longer my internet proxy, this was no problem. I even restarted the server, but still no luck. Note that the error did not re-appear after the reboot, so it is unlikely that was the cause.
I then looked at the Oracle services. The 3 automatic services are all started. I then attempted to start all the manual services. They all started except OracleOraHome81TNSManagementServer, which gives the following error:
Error 997: Overlapped I/O operation in progress
Even with all the other services started, I still get the error.
So, given all that, does anyone have an idea what the problem is, besides the fact that I'm administratively-challenged ;)?
Thanks in advance,
- Chris
-
It looks like your services were started, but for some reason your database could not be opened by the service. Check the last few entries in your alertSID.log file to see in which state the database is in (closed, nomount, mount) and what was the cause for not being in open state.
-
The only alert*.log file anywhere on the machine was alert_dg.log, which was empty.
So I seached for *any* .log files. There were a few in the Oracle directory that were since the reboot:
listener.log - looked fine - no errors
svnode.log - empty
onrsd.log - looked fine - no errors
nmi.log - same
nmiconf.log - same
...logcman.log - had this:
Warning: Error while sourcing third party discovery file nmipaging.tcl : couldn't read file "nmipaging.tcl": no such file or directory
oradmin.log - had this:
ORA-01109: database not open
ORA-01109: database not open
ORA-01078: failure in processing system parameters
ORA-01078: failure in processing system parameters
ORA-01034: ORACLE not available
ORA-01078: failure in processing system parameters
oreperf81.log - had this:
5/22/2001 18:7:20 UPI_CONNECT failure: error 1034 Hostname LongDB Username SYSTEM ST=[snipped]
Any more ideas?
Thanks again,
- Chris
-
You know what, one of the other things I did was to change the init.ora a few days back - forgot about that. This would have been the first reboot since then - Guess that would explain the "ORA-01078: failure in processing system parameters". I'll check that out and report back.
- Chris
-
Well, *that* was certainly an ego-deflating experience :D. It seems I can't spell query_rewrite_enabled - Doh!
But my ineptitude aside, I kinda think that not starting the entire database because of a simple typo was a little harsh - couldn't it have just as easily skipped that param and fed me a nice warning - maybe even in the event viewer, where warnings are *supposed* to go in Windows? So, buried in one of the multiple little log files Oracle seems to keep around is a little error simply stating: "failure in processing system parameters". IMHO, there should be a massive header in front of this error saying: BECAUSE OF THE FOLLOWING ERROR, YOUR ENTIRE DATABASE WAS TOSSED:, with lots of asterisks to bring attention to it. *Something* more than what was done would have been appropriate. Or again, is it simply that I was raised on SQLServer, which, if nothing else, excels at user-friendliness?
Rant over.
Thanks for the help Jurij,
- Chris
-
when you went for the reboot, your database got shutdown. but afterwards the database did not get opened automatically. that is why you get the error message "oracle not available". in order to start the database automatically when you start your system , you can go to control panel -> services, in that select the required oracle services and make it automatic. this could be done by clicking on the startup button which will provide you the window for editing.
-
Chris,
What puzzles me is the fact that you weren't able to find the alert file. My initial definition of its name was wrong - it is not alertSID.log, it is SIDalrt.log. Every database must have an alert file, it creates it automaticaly to record any special events happening to the database. Even if you delete or rename it, your RDBMS will create a new one as soon as any of those special events happens.
You *should* have this file. Loook for it in your BACKGROUND_DUMP_DEST directory
SELECT value FROM v$parameter WHERE UPPER(name) = 'BACKGROUND_DUMP_DEST';
AFAIK the name pattern for the alert file is standard (SIDalrt.log), you can't specify other name for this file with any of the init parameters.
-
Hi Jurij/Chris,
Don't forget that problems during startup will not be written to the alert log in background_dump_dest (If Oracle can not process the parameters, how does it know where background_dump_dest is?) They will be written to the alert log in $ORACLE_HOME/rdbms/log - or whatever the windows equivalent of that Unix directory is.
HTH
David.
-
Yes, there is a LongdbALRT.log file. However, it wasn't updated during any of the bad boots, so looks like Dave is right. But I listed all the log files that were updated, so it certainly appears as if that little line in oradim.log was the only indication of the problem. As I keep asserting, Oracle *has* to simplify and improve their administration nonsense if they want to compete.
In that vein, I've been reading up on 9i a little - looks like they've done a *lot* with the administrative stuff. including a *lot* better integration with Window, but not much at all with the SQL, unfortunately. Actually, since I won't have to re-write whole sections of my book for 9i, I'm actually rather glad they didn't completely re-structure the SQL or the optimizer :).
- Chris
-
Good point, David!
However, to my surprise I've found out on my test NT instance that if a system is unable to mount the database due to some init.ora parameter errors, it will not record this in any alert or trace file at all!
