tag:blogger.com,1999:blog-18037024.post4670854723323714670..comments2024-02-16T14:33:11.277+01:00Comments on Annals of Oracle's Improbable Errors: Dispatcher process taking 99% of CPU on Oracle XE after an Apex requestByte64http://www.blogger.com/profile/15629209362377395020noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-18037024.post-70254634900477096082017-03-27T09:04:56.071+02:002017-03-27T09:04:56.071+02:00I don't remember if it happened once in the la...I don't remember if it happened once in the last 3 years, it's been a long time since the last occurrence, my instances are running on top of Amazon Linux therefore I'm asking myself if the problem lies somewhere in Ubuntu, which was the same Linux flavor my Oracle XE databases were running on.<br />Byte64https://www.blogger.com/profile/15629209362377395020noreply@blogger.comtag:blogger.com,1999:blog-18037024.post-1721755164313456052017-03-25T00:10:26.264+01:002017-03-25T00:10:26.264+01:00This issue is still present on Ubuntu (16.10): Ora...This issue is still present on Ubuntu (16.10): Oracle XE11g + EPG + Apache as proxy.<br />It seems oracle did patch this - but only for windows.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-18037024.post-89872780479049613702015-04-27T11:46:27.894+02:002015-04-27T11:46:27.894+02:00You can't switch off shared servers if you are...You can't switch off shared servers if you are relying on EPG, you need to set up either the Apex Listener or Oracle HTTP server (the latter doesn't work with XE as far as I know). <br />I must say that since I moved to Oracle XE11g, I didn't encounter this problem anymore, so thumbs up for Oracle XE11g + EPG + Apache as proxy.Byte64https://www.blogger.com/profile/15629209362377395020noreply@blogger.comtag:blogger.com,1999:blog-18037024.post-89315736947285694252015-04-27T07:32:31.412+02:002015-04-27T07:32:31.412+02:00Thanks for the post.
Another way can be to disable...Thanks for the post.<br />Another way can be to disable the shared server processes totally.<br />In this case there is no dispatcher process at all, so there is no CPU consuming bug. I hope.<br />For example:<br />alter system set dispatchers = '' scope = both;<br />alter system set shared_servers = 0 scope = both;<br />and restart<br />The dedicated mode will work without any problems CsGnoreply@blogger.comtag:blogger.com,1999:blog-18037024.post-3753827707629278132012-04-23T21:47:31.175+02:002012-04-23T21:47:31.175+02:00Hi Christoph,
I was hoping that in 11.2 that bug h...Hi Christoph,<br />I was hoping that in 11.2 that bug had been fixed (by the way, is that a full-fledged 11gR2 or is it XE?).<br />I have been monitoring my production instances for nearly 2 years now and I still can't the "smoking gun", sometimes they keep running for a week seamlessly, sometimes I have to kill the runaway process twice in a day and there is no clear indication of Byte64https://www.blogger.com/profile/15629209362377395020noreply@blogger.comtag:blogger.com,1999:blog-18037024.post-81709479387402707142012-04-23T17:27:38.066+02:002012-04-23T17:27:38.066+02:00Excellent post! Your clear instructions were a lif...Excellent post! Your clear instructions were a life saver. I had exactly the same problem on a 11.2.0.3 database running Apex on the PL/SQL gateway. The system has very low usage. I'm quite curious what caused the dispatcher process to go crazy like that.<br />The alter system shutdown didn't work, so I did kill -9. <br />Thanks again,<br />ChristophChristoph Rueprichhttp://ruepprich.wordpress.comnoreply@blogger.comtag:blogger.com,1999:blog-18037024.post-65597926777319221092010-03-09T07:53:56.288+01:002010-03-09T07:53:56.288+01:00Hi Flavio,
thanks a lot for your post. This bug is...Hi Flavio,<br />thanks a lot for your post. This bug is really annoying. It totally freaks you out, when you see it the first time. Your workaround works well on our SuSE 10.3 system. I have a few comments though:<br /><br />Sorry, you´ve missed a bracket ;-) <i> ALTER SYSTEM SET DISPATCHERS = '(PROTOCOL=TCP)(DISPATCHERS=1<b>)</b>(INDEX=0)'; </i><br /><br />On our system, the process Anonymousnoreply@blogger.com