Filed 10-DEC-1999 Updated 13-SEP-2000 Product Oracle Server - Enterprise Edition V7 Product Version 8.1.5.0.1 Platform Generic Platform Version 2.2.10-AC12 Database Version 8.1.5.0.1 Affects Platforms Port-Specific Priority Severe Loss of Service Status Code Bug (Response/Resolution) Base Bug 723579 Fixed in Product Version No Data Problem statement: RDBMS INSTANCE SHUTSDOWN DUE TO AN ORA-601 NOTICED BY PMON PROCESS -------------------------------------------------------------------------------- I've noticed this several times now with my 8.1.5.0.1 EE RDBMS on a Red Hat 6.0 with 2.2.10-ac12 kernel. It occurred once after the creation of the database using the dbassist scripts and then it occurred later in that same day after using the database for some OVS regression database tests and leaving it sit idle for a while and then creating a new user's schema. While creating the new schema the database went down with an ORA-00601 error. The alert log shows: Fri Dec 10 13:56:01 1999 Load Indicator not supported by OS ! Fri Dec 10 13:56:44 1999 Load Indicator not supported by OS ! Fri Dec 10 13:57:27 1999 Load Indicator not supported by OS ! Fri Dec 10 13:57:27 1999 LGWR: prodding the archiver Thread 1 advanced to log sequence 1125 Fri Dec 10 13:57:27 1999 ARC0: received prod Fri Dec 10 13:57:27 1999 Current log# 1 seq# 1125 mem# 0: /oradb/app/oracle/oradata/linux81/redo01.log Fri Dec 10 13:57:27 1999 ARC0: media recovery disabled Fri Dec 10 13:57:32 1999 Thread 1 cannot allocate new log, sequence 1126 Checkpoint not complete Current log# 1 seq# 1125 mem# 0: /oradb/app/oracle/oradata/linux81/redo01.log Fri Dec 10 13:57:33 1999 PMON: terminating instance due to error 601 Instance terminated by PMON, pid = 3638 . This system is a SMP (Dual Pentium 133) Dell system with 128MB of ram. At the time of the second failure the amount of system ram available was still between 4MB to 10MB and very little of the swap device was in use. . The alert log entries from the instance startup where this last error occurred is: . Fri Dec 10 09:57:08 1999 Starting ORACLE instance (normal) Fri Dec 10 09:57:10 1999 LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 Fri Dec 10 09:57:10 1999 LICENSE_MAX_USERS = 0 Starting up ORACLE RDBMS Version: 8.1.5.0.1. System parameters with non-default values: processes = 130 shared_pool_size = 52428800 java_pool_size = 20971520 control_files = /oradb/app/oracle/oradata/linux81/control01.ctl, /oradb/app/oracle/oradata/linux81/control02.ctl db_block_buffers = 8192 db_block_size = 2048 compatible = 8.1.0 log_archive_start = TRUE log_archive_dest_1 = location=/oradb/app/oracle/admin/linux81/arch log_archive_format = %t_%s.dbf log_buffer = 163840 log_checkpoint_interval = 10000 log_checkpoint_timeout = 1800 rollback_segments = r01, r02, r03, r04 remote_login_passwordfile= EXCLUSIVE distributed_transactions = 10 service_names = linux81 instance_name = linux81 mts_dispatchers = (ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))(DIS=1)(SES=254)(CON=254)(TIC=15)(POO=NO)( MUL=NO)(LIS=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=PNPKEY))(ADDRESS=(PROTOCO L=TCP)(HOST=127.0.0.1)(PORT=1521))(ADDRESS=(PROTOCOL=IPC)(KEY=linux81))))(PRE=o racle.aurora.server.SGiopServer) mts_servers = 1 open_links = 4 db_name = linux81 os_authent_prefix = job_queue_processes = 0 job_queue_interval = 60 background_dump_dest = /oradb/app/oracle/admin/linux81/bdump user_dump_dest = /oradb/app/oracle/admin/linux81/udump core_dump_dest = /oradb/app/oracle/admin/linux81/cdump . I've had this problem occur with two fresh installations of Oracle 8.1.5.0.1 where I created the database from scratch using the scripts generated by dbassist. . The last section of the pmon log shows . *** 1999.12.10.13.54.31.953 Load Indicator not supported by OS ! *** 1999.12.10.13.55.15.061 Load Indicator not supported by OS ! *** 1999.12.10.13.56.04.053 Load Indicator not supported by OS ! *** 1999.12.10.13.56.44.091 Load Indicator not supported by OS ! *** 1999.12.10.13.57.30.014 Load Indicator not supported by OS ! error 601 detected in background process . From bug 723579 it seems the suggested fix didn't make 8.1.5 Linux (nor SGI, check bug 1103673). Could you please verify this by disabling MTS ? I am running the database with the dbassist inserted mts parameters commented out so the database will not be running any mts dispatchers. Since this error did not show up immediately I will have to run this for a while before I can state for sure that this works around the problem. The workaround seems to be a valid one. I have not seen any ORA-601 problems since I removed the dbassist inserted mts parameters. Updated bug header then to set bug 723579 as base bug. This basically means that on Linux or SGI one can't use MTS... tough. Patch created based on the base bug723579. It's available in tcpatch:/u01/patch/LINUX/8.1.5/bug1109425 Let me know if this works for you. No, this did not fix the problem. I obtained the patch from tcpatch and it was applied successfully according to the patch.sh script. . The instance ran for about 8 hours before it came down with the following alert log info: . Thu Feb 10 06:51:51 2000 Load Indicator not supported by OS ! Thu Feb 10 06:52:25 2000 Load Indicator not supported by OS ! Load Indicator not supported by OS ! Thu Feb 10 06:53:32 2000 Load Indicator not supported by OS ! PMON: terminating instance due to error 601 Instance terminated by PMON, pid = 958 The patch.sh script is buggy, since it cd's to $ORACLE_HOME/rdbms/lib before actually executing the 'ar cr' commands, so the net result is that you do not archive the new modules in libserver8.a and end up using the same kernel which hits the bug. As you noticed before me ;) Give the patch a new round after deleting . # Create the new proc program. # CDIR=`pwd` cd $ORACLE_HOME/rdbms/lib/ <--- this line must be deleted from patch.sh ar cr $ORACLE_HOME/lib/libserver8.a kmm.o 1>/dev/null 2>&1 ar cr $ORACLE_HOME/lib/libserver8.a ksu.o 1>/dev/null 2>&1 . I don't know if the fix is actually okay but I trust SMATURI :) . Cheers, --alessandro. I followed ASUARDI's comments and I modified the patch.sh and moved the cd line to the $ORACLE_HOME/lib to the line after the last 'ar' command and before the make is run to rebuild the oracle kernel. Without the cd before the make the makefile is not found. I extracted the files from the libserver8.a and verfied the new .o files were part of the libserver8.a used to link the new oracle kernel binary. . I then attempted to startup the oracle instance with the default init.ora file contents that referenced mts. The instance immediately comes down with a ORA-601 now. . The pmon trace file shows: . [oradbaitvport-linux bdump]$ cat pmon_1908.trc Dump file /oradb/app/oracle/admin/linux81/bdump/pmon_1908.trc Oracle8i Enterprise Edition Release 8.1.5.0.1 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production ORACLE_HOME = /oradb/app/oracle/product/8.1.5 System name: Linux Node name: itvport-linux.us.oracle.com Release: 2.2.10-1SGI_17smp Version: #2 SMP Wed Feb 9 17:36:52 PST 2000 Machine: i586 Instance name: linux81 Redo thread mounted by this instance: 1 Oracle process number: 2 Unix process pid: 1908, image: oracleitvport-linux.us.oracle.com (PMON) . *** 2000.02.11.14.28.54.122 *** SESSION ID:(1.1) 2000.02.11.14.28.54.119 error 601 detected in background process [oradbaitvport-linux bdump]$ . The end of the alert log shows: . sql: prodding the archiver Fri Feb 11 14:28:37 2000 ARC0: received prod Fri Feb 11 14:28:37 2000 SMON: enabling cache recovery Fri Feb 11 14:28:37 2000 ARC0: media recovery disabled Fri Feb 11 14:28:42 2000 SMON: enabling tx recovery Fri Feb 11 14:28:44 2000 Completed: alter database open Fri Feb 11 14:28:54 2000 PMON: terminating instance due to error 601 Instance terminated by PMON, pid = 1908 . When I remove the mts parameters from the init.ora file the instance starts up with the updated oracle kernel, but now it won't stay up at all with mts parameters in the init.ora file. I have a customer running into this same issue. Should I file a new bug or are you close to a fix for this that I should wait? Thanks! Robert had it right for patch.sh, of course ! . Anyway I can't reproduce on my 8.1.5.0.2 where I have configured the following MTS params in init.ora: . mts_dispatchers="(protocol=tcp)(dispatchers=1)" mts_dispatchers="(protocol=tcp)(presentation=oracle.aurora.server.GiopServer)(d ispatchers=1)" mts_dispatchers="(protocol=tcp)(presentation=oracle.aurora.server.SGiopServer)( dispatchers=1)" . And also connected to my shared servers via this in tnsnames.ora . self8i = (description= (address= (PROTOCOL = TCP)(HOST = 127.0.0.1)(PORT = 1521)) (connect_data= (service_name=linux815) (instance_name=test) ) ) . And made sure I actually connected to the shared servers, see v$session: SQL> select server, program from v$session; . SERVER PROGRAM --------- ------------------------------------------------ DEDICATED oracleprincess (PMON) DEDICATED oracleprincess (DBW0) DEDICATED oracleprincess (LGWR) DEDICATED oracleprincess (CKPT) DEDICATED oracleprincess (SMON) DEDICATED oracleprincess (RECO) SHARED sqlplusprincess (TNS V1-V3) DEDICATED ? princess (TNS V1-V3) . 8 rows selected. . I'd gladly test your configuration if you send me init.ora, listener.ora, tnsnames.ora and sqlnet.ora. I'd put this back to 35 but will leave this to SMATURI and you to decide. Of the two bugs that I filed against 8.1.5.0.0 on Linux this is not the most important one yet it seems to receive the most attention. I really need bug 1109125 (ORA-600 from PL/SQL) fix before this one. I have a workaround for my situation since I didn't intend on using MTS. This would still be a problem for actual customers. Hi Robert - I tested this on another box at a customer site (81502 also) and it works, as on my machine. I am setting the bug status to 35, since the patch seems okay. If you still have problems maybe you can consider upgrading to 81502 and try again ? Any information on when 81502 will be available or if this will be backported to 81501? Thanks! It is not fixed with 8.1.5.0.2 . My alert log file has the following: . Tue Apr 4 22:04:54 2000 PMON: terminating instance due to error 601 Instance terminated by PMON, pid = 24995 Robert - do you see the Load Indicator messages still ? Because I don't. If you do, could you please check that 81502 hasn't overwritten the patch ? . 81502+1109425 should look like this: . [oracleprincess lib]$ ar tv libserver8.a|grep kmm.o rw-r--r-- 41/100 65912 Feb 11 16:01 2000 kmm.o [oracleprincess lib]$ ar tv libserver8.a|grep ksu.o rw-r--r-- 41/100 82776 Feb 11 16:02 2000 ksu.o . . Where are these patches located??? Here is the entire pmon trace file during the latest ORA-601 with 8.1.5.0.2 installed. . Dump file /oradb/app/oracle/admin/linux81/bdump/pmon_24995.trc Oracle8i Enterprise Edition Release 8.1.5.0.2 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production ORACLE_HOME = /oradb/app/oracle/product/8.1.5 System name: Linux Node name: itvport-linux.us.oracle.com Release: 2.2.10-1SGI_17smp Version: #2 SMP Wed Feb 9 17:36:52 PST 2000 Machine: i586 Instance name: linux81 Redo thread mounted by this instance: 1 Oracle process number: 2 Unix process pid: 24995, image: oracleitvport-linux.us.oracle.com (PMON) . *** 2000.04.04.22.04.54.041 *** SESSION ID:(1.1) 2000.04.04.22.04.54.038 error 601 detected in background process . Please remember I'm using the dbassist generated parameters from the install of 8.1.5 to trigger this behavior. Here is the diff of the init.ora file from the dbassist generated init.ora file and the one that allows the instance to run. . diff initlinux81.ora.mts initlinux81.ora 64c64 < mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" --- > # mts_dispatchers = "(PROTOCOL=TCP)(PRE=oracle.aurora.server.SGiopServer)" 69c69 < mts_servers = 1 --- > # mts_servers = 1 . SCAPO: The 8.1.5.0.2 patch is located on linux.us.oracle.com web site as a download file. Sorry Robert to bother you again - am I correct in assuming that 1) you installed 81502 and _then_ patch 1109425, and your 'ar tv' output matches mine 2) you don't see anymore the Load Indicator messages 3) PMON crashes in a short while after instance start ? If 3) isn't true could you please set me straight on what is needed to trigger this behavior ? Leave instance up for a while ? Do something special ? I notice that you're running a SMP kernel - mine's UP... Thanks. *** RBALLER 04/11/00 01:09 pm *** (CHG: Sta->11) *** RBALLER 04/11/00 01:09 pm *** [oracleitvport-linux lib]$ ar tv libserver8.a|grep kmm.o rw-r--r-- 60000/55536 65912 Feb 9 21:01 2000 kmm.o [oracleitvport-linux lib]$ ar tv libserver8.a|grep ksu.o rw-r--r-- 60000/55536 82776 Feb 9 21:01 2000 ksu.o . The files from the patch tar file have the same date/time stamp so I do have the patch in place. . No I don't see any load indicator error messages. . I started my database at 'Tue Apr 4 16:40:36 2000' and the ORA-601 took place in an idle instance at 'Tue Apr 4 22:04:54 2000'. . No one is connected to this instance at all when the ORA-601 occurs. I installed a uniprocessor kernel on this system and that did not change the behavior of the problem. Good ! I will leave my database alive overnight and see if it survives. It's 6h12 since my TNS listener is open and over 8hrs that the db is open, I have 4 services registered though I made no connection over the listener to the database. I've been working on the database in the morning doing performance tuning and left it idling in the afternoon. No problem at all. . LSNRCTL for Linux: Version 8.1.5.0.0 - Production on 13-APR-00 18:47:43 . (c) Copyright 1998 Oracle Corporation. All rights reserved. . Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=test))(PROTOCOL_STACK=(PRESENTATION=TT C)(SESSION=NS))) Services Summary... test has 4 service handler(s) DEDICATED SERVER established:0 refused:0 LOCAL SERVER DISPATCHER established:0 refused:0 current:0 max:254 state:ready D000 (ADDRESS=(PROTOCOL=tcp)(HOST=princess)(PORT=1039)) DISPATCHER established:0 refused:0 current:0 max:254 state:ready D001 (ADDRESS=(PROTOCOL=tcp)(HOST=princess)(PORT=2222)) Presentation: oracle.aurora.server.SGiopServer DISPATCHER established:0 refused:0 current:0 max:254 state:ready D002 (ADDRESS=(PROTOCOL=tcp)(HOST=princess)(PORT=2223)) Presentation: oracle.aurora.server.GiopServer The command completed successfully. . I am making my oracle executable available to you on a Support machine, so you can come and get it if you wish. I'm emailing you the details. . Executable is the obvious oracle.gz there. I know we're at extremes here, but if here it works and there it doesn't we need to find out where the difference IS ! Dang... My instance has now been open for 23hrs and it still works without a hitch. Service updates can be found in the listener.log file at 10' intervals. [oracleitvport-linux bdump]$ cat pmon_29493.trc Dump file /oradb/app/oracle/admin/linux81/bdump/pmon_29493.trc Oracle8i Enterprise Edition Release 8.1.5.0.2 - Production With the Partitioning and Java options PL/SQL Release 8.1.5.0.0 - Production ORACLE_HOME = /oradb/app/oracle/product/8.1.5 System name: Linux Node name: itvport-linux.us.oracle.com Release: 2.2.10-1SGI_17smp Version: #2 SMP Wed Feb 9 17:36:52 PST 2000 Machine: i586 Instance name: linux81 Redo thread mounted by this instance: 1 Oracle process number: 2 Unix process pid: 29493, image: oracleitvport-linux.us.oracle.com (PMON) . *** 2000.04.14.11.25.58.016 *** SESSION ID:(1.1) 2000.04.14.11.25.58.013 error 601 detected in background process [oracleitvport-linux bdump]$ . I started an instance without the mts parameters in the initlinux81.ora file using your oracle binary and the instance stayed up for nearly 24 hours without a problem. I then put in place the initlinux81.ora that had the mts parameters and the instance was restarted. The instance came crashing down within minutes. . You can login to this machine. . hostname: itvport-linux.us.oracle.com user id: oracle password: manager ORACLE_SID: linux81 Okay, logical next move is that I try your parameters on my system - will do. Just in case, you relinked the TNS listener after regenerating the libclntsh, did you ? I'm not sure it's relevant, but... Stay tuned. I let my database / listener run for 7hrs with your params (mts, compatible and listener stuff) but still everything worked. I will peek at your box... I logged on your machine and experienced the PMON crash (heh) in a real short time. I now relinked the lsnrctl and tnslsnr though and the database hasn't died yet - after a whopping 20' uptime ;) I noticed however a strangeness on your machine: though 'date' reports a "good" date, 'ps' seems to think today is 3/16... . [oracleitvport-linux log]$ ps -ef|grep pmon oracle 32598 1 0 Mar16 ? 00:00:00 ora_pmon_linux81 . If everything is okay this way next step is to replace my oracle kernel with yours back again and pray everything works... Approaching 2hrs and database is up - perhaps the tnslsnr relink was needed after all... I'm leaving for Easter holidays and will be back on 5/3 so if any further investigation is needed the PL people shall dive in... In the end PMON crashed :( after 2h30' approx... I give up. Maybe dumping a systemstate when we hit ORA-601 via an event in init.ora may be useful, but I can't be of any further help. I see no obvious reason why PMON crashes - no traces, no core files, nothing in the alert.log. Ball to Linux PL... I have ct. that notice this bug on metalink, and he is asking does this bug reproduce on 8.1.6 ? Is there a solution as IHAC who is facing the same problem and he wants to go live as soon as possible but I'm reluctant on the way its crashing . The config is on Redhat 6.1 with oracle standard edition 8.1.5.0.2 and mts enabled . The connectivity is using php and apache and oci calls to the oracle database . I have developed a benchmarking routine which simulates the connections to the webserver which in turn to the database however this works ok with dedicated and crashes the instance with 601 (pmon) with mts . However this shop will be having something like 200+ simultaneous connections and the db crashes on 50 simulated ones . In dedicated server configuration the system load goes in the 30's - 40's and then we have a lot of oracle server processes which are zombies .. Can we have a patch on this and why is the instance crashing ... strangely this problem was not there when performing the installation on suse linux 6.3 . Will try to provide the errorstack on this !!! Comments and fixes please ... following is the stack trace for the ora-601 from pmon_2887.trc ksedmp()+132 CALL ksedst()+0 ksddoa()+125 CALLr 00000000 ksdpcg()+175 CALL ksddoa()+0 ksdpec()+171 CALL ksdpcg()+0 ksfpec()+122 CALL ksdpec()+0 kgesev()+84 CALLr 00000000 BFFFE434 ? 813C9E1 ? ksesec0()+24 CALL kgesev()+0 ksliwat()+2160 CALL ksesec0()+0 kslwaitns()+24 CALL ksliwat()+0 kskthbwt()+156 CALL kslwaitns()+0 kslwait()+26 CALL kskthbwt()+0 ksbsrv()+1250 CALL kslwait()+0 29A ? 20BAA078 ? 12C ? 1 ? 91B1068 ? 21 ? kmmssv()+29 CALL ksbsrv()+0 0 ? 0 ? 0 ? 0 ? 0 ? kmmlsa()+252 CALL kmmssv()+0 kmmlod()+867 CALL kmmlsa()+0 ksucln()+720 CALL kmmlod()+0 ksbrdp()+560 CALLr 00000000 9203918 ? 200020E8 ? 804C696 ? 0 ? opirip()+463 CALL ksbrdp()+0 opidrv()+968 CALL opirip()+0 sou2o()+22 CALL opidrv()+0 main()+373 CALL sou2o()+0 Also the same problem does not occur on Suse version 6.3 on which I have another customer running live .. Is this a redhat specific problem ?? I'll be testing the same on 8.1.6 on linux and posting the results here .. Can you try the same configuration on RedHat 6.2 ? Is this a redhat specific issue . I do not currently have a copy of Redhat 6.2 but will try to procure one .. Or is it possible the problem could be circumvented by upgrading some packages ?? You mentioned that, you do not see this problem with SuSe 6.3 that bundles glibc 2.1.3, which has fixes for the threads library. Since, only RedHat 6.2 bundles glibc 2.1.3 and not the earlier releases of RedHat, suggesting you to give it a try. This could suggest a reason for this kind of error and will try this and post the updates . thanks smaturi for the tip . In response to "Redhat specific issue", it doesn't appear so. IHAC running in to this problem. They are not using Redhat (using Linux v2.2.14) and Oracle EE V8.1.6. They also hit this bug running Linux 2.2.14 and Oracle EE 8.1.5. 2.2.14 is the Linux kernel version. All the current distributions (RedHat, Caldera, TurboLinux, Suse etc.,) of Linux bundle kernel 2.2.x. I managed to procure a CD of redhat 6.2 . I'm thinking on the following lines a)upgrade just the glibc library to 2.1.3 and then try the regression testing This is a home bred program which spawns multiple connections to apache and which connects via php to oracle) .This program used to crash the server when the no of connections was greater than 50 . I have 30 mts servers running with 2 dispatchers. Also TTILTON 2.2.14 is the kernel version and not the distribution . Which distribution is this ?? . Will be trying with redhat 6.2 then if the glibc library upgrade was not enough . We have to relink oracle after the glibc upgrade right ?? Results on monday I managed to procure a CD of redhat 6.2 . I'm thinking on the following lines a)upgrade just the glibc library to 2.1.3 and then try the regression testing This is a home bred program which spawns multiple connections to apache and which connects via php to oracle) .This program used to crash the server when the no of connections was greater than 50 . I have 30 mts servers running with 2 dispatchers. Also TTILTON 2.2.14 is the kernel version and not the distribution . Which distribution is this ?? . Will be trying with redhat 6.2 then if the glibc library upgrade was not enough . We have to relink oracle after the glibc upgrade right ?? Results on monday My customer is using Debien. It's my understanding this is not one of the distributions Oracle has certified against. Tried the same thing on Redhat 6.2 and the instance crashed after 50 connections . I think we need to do something about this as the instance crashes ( and mts is a feature which is supposed to work !!!) The stack trace is same as the previous time. Nonetheless here it is ksedmp()+132 CALL ksedst()+0 ksddoa()+125 CALLr 00000000 ksdpcg()+175 CALL ksddoa()+0 ksdpec()+171 CALL ksdpcg()+0 ksfpec()+122 CALL ksdpec()+0 kgesev()+84 CALLr 00000000 BFFFE2D4 ? 813C971 ? ksesec0()+24 CALL kgesev()+0 ksliwat()+2160 CALL ksesec0()+0 kslwaitns()+24 CALL ksliwat()+0 kskthbwt()+156 CALL kslwaitns()+0 kslwait()+26 CALL kskthbwt()+0 ksbsrv()+1250 CALL kslwait()+0 29C ? 50926FC0 ? 12C ? 1 ? 91B1048 ? 1F ? kmmssv()+29 CALL ksbsrv()+0 0 ? 0 ? 0 ? 0 ? 0 ? kmmlsa()+252 CALL kmmssv()+0 kmmlod()+867 CALL kmmlsa()+0 ksucln()+720 CALL kmmlod()+0 ksbrdp()+560 CALLr 00000000 9203768 ? 200020E8 ? 804C65A ? 0 ? opirip()+463 CALL ksbrdp()+0 opidrv()+968 CALL opirip()+0 Could we have a solution for this please as trying connections with dedicated server causes the system to slow down and there are many zombie processes as a consequence. Also TTILTON Debian is not certified . check linuxsbu.us.oracle.com for the certification . To prevent the zombie processes in dedicted server I tried to connect using bequesth ( with the detact option ) and then there were no zombies but many customers have a setup where the webserver is on a separate machine and hence the connection has to go via sqlnet . Does this have a fix / workaround or do we ask the customer to go for another platform such as solaris ... Comments The maintenence and support of Oracle releases on Linux is transferred to DDR group and this transition is in progress. These problems will be resolved by that team. Right now the contacts in the DDR group are vsubramaus and rbeckerus. Support Note: there is a patch for this problem on tcpatch (see above) tcpatch:/u01/patch/LINUX/8.1.5/bug1109425 and I can report it works for my cst. , see Will apply this patch and try . Note that I had applied this patch on 8.1.5.0.2 on Redhat 6.1 and still the instance went down after a few hours. Also this patch was for disabling the "Load indicator not suported by O.S " message from recurring in the alert log right ?? My Customer had applied tcpatch:/u01/patch/LINUX/8.1.5/bug1109425, and it doesn't work. . It's not possible work with MTS in 8.1.5 for LINUX. It's a servere problem for my customer, because he needs to work with Java Beans. MTS is mandatory for EJB and CORBA. Can you try this with 8.1.6.1 ? Thanks. Please provide more information - what distribution is your customer running on? Does this reproduce with 8.1.6.1 on Redhat 6.2? My customer es working with Redhat 6.0 and 8.1.5.0.2. We had sent him 8.1.6 release. He is going to test with 8.1.6 on RedHad 6.2 Change status to 11 for read I have a customer who has encountered this on Redhat 6.2, running 8.1.6.1. Hi , I have a customer hitting this problem as well. The patch above does not help. What's more, his workaround of trying prespawned servers does not work either due to bug 1109137 - which is only fixed in 8.1.6.2 which is not available. this is becoming more of a problem. My Ct. is on 8.1.6.0 and RedHat 6.0, same problem... BDE Update: There has been a mistake with the assignment of this bug. It is currently assigned to a Support Analyst in Spain. I'm not sure who this should be assigned to in DDR, so I will assign it back to RDBMSREP. My customer had found a reproducible test case 1- Configure MTS as follows. mts_servers = 2 mts_max_servers = 4 . 2- Execute example: $ORACLE_HOME/javavm/demo/Examples/ejb/basic/helloworld Then create a script that runs simultaneously 8 instances of this same example. After a few seconds oracle instance hangs, generating the ORA-601 and pmon crash . If you configure MTS : mts_servers = 4 mts_max_servers = 4 Then instance take a long time to crash, but finally crash . I hope it helps As per discussion with SMATURI, Linux Port specific bugs should be assigned to EPDREP. Thanks Reproduced on RedHat 6.2 8.1.6.2. After commenting out large_pool_size and appropriately increasing shared_pool_size in init.ora, the error disappeared.