Re: Program delays (Pro*C)

Looks like we have this almost solved....Whooosh.......... I switched to using dedicated connections instead of MTS and the problem went away. I can actually reproduce this almost on demand. Now that I have narrowed this down I did a quick google group search and found that there were very few but similar problems reported and ongoing. When I have a complete answer to this problem I will post it to the news group so that someone who comes looking for this can find it.

dilan

"Dilan" <dilan_at_example.net> wrote in message news:w0Pwa.41$s14.43700_at_news0.telusplanet.net...
> Hi,
> I am starting to look at this from the Net8 side of things. I have found
an
> article on Metalink (Note:73929.1) that comes close to describing a
solution
> to my problem. But we are using tnsnames.ora file to establish our
> connections. So whatever these "bequeath" protocols are I hope we are not
> using them. Is there a way to confirm this?
>
> thanks
> dilan
>
>
>
> "Mladen Gogala" <mgogala_at_adelphia.net> wrote in message
> news:pan.2003.05.15.13.00.02.781499_at_adelphia.net...
> > On Thu, 15 May 2003 06:31:05 +0000, Dilan wrote:
> >
> > > We have been experiencing some delays in a transaction intensive OLTP
> > > program written in COBOL running under Win2K. After narrowing it down
to
> an
> > > embedded sql statement EXEC SQL COMMIT WORK END-EXEC., to get more
> clarity I
> > > re-wrote the program in C. I was able to reproduce the delay in a
block
> of
> > > code that the Pro*C pre-compiler generated for the embedded SQL
> directive
> > > "EXEC SQL COMMIT WORK." The line reads
> > >
> > > "sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);".
> > >
> > > Looks harmless, but has anyone seen anything like this before. Are
there
> any
> > > name resolution operations, potential timeouts around this function
> call.
> > > The longest delay I have seen is about 62 seconds.
> > >
> > > TIA
> > > Dilan
> >
> > Well, SQLLIB calls are not documented, so I cannot help you there.
> > Have you monitored the database side? Any problems there? What does
> > v$session_wait show during that wait? Do you have a gigantic log_buffer
> > that gets filled and then you have to wait for LGWR to write all of it
> > down to something slightly slower then a 5.25 floppy? If not, database,
> > there is also the network component. Any problems there? Have you tried
> > pinging the box?
> > If the database is 9i, set event 10046, level 10 in your session
> > (dbms_system.set_ev will do the trick) and analyze the resulting trace
> > file with tkprow, wait=yes. If you have good reflexes, monitor
> > gv$session_wait as well.
> >
> >
> > --
> > Mladen Gogala
> > Software is like sex, it is better when it is free.
> > Linus Torvalds
> >
>
>
Received on Sat May 17 2003 - 01:46:41 CDT