Error 472 in alert log

error ora 472 means that the PMON process has terminated with an error

have you tried shutting down the database and restarting, to resync the processes ?

Ybarot,
You need to look at the background process trace files, this error indicates that PMON died. Look in the PMON trace file and see if
 there is any indication why it crashed. It is possible there will be an error telling us PMON died because of another background
 process. If you find this, you need to go to that process' trace file and so on. In other words, it is possible the crash was a domino effect
 of processes crashing. We need to find out which process died first and find the errors indicating why it crashed.
Please check the NT Event viewer to see if Oracle is having trouble creating the files. Also look in the default location,
 oracle\ora81\SNP1\bdump, cdump, udump for a trace files.

Hi All,

Actually no Trace file for PMON or any other process is generated. I have the trace file only for DBWR process.
I am attaching it here.

========================================
Dump file F:\Oracle\admin\claims2\bdump\claims2DBW0.TRC
Mon Apr 03 19:34:51 2000
ORACLE V8.1.5.0.0 - Production vsnsta=0
vsnsql=d vsnxtr=3
Windows NT V4.0, OS V5.101, CPU type 586
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Windows NT V4.0, OS V5.101, CPU type 586
Instance name: claims2

Redo thread mounted by this instance: 1

Oracle process number: 3

Windows thread id: 147, image: ORACLE.EXE


*** 2000.04.03.19.34.51.945
*** SESSION ID:(2.1) 2000.04.03.19.34.51.905
error 472 detected in background process

========================================


Sometimes it crashes showing error 472 in SMON process, DBWR or SNP or LGWR process..any of them. I am not shuting down database it crashes automatically.

Thanks,
Yogi.

Yogi
Man... it just not telling us a lot...
Just for clairification...
- Your running NT 4.0 SP5?????
- Your database is crashing immediatily after starting up (ie. before you can   connect and issue a shutdown immediate)
- Based on you SCN#2825 the database has been up before.
- What was the last thing done to the database before it starting acting
   this way?  add any new stored procedures or triggers
- Did you ever check the NT Event Log? system and application
  Start> Programs> Administrative Tools (Common)> Event Viewer
  Then under Log... select Application
- Can you send your init.ora file?  Have you made any changes recently.
- What hardware are you running?  How much memory?
Terry
 

Are you running MTS?

try the startup in nomount mode and with archive logging off. Use the minimal setup approach to begin with.

Hi Terry,

I am running NT4.0, one has SP5.

The error is reported when database is running well for many days.

The job queues were the last thing added to the database. That includes the
procedures too.

Nothing was found in the NT event log at the time of error 472.


The hardware is IBM compatible PC with  P200MMX, 128 MB RAM and not for
development work only.

 <<init.ora>>

This is my init.ora file:
========================================
b_name = claims2

instance_name = claims2

service_names = claims2

db_files = 1024

control_files = ("F:\Oracle\oradata\claims2\control01.ctl", "F:\Oracle\oradata\claims2\control02.ctl")

db_file_multiblock_read_count = 8

db_block_buffers = 2048

shared_pool_size = 15728640

large_pool_size = 70778880
log_checkpoint_interval = 10000
log_checkpoint_timeout = 0

processes = 50

parallel_max_servers = 5

log_buffer = 32768

#audit_trail = true  # if you want auditing
#timed_statistics = true  # if you want timed statistics
max_dump_file_size = 10240  # limit trace file size to 5M each

# Global Naming -- enforce that a dblink has same name as the db it connects to
global_names = true

# Uncomment the following line if you wish to enable the Oracle Trace product
# to trace server activity.  This enables scheduling of server collections
# from the Oracle Enterprise Manager Console.
# Also, if the oracle_trace_collection_name parameter is non-null,
# every session will write to the named collection, as well as enabling you
# to schedule future collections from the console.
# oracle_trace_enable = true

oracle_trace_collection_name = ""
# define directories to store trace and alert files
background_dump_dest = F:\Oracle\admin\claims2\bdump
user_dump_dest = F:\Oracle\admin\claims2\udump

db_block_size = 8192

remote_login_passwordfile = shared

os_authent_prefix = ""

distributed_transactions = 10
mts_dispatchers = "(protocol=TCP)(DISP=1)(mul=OFF)(pool=OFF)"
mts_max_dispatchers = 5
mts_servers = 1
mts_max_servers = 20

compatible = 8.0.5
sort_area_size = 66560
utl_file_dir = d:\Dataconv\Utldir

# The following parameters are needed for the Advanced Replication Option
# and job queues

job_queue_processes = 2
job_queue_interval = 60
license_max_sessions=100
license_max_users=25
license_sessions_warning=80

=======================================
I am running another machine having NT4.0, one has SP4 with PII-450, 640MB
RAM and is also for development. I am unable to give the init.ora & alert
log from the other machine. Both experiencing the same problem.

If you can find some solution than I will appricaite.

Thanks,
Yogi.

I'm going to bow out...
Parting thoughts:
- without some kind of diagnostics, this is going to be tough to solve.
- I believe there are some issues with service pack 5, but you recreated the
  problem on a second machine.
- It could be something to do with the new scheduled stored procedures   (job queues),  But I not sure what.  You might be able to isolate it by   removing the scheduled jobs.  See if that resolves it...
- I suppose it could be something like a memory leak...  but I believe that   even puts out some error messages.
- Seem like there should be a way to create more verbose records in the   alert file
- Last resort, call Oracle Support
- Oh you are running MTS....
  Let me look in to that...
Terry