DDE: Problem Key 'ORA 445' was completely flood controlled

Question

OK, I got this after a bunch of background process did not starts, I see there is a bug and patch for products that can be patched. Anybody else see it? Anything to do besides 3 fingered salute? Anyone know anything?

Answer 1

Virtual machine (some MS product), XP Professional SP3.
A few bits of alert log:
Fri May 25 18:47:09 2012
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production.
Using parameter settings in server-side spfile D:\ORACLEXE\APP\ORACLE\PRODUCT\11.2.0\SERVER\DATABASE\SPFILEXE.ORA
System parameters with non-default values:
  sessions                 = 172
  event                    = "10795 trace name context forever, level 2"
  sga_max_size             = 512M
  memory_target            = 760M
  memory_max_target        = 760M
  control_files            = "D:\ORACLEXE\APP\ORACLE\ORADATA\XE\CONTROL.DBF"
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "D:\oraclexe\app\oracle\fast_recovery_area"
  db_recovery_file_dest_size= 10G
  undo_management          = "AUTO"
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=XEXDB)"
  shared_servers           = 4
  job_queue_processes      = 4
  audit_file_dest          = "D:\ORACLEXE\APP\ORACLE\ADMIN\XE\ADUMP"
  db_name                  = "XE"
  open_cursors             = 300
  parallel_servers_target  = 0
  diagnostic_dest          = "D:\ORACLEXE\APP\ORACLE"
Fri May 25 18:47:24 2012
PMON started with pid=2, OS id=488
Fri May 25 18:47:24 2012
PSP0 started with pid=3, OS id=324
Fri May 25 18:47:25 2012
VKTM started with pid=4, OS id=1940 at elevated priority
VKTM running at (10)millisec precision with DBRM quantum (100)ms
Fri May 25 18:47:25 2012
GEN0 started with pid=5, OS id=1092
Fri May 25 18:47:25 2012
DIAG started with pid=6, OS id=1180
Fri May 25 18:47:25 2012
DBRM started with pid=7, OS id=1872
Fri May 25 18:47:25 2012
DIA0 started with pid=8, OS id=1196
Fri May 25 18:47:25 2012
MMAN started with pid=9, OS id=1212
Fri May 25 18:47:25 2012
DBW0 started with pid=10, OS id=1208
Fri May 25 18:47:25 2012
LGWR started with pid=11, OS id=1392
Fri May 25 18:47:25 2012
CKPT started with pid=12, OS id=1396
Fri May 25 18:47:25 2012
SMON started with pid=13, OS id=1456
Fri May 25 18:47:25 2012
RECO started with pid=14, OS id=1048
Fri May 25 18:47:25 2012
MMON started with pid=15, OS id=1476
Fri May 25 18:47:25 2012
MMNL started with pid=16, OS id=1480
Fri May 25 18:47:25 2012
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 4 shared server(s) ...
ORACLE_BASE from environment = D:\oraclexe\app\oracle
Fri May 25 18:47:28 2012
alter database mount exclusive
Successful mount of redo thread 1, with mount id 2665341696
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: alter database mount exclusive
alter database open
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
read 1670 KB redo, 196 data blocks need recovery
Started redo application at
Thread 1: logseq 865, block 47980
Recovery of Online Redo Log: Thread 1 Group 1 Seq 865 Reading mem 0
  Mem# 0: D:\ORACLEXE\APP\ORACLE\FAST_RECOVERY_AREA\XE\ONLINELOG\O1_MF_1_76Z8WGYF_.LOG
Completed redo application of 1.20MB
Completed crash recovery at
Thread 1: logseq 865, block 51320, scn 1627729638
196 data blocks read, 196 data blocks written, 1670 redo k-bytes read
Fri May 25 18:47:35 2012
Thread 1 advanced to log sequence 866 (thread open)
Thread 1 opened at log sequence 866
  Current log# 2 seq# 866 mem# 0: D:\ORACLEXE\APP\ORACLE\FAST_RECOVERY_AREA\XE\ONLINELOG\O1_MF_2_76Z8WJ0N_.LOG
