Re: application problems

"Ben" <benalvey_at_yahoo.com> wrote in message news:a4f2d667-0cde-433a-a4c4-4055d3567928_at_s12g2000prg.googlegroups.com... On Feb 11, 2:21 pm, "fitzjarr..._at_cox.net" <fitzjarr..._at_cox.net> wrote:
> On Feb 11, 12:55 pm, Ben <benal..._at_yahoo.com> wrote:
>
>
>
>
>
> > On Feb 11, 1:40 pm, Frank van Bortel <frank.van.bor..._at_gmail.com>
> > wrote:
>
> > > Ben wrote:
>
> > > > the application "runs" as a service on a windows machine with 10 or
> > > > so
> > > > threads. These threads seem to be getting killed or just dying off.
> > > > The problem compounds and gets faster as more of them die. So it
> > > > might take 10 hours for the first one to die, then 9 hours more for
> > > > a
> > > > 2nd one, then 6 hours more for the 3rd, then 2 hours for the 4th, 30
> > > > minutes more for the next, etc...
>
> > > > Once the last thread has died, all the users (40 or 50) lock up and
> > > > the service ( and / or ) server must be restarted.
>
> > > Sounds like a MS Windows restriction - Forms cannot run more that
> > > approx
> > > 80 sessions - check Metalink.
> > > Pre NT4.0, things were better... then Microsoft started optimizing.
> > > Some of those optimizations can be reversed by setting the "Allow
> > > service to interact with Desktop", even when it concerns a background
> > > process. Memory distribution (stack, heap) is changed.
>
> > > Care to give some information about what runs on the application
> > > server?
> > > --
>
> > > Regards,
> > > Frank van Bortel
>
> > > Top-posting in UseNet newsgroups is one way to shut me up
>
> > Don't know if I confused or not but I'm not referring to "Oracle
> > Application Server" ( I swear I'll learn to explicitly state that in
> > sometime soon ).
>
> > The Application that is running on a Windows 2K server is DCLink 4.2
> > from Data Systems International (DSI)- Hide quoted text -
>
> > - Show quoted text -
>
> Have you enabled client tracing through the sqlnet.ora file on the
> application machine? This could reveal much. And, then again, it
> could reveal nothing that you don't already know.
>
> It's worth a shot, though, in my opinion.
>
> David Fitzjarrell- Hide quoted text -
>
> - Show quoted text -

seems logical to do so, I've tried convincing others to allow it but they either don't think it's Oracle related or don't want the overhead.

That particular application is capable of running the previous version alongside the new version, according to DSI. So they have moved several of the users back into the previous version to see if they have the same problem and they do.
I'm with you though, I think if we turned on sqlnet client tracing it could very well show us some good information as to what is going on.

I guess I'm really curious as to if it is possible that sessions could be getting dropped by Oracle because of the SGA and I wouldn't see anything on my side.
The only scenario that I can think of where this would happen is if there is some kind of application time out that is being hit when transactions build up waiting for a library cache latch.

If the users "don't want the overhead" then this must not be much of a problem. I view the performance problem you have as much larger than any sqlnet tracing "overhead" could ever be.

The whole thing about not building the app with bind variables shows these developers are freshers. All commercial RDBMSs support bind variables. So the database agnostic crowd doesn't have an arguement there for not using them. Bind variables dramatically increase performance, stability, and scalability.
Jim Received on Tue Feb 12 2008 - 09:23:18 CST