Re: A Real Stinker to Solve - EXPERTS APPLY WITHIN (DB Crashing)

Johne_uk wrote:
> Hi,
>
> It only reports an error 470 which is a largely generic error message.
> My first posting containts output from all the trace files generated -
> not much :-(
>
> rgds
>
> *** 2006-10-11 16:53:28.759
> *** SESSION ID:(1.1) 2006-10-11 16:53:28.714
> error 470 detected in background process
> ORA-00470: LGWR process terminated with error

Let's back up and ask some random questions:

When did you apply 9207?

Did you originally install Oracle with the installer, or some other strange method like copying it from another machine?

Is there a standby involved?

Show modified init.ora parameters.

Are you seeing any other apparently unrelated symptoms on this machine or db instance?

How much real memory are you using? How much is lgwr using? How much and what kind of swap do you have?

What kind of file system and related hardware are you using? Please specify raw/cooked, sync/async, RAID level, number of controllers, SAN, etc.

Where exactly are the log files, archived log files and data files?

Does the system ever just kind of slow down for a while?

Ever see any log file related waits? What is your log buffer size?

What exactly did statspack have to say about waits?

How often are you checkpointing? Any messages about it alert log? Any other messages in alert log besides log switches?

How big are your redo logs? How often do they switch (maximum)?

How many archivers are running?

What else besides Oracle is on the server? Are you running multiple instances or databases? RAC involved?

What kernel parameter modifications have you made?

What memory and filesystem checks have you made? Are you seeing lots of retries when writing to any log devices?

What does ipcs|grep oracle show?

Do you have any processes to kill off users? (I know, that would be really dumb to kill off lgwr, but hey, gotta ask.)

I'm wildly speculating you have some filesystem write problem that causes lgwr to start using more memory and blowing some OS limit. Then whatever misconfiguration you made is also made on the other machine.

jg

--
@home.com is bogus.
Rule #1:  Do not fly into solid objects.
http://hosted.ap.org/photos/2/2cf693eb-ac14-482c-b1c0-5047a336eb4b-small.jpg