Successful open of redo thread 1
Fri May 25 18:47:36 2012
SMON: enabling cache recovery
Fri May 25 18:47:39 2012
[776] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:135218 end:136015 diff:797 (7 seconds)
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
Opening with Resource Manager plan: INTERNAL_PLAN_XE
Fri May 25 18:47:40 2012
Starting background process VKRM
Fri May 25 18:47:40 2012
VKRM started with pid=23, OS id=2056
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Fri May 25 18:47:42 2012
QMNC started with pid=24, OS id=2064
Completed: alter database open
Fri May 25 18:47:53 2012
Starting background process CJQ0
Fri May 25 18:47:53 2012
CJQ0 started with pid=26, OS id=3048
Fri May 25 18:47:54 2012
db_recovery_file_dest_size of 10240 MB is 8.43% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Fri May 25 18:52:43 2012
Starting background process SMCO
Fri May 25 18:52:43 2012
SMCO started with pid=22, OS id=3840
Fri May 25 19:03:01 2012
Time drift detected. Please check VKTM trace file for more details.
Fri May 25 20:03:49 2012
XDB installed.
XDB initialized.
Fri May 25 22:00:00 2012
Setting Resource Manager plan SCHEDULER[0x30FB]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan SCHEDULER[0x30FC]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Sat May 26 23:00:00 2012
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_j000_2824.trc:
ORA-12012: error on auto execute of job "SYS"."BSLN_MAINTAIN_STATS_JOB"
ORA-06550: line 1, column 807:
PLS-00201: identifier 'DBSNMP.BSLN_INTERNAL' must be declared
ORA-06550: line 1, column 807:
PL/SQL: Statement ignoreds...
Mon Jun 11 22:59:52 2012
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc  (incident=34579):
ORA-00445: background process "J000" did not start after 120 seconds
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:01:58 2012
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_mmon_1476.trc  (incident=34578):
ORA-00445: background process "m000" did not start after 120 seconds
Mon Jun 11 23:04:04 2012
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc  (incident=34580):
ORA-00445: background process "J000" did not start after 120 seconds
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:06:10 2012
DDE: Problem Key 'ORA 445' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Mon Jun 11 23:08:16 2012
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:12:45 2012
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:15:41 2012
DDE: Problem Key 'ORA 445' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Mon Jun 11 23:17:47 2012
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:21:58 2012
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:26:36 2012
Process J000 died, see its trace file
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:28:42 2012
DDE: Problem Key 'ORA 445' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
Mon Jun 11 23:30:47 2012
kkjcre1p: unable to spawn jobq slave process
Errors in file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc:
Mon Jun 11 23:35:40 2012
DDE: Problem Key 'ORA 445' was completely flood controlled (0x6)
Further messages for this problem key will be suppressed for up to 10 minutes
kkjcre1p: unable to spawn jobq slave processThe beginning of a trace file:
Trace file D:\ORACLEXE\APP\ORACLE\diag\rdbms\xe\xe\trace\xe_cjq0_3048.trc
Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production
Windows XP Version V5.1 Service Pack 3
CPU                 : 2 - type 586, 2 Physical Cores
Process Affinity    : 0x0x00000000
Memory (Avail/Total): Ph:1182M/2047M, Ph+PgF:1825M/2661M, VA:1230M/2047M
Instance name: xe
Redo thread mounted by this instance: 1
Oracle process number: 26
Windows thread id: 3048, image: ORACLE.EXE (CJQ0)
*** 2012-05-25 22:00:00.096
*** SESSION ID:(14.3) 2012-05-25 22:00:00.096
*** CLIENT ID:() 2012-05-25 22:00:00.096
*** SERVICE NAME:(SYS$BACKGROUND) 2012-05-25 22:00:00.096
*** MODULE NAME:() 2012-05-25 22:00:00.096
*** ACTION NAME:() 2012-05-25 22:00:00.096
Setting Resource Manager plan SCHEDULER[0x30FB]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FC]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FD]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F7]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F8]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F9]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FA]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FB]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FC]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FD]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F7]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F8]:DEFAULT_MAINTENANCE_PLAN via scheduler window
*** 2012-06-05 22:00:00.047
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30F9]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FA]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FB]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FC]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Setting Resource Manager plan SCHEDULER[0x30FD]:DEFAULT_MAINTENANCE_PLAN via scheduler window
ksktopplmod:error[439] is caught
Waited for process J000 to initialize for 60 seconds
*** 2012-06-11 21:16:46.903
Process diagnostic dump for J000, OS id=2532
os thread scheduling delay history: (sampling every 1.000000 secs)
  0.001579 secs at [ 21:16:46 ]
    NOTE: scheduling delay has not been sampled for 0.296929 secs  0.001483 secs from [ 21:16:41 - 21:16:47 ], 5 sec avg
  0.002854 secs from [ 21:15:47 - 21:16:47 ], 1 min avg
  0.003136 secs from [ 21:13:38 - 21:16:47 ], 5 min avg
