RE: Wait event problems
Unfortunately, the original paper in DOC format is required to get any value out of the tests, and the doc isn't available at fors.com anymore (404 from the link). Does anyone have this (Doc 285 from EOUG '97)? TIA! Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -Original Message- > From: Deshpande, Kirti [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 2:24 PM > To: Multiple recipients of list ORACLE-L > Subject: 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 -- 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
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
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
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 mes
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 "rm"s 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 > la
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 "rm"s 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 >
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).
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 com
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
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: This > program's bottleneck is not the same as its system's system-wide > average > bottleneck. 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
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
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
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: This program's bottleneck is not the same as its system's system-wide average bottleneck. 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 (
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
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
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
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
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).
Wait event problems
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.
