Restarting dead background process SNP0, SNP1, etc

[jayharper]

Oracle Server 8.1.7.0.0 on Win2000 SP4

We have a test database set up as a copy of production. A coworker had originally set this up by doing a flat file transfer of all the db files, then recreating the instance and doing a recover database to rebuild the control files. We're getting an error when connecting and updating via the main application - ORA-01331 end of communication channel failure. We have built other test dbs in this manner with no problems. There are no obvious errors in the alert.log. The only thing I spot is that the SNPx processes are restarting over and over again, about every 5 minutes. This is not happening on prod or any of our other test instances.

Any ideas? Thanks.

Dump file C:\oracle\admin\CHFITEST\bdump\chfitestALRT.LOG
Wed Apr 14 11:31:15 2004
ORACLE V8.1.7.0.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.7.0.0.
System parameters with non-default values:
processes = 150
shared_pool_size = 250000000
java_pool_size = 30000000
control_files = C:\oracle\oradata\CHFITEST\control01.ctl, C:\oracle\oradata\CHFITEST\control02.ctl, C:\oracle\oradata\CHFITEST\control03.ctl
db_block_buffers = 15000
db_block_size = 8192
compatible = 8.1.0.0.0
log_buffer = 32768
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
db_files = 1024
db_file_multiblock_read_count= 8
rollback_segments = RBS0, RBS1, RBS2, RBS3, RBS4, RBS5, RBS6, RBS7, RBS8, RBS9
max_enabled_roles = 30
remote_login_passwordfile= EXCLUSIVE
db_domain = SICPA
global_names = FALSE
distributed_transactions = 10
instance_name = CHFITEST
service_names = CHFITEST.SICPA
sort_area_size = 131072
sort_area_retained_size = 65536
db_name = CHFITEST
open_cursors = 600
os_authent_prefix =
utl_file_dir = c:\temp\utl
job_queue_processes = 2
job_queue_interval = 10
parallel_max_servers = 5
background_dump_dest = C:\oracle\admin\CHFITEST\bdump
user_dump_dest = C:\oracle\admin\CHFITEST\udump
max_dump_file_size = 10240
oracle_trace_collection_name=
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
SNP0 started with pid=8
SNP1 started with pid=9
Wed Apr 14 11:31:17 2004
alter database mount exclusive
Wed Apr 14 11:31:21 2004
Successful mount of redo thread 1, with mount id 4158249097.
Wed Apr 14 11:31:21 2004
Database mounted in Exclusive Mode.
Completed: alter database mount exclusive
Wed Apr 14 11:31:21 2004
alter database open
Beginning crash recovery of 1 threads
Wed Apr 14 11:31:22 2004
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 3 Seq 15 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\CHFITEST\REDO01.LOG
Wed Apr 14 11:31:23 2004
Thread recovery: finish rolling forward thread 1
Thread recovery: 25 data blocks read, 25 data blocks written, 35 redo blocks read
Crash recovery completed successfully
Wed Apr 14 11:31:23 2004
Thread 1 advanced to log sequence 16
Thread 1 opened at log sequence 16
Current log# 1 seq# 16 mem# 0: D:\ORACLE\ORADATA\CHFITEST\REDO03.LOG
Successful open of redo thread 1.
Wed Apr 14 11:31:23 2004
SMON: enabling cache recovery
SMON: enabling tx recovery
Wed Apr 14 11:31:25 2004
Completed: alter database open
Wed Apr 14 11:32:28 2004
Restarting dead background process SNP0
SNP0 started with pid=8
Wed Apr 14 11:32:28 2004
Restarting dead background process SNP1
SNP1 started with pid=9

[gbrabham]

Ensure that your SQLNET.ORA is not looking for NTS authenication...
Is this in the SQLNET.ORA on the server???

SQLNET.AUTHENTICATION_SERVICES= (NONE)

Sounds like you may have replication on this database and the
jobs cannot connect ...

HTH
Gregg

[jayharper]

Originally posted by gbrabham
Ensure that your SQLNET.ORA is not looking for NTS authenication...
Is this in the SQLNET.ORA on the server???

SQLNET.AUTHENTICATION_SERVICES= (NONE)

Sounds like you may have replication on this database and the
jobs cannot connect ...

HTH
Gregg

NTS auth - we're using this on all our oracle servers. For grins, I changed to NONE but same results.

Replication - none being used by any of our databases.

It's strange. We have several databases set up in this same way and none have this problem.