X-Received: by 10.50.112.10 with SMTP id im10mr13759533igb.2.1391054295228; Wed, 29 Jan 2014 19:58:15 -0800 (PST) X-Received: by 10.50.30.169 with SMTP id t9mr222521igh.2.1391054295138; Wed, 29 Jan 2014 19:58:15 -0800 (PST) Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!195.71.90.67.MISMATCH!news.unit0.net!news.glorb.com!c10no5135914igq.0!news-out.google.com!vg8ni1igb.0!nntp.google.com!c10no5135905igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.databases.oracle.server Date: Wed, 29 Jan 2014 19:58:14 -0800 (PST) In-Reply-To: <752cfcd9-b397-4838-826f-a955be32110b@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=203.202.124.168; posting-account=oJZDiQoAAAD-FXU2V1mvdIjuYivOHSlr NNTP-Posting-Host: 203.202.124.168 References: <752cfcd9-b397-4838-826f-a955be32110b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9cbd4166-23ba-499f-b25e-65e9d51bb295@googlegroups.com> Subject: Re: Significant difference in response times for same query running on Windows client vs database server From: Noons Injection-Date: Thu, 30 Jan 2014 03:58:15 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.cambrium.nl On Thursday, January 30, 2014 11:15:20 AM UTC+11, mjm...@gmail.com wrote: > Are there are configuration changes that can be done on the Oracle client or database to improve the response times for the query when it is running from the client? I don't think you are after an improvement in response time. Rather a marked improvement in total runtime. Don't know what product you're using on the client. SQL*Plus or similar? If so, look into "array size". As well, you may need slightly different TNS parameters for the connection. But the first cab off the rack is to increase the size of the array. Which basically defines how many result rows come across for every interaction between the client and the db server. Here: http://docs.oracle.com/cd/E11882_01/server.112/e16604/ch_eight.htm#sthref927 There are a few other points raised by your message but I won't go into them now.