Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Oracle, multi thread and heavy load leads to access violation in ORA73.dll

Re: Oracle, multi thread and heavy load leads to access violation in ORA73.dll

From: Michel Gauthier <qgmi1_at_clic.net>
Date: Mon, 13 Dec 1999 14:32:18 GMT
Message-ID: <Sr754.30196$0c2.326726@carnaval.risq.qc.ca>


I'm not going to discuss Henry's problem exactly, but simply share our experience with MTS.

We used MTS on a HP3000 with 7.2.3 for about haf a year. We used it because it made connections faster (and gave users illusion the app fast fast) and the SQL*Net PRESPAWN option was not available on our O/S. But after 5 or 6 month, when we got bored enough of having "end of communication channel" errors, we switched back to a standard listener configuration. Connection became slower, but after that change, we stopped having problem with C/S application, and I have no doubdt it was because we left MTS.

From what I read and heard, MTS had been developped by Oracle to suits applications where there are a very lot of simultaneous sessions that are very few active. Let's say 500 concurrent users which make 20 trsanctions/hour (avg). In this kind of app, it would be very resource consuming that each user has its own server process (500 !). With MTS, you may configure about 30 dispatchers and 30 shared server process (rule of thumb) which is a lot less than 500.

Since your app seems to be sometimes very loaded, I would guess it is really not the kind expected for a MTS configuration. With MTS, a client request could be served by server process #1, and its next request could be served by server process #24, you never know. During its whole life, a session could be served by many different processes on the host server: this means, in the communication perspective, a lot of context switch activity. Plus, with MTS, session information (called UGA I think) is stored in the SGA instead of the server process, which require configuring a slightly bigger SGA. So, I encourage you not just to change your MTS parms, but instead to stop using MTS (at least for a test). Communication problems are quite hard to troubleshoot, and MTS makes an intensive use of communication falicities. So, I wouldn't be surprised it solves your problem.

Michel Gauthier
Donohue Inc.
Suuronen Henri <henri.suuronen_at_ej.insta.fi> wrote in message news:3854ACF6.AA9482AD_at_ej.insta.fi...
> We haven't tryid it without the MTS because it has seemed like a
> client-side problem. Is the only other alternative to use dedicated
> method?
>
> We will try adjusting the MTS parameters and see if that helps.
>
> Thank you for your suggestions!
>
> --
> Henri Suuronen
>
>
> Michael Daskaloff wrote:
> >
> > Hi,
> > does this happen without MTS?
> > I think you must increase the dispatchers count, and several other
> > parameters on the HP.
Received on Mon Dec 13 1999 - 08:32:18 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US