Rajesh,

If your report is tied up doing things on it's side, formatting, format
triggers, formula and summary columns, etc, there could be some time before
the "client" (Reports) next communicates with the database. So, the wait
indicates the server is simply waiting for another instruction from the
client, in this case reports.

For diagnosing this, consider the use of PROFILE: Tools | Preferences |
Runtime Settings. You can also specify it on the command line. For details
on this option, while in Form Builder with the Preferences dialog box up,
click Help and then choose Runtime Settings, and the Profile. It describes
the type of information being captured, with the major points of interest
being how much time is spent on the DB side vs. Report side. There are other
things such as TRACE (Tools | Trace) that can let you see where time is
being spent within the report. Very helpful information.

It is possible, particularly with complex reports with lots of frames,
format triggers, page x of y (total number of pages), matrix reports, etc
for one of the performance bottlenecks to be the "formatting" of the report
itself. In the help system, under Contents | Tips and Tricks | For
Performance you can get more info and trouble-shooting performance issues as
well as many performance tips. I've always gotten the biggest bang for the
buck by tuning the SQL (if that was the problem), but at times we need to
"tune" the report itself.

Regards,

Larry G. Elkins
[EMAIL PROTECTED]
214.954.1781

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rajesh
> Dayal
> Sent: Tuesday, November 20, 2001 12:45 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Report waiting on SQL*Net message from client
>
>
> Hi All,
>       Hope someone can show me some light on this weird performance
> Issue.
>       One typical report at one of customer site is having major
> performance
> Issue. When I traced the session using event 10046 it shows major waits
> only
> on "SQL*Net message from client". Some other minor waits are present but
> they
> are negligible compared to the one mentioned.
> I am sure that this wait is not due to user input. It's difficult to
> imagine
> Network Bottleneck also, coz other parts of Application is running
> perfectly all-right.
>       After tkprofing it shows total elapsed time as 1.11 minutes for
> the whole
> report execution, while actually it takes around 7 minutes for
> executing. After
> tracing the events system/user wise it only shows, waits on event
> "SQL*Net
> message from client".
>       What could be reasons for this wait ( apart from user inputs,
> which is
> definitely not the case)?
>       Appreciate your time and suggestions.
>
> TIA,
> Rajesh
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Rajesh Dayal
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Larry Elkins
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to