RE: Wait event problems
Well, with all the caveats that's a long and boring story, so I'll shorten it up. ;) 1) SDU/TDU values of 32768, as were specified by our 3rd-party vendor in their extremely non-OFA f'd-up install, are not valid. 2) Specifying SDU/TDU in TNSNAMES.ORA (or ONAMES) is useless unless it's corresponding value is also in the server's LISTENER.ORA. If you don't specify the value in LISTENER.ORA, you will be using the default SDU value of 2048. 3) Specifying SDU/TDU in a LISTENER.ORA will not work out-of-the-box in 8i. I've verified this thru a client trace. Apparently, in 8i, the automatic registry of an instance to the listener will overwrite any SDU/TDU values specified in the LISTENER.ORA. The workaround to override the auto registry, you must declare a bogus SERVICE_NAMES and LOCAL_LISTENER in the DB's init.ora and restart the instance. 4) What value to set SDU? Test! On a TEST client set an SDU value in the TNSNAMES.ORA (see Oracle docs for how/where). Then, set the following in the client's SQLNET.ORA: TRACE_LEVEL_CLIENT = SUPPORT TRACE_FILE_CLIENT = sqlnet TRACE_DIRECTORY_CLIENT = /some/directory TRACE_UNIQUE_CLIENT = on 4a) If you aren't using TNSNAMES, make sure your NAMES.DIRECTORY_PATH in the SQLNET.ORA starts with TNSNAMES. 5) Connect a test client. Do some work from this client, preferrably as close to a real user as possible. Note that the tracefile created will contain every bit from every packet sent to and from the client, as well as all the overhead involved for debugging, so the file can grow large quick. It only less than 5 minutes of testing to produce a 55MB trace file for us. 6) Disconnect the test client. Before running trcasst, you'll need to edit the trace file in order to workaround a bug in trcasst. If you're Unix-y, you can use this instead of trying to pull 50+MB into mem (VERY crude SED -- there's a much more elegant way of doing this!): mv sqlnet_.trc t.t sed -e 's/nspsend: /nspsend:/g' t.t t.tt rm t.t sed -e 's/nsprecv: /nsprecv:/g' t.tt t.t rm t.tt sed -e 's/nsprcvs: /nsprcvs:/g' t.t t.tt rm t.t rm sqlnet_.trc mv t.tt sqlnet_.trc The rms are in there to reduce the amount of disk needed. PLEASE adjust for your own environment! If you're using Winders, get CygWin to use sed (or use any of a number of tools for search/replace). 7) trcasst -od sqlnet_.trc sqlnet_.lis 8) Examine the .lis file for send/receive packet sizes. I dumped the output from a grep of the .lis file to MS Exhell to graph the send and recieve packets. It's easier for me to see the need for a larger SDU when the graph shows a nice square wave pattern. The theory being that if SQL*Net is pushing the maximum SDU size several packets in a row (a nice, flat horizontal line at the top of the graph), that the SDU could stand to be larger so as to minimize the length of that line. 9) Repeat steps 5 thru 8 with different values of SDU, remembering to change both the client and the server, and to restart the listener after each change. Anyone care to comment on this? This is pretty much just what I figured out yesterday, so I'm interested to know of any whoopses I may have made. One thing I'm not sure of is How big is too big for an SDU value?. HTH! GL! Happy Flag Day! :) Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- From: Seefelt, Beth [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 7:28 PM To: Multiple recipients of list ORACLE-L Subject: RE: Wait event problems Hi Rich, I'm curious, what value did you decide on for SDU? Let us know how it works out. Thanks, Beth -Original Message- Sent: Thursday, June 13, 2002 1:39 PM To: Multiple recipients of list ORACLE-L Hi Lee, I'm investigating a very similar problem on 8.1.6.0.0 on Solaris. So far, I've found out that the 3rd-party vendor who setup this debacle had inserted invalid values for SDU/TDU in tnsnames.ora on the client and listener.ora on the server. I'm correcting them now as we speak. (Incidentally, Oracle recommends NOT modifying TDU and gives no guidelines as to how to select a value.) Also, our clients are Java apps, which would be my guess as to the root of the problem. The clients just aren't fast enough to deal with the rather large overhead of Java. But I'm cautiously optimistic on the SDU/TDU fix... And www.fatcity.com doesn't want to respond, so we'll have to wait a bit to search the archives. GL! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- Sent: Thursday, June 13, 2002 10:23 AM To: Multiple recipients of list ORACLE-L All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem
RE: Wait event problems
Excellent information! Thanks for taking the time to write it all down. Beth -Original Message- Sent: Friday, June 14, 2002 10:42 AM To: '[EMAIL PROTECTED]' Cc: Seefelt, Beth Well, with all the caveats that's a long and boring story, so I'll shorten it up. ;) 1) SDU/TDU values of 32768, as were specified by our 3rd-party vendor in their extremely non-OFA f'd-up install, are not valid. 2) Specifying SDU/TDU in TNSNAMES.ORA (or ONAMES) is useless unless it's corresponding value is also in the server's LISTENER.ORA. If you don't specify the value in LISTENER.ORA, you will be using the default SDU value of 2048. 3) Specifying SDU/TDU in a LISTENER.ORA will not work out-of-the-box in 8i. I've verified this thru a client trace. Apparently, in 8i, the automatic registry of an instance to the listener will overwrite any SDU/TDU values specified in the LISTENER.ORA. The workaround to override the auto registry, you must declare a bogus SERVICE_NAMES and LOCAL_LISTENER in the DB's init.ora and restart the instance. 4) What value to set SDU? Test! On a TEST client set an SDU value in the TNSNAMES.ORA (see Oracle docs for how/where). Then, set the following in the client's SQLNET.ORA: TRACE_LEVEL_CLIENT = SUPPORT TRACE_FILE_CLIENT = sqlnet TRACE_DIRECTORY_CLIENT = /some/directory TRACE_UNIQUE_CLIENT = on 4a) If you aren't using TNSNAMES, make sure your NAMES.DIRECTORY_PATH in the SQLNET.ORA starts with TNSNAMES. 5) Connect a test client. Do some work from this client, preferrably as close to a real user as possible. Note that the tracefile created will contain every bit from every packet sent to and from the client, as well as all the overhead involved for debugging, so the file can grow large quick. It only less than 5 minutes of testing to produce a 55MB trace file for us. 6) Disconnect the test client. Before running trcasst, you'll need to edit the trace file in order to workaround a bug in trcasst. If you're Unix-y, you can use this instead of trying to pull 50+MB into mem (VERY crude SED -- there's a much more elegant way of doing this!): mv sqlnet_.trc t.t sed -e 's/nspsend: /nspsend:/g' t.t t.tt rm t.t sed -e 's/nsprecv: /nsprecv:/g' t.tt t.t rm t.tt sed -e 's/nsprcvs: /nsprcvs:/g' t.t t.tt rm t.t rm sqlnet_.trc mv t.tt sqlnet_.trc The rms are in there to reduce the amount of disk needed. PLEASE adjust for your own environment! If you're using Winders, get CygWin to use sed (or use any of a number of tools for search/replace). 7) trcasst -od sqlnet_.trc sqlnet_.lis 8) Examine the .lis file for send/receive packet sizes. I dumped the output from a grep of the .lis file to MS Exhell to graph the send and recieve packets. It's easier for me to see the need for a larger SDU when the graph shows a nice square wave pattern. The theory being that if SQL*Net is pushing the maximum SDU size several packets in a row (a nice, flat horizontal line at the top of the graph), that the SDU could stand to be larger so as to minimize the length of that line. 9) Repeat steps 5 thru 8 with different values of SDU, remembering to change both the client and the server, and to restart the listener after each change. Anyone care to comment on this? This is pretty much just what I figured out yesterday, so I'm interested to know of any whoopses I may have made. One thing I'm not sure of is How big is too big for an SDU value?. HTH! GL! Happy Flag Day! :) Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- From: Seefelt, Beth [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 7:28 PM To: Multiple recipients of list ORACLE-L Subject: RE: Wait event problems Hi Rich, I'm curious, what value did you decide on for SDU? Let us know how it works out. Thanks, Beth -Original Message- Sent: Thursday, June 13, 2002 1:39 PM To: Multiple recipients of list ORACLE-L Hi Lee, I'm investigating a very similar problem on 8.1.6.0.0 on Solaris. So far, I've found out that the 3rd-party vendor who setup this debacle had inserted invalid values for SDU/TDU in tnsnames.ora on the client and listener.ora on the server. I'm correcting them now as we speak. (Incidentally, Oracle recommends NOT modifying TDU and gives no guidelines as to how to select a value.) Also, our clients are Java apps, which would be my guess as to the root of the problem. The clients just aren't fast enough to deal with the rather large overhead of Java. But I'm cautiously optimistic on the SDU/TDU fix... And www.fatcity.com doesn't want to respond, so we'll have to wait a bit to search the archives. GL! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- Sent: Thursday, June 13
RE: Wait event problems
FWIW I tried mucking around with the SDU/TDU parameters on both the client and the server and never got much success. Tried to up the 2K to 8K but it still was sending alot of 2k packets. I had more results upping the array size to 90-100 in glogin (default is 15). Kathy -Original Message- Sent: Thursday, June 13, 2002 6:53 PM To: Multiple recipients of list ORACLE-L This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 10:08 AM Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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: Tim Gorman 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). Confidential This e-mail and any files transmitted with it are the property of Belkin Components and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kathy Duret 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
Re: Wait event problems
Hello, There are many theoretical things about tuning SDU/TDU. But, I don't think tuning SDU/TDU makes benefit in practice. Kathy Duret wrote: FWIW I tried mucking around with the SDU/TDU parameters on both the client and the server and never got much success. Tried to up the 2K to 8K but it still was sending alot of 2k packets. I had more results upping the array size to 90-100 in glogin (default is 15). Kathy -Original Message- Sent: Thursday, June 13, 2002 6:53 PM To: Multiple recipients of list ORACLE-L This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 10:08 AM Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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: Tim Gorman 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). Confidential This e-mail and any files transmitted with it are the property of Belkin Components and/or its affiliates, are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not one of the named recipients or otherwise have reason to believe that you have received this e-mail in error, please notify the sender and delete this message immediately from your computer. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Kathy Duret INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing
RE: Wait event problems
Here is an old paper from an Oracle analyst discussing SDU/TDU settings... http://www.fors.com/eoug97/papers/0285.htm. I never came across any upgraded version of the same. - Kirti -Original Message- Sent: Friday, June 14, 2002 2:01 PM To: Multiple recipients of list ORACLE-L Hello, There are many theoretical things about tuning SDU/TDU. But, I don't think tuning SDU/TDU makes benefit in practice. Kathy Duret wrote: FWIW I tried mucking around with the SDU/TDU parameters on both the client and the server and never got much success. Tried to up the 2K to 8K but it still was sending alot of 2k packets. I had more results upping the array size to 90-100 in glogin (default is 15). Kathy -Original Message- Sent: Thursday, June 13, 2002 6:53 PM To: Multiple recipients of list ORACLE-L This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Deshpande, Kirti 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).
Re: Wait event problems
The database server is waiting for the client. The client could be Oracle Reports --- thus you are running a report which does some calculations in the report before executing the next SELECT on the server. Hemant At 07:23 AM 13-06-02 -0800, you wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale 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).
Re: Wait event problems
Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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).
RE: Wait event problems
Ha ha, not quite but I think I know where the problem may lie. It does a lot of OS file handling between inserts. Thanks for that Lee -Original Message- Sent: 13 June 2002 16:44 To: Multiple recipients of list ORACLE-L The database server is waiting for the client. The client could be Oracle Reports --- thus you are running a report which does some calculations in the report before executing the next SELECT on the server. Hemant At 07:23 AM 13-06-02 -0800, you wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe 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).
Re: Wait event problems
You may want to search the archives of the list as well, I seem to recall Cary Millsap posting something not too long ago where they found that this idle wait event was a real problem. If you can't find it, I can try to dig it out of my files Rachel --- Jack Silvey [EMAIL PROTECTED] wrote: Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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). __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Rachel Carmichael 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).
RE: Wait event problems
SQL*Net more data from client is a probable indication that your application is passing huge SQL statements from the client to the server (very hard on your database performance for a number of reasons) instead of calling stored procedures. Cary Millsap Hotsos Enterprises, Ltd. [EMAIL PROTECTED] http://www.hotsos.com -Original Message- Lee - lerobe Sent: Thursday, June 13, 2002 11:08 AM To: Multiple recipients of list ORACLE-L Ha ha, not quite but I think I know where the problem may lie. It does a lot of OS file handling between inserts. Thanks for that Lee -Original Message- Sent: 13 June 2002 16:44 To: Multiple recipients of list ORACLE-L The database server is waiting for the client. The client could be Oracle Reports --- thus you are running a report which does some calculations in the report before executing the next SELECT on the server. Hemant At 07:23 AM 13-06-02 -0800, you wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hemant K Chitale 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). The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robertson Lee - lerobe 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: Cary Millsap 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).
Re: Wait event problems
I think Rachel is referring following email from Carry Millsap.. It is a really nice explanation of this issue Regards Rafiq I have an example for you (Anjo, I hope you won't mind). A prospect we visited once upon a time had been fighting a performance problem with an Oracle Payroll program. They knew what their problem was: very clearly, v$system_event was telling them that their overwhelmingly dominant system performance problem was waits for latch free. (Well, no it wasn't. It was waits for the Oracle Payroll program. ;) ) Actually, the v$system_event view indicated clearly that the top wait event was SQL*Net message from client (and some other SQL*Net % stuff), but of course every good DBA knows that you have to discard all the SQL*Net events because they are idle events. Three months of trying and failing to fix the problem led finally to a last-resort, desperation hardware upgrade. Twelve 700MHz CPUs became twelve new 1,024MHz CPUs. (Don't ask why waits for latch free was translated as need to upgrade CPUs.) And unfortunately, the Payroll program got *slower*. Not just seemed slower--*was* slower. After the upgrade failed to help, these guys finally let us come see them. We traced the Payroll process (10046, level 8), very carefully initiating the trace immediately after the initiation of the Payroll run, and very carefully terminating the trace immediately after the completion of the Payroll run. The key here is that every second of data in the trace file was a second of somebody's response time. The result was a really fun story. The thing ran in about 33 minutes. Here's a summary of what was in the session's trace file: Oracle Kernel Event DurationCallsAvg -- -- -- SQL*Net message from client 984.01s 49.6% 95,161 0.010340s SQL*Net more data from client 418.82s 21.1%3,345 0.125208s db file sequential read 279.54s 14.1% 45,085 0.006200s CPU service 248.69s 12.5% 222,760 0.001116s unaccounted-for27.73s1.4% latch free 23.69s1.2% 34,695 0.000683s log file sync 1.09s0.1% 506 0.002154s SQL*Net more data to client 0.83s0.0% 15,982 0.52s log file switch completion 0.28s0.0%3 0.09s enqueue 0.25s0.0% 106 0.002358s SQL*Net message to client 0.24s0.0% 95,161 0.03s buffer busy waits 0.22s0.0% 67 0.003284s db file scattered read 0.01s0.0%2 0.005000s SQL*Net break/reset to client 0.00s0.0%2 0.00s -- -- -- Total 1,985.40s 100.0% Well, waits for latch free accounted for only 1.2% of the total response time. If the DBAs had been completely successful in eliminating latch free waits from their system, it would have made only a 1.2% difference in the runtime of this program. Point 1: emphasisThis program's bottleneck is not the same as its system's system-wide average bottleneck./emphasis This happens all the time. You can NOT see this type of problem when you look only at system-wide average statistics. You probably didn't pay much heed to the first thing you should have noticed: slightly more than 70% of this program's runtime was consumed by so-called server idle time. ??! You can't ignore this time, even if people do call it idle. Idle or not, this time was part of someone's response time, so we need to deal with it. Now if we hadn't collected our statistics so carefully (with proper time scope and proper program scope), then we would have seen probably much more SQL*Net message from client time in our data. If you make that particular collection error, then you *have* to disregard the so-called idle wait time. What was the Payroll program's problem? A couple of things. First, we knew that the Payroll program was running on the same host as Oracle. But the latency per call on the SQL*Net message from client event looked suspiciously LAN-like (order of 10ms), not IPC-like (order of 1ms or less). So we checked the tnsnames.ora file. Turns out that to conserve administration effort, the DBAs had decided to use a single tnsnames.ora file system-wide. So the Payroll program was using the same TCP/IP protocol that the system's PC clients were using. Just by switching the protocol to BEQ instead of TCP in the db server's tnsnames.ora file (a change that took about 15 minutes to test, 20 seconds to implement, and about a week to navigate through change control), we eliminated about 50% of the program's runtime. Next, what's with the SQL*Net more data from client? The developers of this particular Payroll program did a pretty bad thing in their code: they passed several really long (10KB) SQL texts
RE: Wait event problems
Hi Lee, I'm investigating a very similar problem on 8.1.6.0.0 on Solaris. So far, I've found out that the 3rd-party vendor who setup this debacle had inserted invalid values for SDU/TDU in tnsnames.ora on the client and listener.ora on the server. I'm correcting them now as we speak. (Incidentally, Oracle recommends NOT modifying TDU and gives no guidelines as to how to select a value.) Also, our clients are Java apps, which would be my guess as to the root of the problem. The clients just aren't fast enough to deal with the rather large overhead of Java. But I'm cautiously optimistic on the SDU/TDU fix... And www.fatcity.com doesn't want to respond, so we'll have to wait a bit to search the archives. GL! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- Sent: Thursday, June 13, 2002 10:23 AM To: Multiple recipients of list ORACLE-L All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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).
Re: Wait event problems
This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 10:08 AM Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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: Tim Gorman 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).
Re: Wait event problems
yep, that's the one --- Mohammad Rafiq [EMAIL PROTECTED] wrote: I think Rachel is referring following email from Carry Millsap.. It is a really nice explanation of this issue Regards Rafiq I have an example for you (Anjo, I hope you won't mind). A prospect we visited once upon a time had been fighting a performance problem with an Oracle Payroll program. They knew what their problem was: very clearly, v$system_event was telling them that their overwhelmingly dominant system performance problem was waits for latch free. (Well, no it wasn't. It was waits for the Oracle Payroll program. ;) ) Actually, the v$system_event view indicated clearly that the top wait event was SQL*Net message from client (and some other SQL*Net % stuff), but of course every good DBA knows that you have to discard all the SQL*Net events because they are idle events. Three months of trying and failing to fix the problem led finally to a last-resort, desperation hardware upgrade. Twelve 700MHz CPUs became twelve new 1,024MHz CPUs. (Don't ask why waits for latch free was translated as need to upgrade CPUs.) And unfortunately, the Payroll program got *slower*. Not just seemed slower--*was* slower. After the upgrade failed to help, these guys finally let us come see them. We traced the Payroll process (10046, level 8), very carefully initiating the trace immediately after the initiation of the Payroll run, and very carefully terminating the trace immediately after the completion of the Payroll run. The key here is that every second of data in the trace file was a second of somebody's response time. The result was a really fun story. The thing ran in about 33 minutes. Here's a summary of what was in the session's trace file: Oracle Kernel Event DurationCallsAvg -- -- -- SQL*Net message from client 984.01s 49.6% 95,161 0.010340s SQL*Net more data from client 418.82s 21.1%3,345 0.125208s db file sequential read 279.54s 14.1% 45,085 0.006200s CPU service 248.69s 12.5% 222,760 0.001116s unaccounted-for27.73s1.4% latch free 23.69s1.2% 34,695 0.000683s log file sync 1.09s0.1% 506 0.002154s SQL*Net more data to client 0.83s0.0% 15,982 0.52s log file switch completion 0.28s0.0%3 0.09s enqueue 0.25s0.0% 106 0.002358s SQL*Net message to client 0.24s0.0% 95,161 0.03s buffer busy waits 0.22s0.0% 67 0.003284s db file scattered read 0.01s0.0%2 0.005000s SQL*Net break/reset to client 0.00s0.0%2 0.00s -- -- -- Total 1,985.40s 100.0% Well, waits for latch free accounted for only 1.2% of the total response time. If the DBAs had been completely successful in eliminating latch free waits from their system, it would have made only a 1.2% difference in the runtime of this program. Point 1: emphasisThis program's bottleneck is not the same as its system's system-wide average bottleneck./emphasis This happens all the time. You can NOT see this type of problem when you look only at system-wide average statistics. You probably didn't pay much heed to the first thing you should have noticed: slightly more than 70% of this program's runtime was consumed by so-called server idle time. ??! You can't ignore this time, even if people do call it idle. Idle or not, this time was part of someone's response time, so we need to deal with it. Now if we hadn't collected our statistics so carefully (with proper time scope and proper program scope), then we would have seen probably much more SQL*Net message from client time in our data. If you make that particular collection error, then you *have* to disregard the so-called idle wait time. What was the Payroll program's problem? A couple of things. First, we knew that the Payroll program was running on the same host as Oracle. But the latency per call on the SQL*Net message from client event looked suspiciously LAN-like (order of 10ms), not IPC-like (order of 1ms or less). So we checked the tnsnames.ora file. Turns out that to conserve administration effort, the DBAs had decided to use a single tnsnames.ora file system-wide. So the Payroll program was using the same TCP/IP protocol that the system's PC clients were using. Just by switching the protocol to BEQ instead of TCP in the db server's tnsnames.ora file (a change that took about 15 minutes to test, 20 seconds to implement, and about a week to navigate through change control), we eliminated about 50% of the program's runtime. Next, what's with
RE: Wait event problems
Hi Rich, I'm curious, what value did you decide on for SDU? Let us know how it works out. Thanks, Beth -Original Message- Sent: Thursday, June 13, 2002 1:39 PM To: Multiple recipients of list ORACLE-L Hi Lee, I'm investigating a very similar problem on 8.1.6.0.0 on Solaris. So far, I've found out that the 3rd-party vendor who setup this debacle had inserted invalid values for SDU/TDU in tnsnames.ora on the client and listener.ora on the server. I'm correcting them now as we speak. (Incidentally, Oracle recommends NOT modifying TDU and gives no guidelines as to how to select a value.) Also, our clients are Java apps, which would be my guess as to the root of the problem. The clients just aren't fast enough to deal with the rather large overhead of Java. But I'm cautiously optimistic on the SDU/TDU fix... And www.fatcity.com doesn't want to respond, so we'll have to wait a bit to search the archives. GL! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA -Original Message- Sent: Thursday, June 13, 2002 10:23 AM To: Multiple recipients of list ORACLE-L All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich 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: Seefelt, Beth 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).
Re: Wait event problems
Sorry, Tim is exactly right. Got this confused with the SQL*Net message from client event. Need to stop drinking more Budweiser and start drinking more Guiness. At least, that is what *I* am taking away from this experience. ;) jack --- Tim Gorman [EMAIL PROTECTED] wrote: This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 10:08 AM Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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: Tim Gorman 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). __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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).
RE: Wait event problems
I would add that the Statspack's Top 5 events miss out other SQL*Net related waits. Those can not be ignored in the client/server type environments. I fiddle with the perfstat.stats$idle_event table that contains a list of such 'idle' events. The events in this table are never reported by statspack in the 'Top 5' category. And that can be misleading. - Kirti -Original Message- Sent: Thursday, June 13, 2002 8:53 PM To: Multiple recipients of list ORACLE-L This is never an idle event. The phrase more data from client indicates that the individual SQL operation is larger than a single SQL*Net packet. No big deal; it happens all the time, and SQL*Net handles it with continuation packets. Only issue is that the client is taking a lot of time between each packet sent. Jack's conclusion that the client process (in the client-server database connection) is not providing data in a timely fashion is exactly correct. You most likely have a slow client process... Oracle documentation frequently tries to encourage mucking about with SDU/TDU parameters in SQL*Net configuration files, but I've rarely seen this be more effective than tuning the client process... :-) - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Thursday, June 13, 2002 10:08 AM Lee, This is an idle wait event, meaning that the query process is waiting on instructions from the client. Usually this process is benign, but sometimes can indicate that the feeding process is not providing data in a timely fashion. hth, jack silvey --- Robertson Lee - lerobe [EMAIL PROTECTED] wrote: All, Oracle 8.0.5.0.0 Tru64 v4.0f We are running a job and statspack reports show that our only problem (it is running like a dog) is the following SQL*Net more data from client. Done some reading and still none the wiser. Anyone else had this sort of problem and if so how did you get around it ?? Regards Lee The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message or any copy of it from your computer system. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jack Silvey 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: Tim Gorman 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: Deshpande, Kirti 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).
