From oracle-l-bounce@freelists.org  Wed Jul  7 17:15:05 2004
Return-Path: <oracle-l-bounce@freelists.org>
Received: from air189.startdedicated.com (root@localhost)
 by orafaq.com (8.11.6/8.11.6) with ESMTP id i67MEeL01448
 for <oracle-l@orafaq.com>; Wed, 7 Jul 2004 17:14:50 -0500
X-ClientAddr: 206.53.239.180
Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180])
 by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i67MEU601418
 for <oracle-l@orafaq.com>; Wed, 7 Jul 2004 17:14:40 -0500
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP
 id AF52672C34E; Wed,  7 Jul 2004 16:55:51 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18500-77; Wed,  7 Jul 2004 16:55:51 -0500 (EST)
Received: from turing (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP
 id 0A72F72C319; Wed,  7 Jul 2004 16:55:51 -0500 (EST)
Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 07 Jul 2004 16:54:30 -0500 (EST)
X-Original-To: oracle-l@freelists.org
Delivered-To: oracle-l@freelists.org
Received: from localhost (localhost [127.0.0.1])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id E32DD72C138
 for <oracle-l@freelists.org>; Wed,  7 Jul 2004 16:54:29 -0500 (EST)
Received: from turing.freelists.org ([127.0.0.1])
 by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 18500-53 for <oracle-l@freelists.org>;
 Wed,  7 Jul 2004 16:54:29 -0500 (EST)
Received: from owa.metratech.com (mail.metratech.com [199.171.52.172])
 by turing.freelists.org (Avenir Technologies Mail Multiplex) with SMTP id 97F9F72C0FE
 for <oracle-l@freelists.org>; Wed,  7 Jul 2004 16:54:29 -0500 (EST)
Received: from ex2003.metratech.com ([10.10.100.18]) by owa.metratech.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 7 Jul 2004 18:18:20 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: RE: v$sql problem
Date: Wed, 7 Jul 2004 18:18:19 -0400
Message-ID: <D6424CD4C8A3C044BBC49877ED51C5187D9258@ex2003.metratech.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v$sql problem
Thread-Index: AcRkb3iiCc6fh1C1RheUfBGmirh/+gAAIR+Q
From: "Harvinder Singh" <Harvinder.Singh@MetraTech.com>
To: <oracle-l@freelists.org>
X-OriginalArrivalTime: 07 Jul 2004 22:18:20.0013 (UTC) FILETIME=[4F2499D0:01C46470]
X-Virus-Scanned: by amavisd-new at freelists.org
X-archive-position: 4602
X-ecartis-version: Ecartis v1.0.0
Sender: oracle-l-bounce@freelists.org
Errors-To: oracle-l-bounce@freelists.org
X-original-sender: Harvinder.Singh@MetraTech.com
Precedence: normal
Reply-To: oracle-l@freelists.org
X-list: oracle-l
X-Virus-Scanned: by amavisd-new at freelists.org

session_cached_cursors =3D 0
cursor_space_for_time =3DFALSE

These are the only 2 sessions using the database and they both are able =
to find same insert statement in memory and not try to parse new insert =
statement but only problem is not updating the execution column =
properly.

-----Original Message-----
From: oracle-l-bounce@freelists.org =
[mailto:oracle-l-bounce@freelists.org] On Behalf Of Tanel P=F5der
Sent: Wednesday, July 07, 2004 6:12 PM
To: oracle-l@freelists.org
Subject: Re: v$sql problem

> I am testing the insert performance into a table from 2 sessions both
> reading from same table. I am inserting in a batch of 1000 rows at a
> time and in 1 session we are inserting 1000 batches so total 1M rows
> inserted. Also we are doing commit after every 1000 rows. When I check
> the view v$sql and run statement from only 1 session it shows =
executions
> as 1000 (for 1000 batches) and increment in 1000 for each run. But =
when
> I run both sessions concurrently it only increases the execution by =
1010
> instead of 2000. Is this the normal stats or it is not showing =
execution
> stats properly?

I think Oracle is doing latchless updates to these execution counts to =
avoid
contention/performance issues, that's how few of the incrementations =
might
get lost. However, losing nearly half of the updates seems somewhat =
unlikely
for a two session operation, so there might be some other issues.

Btw, what's your session_cached_cursors and cursor_space_for_time
parameter's values? And which version/platform?

Tanel.


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

