The 'SQL*Net message to client' event accounts only for the time required to push a very small amount of data (typically only 1 byte) onto a file descriptor. The duration of this event rarely exceeds a few microseconds. There's no network latency counted in this event's duration at all. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com * Nullius in verba * Upcoming events: - Performance Diagnosis 101: 5/7 Dallas, 5/18 New Jersey, 6/22 Pittsburgh - SQL Optimization 101: 5/3 Boston, 5/24 San Diego, 6/14 Chicago - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details... -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Khedr, Waleed Sent: Friday, April 30, 2004 11:19 PM To: oracle-l@xxxxxxxxxxxxx Subject: RE: CPU upgrade caused application slow down Imagine you have a session that does a Nested Loop using an index and = the results are being sent over the network. If total bytes the needs to be sent is B and the bandwidth is W and the = time of execution is T: Then data pushing rate is B / T W is constant. If B / T is < W then transfer time will be B / W=20 Now using faster CPU's T is smaller which causes B / T to be bigger = value plus the machine is capable of processing more sql requests in the = same time. I'm not sure if this could be reflected as some <sqlnet/data to client> = wait event. -----Original Message----- From: zhu chao [mailto:chao_ping@xxxxxxxxxxx] Sent: Friday, April 30, 2004 11:54 PM To: oracle-l@xxxxxxxxxxxxx Subject: Re: CPU upgrade caused application slow down Hi, Waleed: That is what I do everytime I reorgnized a table. The table that got reorgnized was an IOT table with Overflow segment. After table = recreated, I move overflow segment to make it sorted. One more thing, the table is not a key table of the applications = running on this server, thoug the table is pretty big in size. I guess the difference in response time is from the network = layer.But I cannot prove it. No improvement in response is ok for CPU upgrade, as = CPU time is just part of the total response time, but it should not get longer:(, right? Thanks Zhu Chao ----- Original Message -----=20 From: "Khedr, Waleed" <Waleed.Khedr@xxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Saturday, May 01, 2004 11:26 AM Subject: RE: CPU upgrade caused application slow down > Wondering if you have one major index that gets used most of the time = =3D > using range scan. > If this is true, then reorganizing the table might have damaged a = little =3D > bit the clustering factor. > > If this is the case, then loading the table sorted on the columns used = =3D > by that index should help a lot. > > Regards, > > Waleed ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------