Title: RE: Database/system Crashing
I'm not sure about savecore but I do know that the disks
are internal. No SAN... They're about to yank SUN's chain because they are
trying to resolve this remotely and its taking too long. Hopefully we'll have
something solid from SUN next week. I am going
Title: RE: Database/system Crashing
Please do. Any information at this point will help. The
only difference is that when it fails it doesn't even get to write the
/var/adm/messages or the core dump. Oracle wasn't writing to the alert log file
until I moved it off the root disk an onto
Title: RE: Database/system Crashing
Val,
Here is the Sun patch
108727-16 that was related to our problem.
Does the system have savecore running?
You
can try to symbolic link /var/adm to another disk. In our case Oracle
never wrote anything
to
alert log because it was a system crash
Title: RE: Database/system Crashing
Sorry
for getting back to you late on this. In our case, the server crashes each
time with CPU panic message
in
/var/adm/messages. We used adb to analyze the core dump and saw in each
instance of the crash, NFS
lead
to it. It was trying to free memory
Title: RE: Database/system Crashing
No sorry... just a simple 2 disk development Unix box...
Sun Solaris 8
-Original Message-From: Burke, William F (Bill)
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 07, 2003 5:09
PMTo: Multiple recipients of list ORACLE-LSubject: RE
Title: RE: Database/system Crashing
Well I relocated the background dest files and I got the
following error... that was a great idea!
ORA-00206: error in writing (block 3, # blocks 1) of
controlfileORA-00202: controlfile:
'/u04/oradata/ERCS/ora_control2'ORA-27063: Message 27063 not found
Title: RE: Database/system Crashing
Got the same error on NT last week.
Check if there are system backups that backup the control
files.
When Veritas backup the control file as a regular file the
database can not write to it and you get this message.
Yechiel AdarMehish
- Original
Title: RE: Database/system Crashing
Val,
Have you tried copying a known good controlfile in place of
the bad one? If not, try it and report the result. If it corrupts as well, it
seems to me that there is a much bigger problem. If it does not corrupt, then
the question is, why didn't oracle
Title: RE: Database/system Crashing
Dan,
I meant to say that I found out why Oracle crashed. There
is a bigger problem with the OS since it crashes when the db is down and it
seems to lose parts of itself if that makes sense. After the OS "sorta crashes"
or partially crashes,
Title: RE: Database/system Crashing
"PS.. do we all get a virtual
"pass" on a future audit for helping? :)"
ABSOLUTELY!!
;)
-Original Message-From: Mercadante, Thomas F
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, January 07, 2003
3:52 PMTo: '[EMAIL PROTE
Title: RE: Database/system Crashing
Val,
if the
unix commands are disappearing, then it sounds like you are either losing disk
directories, or the paths that point at them.
when I
first read your post last week, I had a sneaky feeling that this was an OS
problem and not an Oracle one
Title: RE: Database/system Crashing
I'm
late on this thread... Is this a SAN which is mirrored by any
chance?
Regards,
Bill Burke "The
Kinder and Gentler DBA" IOUG University
Master Class Faculty 2001-2002 "iDBA
Management, High Performance Infrastructure and HA" IOU
Title: RE: Database/system Crashing
Yes there are NFS mounts involved. What you said about the OS locks on the audit directory makes a lot of sense. My SA's are back to thinking it's a OS problem because it crashed again with the database shut down.
The odd thing is that there is nothing
Val - I had a horrible problem using RMAN over NFS. Just hanging. Eventually
it turned out that NFS was configured for only a few connections (I can't
recall the exact term used). The assumption was that if we were only doing
one thing, then that should be adequate. It turned out this needed to be
Title: RE: Database/system Crashing
If the database
has data files on NFS mounts, then any network problems or problems on the NFS
server can crash things. Disappearing NFS mounts can be very nasty.
That's why it's a big no-no to putANY files related to the database --
data files, log files
Title: RE: Database/system Crashing
Val,
Not having an entry in the alert log
or having trace files is not all that odd. This indicates a hard crash of the
instance, where the background processes were unable to write to the files. This
could be a result of the instance being forcefully
Title: RE: Database/system Crashing
I'd
agree with Dan. You need to find the root cause of the crash. If you
rebuild to the current state from scratch, the odds are you'll see the same
problem reoccur. Secondly, while NFS mounted volumes will work, they
should always be a last resort as any
Title: RE: Database/system Crashing
Val,
Sorry
I missed the previous messages. Was this a Sun platform? Did the
system crash with a CPU panic
in
/var/adm/messages? We resovled a Sun NFS related crashes a couple of
months ago.
Richard Ji
-Original Message-From: Webber Valerie H
Title: RE: Database/system Crashing
Richard,
Yes this is a SUN platform. One SA now believes it is
independent of the database since it happens when the database isn't running. I
moved the background dest files to the other disk (other than the root disk.)
Normally it would have crashed
I wonder if a file lock is being left in place when the instance crashes,
and the OS does not clear the lock until a reboot. I would think the OS
should clear this without a reboot, but stranger things have been seen with
OS's ... even Unix. This doesn't explain why the instance crashes. I
Title: Database/system Crashing
I have a 8.1.7 repository database for Designer 9i (client) running on SUN Solaris 8. I can start the database up but when I access the data via Designer it crashes. I try to start it back up and I get the following message
ORA-09925: Unable to create audit
My mistake. The parameter is audit_file_dest, which is the location
where audit files are written if audit_trail=os. By default
audit_file_dest is $ORACLE_HOME/rdbms/audit. I suspect audit_file_dest
is explicitly set to another location which either doesn't exist or
lacks proper permissions.
Check your init.ora for the audit_trail parameter. It's probably set to
write a file to a location that either doesn't exist or lacks proper
permissions.
Webber Valerie H wrote:
I have a 8.1.7 repository database for Designer 9i (client) running on
SUN Solaris 8. I can start the database
Valerie:
What is the audit parameter in the init.ora file set to? Is it set to
database (db) or os files? What are the other audit parameters in the
init.ora file set to?
RWB
Webber Valerie H [EMAIL PROTECTED]@fatcity.com on 01/02/2003
01:45:17 PM
Please respond to [EMAIL PROTECTED]
Title: Database/system Crashing
Check
the oracle executable and make sure the setuid bit is set.
-Original Message-From: Webber Valerie H
[mailto:[EMAIL PROTECTED]]Sent: Thursday, January 02, 2003
1:45 PMTo: Multiple recipients of list ORACLE-LSubject:
Database/system
Title: Database/system Crashing
Valerie,
What happens when the database first crashes? Is there an
error in the alert log?
As for the second error, the issue is not that the device
is full (you would get a different O/S error). It sounds more like either the
audit_file_dest value
Title: RE: Database/system Crashing
Yes, you're correct and it can write the file to $ORACLE_HOME/rdbms/audit once the system is rebooted. Its just that when the database crashes, it can't write to that location until its rebooted.
Is it possible that I need to beef up my init.ora parameters
: Database/system Crashing
My mistake. The parameter is audit_file_dest, which is the location
where audit files are written if audit_trail=os. By default
audit_file_dest is $ORACLE_HOME/rdbms/audit. I suspect
audit_file_dest
is explicitly set to another location which either doesn't exist
28 matches
Mail list logo
