| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Configure SDU and TDU parameters to improve Performance
Stephen,
Thanks for the info. I have lot of soft parsing. I have setup CURSOR_SHARING to SIMILAR. I am planning to increase the value for SESSION_CACHED_CURSORS to solve soft parsing problem.
Thanks
Muqthar
-----Original Message-----
From: Stephen Andert [mailto:StephenAndert_at_firsthealth.com]
Sent: Thursday, April 29, 2004 3:21 PM
To: Muqthar.Ahmed_at_decoratetoday.com; oracle-l_at_freelists.org
Subject: Re: Configure SDU and TDU parameters to improve Performance
Muqthar,
I have done some work with configuring SDU and TDU, but not with RAC. To tune SQL*Net-related waits, you can take one of two approaches (or both):
Approach 1: Make SQL*Net communication more efficient. This can be done the way you are suggesting. In my experience, the time invested in this resulted in a very minor (almost unmeasurable) improvement that might have been caused by other factors. Increasing network bandwidth and similar activities also fall into this category.
Approach 2: Reduce the SQL*Net traffic. For example, if you are parsing a lot, look at cursor sharing and cursor utilization (Steve Adams has some good scripts for this). Reducing parsing will reduce network traffic and make remaining traffic more efficient. Reducing unecessary network traffic would also help this as well.
Good luck.
Stephen Andert
>>> Muqthar.Ahmed_at_decoratetoday.com 04/29/04 08:08AM >>>
Hi,
I have a RAC system of 3 nodes with 7 webservers (clients). I would like to configure SDU/TDU parameters at client level to improve the performance.
Reference:
Note:69591.1 "SQL*Net Performance Tuning in Applications"
Note:44694.1 "SQL*Net Packet Sizes (SDU & TDU Parameters)"
The STATSPACK output is:
Avg
Total Wait wait
Waits
Event Waits
Timeouts Time (s) (ms) /txn
---------------------------- -----------------
---------------- ---------------- -----------------
SQL*Net more data to client 172,456
0 6 0 13.6
SQL*Net break/reset to clien 685
0 0 0 0.1
SQL*Net message from client 728,623 0
34,884 48 57.3
SQL*Net more data from clien 34,055
0 5 0 2.7
SQL*Net message to client 728,626
0 1 0 57.3
NODE2
SQL*Net more data to client 208,574
0 19 0 15.5
SQL*Net break/reset to clien 10
0 0 0 0.0
SQL*Net message from client 852,229 0
36,419 43 63.5
SQL*Net more data from clien 41,220
0 7 0 3.1
SQL*Net message to client 852,234
0 2 0 63.5
NODE3
SQL*Net more data to client 112,425
0 8 0 16.3
SQL*Net break/reset to clien 18
0 0 0 0.0
SQL*Net message from client 462,005 0
20,244 44 66.9
SQL*Net more data from clien 22,418
0 5 0 3.2
SQL*Net message to client 462,009
0 1 0 66.9
Statistic
Total per Second per
Trans
---------------------------------
------------------------ ---------------------
----------------------
NODE1
SQL*Net roundtrips to/from client 725,847
769.7 57.1
bytes received via SQL*Net from c 188,354,007
199,739.1 14,822.9
bytes sent via SQL*Net to client 546,604,076
579,643.8 43,016.0
NODE2
SQL*Net roundtrips to/from client 852,882
916.1 63.5
bytes received via SQL*Net from c 224,478,043
241,115.0 16,722.1
bytes sent via SQL*Net to client 654,527,562
703,037.1 48,758.0
NODE3
SQL*Net roundtrips to/from client 462,472
496.8 67.0
bytes received via SQL*Net from c 122,075,296
131,122.8 17,671.6
bytes sent via SQL*Net to client 353,129,083
379,300.8 51,118.9
Any recommendations??????
Cary,
Last week I have received your book in the mail. I started reading and I am in chapter 4........the concept about performance is completely different. Some of the examples / scenarios about managers / developers / end users you mentioned are so true.
Thanks
Muqthar Ahmed
Database Administrator
DecorateToday.com
The information contained in this E-mail message is privileged,
confidential, and may be protected from disclosure; please be aware that
any other use, printing,copying,
disclosure or dissemination of this communication may be subject to
legal restriction or sanction. If you think that you have received this
E-mail message in error, please
reply to the sender and delete it from your computer. Thank you.
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- * * * * * * * * * The information contained in this E-mail message is privileged, confidential, and may be protected from disclosure; please be aware that any other use, printing,copying, disclosure or dissemination of this communication may be subject to legal restriction or sanction. If you think that you have received this E-mail message in error, please reply to the sender and delete it from your computer. Thank you. ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Apr 29 2004 - 15:59:58 CDT
 |
 |