Memory (Avail/Total): Ph:708M/2047M, Ph+PgF:1723M/2661M, VA:1211M/2047M
CPU Load: 0%                                                                 
Stack:
------------------- Call Stack Trace ---------------------
calling location                                                 entry point                                                      arg #1   arg #2   arg #3   arg #4 
7C90E514                                                         00000000                                                         00000000 00000000 00000000 00000000
7C8115F4                                                         7C80B7EC                                                         7ff98c00 3188e444 07b6cc3b 310af8f9
_sdbgrfude_dir_exists()+49                                       00000000                                                         310af8f9 310afb44 00000100 3188e734
__VInfreq__dbgrgad_get_adrbase_directory()+342                   _sdbgrfude_dir_exists()                                          3188e458 310af8f9 00000002 00000000
0803823D                                                         08065AD2                                                         00000004 00000000 310af8f9 000001ff
10085B2A                                                         1028D8B6                                                         0b4b1028 3188f570 3188f391 00000100
100842D4                                                         10085A1C                                                         0b4b1028 3188f678 3188ee64 3188ead0
100838AC                                                         10084104                                                         0b4b1028 3188f678 3188ee64 0b4b1028
10083626                                                         10083634                                                         0f9b9440 3188f678 3188fd50 00000100
100835EF                                                         10083610                                                         0f9b9440 3188f678 3188fd50 00000100
_npinli()+77                                                     _nlstdgo()                                                       0f9b9440 00000000 00000000 00000000
_opiinit()+150                                                   _npinli()                                                        00000001 00000000 00000000 00000000
_opimai_real()+212                                               _opiinit()                                                       30dc00b0 ffffffff 00000000 00000001
_opimai()+125                                                    _opimai_real()                                                   00000003 3188feb0 00000000 00000000
_BackgroundThreadStart@4()+520                                   _opimai()                                                        00000003 3188ff4c 89801ba8 000009e4
7C80B726                                                         00000000                                                         0b49b128 00000027 0b78d4cf 0b49b128
00000000                                                         00000000                                                         00000000 00000000 00000000 00000000
---------------- End of Call Stack Trace -----------------Since this is XE and a known bug, my expectations aren't too high. Should I just reboot every week?
There is a dblink that comes in every half hour and deletes and adds around 4K rows in a table. Everything else is just a bored database playing with itself.
I see from MOS ORA-00445 Is Reported While Waiting Too Long To Spawn A Process [ID 1382349.1] an event to set. Should I? Or should I make some dummy process to give the db something to do? (The thinking on the latter is that with so little for the db to do, Windows is making startup of normal things take longer).
Bug 9871302 by the way, buried in there is a mention of background processes failing to start.
Edited by: jgarry on Jun 13, 2012 9:28 AM (corrected xp sp)