Re: Common large wait events

Douglas Cowles <dcowles_at_us.ibm.com> wrote:

>#1 waits in many systems on our site appears to be
>SQL*Net message to client...

I would think this means that Oracle has completed the request from the client and is waiting for the next request. Nothing strange about this - the major amount of time spend by the client application is to "interface with the user" and not "talk to the database".

Only batch type system usually deal solely with a lot of "talk to the database". Any interactive online system spends more time "talking with the user".

>SQL*Net more data to client...

This means that the client's request has been completed and the client notified. The client needs now to request the data from Oracle. Either single row fetches or array fetches. Either way, there's data waiting to be delivered and Oracle is waiting for the client to say when and how much.

>And in a system
>where all that's being executed is a stored procedure accessing
>a DB/2 gateway with no other sessions... exactly who is the client
>we are waiting on.. the gateway?

Yes.

>How about in a system such as Peoplesoft or Applications.. is there
>a difference in the significance of that event? (where there is no
>gateway).

No. How could there be? The Oracle database kernel does not know the difference between client system 1 or 2, or gateway for DB2 or gateway for SQL-Server or gateway for Informix. From the database engine perspective they are all the same, subject to the same rules and events.

>Is this generally the most popular wait in most systems?

Popular? I doubt that any event can be called "popular" in Oracle. :-)

I would say that in any online system is only natural to see a large number of "waiting for client requests". Not a symptom of a problem, simply the way things are. And not unique to Oracle either. This is a characteristic of any "interactive" server system - from databases, to NNTP server, POP server, SMTP server, web server, telnet server/daemon, etc. They all usually spend more time waiting than serving.

One way around this is to open a single dedicated connetion per transaction on the client, and then immediately close it after completion of the transaction. But then that defeats IMO the whole concept of fast client-server online systems. More is lost than gained by using single dedicated per transaction connection.

regards,
Billy Received on Wed Jun 07 2000 - 00:00:00 CDT