Rogue alert log in $ORACLE_HOME/dbs

Question

Hi there, have looked all over and not yet found the answer to my query. I have a database instance running at 10.2.0.4.0. There is a rougue alert-{ORACLE_SID}.log created in $ORACLE_HOME/dbs directory when an instance is started. Show parameter background_dump_dest points to the correct directory - $ORACLE_ADMIN/$ORACLE_SID/bdump wether using spfile or pfile.  To confirm what is happening I shutdown the instance and deleted both alert logs from the two locations and restarted the instance. Again two alert logs were created. Can anyone please advise why this is happening. I have found threads suggesting that logs are created in $ORACLE_HOME/dbs as default if parameters are not set correctly, but this is creating an alert log in two locations at startup.
in $ORACLE_ADMIN/$ORACLE_SID/bdump/alert_DBAASS06.log shows -
[oracle@el64dev03 bdump]$ cat alert_DBAASS06.log
Wed Jul 24 09:29:19 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =30
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.4.0.
System parameters with non-default values:
  processes                = 250
  __shared_pool_size       = 92274688
  __large_pool_size        = 4194304
  __java_pool_size         = 4194304
  __streams_pool_size      = 0
  nls_language             = ENGLISH
  nls_territory            = UNITED KINGDOM
  sga_target               = 327155712
  control_files            = /oradata/10.2.0/DBAASS06/DBAASS06ctrl01.ctl, /oradata/10.2.0/DBAASS06/DBAASS06ctrl02.ctl
  db_block_size            = 8192
  __db_cache_size          = 218103808
  compatible               = 10.2.0.4.0
  log_archive_dest_1       = LOCATION=/oradata/10.2.0/DBAASS06/archive
  log_archive_format       = DBAASS06%t_%s_%r.dbf
  db_file_multiblock_read_count= 16
  undo_management          = AUTO
  undo_tablespace          = UNDO
  remote_login_passwordfile= EXCLUSIVE
  db_domain                = bctn.wheatley-associates.co.uk
  utl_file_dir             = *
  job_queue_processes      = 10
  background_dump_dest     = /orahome/app/oracle/admin/DBAASS06/bdump
  user_dump_dest           = /orahome/app/oracle/admin/DBAASS06/udump
  core_dump_dest           = /orahome/app/oracle/admin/DBAASS06/cdump
  session_max_open_files   = 20
  sort_area_size           = 65536
  db_name                  = DBAASS06
  db_unique_name           = DBAASS06
  open_cursors             = 300
  pga_aggregate_target     = 31457280
PMON started with pid=2, OS id=13977
PSP0 started with pid=3, OS id=13979
MMAN started with pid=4, OS id=13981
DBW0 started with pid=5, OS id=13983
DBW1 started with pid=6, OS id=13985
LGWR started with pid=7, OS id=13987
CKPT started with pid=8, OS id=13989
SMON started with pid=9, OS id=13991
RECO started with pid=10, OS id=13993
CJQ0 started with pid=11, OS id=13995
MMON started with pid=12, OS id=13997
MMNL started with pid=13, OS id=13999
Wed Jul 24 09:29:57 2013
ALTER DATABASE   MOUNT
Wed Jul 24 09:30:01 2013
Setting recovery target incarnation to 2
Wed Jul 24 09:30:01 2013
Successful mount of redo thread 1, with mount id 3614370965
Wed Jul 24 09:30:01 2013
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Wed Jul 24 09:30:01 2013
ALTER DATABASE OPEN
Wed Jul 24 09:30:01 2013
LGWR: STARTING ARCH PROCESSES
ARC0 started with pid=15, OS id=14163
Wed Jul 24 09:30:01 2013
ARC0: Archival started
ARC1: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC1 started with pid=16, OS id=14165
Wed Jul 24 09:30:01 2013
Thread 1 opened at log sequence 14
  Current log# 2 seq# 14 mem# 0: /oradata/10.2.0/DBAASS06/DBAASS06_redo02.log
Successful open of redo thread 1
Wed Jul 24 09:30:01 2013
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Jul 24 09:30:01 2013
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Wed Jul 24 09:30:01 2013
ARC0: Becoming the heartbeat ARCH
Wed Jul 24 09:30:01 2013
SMON: enabling cache recovery
Wed Jul 24 09:30:01 2013
Successfully onlined Undo Tablespace 1.
Wed Jul 24 09:30:01 2013
SMON: enabling tx recovery
Wed Jul 24 09:30:01 2013
Database Characterset is WE8MSWIN1252
Opening with internal Resource Manager plan
where NUMA PG = 1, CPUs = 12
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=17, OS id=14167
Wed Jul 24 09:30:01 2013
Completed: ALTER DATABASE OPEN
[oracle@el64dev03 bdump]$
There is also a trace file created -
[oracle@el64dev03 bdump]$ cat dbaass06_lgwr_13987.trc
/orahome/app/oracle/admin/DBAASS06/bdump/dbaass06_lgwr_13987.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /orahome/app/oracle/product/10.2.0/db_1
System name:    Linux
Node name:      el64dev03.bctn.wheatley-associates.co.uk
Release:        2.6.32-300.39.2.el5uek
Version:        #1 SMP Wed Dec 19 14:56:59 PST 2012
Machine:        x86_64
Instance name: DBAASS06
Redo thread mounted by this instance: 1
Oracle process number: 7
Unix process pid: 13987, image: [email protected]
*** 2013-07-24 09:30:01.622
*** SERVICE NAME:() 2013-07-24 09:30:01.622
*** SESSION ID:(275.1) 2013-07-24 09:30:01.622
Maximum redo generation record size = 156160 bytes
Maximum redo generation change vector size = 150676 bytes
tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x10)
tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x10)
in $ORACLE_HOME/dbs/alert_DBAASS06.log shows -
[oracle@el64dev03 dbs]$ cat alert_DBAASS06.log
Wed Jul 24 09:29:19 2013
Adjusting the default value of parameter parallel_max_servers

Answer 1

Thanks for the reply. The cloned database source looks like it uses spfile on startup on the test box, but as I hadn't checked this at the time it was cloned, the spfile was not copied over, so I'm assuming it would have used the default init.ora created which had the correct dump dest defined. As for the new database, it was created from scratch, so I don't see why this should not work correctly. Unfortunately as I am new to this establishment, I have no history as to how Oracle was installed on either machine or how any of the other databases were created, though I do understand that many may have been cloned.
So while I can't speak for the databases that already existed on the Dev box, it seemed weird that they all appeared to be doing the same thing.  So I found one that hadn't been started for a while for which there was no historic alert log in dbs and started it to see what happened. It had no spfile, started with pfile and did not create a rogue log. I created an spfile and restarted and still no rouge log.  I ran show paremeters and compared to another similar database that had a rougue log, DASSEN02 v DASSEN04 and the only differences were with the instance name and all the files (bdump, cdump etc) existed correctly. Had a further look ref RMAN as some but not all databases had snapcf files in the dbs directory, but again some that had snap files had rougue alert files and others didn't. Also double checked file permissions on the bdump directory, no issues there. Unexplained issues really do bug me, but I think I'll just have to live with not knowing for now, till I have a spare few hours to look at again.