RE: Configure SDU and TDU parameters to improve Performance
- From: Muqthar Ahmed <Muqthar.Ahmed@xxxxxxxxxxxxxxxxx>
- To: 'Stephen Andert' <StephenAndert@xxxxxxxxxxxxxxx>,Muqthar Ahmed <Muqthar.Ahmed@xxxxxxxxxxxxxxxxx>,<oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 29 Apr 2004 16:49:55 -0400
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@xxxxxxxxxxxxxxx]
Sent: Thursday, April 29, 2004 3:21 PM
To: Muqthar.Ahmed@xxxxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx 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
---------------------------- -----------------
---------------- ---------------- -----------------
---------------
NODE1
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.
----------------------------------------------------------------
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
-----------------------------------------------------------------
* * * * * * * *
*
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@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
-----------------------------------------------------------------
Other related posts:
